- Immediate Risks
- Two Cautionary Tales
- Avoiding the Pitfalls
- A Final Reminder
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Two Cautionary Tales
A few years ago, I presented a seminar on test-driven development at a large testing conference. Many of the participants were "doing Agile." One in particular was having a very hard time. Her development group was rewriting a piece of core functionality from scratch in Java—a new language for them. They hired a group of Java coders and created a schedule with four-week iterations. Every four weeks, the developers were supposed to throw a chunk of code "over the wall" for the testers to test. The software was supposed to be developed in six iterations of four weeks each, with a final QA phase at the end.
The first iteration was two weeks late, and buggy. The second iteration was a week late (making the project now three weeks late), and completely buggy. The basic functionality didn’t even work, and it introduced a number of regression errors in the software, so the testers had to go rerun the original test plans for phase I. It didn’t take a crystal ball to foresee what the next five iterations would be like, and they weren’t good. Worse, the testing group was in trouble because they were the supposed bottleneck "holding up the Agile developers."
In other words, the organization tried the following:
- "Big bang" style software scheduling with a new staff in a brand-new language. (But hey, they had iterations!)
- Iterative development without automated tests.
- "Iterations" that delivered incomplete work products (for instance, software that wasn’t ready to release to the customer).
- Agile development while keeping the developers and the testers in separate buildings, with testing as an afterthought, verification activity.
You can probably guess the results; they weren’t pretty. That sad part is that Agile was blamed for the failure of the project. Here’s the real truth: New people, new processes, and new technologies throw realistic scheduling out of whack. By focusing on delivering working software early and comparing expected features completed to actual features delivered, Agile development provides feedback, which can allow a management team to make good decisions.
A second organization was having integration problems; specifically, problems with different versions of the same libraries on different products. When management heard the Agile pitch of "continuous integration," they were immediately sold, buying all of the developers copies of a famous book on Agile development. Management went to an iterative development standard, began daily standup meetings...and that was about it.
Without substance, the so-called Agile development conversion devolved into "work harder on tighter timeframes, with standup meetings." The developers still lacked direct contact with the customers and had requirements that were even more light, vague, and unverifiable.
Twelve months later and the team is basically back to square one. That’s not Agile; that’s "code and fix."