I must admit that I’m a fairly rabid agilist. Part of the rationale for that is the pain I’ve experienced in leveraging traditional PM techniques in software projects. Another influence is my experience dealing with traditional leadership and the dysfunction relating to driving projects and teams towards unrealistic goals.

What’s interesting though is a conversation I had with our Scrum Master team the other day. I asked them to act more like “traditional project managers”. To begin to—

  • be more prescriptive at times with their teams; demanding high quality, excellent software, and adherence to our agile principles
  • pay close attention to risks – planning, real-time surfacing and guiding team reactions
  • encourage the teams to improve at an accelerated rate; to set the bar high for improvement
  • become visible as leaders and spokespersons for their teams; to do a better job of socializing state & progress
  • take the role of impediment resolution to the next level; mining for impediments…and dependencies, then inspiring action
  • cheerlead for their teams; inspire and demand that the Product Owner does the same

What I was trying to convey to them was the ‘mindset’ of a “good Project Manager”…or at least the ones I’ve seen and collaborated with in my journey. You see, many agilists use the role of Project Manager as a bit of a verbal “punching bag”—implying that there is no need for them in an agile context. By the way, you see these same folks trivializing other roles too—functional managers, testers, and business analysts to name a few.

I can’t disagree more with these folks and that position. I think solid Project Managers can find a place in agile teams…a place that makes a HUGE difference. Yes, they might need to reframe their style and behaviors for an agile context, but please, please, please don’t throw away all of your approaches. Your teams absolutely need and will appreciate your skills, as long as you reframe appropriately without throwing out your essence!

The “Agile Way”?

An anti-pattern that often shows up in agile teams relates to managers and project managers losing their way when it comes to knowing when and where to engage their teams. Knowing how to effectively handle the fuzzy and scary notion of a “Self-Directed Team” it turns out can be quite challenging.

A common reaction is to treat the team as if walking on egg shells. If you see the team heading for a cliff, you can’t really say anything—as they’re “self-directed”. Of if you do say something, you must whisper…quietly…hoping that someone might hear you.

I once coached a team in Toronto. As is my typical practice, I gave them a quick Scrum overview, then planned and kicked off their first sprint. I stayed for a few days to ensure they were going in the right direction, and then I went home. I came back at the sprint transition just to see how things were going. In my first morning Scrum upon returning, one of the developers sort of “yelled at” their functional manager who was attending as a ‘Chicken’.

The team was stuck at a technical impasse and she said: “You better step in and tell us how to handle this, or I’m going to scream”. I was taken aback and after the stand-up I asked her what was up.

She said that ever since the sprint started that none of the functional managers were saying anything—nor providing any guidance whatsoever to their teams. And that she was sick and tired of it. She wanted help! I then asked the functional managers what was going on. They said that they were only doing what I’d told them—that the team was “self-directed” and that they were to keep quiet…being ‘Chickens’ if you will.

Ugh I thought as I smiled a wry smile to myself. Yes, I had told them that respecting self-direction is important. But that doesn’t imply that you don’t have a role and responsibility as the teams’ functional manager. You certainly don’t let them crash into a wall without yelling and warning them. You see, the managers missed the nuance of leading within agile teams, as many roles do. They mistakenly behaved as if they were marginalized and didn’t matter…when nothing could be further from the truth!

So—Which way do we go George?

It’s Situational & Skills Matter

Always remember that your agile PM role is situational. You’ll want to keep the values (Lean principles, Agile Manifesto Principles & Practices, Essence of your specific methods, Quality, and focus on Team) core in your thinking, but at the same time very much react to situations as you always have—with simply some ‘adjustments’.

As part of being situational, always remember that the teams’ skills & experience matter quite a bit in how you should react. If you have a brand spanking new team, then you probably want to provide more prescriptive guidance. If you have a master-level team, then your job is to softly guide & support them, but truly get out of their way. The Dreyfus model of skill acquisition is a good model to become familiar with to conceptualize the various team levels that you might encounter and to guide your adjustments.

Risk an Opinion

As in the above story, your teams still need leadership—leadership that provides clarity, vision, missions, and goal-setting. Leadership that is “in the game or trenches” with them. Leadership that endeavors to protect them and to shield them from major obstacles and mistakes. Leadership that is supportive and encouraging. Leadership that is in all cases, well, leading them…

In a word, you should evolve towards a more Servant-Leadership style. But you also need to share your thoughts with you team. Risk saying how you feel and what you’re concerned about, but then allow the team to take risks and chart their own paths. Risk telling the team ‘No’ if you feel they’re on a destructive path and be prepared to also tell them ‘Why’. Finally, risk ultimately becoming a part of the team and sharing their responsibilities.

Leverage your Instincts

As I’m writing this, my company iContact is making a fairly major release of our eMail Marketing software platform. We’ve been adding social capabilities for several months and are now exposing them via this release.

One of the things we struggled with was how we turn on our +70k customers. Do we do it all at once, or in a more measured way to mitigate risk and allow us to see how the new functionality ‘behaves’ under load. There were two schools of thought across the teams—release it ALL and release it incrementally. Most of the teams had an ALL perspective, as did our QA team members. However there were a few in the development organization that wanted a more controlled release and argued for that option. Initially they were considered naysayers, only reacting to FUD, but to our credit—we listened to them.

After much discussion, we opted for a controlled roll-out. While we didn’t encounter huge problems as we ramped-up, it allowed for us to better understand our usage metrics, plan for incremental use, and have time to fix a few lingering issues. In the end, it proved that our overall risk-handling instincts were the right way to go. I’m glad the few had the courage to “speak up” and that we trusted their instincts.

Ceremony & Reporting Matter

Remember that even agile teams still bear a responsibility to integrate back into the organization. They need to be transparent and communicative—and not simply in agile terms. It’s not sufficient to simply say “come review our burndown chart” or “just attend our Daily Scrum” if an executive or stakeholder asks you or the team for status.

Sure that is a mechanism or ceremony setup for this sort of communication. But what if that stakeholder doesn’t show up? Does that alleviate your communication responsibilities? Of course not! So beyond the information radiators, a PM can ensure the team is effectively communicating broadly across the organization.

Another important point is communicating in ‘terms’ that the business can understand. Whether it is reports, data, videos, or whatever it takes to represent the teams’ progress and efforts.

The PMBOK!

I’ll even go so far in this post to say that many of the ‘traditional’ principles and techniques from the PMBOK shouldn’t be “thrown away” from an agile perspective. Let’s take the notion of critical path for instance. In larger agile projects, with multiple teams, there still are plans that evolve. And within that framework keeping the critical path of work in-sight across teams can be a crucial visibility point.

As can asking the team to manage risks, or creating a project charter, or establishing effective milestones for cross-team integration. So please don’t throw away or ignore these skills if you “Go Agile”. Just transform them (and yourself) a bit and then trust your instincts in the situations that emerge.

Wrapping Up

I want to wrap-up this post with caution though—traditional Project Managers DO need to reframe themselves and their approaches in an agile context. Throw away your templates and checklists that prescribe a specific approach to all projects & teams. Instead you must become context-based and situational in your approaches.

You must also engage your teams, not as an execution monitor or policy cop, but as a true partner.

I’ll leave you with the following two charts that nicely illustrate some of the focus and tempo changes that occur between Traditional & Agile PM activities.

 

 

So, Project Managers—may you navigate these waters well and engage with your teams. They NEED YOU!

Thanks for listening,

Bob.