Category Archives: Agile Project Management

The Agile Project Management Pendulum

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.

Agile Project Management Pendulum

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.
    1. 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.
    2. 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.

People, Process, and Tools in an Agile Project

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.