Thoughtful software engineers and architects struggle between two extremes: traditional software development (i.e. often well documented, planned and executed) and agile development (i.e. often sprint driven, iteration focused). Each offers characteristics that drive the decision to select one approach over the other, however we all fail to communicate what we will not be getting because of our reasoning.

Booch has written about accidental architecture where the end product is a result of decisions that make the solution what it is, not what we might have intended it to be or how we would do it if we began again. This is a plague of almost any developer or architect. Given constraints, we create software and solutions and the result may or may not be viable shortly after delivery. Initial constraints may not be real (e.g., performance is more important than end-to-end user experience), and they are surly to change over time (e.g., mobile devices are irrelevant).

A recent article from UXMatters.com explores how UCD and agile might work better together. Clearly, if a small group of developers are to deliver working code in four weeks time, user centered design – all of user experience – will need to be working overtime prior to the start of development. This is counter to the idea that agile development iterates to deliver better software sooner. Waiting to deliver initial prototypes is similar to having a much larger process governing the flow of end-to-end solution development, do not look now, we are back at traditional software development. Cecil makes a point that it is possible to work better, albeit challenging – it takes a better collaboration between UX and development. I believe this is possible, but it actually takes the right attitude to make it work.

These general challenges have me wondering, “What is it that we are trying to achieve with more nimble methods of development?” One reason is that we want to get a preview of the possibilities without actually committing to a long drawn out process. This is critical in an innovation lab where no one is sure if the current prototype is the next big thing or just a nice experiment. Here in rubs the pain of innovation – “When will it be complete now that it is twitching?” The developers are often pleased at this point, bragging all the excitement that can be delivered from a 30 or 60 day development effort and yet the fun has just begun. They embark on the accidental architecture and the tough collaboration of creating a delightful end-to-end user experience under the pressure of delivering final software in another 30 days, after all it is an innovation team and the whole point is to be fast, right?

Everyone is always attempting to create software the right way the first time and that is where expectations are horribly wrong. We make decisions that trade one characteristic for another (e.g. great end-to-end experience for quicker initial deliver) but forget to revisit that executing the solution correctly, in a world-class manner, requires a moment of thoughtfulness to ensure the end solution, without course correction, will actually deliver value to users and the business. “Iterate often” is a good motto. It keeps everyone focused on delivering incrementally with less overall investment. Great user experience naturally causes rework in an iterative environment. The two processes do not align easily and it takes real work to produce stellar experiences. Patience among an entire team, to do the right thing distinguishes good from great. A place to start is remembering why we approached our work the way we have, to communicate it and ensure that it fits with changes in the environment (e.g. shifts in strategy, management or schedule). All too often, the delivery of an exciting technology drives the desire to deliver more maturity, faster and better without the thought that maybe regrouping actually delivers a bit slower, but with greater impact and longevity.