Agile Development Isn’t Scrum or Kanban

When I was a little brat, my parents made a point of telling me to fast on Christmas Eve. That meant no meat until Christmas dinner, or I wouldn’t see the golden pig. I dutifully did it until I was ten. Then I realized that I was never going to see a pig, much less a golden one, and that I didn’t even know what it was supposed to look like. Most developers and managers have a similar relationship with agile development, or Agile. At best they picture Kanban or Scrum, or a particular technique such as pair programming or stand-up meetings. At worst they draw a blank or file it under “bullshit.” What they usually have in common is that they’ve seen everything in theory and nothing in practice, and at some point they stopped believing, just as I did with the golden pig. A cynic might add that both are lovely fairy tales.

In this article I’ll try to dispel the idea that practicing Scrum or Kanban leads to agile development. It’s about the same leap of logic as going from sex to conceiving a child. You can have oral sex, but you can hardly expect anyone to get pregnant from it. Agile development works much the same way. You practice Kanban and end up shipping a product twice a year with zero added value for the customer. At least somebody enjoys the oral sex. All you get from botched agile development is a frustrated customer and a bunch of pissed-off developers. Two people can do the same thing and get very different results.

Let’s ask a simple question. Did agile development exist before methodologies like Kanban were introduced? Of course it did. We just didn’t call it that. Techniques that grew popular over time, such as pair programming and test-driven development, probably existed before anybody thought to turn them into a set of rules. So if agile development existed before anyone tried to fit it into the confines of, say, Scrum, it follows that you can do it without blindly applying Scrum. To be fair, Scrum and Kanban are of course both flexible and designed to be adapted to context, as plenty of agile experts will tell you. What matters is how it works, whatever you call it.

Please take a pencil and a piece of paper, or find some other way to write down what agile development means to you.

Got it? Excellent. We’ll need it in a minute.

For the next part of the exercise, choose the option you instinctively prefer, on the left or the right, in each of the following statements.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

If you prefer what comes before “over,” you’re in the right frame of mind to let go of any stereotypes about agile development. If you prefer what comes after it, you still believe in the golden pig, so to speak. In any case, I didn’t just make those statements up. They come from the Agile Manifesto, an essential document for understanding agile development. In the same document you’ll find 12 simple principles that define agile development.

1. Our highest priority is to satisfy the customer by delivering valuable software early and continually.
2. We welcome changes to requirements, even late in development. Agile processes use change to help the customer become more competitive.
3. We deliver working software every few weeks or months, with a preference for shorter intervals.
4. Business and development people must work together daily for the life of the project.
5. We build projects around motivated individuals. We give them the environment and support they need and trust them to do good work.
6. Face-to-face conversation is the most effective and efficient way to convey information to a development team and within it.
7. Working software is the primary measure of progress.
8. Agile processes support sustainable development. Sponsors, developers and users should be able to maintain a steady pace indefinitely.
9. Continual attention to technical excellence and good design improves agility.
10. Simplicity, the art of maximizing the amount of work left undone, is essential.
11. The best architectures, requirements and designs emerge from self-organizing teams.
12. The team regularly reflects on how to become more effective and adjusts its behavior and practices accordingly.

How much of what you wrote down about agile development fits these principles? The twelve say nothing about Scrum, nothing about having a daily stand-up meeting, and nothing about how to put them into practice. The comparison is even more interesting if you’re trying to use Scrum or Kanban. If you are, ask yourself whether you actually work this way.

At GoodData, we spent several years trying to do agile development. Unfortunately, we went through Scrum and later Kanban and mostly failed. The problem wasn’t either methodology. We had never said that the way we actually wanted to work was by those twelve principles. That was the goal. Scrum or Kanban may or may not be a way to reach it. Agile development only started to work once we focused on the principles themselves. Spare yourself the same mistake. Focus your efforts on working by those simple principles, whatever methodology you use. You’ll end up doing agile development for real instead of pretending and kidding yourself.