Agile Software Development and Project Risk Management
By Jim Coyle Product Test Managerat Sage
If we go back ten years or so (a long time in the world of software development), nearly all Sage software teams worked to a process loosely described as ‘Waterfall’. This involved the creation of mandatory project deadlines, along with an unflinching determination to create a rigid, highly detailed plan, covering the best part of a year, and the heroic defence of this plan come what may. The plan ruled.
- Defending the plan became a goal itself (and what customer cares about our plans?)
- The world does not stand still once the plan is set
- Feedback on the product (including the test team feedback) was far too late
- More time was spent on documentation than delivering real value (aka software)
- Failure to accept changing requirements was not realistic and out of step with our customers’ needs
- In effect, risk was carried very late in the project timeline – almost setting up projects to fail
Once people realised the failings of Waterfall development, the switch to Agile processes was inevitable and involved a major cultural shift for the R&D teams:
- The emphasis switched from defending the plan to flexible planning (accepting change is inevitable and changing the plan accordingly)
- Fortnightly drops of working software became the sole measure of success – rather than documentation and PowerPoint presentations
- Agile processes encouraged early user feedback and test team participation
- Customer collaboration was forefront
- Individuals and their interactions was placed higher than processes / tools
- High risk / high value items are tackled first to front load risk. High risk / low value items are dropped
The result – our software success rate improved enormously. These days, to a large degree, our customers get what they want, when they want it, and with quality built in.
Is this a success story? Yes it is. Was the change to Agile seamless? No it wasn’t. There were challenges. Specific to the test team:
- Things change quickly. We need to keep on top of evolving requirements and change our test scripts and test data accordingly.
- A release of software every two weeks means testing can become a treadmill – there is constantly a new build to test
- Test automation becomes a necessity – this was a new skill to learn and make a reality.
- With so much change, we needed to work tightly with the development teams and Business Analysts or risk falling out of sync with what was happening
- Exploratory testing became a mandatory skillset – the ability to simultaneously learn / test / create test scripts and test data
- We became adept at reading UML diagrams (especially of use cases)
So – the switch to agile worked. And the speed of agile is gathering pace as we try to deliver our customers’ needs in shorter and shorter timeframes. Indeed, our latest Sage One Payroll product generates about five builds of working software a day (I may write about that in a separate blog).
But if we’re really honest with ourselves, the agile principles are not new – the goals above are hardly rocket science. But be gentle with us, software development is only about twenty-five years old. Construction has been around for more than five thousand!