Have you ever met someone who has “Methodology Myopia”? The symptoms of this problem are that the person thinks that there is one particular methodology (whatever it might be – Agile, Waterfall, or something else) that is a universal solution for any kind of project you might have. This “one size fits all” approach many times results in people force-fitting a project to a methodology whether it fits or not and practicing that methodology rigidly without necessarily tailoring it to fit the situation. I believe that a better approach is to fit the methodology to the project and sometimes that might require blending elements of different methodologies together to fit the situation.
Why does this problem exist?
- Sometimes people only know one methodology. For example, for many years, project managers were heavily schooled in the Waterfall approach and there was no need to learn any other methodology.
- It takes a lot more skill to know how to tailor a methodology and/or mix-and-match elements of different methodologies to fit a situation. It requires knowledge of a broader range of methodologies and a deeper understanding of the principles behind the methodology rather than just the mechanics of how it is implemented.
- Sometimes people get so over-zealous about a particular methodology that they lose their objectivity and forget that any methodology has limitations and needs to be applied intelligently and tailored as necessary to fit a situation. For example, there are some agilists who are so zealous about Scrum that they completely reject any kind of more traditional plan-driven approach as obsolete and no longer relevant.
- Consultants often fan the flames of this fire by building the frenzy about a particular methodology or approach being the best thing possible because they are selling their services based on a particular approach or methodology.
In my book, I use the analogy of a Project Manager as a “Cook” versus a Project Manager as a “Chef” (credit for this original idea is due to Bob Wysocki). A “Cook” knows how to prepare a limited number of recipes and do it by the book – a “Chef” knows how to prepare a much broader range of recipes with different and more exotic ingredients and also knows how to create entirely new recipes when required. This is a major challenge for the Project Management profession today…we need more Project Managers who are “Chefs”, who know how fit a methodology or combination of methodologies to a given situation. Many times this will require learning how to blend seemingly disparate approaches like Agile and plan-driven methodologies in the right proportions to fit the situation. Any Project Manager who only knows how to do a traditional plan-driven project management approach based on Waterfall may be severely limited in their career options in the future.
This is a difficult challenge to take on because I don’t believe anyone has all the answers of how to go about blending Agile and traditional plan-driven principles and practices together in the right proportions to fit a given situation. That takes a lot of skill, there is no “canned” solution, and the knowledge of how to do that as well as what works and what doesn’t work in different environments is constantly evolving at this time. However, even though this is a difficult challenge to take on, it’s important to recognize that this problem does exists and begin to take action to resolve it.
For many Project Managers, this requires developing a very broad and deep knowledge of both Agile and traditional plan-driven project management approaches as well as some actual experience in to blending them together that goes well beyond what is covered in the PMI-ACP certification. And, for both Project Managers and agilists, it requires getting past many of the stereotypes, myths, and misconceptions that have polarized these two communities to begin to see how these seemingly disparate approaches can be complementary to each other rather than competitive with each other.
The original Agile movement started out as a revolution against the traditional Waterfall methodology which was viewed as very cumbersome, bureaucratic, and inflexible. The need for that revolution was absolutely correct – an Agile approach does offer many advantages where a more adaptive approach is needed; particularly in environments where the requirements are very uncertain and subject to change. However, as in many other revolutions, there’s often a tendency for The Agile Project Management Pendulum to swing too far in the opposite direction to make a correction.
In particular, a lot of polarization has developed between some people in the Agile community and people in the more traditional project management community.
- There are many agilists who are entrenched in their perspective that the only way to be “agile” is strictly “by the book” and that there is no need for project management at all – they see project management as a role rather than a set of principles that can be adapted to a broad range of different environments, just as the agile principles can also be applied to a broad range of different environments
- There are some project managers who are equally entrenched in thinking that traditional, plan-driven, control-oriented approaches are the only way to do project management and have not learned how to integrate an Agile approach into their overall toolkit
The pendulum has begun to swing back towards the middle a bit and there’s less polarization today than there was several years ago, but some of that bias still does exist on both sides of this fence. Some of the progress that has been made over the past few years has been:
- PMI has recognized the need for integrating an Agile approach with a traditional project management approach and has begun moving in that direction with the PMI-ACP (Agile Certified Practitioner) certification. Although it is a step in the right direction, it doesn’t go far enough, in my opinion. It doesn’t really address the larger question of how a project manager would go about blending together Agile and traditional plan-driven principles and practices in a real-world situation and what role a Project Manager would play in an Agile project to use this knowledge.Is the PMI-ACP certification PMI’s answer to the Agile CSM certification? That would imply that the goal of the PMI-ACP exam would be to compete with CSM and train project managers for the Scrum Master role and I don’t believe that makes sense at all. The only way it makes sense, in my opinion, is for a Project Manager to take on a higher-level role in larger projects that require blending together some traditional plan-driven and Agile principles and practices in the right proportions to fit the situation, but that role is somewhat undefined at this point and also not necessarily widely understood and accepted.
- As Agile begins to be utilized for larger and more complex, enterprise-level projects; there is an increased recognition in the Agile community that an Agile development process like Scrum that works very well at the team level doesn’t necessarily scale very well without some kind of overall management framework and several different frameworks have been developed to fill this need.
- The Scaled Agile Framework developed by Dean Leffingwell is an example of a relatively complete approach that incorporates higher levels of project and program management as well as project portfolio management into an overall framework that is fairly Agile from top-to-bottom; however, it is not easy to implement and would typically require a very major transformation for a company to adopt that kind of approach.
- For companies who want to integrate an Agile development approach at the team level into a more traditional management framework, the Managed Agile Development approach defined in my latest book and Scott Ambler’s Disciplined Agile Delivery framework are both alternatives that can be used in a more traditional management environment.
It’s time to get past the polarization that has existed in the past and begin to see Agile and plan-driven approaches as complementary to each other, rather than competitive. It’s not an “either-or”, “black-and-white” alternative to adopt an Agile or Waterfall approach as some people have portrayed it; it’s more of a continuous spectrum of alternatives offering different levels of control and adaptivity as needed to fit a given situation. That’s the challenge I’ve tried to take on in my two books on this subject.
The inter-relationship of people, process, and tools in an Agile project is important to understand. On several occasions, I’ve been brought in to rescue a project that was in trouble. In many cases, there is an expectation that, as a Project Manager, I will re-plan the project, get it on the right track, and perhaps also”ram-rod” the effort to get it moving through to completion if necessary. That’s the typical expectation of what a traditional Project Manager might do. I think the Agile environment is different…I’ve certainly seen a need to re-plan projects and get them on the right track and it often takes some strong leadership skills to do that; however, a more critical role in many cases in an Agile project is working on developing the right people, process, and tools to make the Agile project teams more effective and self-sufficient. The irony is that if you do that successfully, you might practically eliminate the need for a Project Manager and put yourself out of a job, but that’s the right thing to do. I think that’s a key difference in an Agile project – in a traditional project, the role of the Project Manager might normally be expected to continue all the way to the end in order to push the project on to completion.
I’ve seen several Agile projects that got into trouble because they didn’t have an adequate amount of upfront planning and, as a result didn’t have the right people, process, and tools to do the project successfully – this happens frequently in larger, enterprise-level projects because many people don’t understand or appreciate what it takes to scale an Agile development approach to an enterprise level. Here are a few examples of typical problem areas I’ve seen:
- People – It takes a lot more skill to organize a large, enterprise-level Agile project because the number and different types of people involved are typically a lot more numerous and complex. It can be a real challenge to figure out how to organize all of the people (both inside and outside of the project teams) to get the effort done successfully. For example, I’ve seen projects get in trouble because there was no Project Governance model defined to provide overall direction to the project. In many cases at an enterprise level, its not as simple as having a single Product Owner to provide direction and without a plan for how all of the stakeholders and decision-makers will participate in the project as it moves forward, it’s very easy for a project to go off-course and get in trouble.
- Process – In many cases, there’s also not a clear understanding of what it takes to scale an Agile process like Scrum to enterprise levels. There are typically layers of management needed above the team level and it has to be well-integrated with the company’s primary management structure. It may not be as simple as layering a Scrum-of-Scrums approach on top of a couple of Agile teams. There is also often a need to define a hybrid process that blends together some amount of traditional plan-driven project management at a higher level with an Agile development approach like Scrum at the team level.
- Tools – Tools also can be a major problem area. The tools that people many times use for small, simple Agile projects, just don’t necessarily scale well to larger, more complex, enterprise-level projects. For example, people might use physical story cards and white-boards for tracking progress of small, single-team Agile projects but those methods start to fall short very rapidly as you to try to scale the effort to larger, enterprise-level projects with multiple teams that need to coordinate with each other and may not be collocated. Managing that type of situation typically requires more sophisticated, on-line electronic tools.
I’ve been in situations where clients might not have the patience to address some of these more systemic issues involving people, process, and tools. In some cases, there might be an expectation that the Project Manager will just somehow “ram-rod” the project to get it moving and get it back on the right track but taking that kind of approach and ignoring the more systemic factors associated with people, process, and tools is not likely to be very successful. That’s equivalent to just putting pressure on a broken process to make it work better. A more effective approach in most cases is to fix the broken process.