The Agile Project Manager—No Upfront Estimates!

The diagram represents the Cone of Uncertainty—coined by Steve McConnell of Construx. I’m sure he’s not the first or only one to reference the cone, but he famously has connected it with software development. The cone indicates the futility of estimating & committing to software projects at project initiation—not matter how well conceived the estimates are. There’s typically too much uncertainty to be accurate. Instead, an iterative or incremental approach will glean more information to improve the estimates over time. This is particularly true for projects that include new technologies, new teams, or trying to create novel or innovative products.

I’ve been managing software projects for much of my career. Early on, I spent most of my time trying to estimate projects more and more effectively. I pulled together models for how to estimate. I kept track of historical estimate vs. actual data, so that I could evaluate the quality of my estimates. I even tried some modeling or arithmetic techniques to fine tune my estimates. Some of these are quite well know techniques like Function Points or Cocomo or the Personal Software Process.

All of this was focused towards estimate quality…not software product quality. I was worrying about how to represent the time to build the software to stakeholders and accountants so that we could reasonably know how much it would cost. Then we could make better decisions around whether to start it or not.

The odd thing, at least in my experience was that no matter neither how hard we tried nor how much effort we expended on estimation and planning, over 60% of our projects went awry. They failed. They were Death Marches. They were incredibly painful. And in many cases, they resulted in people losing their jobs.

I guess my point is—accurate software project estimation is incredibly hard.

The Agile Project Manager—Engaging Your Customer!

The agile methods come at software development by challenging many of our status quo practices. The first one is the engagement level of the ‘customer’.

It’s my experience that most waterfall or traditional projects allow the customer to disengage after they start the project and provide an initial version of the requirements. After some time…later…they appear at the end of the project to receive their prize. Usually they’re disappointed in the end result—finding the functionality not living up to their original vision & expectations.

This sort of “end-points” behavior leads to many project failures due to a lack of clear communications, misunderstanding, and missed expectations.

The Agile Project Manager—The TRIAD at the Heart of Agile Collaboration

I was employed a few years ago at a wonderful company. I first joined them as an agile coach and Scrum Master. I had been spending an inordinate amount of time on the road teaching, so this local opportunity to coach a set of agile teams was timely and incredibly welcome by my family and I.

After joining, I was soon promoted to a Director of Software Development role and became a member of the senior leadership team. That was my title and my primary role, but I continued to coach and champion agility across the organization.

I used to joke about arguing with myself because I had two halves. I had the dark-side responsibility of “management” (Darth Vader) and the light-side responsibility of coaching our self-directed agile teams (Luke Skywalker). Although I felt I achieved a reasonably good balance, it certainly was challenging at times to keep my heavy breathing to a minimum.

The Agile Project Manager—Don’t Throw out the PMBOK!

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

The Agile Project Manager—Listen to your Spider Sense

I was working with an organization a few weeks ago on a coaching assignment. They’ve been experiencing quite a bit of attrition within their technology teams and the discussion inevitably went to root causes. Several leaders at the client were confused about the drivers behind it.

One of them said that they had sat down with several developers before they left and everything seemed fine. They talked about the developers concerns and tried to address every one. They felt that there were “tuned into” the team and were trusted. They just couldn’t understand why folks were leaving without giving them an earlier warning…and more importantly, a chance to address their concerns.

Here’s another interesting ‘twist’ to the plot.

The Agile Project Manager—Driving Value or Where’s the Beef?

The Agile Project Manager—Driving Value or Where’s the Beef?

There was a wonderful commercial I remember from years ago where a matronly woman named Clara Peller judged hamburgers by the amount of beef she found in them. Quite often, when she was disappointed in her quest, she would shout “Where’s the Beef?” in frustration. Wendy’s was the chain who came up with the advertising idea and to this day the line has become a catch-phrase for value delivery and customer expectations.

I guess Clara was onto something though. In my experience, business’ often miss the beef when they’re trying to deliver value to their customers—particularly in the software product arena. I don’t know why that is exactly. Sometimes I think the developers are too abstracted from their customers. They can rarely touch or observe them. Or understand their true challenges. So they’re guessing when it comes to needs—sort of throwing the software “over the wall” for feedback.

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…