Agile. That’s it. Agile. The perfect project management tool or methodology. You can use it in general project management. You can use it in software project management. Don’t Google it as you will get confusing things like agile project management and Scrum. You just want to be agile. Look it up in the dictionary. That is a much better source for the methodology.
So is this a change from my original position in The Ultimate Project Management Tool? No, they are complimentary. You pay attention and based upon that attention you – with agility – make changes as needed.
OK, yes, this is way too simple and I am being a bit facetious. So, why did I even bring it up? Is there a perfect project management methodology, tool or approach (software, IT, construction, health care, defense, financial, supply, etc.)?
Many people seem to think so. It comes in various names, acronyms and forms (Scrum, XP, PMI, CMMI, TSP, Prince2, Kanban, Lean etc.). If you have been managing for as long as I (30+ years) you’ve seen these come and go. I’ve also seen the hype come and go. I’m intrigued by the current hype around Agile. I’m a software and information technology (IT) guy so I pay the most attention to these fields. I personally love the agile software development approach called Scrum.
I’ve specialized in helping organizations move from late and low quality project deliveries to on time, high quality deliveries. Yet, I’ve never used one method. I’ve never used “my” method. I’ve always taken the current method of the organization and tweaked it to get them up to the next level of performance (usually to on time with good quality). I’ve never seen the adoption of an all new methodology that then solved the problems of an organization. Never. In almost every case, there were underlying — often cultural and political — problems that undermined the methodology being used and they had to be fixed first. While I was at the Software Engineering Institute, it was an often stated maxim that no tool or technical methodology was going to fix a dysfunctional organization.
So is Agile the perfect solution? I read a great article by Cyndi Mitchell in Software Development Times, March 15, 2010, titled “The half-agile path leads nowhere.” I knew Cyndi and I must be on the same wavelength as she used the term “grok.” We weren’t. Or at least, not yet. I figure in a few years, we will be.
Her article talked about how doing Agile completely will reap all sorts of benefits. How not doing it completely will result in failure. I’ve heard this before. In fact, I’ve heard it from just about every methodology and tool evangelist in the past 30 years. For consultants and vendors it was often the excuse why we didn’t see the 10x improvement (or whatever promise was made) when implementing their tool or methodology. We were told that if we just did a few more things right, the magic would suddenly appear. They were also ready and willing to help us do it, for a price.
However, I absolutely agree with Cyndi. The only difference is that we can take the word “agile” out of the article and replace it with just about any good methodology of our choice. My experience is that almost any methodology — when understood and executed well — will result in exceptional benefits. I know, because we’ve done it consistently for years.
Yes, I’ve seen techniques and methods that just didn’t have a sound basis. In particular, Theory X types where it assumes people are lazy, untrustworthy and need to be managed closely didn’t work well no matter how hard a group tried. I’ve only rarely seen an organization-wide approach with this problem. Generally we’ve experienced only individual techniques, often associated with individual managers, which had this flaw. Sometimes it was the VP — who asked us to help “fix” the issue — who was the source of the problem. In just about every case where I’ve dug into the failing methodology to understand it, I’ve been pleasantly surprised to find an innovative and interesting approach that had a lot of good reasons behind it (e.g., Motorola’s M-Gates). Using those reasons and “rediscovering” the methodology — while removing dysfunctional practices — were keys to our success.
For methodologies, I’ve seen many diverse approaches work and work well. For specific project and software management tools, not so much. This has been primarily because in trying to learn or adopt a tool, those organizations often get lost in the mechanics of the tool itself. Also, many tools add multiple features to try and make them look competitive or rich. Too often these other added features are just noise and not anything someone would want to use. In the consumer products industry we called these “table stakes.” These were things we had to include to even be considered by a customer. Many of these, we knew, were not great features but our customers insisted we have them because competitive products had them. They also looked good in advertisements.
For those in the Agile versus Waterfall project management debate, I will comment that I’ve never seen a perfect waterfall approach. It was always a goal, a worthy goal we thought, to achieve that perfect waterfall (i.e., once a stage was complete it was done perfectly and it never had to be revisited). I do find the Agile evangelists often talk about “Waterfall” as if there was some perfect canonical form and that anyone doing it was doing the same thing. Just as there is “Scrum … but” in Scrum, there was always “Waterfall … but” in Waterfall. “Scrum … but” is considered something negative, but for Waterfall, “Waterfall … but” was often an adaptation to make the “falls” more concurrent and iterative for an imperfect world.
I will offer that when we achieved excellence in software development, where we were making few mistakes — increasing productivity and hitting our milestones — the methodology we used inevitably evolved towards pure Waterfall from something that was almost always incremental (some said trial and error). Once a team got good at what they did, they didn’t want to waste time with iterations/increments and all the overhead. Pure Waterfall had almost no overhead — and we usually executed it using a concurrent engineering approach (i.e., if something could be started now, we started, even if we were still planning other areas).
The perfect project management method is the one we make work for us in our unique environment. The insight is that most well known methods, when understood and done well, will result in great project performance. The trick is to take our current approach and incrementally improve it to where we see the full benefits of our chosen methodology. Easy? No, but it is a project management tool that works.