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.
“Look, we’ve been reviewing this feature… and it just isn’t right.” And yes, I am being cagey about what the feature is and who the person involved is. I have to live with these people.
“Okay, ‘not right’ how?”
“It doesn’t do what we think it should.”
“But it does what we said it would do.”
“Yeah, but …”
“It does what it did when we reviewed it last year.”
“Yes, but it’s not what we wanted.”
“It’s a little late to bring this up now, don’t you think?”
“I thought we were doing ‘Agile’ now. Can’t you just fix it? isn’t that what ‘Agile’ means?”
SmartBear Software Agile Solutions
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:
● reduce the overhead involved in building software
● while adapting to the way requirements change over time
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, and 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.”
Not “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.
About Charlie Martin
