Let’s say your team deploys a new software release every four weeks. (I’m a big fan of short release cycles. In fact, I think four weeks is too long but let’s try that.) On the surface, the team appears to be using an agile development approach. But let’s stir the pot a little.
What if I tell you that the team spends the first week of each cycle planning and designing? They have a rule stating that the content of the next release must be finalized during the first week. Change requests are allowed but usually deferred until the next cycle. They spend part of the first week documenting and designing the changes. (Hmmm, this “agile” approach is starting to show some wrinkles.)
The team implements the features that made the cut during weeks two and three. The developers perform unit tests and fix the defects they discover. Toward the end of week three, they package the software and deliver it to the quality assurance team. (At least, that’s how the process is supposed to work. At times, development runs late and spills over into week four.)
During week four (or what’s left of it), SQA tests the software and reports defects. If time allows, developers fix the defects and send another build to SQA for testing. If time doesn’t allow, the known defects are noted in the release notes and SQA testing spills over into the next cycle (or simply stops). Defects found beyond week four may not get fixed in the next cycle if they miss the week one planning window.
Iterative, yes. Agile, no!
I try to stay away from dogma. For example, ‘to be agile you must have daily standup meetings’ (the team has to stand or it doesn’t count). Or, ‘you can’t be agile if you use sprint zero, hardening sprints or any other technique that doesn’t focus on completing user stories’.
But there is one principle that I steadfastly maintain — to be agile, the business, development and SQA teams must collaborate. (In an ideal world, there would only be one team and collaboration would be simpler. The world is not ideal. Get over it.)
True collaboration must happen every day, not every fourth week. SQA should be testing new builds daily (you are doing daily builds, right?). The business should be actively involved in the development process daily (you told them they must be engaged in the effort, right?).
Iterative waterfall techniques work in some environments. If you absolutely, positively must use waterfall, please iterate. However, if you want to be agile, you must collaborate. There is no substitute.
photo credit: jaygoldman via photopin cc