On Adopting Agile Development
We are slowly moving from a traditional waterfall software development process to a more agile one. We are looking to adopt scrum without going all the way to extreme programming (XP). As a first step we are looking to go to an iterative waterfall model. In this case we adopt agile iterations, but then do a mini-waterfall in each iteration. This would be a first step to learn some of the ideas of agile, rather than biting off too big a process change at once and risking chaos.
The waterfall method of software development has been around a long time, and many successful products have been developed using it. However it does have a number of drawbacks:
1. It relies heavily on all the requirements being defined upfront and then complete accurate specs being developed before coding begins. Practically speaking this has turned out to be humanly impossible. Requirements change as market conditions evolve. No one can review a large spec and ensure that something hasn’t been missed, or gone in a bad direction.
2. The handover from programming to QA leads to huge scheduling problems. You can schedule how long to code something (at least relatively) and how long to perform functional tests. But how do you schedule how many bugs will be found? How long to fix those? How long to retest these? How long QA is delayed because they are blocked by these bugs?
3. Combining 1 and 2, practically speaking the worst design defects are found in QA when it is quite expensive to fix these. Again this tends to be un-sheduleable work and usually is the cause of the biggest product delays.
Agile looks to fix these problems (and many more besides). The idea is to keep units of work manageable without requiring super-human powers. Another idea is that you don’t need the requirements up front, not do you need the specs up front (if at all). Some of the key ideas:
1. Break down requirements into small easy to manager “user stories”. This makes the requirements more customer focused and really forces functional decomposition right from the beginning. It then lets you prioritize these requirements and tends to limit designer gold plating.
2. All team members are involved for the whole project. There are no hand overs from one group to another. Traditionally these hand overs lead to delays (due to people not being available at the right time), defects due to misunderstandings, and lack of teamwork. With agile the design analyst, programmer, ucd specialist, QA person and product owner are always working together as a team through the whole process.
A lot of the rest of the Agile Development Process is then executing these ideas in a best practices type environment using the experience of previous teams. From the experience of others, leads to the scrum principles:
1. Short fixed length iterations (usually 2 or 3 weeks).
2. The product is “shippable” quality at the end of every iteration.
3. How to break down the user requirements, and pick the ones to implement in each iteration.
4. How to prioritize the requirements and handle things that go wrong, like too hard user stories, key team members on vacation, etc.
Generally many product groups have discovered that Agile Development Process’s are more productive (more features or products are developed), quality is higher and the process is more predictable. Probably the hardest thing with adopting Agile is just to forget all those practices taught in older Software Engineering courses in University and accept the newer methods.