On June 24th Mary Poppendieck gave a free talk at the IT University in Copenhagen arranged by BestBrains. The title of the talk was “Is Agile a Fad?” with the subtitle “Will Agile Software Development End Up On the Dumping Grounds of History?”. This dramatically titled talk gathered more than a 100 agile enthusiasts in a packed auditorium, and I spotted several members from Danish Agile User Group and Copenhagen Ruby Brigade, as well as both students and teachers from Copenhagen Business School and, of course, ITU.

Mary Poppendieck started her talk with a story about the dot-com bubble of the 1800’s: Plank roads. She ended the story by asking: Is agile development a plank road? Is agile development just another fad that gets everyone exited for a time, but doesn’t really solve anything in the long run? Poppendieck never really answered this question, but she went on to go through software development from the 1960’s up to our century, concluding that for each decade and each new software development paradigm, large software projects (over a year) was still late, over budget and full of bugs - even today this is the case. She did, however, point out that the opportunity to do small software projects (around 3 months) has increased greatly during these decades, and that large projects is falling out of favor.

Why is software development so hard to manage? Why have we passed through so many paradigms in such a short time span? Poppendieck had three theses on why this might be so:

Thesis 1: Silver Bullet Thinking
People has a tendency to believe that a certain process, method or tool is so great that it will magically solve the problems right away for anyone who use it. They tend to ignore the details of this silver bullet, and just try to apply it directly to their company or project while ignoring what the real world is like. When this happens, the “silver bullet” will just be a fad, and it won’t work.

Thesis 2: Different Contexts
Extremely different approaches to software development exists, from the very rigorous and structured to the very people-driven and agile, and both extremes and a lot between seem to work in different contexts. One approach might be good for one kind of software, but not necessarily for another kind of software. There is no single answer, no single method that works for all contexts.

Thesis 3: Essential Tension
There is an essential tension between getting started with development (coding) right away versus planning and spending time doing design and architecture. The first might get you fast results and early feedback, while the latter might save you from major refactoring and incoherent software. Spending time planning is good, but following a plan you created when you where most ignorant is not. Maybe there is a fundamental tension between these two poles, and maybe projects need to be in the middle, driven by essential tension.

Mary Poppendieck went on to describe how to fail with agile. She listed four mistakes that people are likely to do when trying to adapt agile processes, but she also listed four principles that should be followed to avoid these mistakes:

Mistake #1: Copy What Successful Companies are Doing
Poppendieck referred a lot to the book The Wisdom of Crowds, and quoted the notion of “the instinct to imitate” from book in connection with this mistake. If we let ourselves be influenced too much by existing practice, we will believe the same things are right and make the same mistakes. The solution is to maintain indepence and think for yourself. Don’t believe in all success stories, but look for the flaws and mistakes in them. Just because it is the textbook’s way of doing it, it doesn’t mean that way is good for you. You don’t get world class development by copying best practice, but by inventing it.

Mistake #2: Insist that Everyone Follow a Standard Process
Different people have different views of the world, and different processes will work best for them. For this reason, the agile process should draw on local knowledge, letting people fit the process to their needs locally and constantly improve this process. Again, there is no such thing as a “best practice” for everyone.

Mistake #3: Limit Agile Implementation to Software Development
Poppendieck quoted The Wisdom of Crowds for its notion of “the value of cognitive diversity”. Having a team with software developers only is not very diverse, so you need to gather a group of people from all parts of the organization - creative, testers, operations, etc. The solution is to widen the boundaries and accept that “IT” is part of “The Business” and not outside of it. The team should be responsible for business success, not just technical success, which has no value in itself.

Mistake #4: Avoid Tension
There is a natural tension, not just between programming and planning, but also between marketing people who wants the job finished right now, and developers who want to develop forever. Many other examples could be found. Tension, even conflicts, is what provides a balanced solution, and consensus decisions is nothing to strive for.

Mary Poppendieck concluded her talk by explaining, that if we want to make agile something more than a fad, we must recognize all three theses - stop silver bullet thinking, recognize different contexts and welcome essential tension - while avoiding the common mistakes.