The Challenges of Being Agile in a Project Manager's World

12 November 2013


During the course of the latter half of the last decade, the adoption of Agile as the de facto software development paradigm has gained significant momentum. As more and more clients demand increased visibility into the progress being made in a project and require that there be frequent checkpoints to respond to change, the adoption of Agile is no longer an option that organizations can ignore.

When it comes to large service-based organizations that have managers who have for years been entrenched in executing projects in a certain way, the situation at times is quite challenging. As discussed, since the clients demand following Agile and/or Scrum, companies might be tempted to put tools and practices together that create an impression of being Agile to an external observer. However, given deeply ingrained traditional project management practices, they might not actually be Agile.

One of the key principles espoused in the Agile Manifesto is to respect "People over processes." The Agile Manifesto, however, clarifies that this should not be construed to imply that processes do not matter. But the stress is certainly on "people." This is in stark contrast to what project managers have traditionally been trained to do. Traditional management (let's call it "legacy project management") lays a great deal of emphasis on having a predefined plan that conforms to certain organization-specific processes and tries to hold team members to the sword, based on that plan. Being groomed in a world in which plans and corresponding reports provide a false sense of control and security, the uncertainty and openness imbibed in following Agile makes them feel extremely uncomfortable.

Instead of using Agile for enabling and empowering teams, legacy project managers tend to skew Agile practices by using core Agile principles, like the daily stand-up, as instruments of micromanagement. They demand daily status reports, and instead of focusing on trying to remove the impediments that might have prevented a Scrum team member from completing a planned task, they try to corner people by pointing fingers during the stand-up. It is important for them to understand that in order to garner some sense of the consistent work that the team can produce, they need to accept some uncertainty and observe the team's velocity over at least three sprints. Once the team has settled down, both in terms of domain knowledge and technology, and once team dynamics have started panning out, prediction and planning might begin to lean more toward accuracy. For this to happen, one should encourage the team to be open and report the actual status so that empirical evidence, instead of expected results, drives future sprints and estimates lean more and more towards accuracy.

Agile, as explained by its founding fathers, is an approach that demands that team members be trusted that they are always doing their best. For this trust to be based in reality, it is of great importance that the project manager invest a significant amount of time in hiring the right team members. This, more often than not, is a catch-22 situation. Most service organizations derive their profits from the number of people working on a project. The stress on quality takes a backseat, as keeping a position open simply because the right candidate hasn't been identified leads to a direct hit to the profitability in the shorter term for the organization. Thus, organization policy in this case might incentivize these legacy managers to fill these positions up as soon as possible.

Lack of long-term vision and ignorance of the principles of Systems Thinking prevents such managers and organizations from looking at the fact over the longer run: People who do not belong to a certain threshold as required by the team are going to drag the team down, adversely impacting the velocity and times and turning the customer entirely off. Handing over control to the team to set the benchmark when it comes to hiring is off-putting for such managers.

The onus is on the organization to emphasize and enable a paradigm shift among its project managers, so that being Agile is required across all levels and so that questioning existing practices, having a client focus, and adapting instead of planning are encouraged. A project manager might better serve the customers, the organization, and the team by letting go of strategies that have more often than not failed in the past. This is, after all, one of the reasons that Agile seeks to replace traditional project management. Adapting to the requirements of the team and giving up trying to seek control are probably the most important traits for a successful Agile project manager.

Article Rating

Current rating: 4.4 (5 ratings)

Comments

ABHISHEK KUMAR SRIVASTAVA, CSM, 11/12/2013 10:02:53 PM
Nice article!
David Lowe, CSP,CSM, 11/14/2013 2:25:07 AM
It's a hard transition for old-school PMs to make. It's similar for the business too (what we call POs) as they have always been able to get a commitment on which to pass on blame to execs when anything goes wrong.

Hopefully the mass use of Scrum (and XP) is gradually going to help these two groups transition over to a more collaborative approach.
Robert Kalweit, CSM, 12/3/2013 7:02:16 AM
Sourabh, thanks for this wake-up call to traditional PMs feigning "being agile".

Also good mentioning the constraints on hiring principles: With agile a team of 4 team-work-enthusiastic Junior-Whatevers could achieve project success, where 4 "I'm the best" Senior-Whatevers might fail...

You must Login or Signup to comment.