I went to see a bad chiropractor a few months ago and his approach diminished my (already quite skeptical) perception of this medical practice. His outright dismissal of conventional medicine and biased view that chiropractic treatment is the only true solution to all ailments turned me away from him and from any benefits I may have found by continuing with his treatment.
I am not comparing agile methods to alternative medicine, instead I’m just pointing out that zealots who fail to acknowledge alternative views can do a lot to damage their profession. As proponents of agile methods, I believe we can make a stronger case for agile by acknowledging strengths of traditional approaches and explaining how agile can help common challenges, rather than by dismissing traditional techniques.
Encouraged by other recommendations, I visited a different chiropractor and received great benefit. He did not attempt to undermine traditional medicine, instead he explained how he might be able to help and we took it from there. My symptoms got worse before they got better, but I stuck with it since his explanations seemed reasonable. My “conversion” moment came when he also relieved some additional injuries I had been suffering with for many years.
I do not think I am alone in appreciating a considered approach. Most of the people I deal with in the business community are smart, conscientious professionals who are looking for successful projects. Yet, we see the actions of zealots and as a believer it is easy to be caught up in their damaging behaviour.
The following list outlines some common examples of how biased thinking can undermine the value of agile methods and offers some advice to ambassadors of agile methods for avoiding these pitfalls.
Dismissing the Waterfall Process
The waterfall process as originally outlined by Winston Royce in 1970 actually contains some really good advice. For a start it recommends that the waterfall process always be run at least twice for a project because you will not get everything right the first time. Also that there should be regular feedback loops and checks along the way to ensure things are working correctly. Take a look, here’s a reprint of the original 1970 paper, look at page 7.
Agile ambassadors could do better to offer agile as a solution to single pass waterfall challenges on software projects rather than a superior approach period.
Running down the PMI, PMPs and the PMBOK
The PMI is a large organization and like all large organizations has its problems. The PMBOK Guide is a victim of its own success; it is not intended to be a “how to run projects” guide, heck it is not even written for the software industry. Instead it is an industry agnostic set of project management basics; a starter kit of standards from which to build guidelines and management frameworks to fit your own project environment.
I teach a two day agile project management course as part of the PMI SeminarsWorld training program and the PMP project managers who attend are smart and inventive. None blindly follow the PMBOK Guide, instead they run projects with the most pragmatic mix of tools and techniques they know of.
Agile Ambassadors could do better by fully understanding the content and strengths of traditional PMI / PRINCE2 offerings before suggesting other tools for software projects with high rates of change.
Obsessing on Agile Processes
Measuring conformance to agile principles, debating “agile” vs “Agile”, declaring a group more agile than another is somewhat oxymoronic. At the root of agile methods is a focus on delivering business value and removing non-value adding, “compliance” activities (waste) wherever possible. In terms of delivering valuable working software to business, debate and measurement of agile conformance are just waste.
Agile Ambassadors could do better by focusing on pleasing customers by delivering amazing software. “You have one tongue in your head and two in your shoes, use them in those proportions.” Focus on building great software and do not get drawn into non-value adding work or debates.
Claiming agile methods are the new way to develop software
There is little if anything new about the techniques promoted by agile methods. Short iterations, story cards, pair programming, test first, empowered teams, the list of reused processes goes on and on. Craig Larman did a great job of tracing the history of today’s agile techniques back as far as the 1950’s in his book “Agile and Iterative Development: A Manager’s Guide”. What the agile movement has done is collect and popularize grouping of techniques that work well on software projects – which is tremendously valuable.
Agile Ambassadors could do better by recognizing the contributions from many previous approaches and focus on the benefits of their combination over claiming to be the latest, new thing.
As the Agile 2007 conference approaches I am looking forward to learning more again, but am also a little hesitant about the hype and “ zealot speak”. Belittling other approaches reduces the set of people who will be willing to listen to you and demonstrates a “scarcity” mentality towards ideas. The middle-way between agile and traditional is a whole lot messier, and more complex, but ultimately more useful too.