Agile software development practices in the Mechanical Analysis Division

From a software user’s perspective it really doesn’t matter exactly how that application was developed. A user is concerned with functional capability (what the software does), non-functional performance (how the software behaves) and ultimately their personal experience when using the software. Those tasked with creating the application though need to meet such user expectations whilst working within time, quality and resource constraints. The software development industry has undergone quite radical changes over the last 10 or so years in the methods used to produce sellable product. Moving away from classic waterfall developments methods, a whole slew of what are termed agile development practices have emerged. Indeed an entire industry of terms and tools have themselves grown up around what is essentially an (agile) attitude towards developing software product.

The industrial revolution, from around 1750 to 1850, saw the rapid mechanisation of existing industries and manufacturing processes. Entrepreneurial innovation in Great Britain heralded new technologies that bought about cultural changes on which most of western culture today is based. As a species, we became much better at making things, lots of things and quickly. Wind the clock forward another hundred years and it comes as no surprise that, in lieu of any other established approach to making things, software development adopted the same regimented processes as were required to make physical product.

The so called waterfall approach describing this process entails a sequential series of activities. The requirements, defining what it is that is to be created, are fully documented, reviewed, signed off and cast in stone. This then leads into a design stage where it is determined how the product is to be built, the implementation is the actual making of it, verification the testing of it to ensure it meets the requirements and finally maintenance of that product. The mechanical infrastructure required to manufacture a physical product is itself a large investment and one that does not suffer change well. As such it’s critical that the requirements do not change throughout the process for that would require costly tooling adaption. In the absence of any other alternative it was this process that was applied to software development from the 1950s onwards.

So what’s inherently different in building a software product compared to a physical one? I think it comes down to tooling, the cost and time of re-tooling. Compiling, linking and building an executable software application is cheap. Unlike the physical equivalent where (compiling and) building only repeats the creation of a single product design, the process of software building can lead to different products each time, the only change in the design is implicit in the changed source code. To do that for a physical product would require massive re-tooling costs. Not having to suffer that cost of re-tooling for different design can radically change the way in which the software product itself is refined to meet the requirements.  Many interim, iterative, prototype variants can be quickly created and verified. In the context of change; changing market pressures and opportunities, changing competitive product landscapes, changing of available software technologies, such an ability to evolve your product concurrently is an opportunity not to be missed. This puts to bed the idea of change being something to fear, an unplanned distraction that should be ignored, a costly change of direction. Embracing change as a natural part of the product development process requires your ability to adjust to it. This requires agility in your development processes.

There are a few established agile development processes about. Back in 2003 when we were developing the first version of FloTHERM PCB, we decided to pioneer the use of SCRUM. The small agile team was able to get the first version out under time and under budget. It was a revelation and one that we’ve adopted and adapted ever since. It’s now used to drive all FloTHERM and FloVENT development. From my perspective there are a few key aspects to the approach. The following isn’t a complete list, but the ones that have struck a chord with me over the last 9 years…

• Bite size chunks. All development tasks are broken down into small ‘one liners’, tasks that take no more than say 2 or 3 days. That task is performed (code written), the feature acceptance tested, any defects are fixed there and then, the user documentation updated. All done and dusted. (On a long walk it’s sometimes better to look at the ground directly in front of you as opposed to the horizon)
• Commit one month at a time. SCRUM involves sprints. Often 4 weeks duration. The team decides what tasks to attempt to complete that month. At the end of that, planning for the next sprint is the opportunity to be agile in what you decide to attempt for the next sprint. It’s the monthly opportunity to change or adapt direction.
• Process heavy, document light. A well written, detailed, reviewed and signed off requirements document is indicative of an effective development practice. Utter crap, no it’s not. When working in a high context environment where you know everyone well, have done for years, why not capitalise on the effectiveness of talking, interacting by the water cooler, discussing, theorising, imagining? Document only what you have to and no more than that.
• Constant client representation. As a product manager I take the role of the customer (user) representative in our agile team. We talk daily, formally weekly and in detail at the end/start of the sprint process. The team never has the chance to start to go ‘off piste’ and deviate away from what the customer requires.
• Ready for release often. This is the key for me. The process mentality should be one of concurrent activities; implement, test, fix, document the bit size chunks before going onto the next. Bugs don’t build up. The software is usable often. After all, you wash up the dishes after each meal at home, not at the end of the week.
• Working prototypes. I can’t determine how a large feature should work in totality, a priori. I’m pretty good at virtually prototyping the user experience of a new capability in my head, but not that good. Product managers feed off working prototypes and that’s what agile gives you, frequently. Working with the team we can effectively balance the desirable with the achievable, iteratively.

Sure, agile has issues. I don’t think it works well with distributed teams. There’s the ongoing issue of how do you get a good design if you don’t know where you’re going. But no argument I’ve heard is strong enough to consider any other alternative.

11th June 2012. Ross-on-Wye.