Bamboo Blog

Patterns aren't just for software design. We can find generally reusable solutions to common problems in handling clients.

Taking simple actions early can avoid serious problems with the client relationship later on. After seeing this work a couple of times, I ran a workshop at XP2010 where we developed detection heuristics and early interventions for several classes of difficult* clients.

The Stealthholder

Also featured in our 'Sword and Other Tales' presentation, the Stealthholder is a stealthy stakeholder who appears from nowhere at the end of a project and turns a success into a failure. This might just because an entire area of critical requirements was missed, but can also happen when the continuous process of redesign throughout the project doesn't reach them, so they get a sudden shock at the final demo. War stories for this one were surprisingly common; my personal experience is with a high-ranking person who appears only at the beginning and end of a project, but others had encountered variants where the stealthholder is always visible but their apparent position in the hierarchy misstates their real power, or where the person is visible for the very first time at the end of the project.

We came up with lots of heuristics:

• Mysterious strangers in meetings (particularly the kickoff), or appearing in email
• Software design seems to be creating interfaces for another piece of software you can't see
• Only person you ever talk to is the PO
• PO suddenly changes their mind, and it's not clear why
• Lots of middlemen
• There's a "hole" in the hierarchy - a level where nobody seems to be directly involved in the project
• Appearance of surprising requirements (where did they come from?)
• Impossible requirements (that have probably come from someone very far from the project)
• Appearance of someone who talks to the scrum master before they meet the team, but never afterwards

And there are a few early actions:

• Find out who they are. Get their details, invite them to the demos, and then make sure they come.
• If they don't come, start by calling them. Escalate by suspending work, if you really have to.
• Find out their most critical priorities through lots of open questions.
• Possibly involve stakeholders in sprint planning.
• Ensure that you have a strong Product Owner. Provide pre-training if necessary.
• Create a Big Visible Chart of the people involved in the project. Passers-by will point out errors.

I think there's scope to develop strong patterns for Sergeants ("people who won't take anything but 'yes, sir' for an answer") and Shapeshifters (the client contact who is always a different person), among others. I'll talk about them in a future post.

* There are no difficult people, only difficult situations. Categorising people like this is a useful abstraction of a much more complex situation, nothing more.