Marathon in Sprints-Towards Sustainable Agility
Well, that’s the spirit of Agile. You sketch, you erase a few elements, sketch again and arrive at the final picture. To adapt is to survive.
Ask any self-respecting software firm about what development methodology they run within their organizations. And, then, ask if they’re happy with the outcome. You’ll be surprised with the range of answers. Most of these firms are still struggling with either the process, or the tool; most are not even getting the fundamentals right. Some give up and shift to a more fashionable methodology. Shifting to a new methodology, alone, is of little help. The real shift happens only when you appreciate the core, underlying principles of any methodology – be it Waterfall, Agile, or DevOps.
Where does process really help
“Prediction is very difficult, especially if it’s about the future.” (Niels Bohr)
The motivation to have any process in place is to ensure a predictable and reliable outcome. Two fundamental internal metrics to assess the outcome of any SDLC process are (i) delivery on time/budget, and (ii) delivered with quality. And, of course, the most important assessment criteria, which is oftentimes forgotten: will this delight the customer? Time, budget, and quality are relatively easier to assess – and software development methodologies, most notably Waterfall, have mastered the art of optimizing these parameters. The last one – customer delight – is harder to assess, and undoubtedly the most important criteria for any firm. To fine-tune the process, you need a crisp feedback loop – you listen, you learn, and then you adapt and tweak your processes a bit. The recent trends in software development methodologies – namely Agile and DevOps – address this customer feedback aspect more squarely than the earlier models. The mileages however vary.
Underlying principles – aspects of common sense
“Common sense is genius dressed in its working clothes.” (Ralph Waldo Emerson)
In Agile, and related, methodologies, a sprint is essentially a mechanism to encapsulate the KNOWN elements within a time-box and leave the unknowns outside this box. The more unknowns you leave outside, the more predictable your sprints will be. To a practitioner, this is what it implies:
• Product specs and user-interface designs should be available at the beginning of the sprint. This is the source of the biggest surprises and can potentially derail the entire sprint. In Agile, the user-stories must also include (i) the acceptance criteria (a move towards Behavior Driven Development), and (ii) the ROI metrics that need to be tracked and monitored.
• Insist on a quality dashboard that’s generated automatically and triggered on every build. QA automation, unit test coverage, and effective code reviews has to be built into the process from day-1. Doing this tightens the feedback loop – you know right away whether the code is functional and is of
• Insist on frequent demos – this is the real proof of the pudding and keeps the progress transparent for everyone. Another benefit of frequent demos is that you typically figure out the cross-module integrations much early on, which, in my assessment, is one of the biggest engineering risks.
What kills agility, and did we just forget these critical aspects
“The only source of knowledge is experience.” (Albert Einstein)
Here’s where the tooling support, people’s mindsets, and organizational mandates come in - the most complicated parts of the equation, and where Agile methodology frustrates practitioners the most.
• Fixed cost of manual QA that corrupts the sprint cycles and forces it to become more like waterfall. QA being left till the end is, by far, the single, biggest factor that kills agility – be it Waterfall, Agile,
• Long term planning – Most of the Agile tools don’t really help you plan the long-term roadmap, or address the long-term artifacts such as software architecture, infrastructure planning and complex resource dependencies. It’s best to have a longer-term roadmap within which the sprints fit. You need to have the big picture in mind before you focus on the
The long and short of it
“After changes upon changes, we’re more or less the same” (The Boxer, Simon and Garfunkel)
Software methodology falls in the practitioners’ realm. And only sensible practice makes it perfect. While every methodology has its own set of pros and cons what makes the real difference is to understand the fundamentals, choose a methodology that makes sense within your environment, and keep on fine-tuning till it starts yielding the right dividends.