The Agile Project Manager—What’s the Big Deal about Commitment?

As I discussed in my last post, I’m a bit of an “odd bird” when it comes to certain aspects of coaching agile teams. For example, I like the notion of calling sprints either a success or a failure based on how the team swarmed around and delivered on their Sprint Goal(s). Many agilist’s struggle with using the word failure to connote team performance and delivery—some prefer avoiding it entirely.

Another term that causes angst within agile circles is the word commitment. Again, I personally like the word commitment. After finishing sprint planning, I like to ask a team to “commit” to their sprint goal. I like the visualization of going “hands-in” as a team—in formalizing their commitment. Sometimes teams even physically do it, which always makes me smile. I see commitment as being a bond within the team to deliver on a realistic goal that they determine as part of sprint planning. It’s a bond extended to the business and generates meaning and focus for the team. But again, I may just be odd and miss the true nature of commitment.

The Agile Project Manager—Do You TRUST Your Team?

As an agile coach, one of my favorite expressions in response to nearly any situation I encounter in an agile team is—“trust the team” or “trust the process”. So here are a few examples of what I mean:

If you think the team has underestimated their work and are leaving velocity on the table, “trust the team”…

- If they have underestimated they can always pull in more work. And you know, you could be wrong, so allow the team to sort through how they understand, size, and execute their work. They’ll appreciate the trust you’ve given them and will invest in doing good work.

- If you do see poor estimation or poor execution & adjustment, then bring this to the attention of the team within their retrospective. Give them examples, but allow them to explore the most effective way(s) to improve.

The Agile Project Manager—Viewing RISK Through a Different Lens

This post was originally made in PM Times in June 2010. However, I wanted to make it part of my “Agile Project Manager” series, so I’ve updated and extended it a bit…hope you enjoy v2.

 I often find myself teaching various classes on agile methods. One of my more popular sessions surrounds the mapping of traditional project management techniques towards the agile methods. I do this quite often in a wide variety of venues. One metric I’ve noticed is that the more PMP’s in the audience the more spirited the discussions become.

The Agile Project Manager—Voila: The Great Reveal

The Agile Project Manager—Voila: The Great Reveal

I remember the day as if it was yesterday. It was my first sprint review at a company I’d just joined as an agile coach. They’d been ‘doing’ Scrum for several years and I had gotten the general sense that they were well disciplined and mature agilists.

So when they scheduled a series of sprint reviews to expose the x-team efforts of their latest sprint cycle, I was understandably excited. So I got into the room early to get a good seat and was eager with anticipation.

Gradually, the room filled and it became quite noisy, which only drove my anticipation higher. Then the first team took “the stage” and began their review. They popped up some PowerPoint slides and away they went…

The Agile Project Manager—“Going Agile”...The Price of Admission

I often get asked to visit agile teams—delivering some ad-hoc training and taking a look about. Usually I’m asked to do an informal assessment and share improvement feedback—framing the visit as part get to know each other session and part agile assessment. A short while back I visited a team. They’d been doing agile (mostly Scrum) for quite a while and considered themselves relatively mature in their adoption.

Right away, when I got off the elevator, I noticed that their environment was open and airy; so very conducive to collaborative agile teams.  There were rolling whiteboards all about and small groups of people were talking and pairing all over the place. Even the managers were sitting out in open space.

Fail NOW as a Strategy

Fail NOW as a Strategy

I was at a conference not that long ago speaking and sharing on various agile topics. As often happens, a young man stopped me to ask a few questions after one of my presentations. We struck up a nice conversation that eventually slipped out into the hotel corridors.

We started talking about sprint dynamics within Scrum teams and I happened to mention that I usually coach teams towards declaring their sprints a success…or (pause for meaningful effect) …a failure. That we do this as part of the teams’ Sprint Review, with the Product Owner being the final determinant based on whether the team achieved their Sprint Goal(s).

The Agile Project Manager—The Cost of Transparency

The Agile Project Manager—The Cost of Transparency

As I learn and grow my agile experience, I continue to find value and power in the notion of transparency. It’s one of the softer of the agile tenets and one that gets mentioned often, but rarely emphasized as a critical success factor.

So what is transparency? Let me give you an example. In many agile instances teams and structure don’t simply come into being. Usually functional managers or other leaders put some serious thought into the composition of their initial agile teams:

The Agile Project Manager—The Clarity of Transparency

The Agile Project Manager—The Clarity of Transparency

I’d like to begin this post by trying to describe some of the anti-patterns or characteristics of non-transparent work behaviors. This list will probably not be complete, but it should give you a sense of the other side of the transparency fence—obfuscation. 

There are several show-stopping defects in your current code base and you are either not tackling them with your best people or hoping their intermittent nature won’t surface inopportunely before general release. So essentially you are throwing a few bodies at the problem and hoping nobody truly notices.

...If you’re transparent, you must acknowledge and manage quality—being willing to “stop the line” if things aren’t’ right and fix them. This takes courage and commitment.

The Agile Project Manager—There Can Be Only One!

I hope I’m not the only reader who remembers the Highlander movie & television series. Duncan McLeod was an immortal amongst others who was fighting to be the last remaining immortal. In each episode, there was inevitably a decapitation or two as the immortal population was reduced to the final one.

I use the symbolism of the Highlander to remind myself of several aspects of agile project management. The first relates to focused teams and our earnest effort to reduce all levels of multi-tasking. The second reminder is the subject of what I want to explore in this article—the notion of investing in a single team to create a working model for your agile adoption efforts.

The Agile Project Manager—Traditional PM Triangle be Damned, Keep Quality First!

I can’t say how many times I have heard software practitioners talk about the Triple Constraints of Scope, Time/Schedule, and Cost as a triangle and suggest mental games of adjusting one and fixing the other two. Often you see Quality as a fourth constraint that is dependent on the other three, which is very true.

In my traditional project experience, stakeholders try to fix all three constraints—dictatorially fix them. This inevitably leaves quality as the only variable and, as teams flex on quality, the trade-off is hidden from the business until after the software is deployed.