April 23rd, 2014 by Adam Sandman
Conversations about Agile processes have become popular with the younger set as a rather trendy after work accessory along with micro-brewery beer and gourmet pub food. Waterfall software development processes are for those ‘older’ people who prefer an old-fashioned steak and some potatoes. Ok, so that might be a bit of an exaggeration, but there is no doubt that formal Agile methods are considered to be forward-looking software development processes, ahead of other methods in their sophistication.
But are Agile principles really as new as we like to think? Or is there something rather traditional about Agile development methods that we don’t particularly like to draw attention to? Are there aspects of Scrum that actually have echoes of methods now considered ‘yesterday’s ideas’? Is this all just a rehash of old concepts, dressed up to appeal to the jet set and sell more books?
One of the great things about Scrum is that we get to see the results of the initial sprint and make requirements, design and development changes based on what we see.
In fact, this is encouraged as a feedback loop so that we learn and improve, working towards a solution closer to the needs of the users. But hold on, that sounds like prototyping! Scrum wraps it up with some formality so that the prototype is a solid basis for further development, but it’s still prototyping. Each sprint results in a quality prototype that is the basis for the next iteration. Eventually, the final sprint should make the prototype production quality. No matter how you look at it, there’s a striking resemblance to prototyping.
Kanban has gained popularity with those wishing to join the Agile ‘club’ but who are afraid to take the plunge all the way; it lets the meek test the waters without making a full commitment. Kanban allows a project to pick off requirements in a piecemeal fashion whenever the resources at the start of the lifecycle become free. There are no iterations; work begins when we have the available effort and ends whenever the task gets done. Each functional area being implemented goes through the same stages of development, and these are repeated until the project has addressed all the necessary requirements. Maybe I’m being too simplistic, but this sounds like the spiral model, unwrapped and laid out flat.
Cross-functional teams are another important part of the Agile philosophy. Break down the silos between developmental disciplines, let the ideas flow, encourage innovation and encourage everyone to think ‘quality’. Well, yes, that’s rather how it worked way back when; before the rigor of the formal software process became the norm.
Now having said all this, I don’t want to give the impression that I’m anti-Agile development, (would that be ‘lumbering’ development?) because I’m not. I am not really the Agile cynic this might paint me as. But I don’t want to get sucked into the Agile vortex and get carried away with some of the hype that presents Agile methods as if nobody thought of these things before. The beauty of Agile development is that is takes the best of old ideas and improves on them. Agile is process reengineering. Every generation has ideas it claims as its own, but in truth, they are rarely anything truly original.