Agile: What’s in it for the Project Manager?

Over on, my article “Agile: What’s in it for the Project Manager?” has been posted in two installments: part 1 on gathering requirements and work breakdown, and part 2 on interpreting requirements and tracking progress. requires free registration to access the full content.

How do we estimate?

There have been some web posts and twitter comments lately that suggest some people have a very narrow view of what techniques constitute an estimate. I take a larger view, that any projection of human work into the future is necessarily an approximation, and therefore an estimate.

I often tell people that the abbreviation of “estimate” is “guess.” I do this to remind people that they’re just estimates, not data. When observations and estimates disagree, you’d be prudent to trust the observations. When you don’t yet have any confirming or disproving observations, you should think about how much trust you put into the estimate. And think about how much risk you have if the estimate does not predict reality.

This does not mean, however, that you have to estimate by guessing. There are lots of ways to make an estimate more trustworthy. (Continued)

What Decision Are We Supporting?

In business, we’re often asked for estimates with too little context to understand the request. When that happens, we’re likely to expect the worst–that our estimate will be treated as a “guarantee not to exceed” and we’ll likely be in trouble at some time in the future. Of course we think that; we’ve been burned too many times in the past. Our fear of the consequences will encourage us to spend far too much time and effort trying to get the estimate “right” so we won’t be blamed.

If an estimate is really an estimate, then we know that it’s “wrong” in the sense that the subsequent actual reality is unlikely to equal it. The estimate is a guess, perhaps an educated guess, predicting the future. Predictions are hard, especially about the future.

Given these problems with estimates, why do we bother to make them at all? (Continued)

Building Frameworks For Internal Use

Suppose you have a number of products, or a number of applications, that share some common functional needs. It seems obviously reasonable to create a separate team to build those functions in common. Often these grow to become known as a framework, and the product or application teams are expected to use it.

It’s a seductive concept, but don’t do it. Why not? I can think of several reasons. (Continued)

Adding a new team member

Adding a new team member to an existing team always introduces challenges. The introduction changes the makeup of the team, and if the team had jelled, it has to do so, again, with the new member.

Also, the new member has to learn about the team and its work. There are many tacit assumptions held within a team. It’s impossible to document them all and, even if you could, both reading such a document and keeping it up to date are daunting herculean tasks.

So how do you maximize the integration of a new team member with a minimum amount of work?  (Continued)

Project Communication: Caught in the Middle

My article, “Project Communication: Caught in the Middle” has been published on now. It talks about the communication issues for a project manager in charge of an Agile project, and ways to manage both downwards and upwards.

(Free registration required)

Coherence vs. Standardization

I’ve talked about the rush to standardization before. My article, Coherence vs. Standardization, published yesterday on, offers a more detailed look at the problem, and offers an alternative.

[Note: requires registration, which is free.]

Avoiding Mini-Waterfalls

A lot of people and organizations, when transitioning from a serial software development lifecycle toward an Agile one, fall into the pattern of mini-waterfalls. They start doing iterations, but each iteration resembles the development lifecycle they already know. The programmers do some design work, then they write the code to implement the design, then unit test the code, and then they pass it to the testers for testing. To many people, this is the only way it can work. Their mental model only admits to this series of phases.

And they run into typical problems. Sometimes the design doesn’t fit the problem well, and patches are needed because there isn’t time to go back to design. The testers get squeezed for time at the end of the iteration, and no one knows how to accommodate the rework when a problem is found. More patches are added, because there isn’t time to redesign. And the next iteration starts the cycle over again.

Sure, doing this in two to four week cycles beats doing it in six to twelve month cycles. But only a little. Most of the time, it starts to fall apart if the team doesn’t learn to work differently.

But it’s inevitable, they say. (Continued)

Coaching Conversations: Organizational Values

A video of a conversation I had with Esther Derby, Geoff Watts, Maria Mastarelli, Susan DiFabio and David Koontz at Agile 2012 has now been posted on the Agile Alliance website. In this conversation, we talk about organizational values and how that impacts organizational behavior.

Unintended Demotivation

Are your well-intentioned actions having consequences you don’t intend and don’t want? Read “Unintended Demotivation,” my latest article on Gantthead (free registration required).

Also, I don’t think I ever announced my previous article on Gantthead, “Better Success Across Large Projects.”