Jun 282011
 

Sincerity, reliability and competence to hold promises

The “Top Three Rules for an Agile Project Manager“, according to Terry Bunio (bornagainagilist), are:

  1. Team velocity
  2. Client interaction
  3. Deliver something personally

…I see that as a great list, as long as the client is ready to accept delivery of the product when the release is ready.

Now, maybe it’s different for software companies that have made a commitment to agile practices. When professional services teams shift from one client to another, though, accepting delivery can’t be taken for granted.

That a client accepts delivery of the product is a matter of trust, like so many other aspects of trust that show up within and among members of the agile team.

There are at least two common themes I have seen when clients hesitate to accept a product that has otherwise satisfied releases requirements:

  1. Sometimes early in a release cycle, or even after a couple releases, a deeply ingrained history of unmet expectations from earlier software projects can make a client less willing to simply accept the product.
  2. In addition, it can seem to some clients who are concerned to continue getting new features in the future that they need to have everything crammed into the current release.

In both cases, the psychology of the customer could be oriented around either threats of undiscovered defects or of losing potential opportunities.

Declining product delivery is a trade-off weighed against the potential that these threats could materialize.

The agile project manager can preempt the trade-off by acknowledging which potential threat may exist and working in advance to mitigate the risk.

The good news is that it turns out the key to mitigating both of these threats is also a form of trust: in the first case, it is trust in the quality of the release… and in the second case it is trust in the iterative nature of release planning.

No surprises, no panic

Throughout the first release, the agile project manager works through iteration planning meetings, retrospectives, stand-ups, and other forms of status and communications to reinforce the close relationship between the development team and the product under development.

There are zero if any surprises, and when executed strategically there are many opportunities to show and build trust with your customer throughout the release cycle.

Each opportunity to build trust is highlighted and emphasized so that everyone knows we are sincere, competent and reliable to keep the promises we make (or make amends quickly and effectively).

In addition, while the project manager must keep everyone directed and focused on the features of the release, s/he cannot lose track of the place this release plays as a tactic within the customer’s larger goals. If we do not expect this is a final release, then it always fits into an ongoing story with each release achieving one strategic objective or another.

We ship early, we ship often, we ship quality, we ship value. It’s a good life.

What strategies or tactics do you use (or could you envision) for helping a customer accept delivery of a release if they show signals of reluctance? Can you anticipate reasons other than the two I outlined, and how might you address them?

  4 Responses to “A fourth rule for agile project managers”

  1. nice post! Building trust is more significant than most PMs / Teams realize. It has to be addressed with full intent… it isn’t an accidental thing.

    • Thanks, Ken. You are certainly one to know. It is good to have you reading, make sure and set me straight from time to time.

      –k

  2. […] I just want to link back to a past article I wrote about the role of project managers to hold customers to their end of the bargain – that they take receipt of our products. Not every team has this problem because they have […]

  3. […] “A fourth rule for agile project managers,” I mentioned the unfortunate circumstance that software/IT customers sometimes suffer from […]

Leave a Reply