A lot of people have claimed to adopt "Agile methods," when what they really mean is, "Oh we never liked all that software engineering discipline anyway." Real Agile methods mean more discipline: discipline in establishing requirements, discipline in setting schedules, and discipline in saying "No."
It started, as these things often do, with someone coming into my office. We're close to shipping a product after a long struggle with all the usual issues – hardware difficulties, operating system bugs, personnel changes – but we're beginning to see the light at the end of the tunnel without the chug-chug of an oncoming train.
But from the look on my colleague’s face, I knew it I wasn't going to like what he had to say.
Him: "Look, we've been reviewing this feature... and it just isn't right."
Me: "Okay, ‘not right’ how?"
Him: "It doesn't do what we think it should."
Me: "But it does what we said it would do."
Him: "Yeah, but ..."
Me: "It does what it did when we reviewed it last year."
Him: "Yes, but it's not what we wanted."
Me: "It's a little late to bring this up now, don't you think?"
Him: "I thought we were doing 'Agile' now. Can't you just fix it? Isn't that what 'Agile' means?"
I'm sure there are places in which Agile methods are adopted with general agreement and used with great success, but I don't seem to work for them. (I suspect the Evil Eye put on me as a baby.) Instead, I end up working in places where people learn the phrase "Agile methods" and think they sound cool, but they adopt only some of the window dressing – something I've called "cargo cult Agile." There's this general notion that as long as you do some of the things that "Agile people" do, you're using Agile methods.
What can be even more insidious, though, is when people think of "Agile" in terms what Agile methods don't do. Agile minimizes upfront design, so obviously you're being Agile if you eliminate upfront design. Agile minimizes process, so you just eliminate process.
The result is what Dilbert's boss summarized as "No more planning and no more documentation. Just start programming and complaining."
So that we do not get down into the weeds, let's look at Agile methods in terms of the Agile Manifesto. The guiding values of Agile, according to the manifesto, are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile methods, uniformly, work toward these values by reducing documentation to a minimum, shortening delivery cycles as much as possible, and defining requirements in customer terms with customer input. The idea here is to:
To guide development, every published Agile method has its own little proverbs and best practices, like "Do the simplest thing that can possibly work" and the SCRUM Planning Game. These are the keys:
- Don't do work you don't need.
- Be ready to respond quickly to changes.
But that's not the whole story. Let's look at the most extreme of Agile methods, Extreme Programming. The core of extreme programming is laid out in a page of simple rules – but now consider those rules.
- "User stories are written."
- "All code must have unit tests."
That's not the same as, "it would be nice to have user stories" or "code should have unit tests." It's all written in terms of rules that must be followed.
If someone wants a feature, it's described in user stories, scheduled in a release plan, coded including unit tests, and approved through an acceptance test. If no user stories are produced, then the feature never happens. If a customer asks for a last minute change, it shouldn't be squeezed in at the last minute; it becomes a new user story, and is taken up in another iteration.
The result is that when you start an iteration, you know exactly what is to be built in that iteration. You have an agreement for acceptance and you can measure effectively how close you are to completing the iteration.
This is discipline.
The problem is that discipline is hard. It means saying "No," and often you're saying No to your boss. No, you can't come on Thursday and get an additional feature on Friday; put it into the user stories and we'll schedule it. No, you can't shorten the schedule by two weeks unless you choose which user stories you don't need.
But that's discipline. Without it, you lose everything Agile methods promise. The key to Agile methods is this: You may have less process, but you must have more discipline.