Share →

I am currently working on a Team Foundation Server – Project Server integration engagement. If you talk to people in the ALM community, many of them think that is like trying to integrate a motorcycle with a truck. Sure, you could do it, but why would you want to? It begs the question, “Where do project managers and the PMO fit in an agile organization?” There are many in the agile community who have come to the incorrect conclusion that they don’t. To be perfectly honest, I used to believe that myself. However, my belief was based on experience with project managers who held literally and to the letter of the classic mantra of Project Management 101, “The project manager’s role is the overall responsibility for the successful planning, execution, monitoring, control and closure of a project.

The project managers I worked with interpreted their role as needing to “monitor and control” all work down to the individual developer task. The outcome of that approach is not agility. Instead of allowing agile teams to “self-organize,” this type of project manager unintentionally encourages inefficiency and deception by trying to nail down developers to a specific time frame for all listed tasks by assigning the time.

The inefficiency plays out according to Parkinson’s Law, “Work expands so as to fill the time available for its completion.” In other words, developers will continue to work on a task long after the 5 hours it should have taken because the project manager allotted 20 hours to complete it. The deception comes as a side effect of trying to track developer productivity and utilization. The developers will invariably start reporting 40 hours a week of development time regardless of how much time they really spent coding because it’s easier to report, and reporting the truth to the project management office makes them look like they aren’t being productive since they may only be writing code for four or five hours a day. The typical process looks like this:

PM: Hey, Dev, how long will it take to build widget A?
Dev to self:  I’m busy, but he’s back. That’ll probably take 2 days I can’t afford to lose right now. What can I say that will make him go away?
Dev out loud: About a week.
PM to self: They always say that. So, 2.5 weeks. I’ll make it 3.
PM out loud: Thanks, Dev. I’ll go write the specs now.

Sound familiar? So instead of it taking the developer 2 days, it will take 3 weeks and the developer will log 120 hours against the task.

The repercussions of this kind of PM/Dev relationship is that projects invariably take longer than they need to and the amount of value delivered is also invariably less than what it could be. So what’s the solution?
If an organization wants to deliver the most value in the least amount of time, project managers need to become more spectators than players when it comes to assigning, planning and scheduling tasks. Project managers need to be actively involved in value delivery, but at the appropriate level and that level is not the task level, it’s much higher. Agile project managers also need to redefine a key word in the above role definition; the word “control.” Agile project managers do not directly control the team, they support the team. They do this through a variety of ways, including monitoring and reporting on project health to stakeholders, upper management and even the team, just to make sure they are paying attention. However, it is critical in an agile environment that project managers resist the urge to assign and control at a low level.

The practical application of this role change for project managers is that they become more consumers of data than creators of it. From a technology standpoint, such as that provided by a TFS – Project Server integration, the project managers view the data provided by the development team as they add and update work items in TFS. The project managers rarely (if ever) assign tasks or determine task length. That is left entirely to the development team. What the project managers should concern themselves with is the progress of features in a release cycle. This is easily done by consuming the data from TFS. With this top down look at the work, project managers can track the percentage of tasks completed for a feature, identify lack of progress, bottlenecks and at-risk features. They can proactively assist the development team by helping to remove impediments or work with product owners to re-prioritize work. They also get a very real view in to how much work is actually involved in delivering a feature and therefore they can know the true cost of delivery.

I have recently had the pleasure of working with a couple of very talented project managers that understand agile principles and embrace them. As I worked with the development teams, these project managers were there every step of the way. They asked questions and provided feedback to the team about project goals and deliverables as well as target dates. They had learned not to ask the question “how long will that take?” Instead, they attended meetings and listened as the developers discussed the work that needed to be done. These project managers were a valued asset to the teams and in one case the project manager acted as the product owner for the scrum team which is a fairly natural fit in many cases.

Regardless of the agile methodology or framework applied, the primary goal of a project manager should be to help the development team deliver quality to the customer. By allowing the team to self-organize and commit to prioritized work, the project manager is viewed differently. They are no longer the task master; they are a valuable resource for overall project success. They do this by helping the teams navigate shifting priorities and directions and keeping a careful eye on the big picture. They can and should continue to “monitor and control,” but it is done at a level that is non-intrusive to the team with the “control” piece done by influencing and supporting the team, not directing. In this way, both the teams and the project managers will become more effective and consistent in delivering value at a regular cadence.


Print Friendly
Tagged with →  
  • “How long will it take” is an important question, that does need to be answered for any kind of planning whether in agile or not. But I totally agree with you that project managers should continue to monitor and control with the control piece done by influencing and supporting the team.

  • Candy Titko

    “how long will it take” is answered as soon as the team points out the stories and tasks, but the important part of being the PM is not to influence the team; let them tell you how much time it will take. I loved this article and have tried to manage my teams in this manner.

  • “How long will it take” is completely a legitimate question, or even better, a legitimate statement, as in “It has to be done by October 1st.” This is true just so long as the development team has the freedom to determine what “it” is. In agile, you can commit to a feature set OR a deadline. Committing to both is a recipe for disaster. Teams that are put in that position frequently inflate their estimates grossly to allow for variability. They may meet the deadline with the requested features, but at what cost? In the organization’s drive to put a fixed time and cost to development efforts they inadvertently, but very effectively made their developers significantly less efficient.

  • Thanks Candy! I am glad you enjoyed it and agree wholeheartedly.