We’re off on an adventure!

The Dream Team Nightmare

The Dream Team Nightmare

It took a while to arrive because the book was out of stock at Amazon, but it’s finally here, just in time for the holiday break: Portia Tung‘s “Dream Team Nightmare“!

I sat down with a cup of coffee and started to read the book. Portia’s writing style is engaging and lively with lots of dialogue and very short chapters. At the bottom of the chapters you have to make a choice and then go to a designated page.

I’ve been on agile projects for years, so I expected to breeze through the book. After all, most teams face the same problems. I’ve solved them many times. Why should this “Dream Team” be any different?

After only a few pages I read

Patrick [who hired you as an agile coach] asks his secretary to escort you out of the office. Before you know it, you’re back on the street.

It feels like you’ve been punched in the gut. Thoughts swirl in your head. Should have. Would have. Could have. You decide to take time out to reflect on what happened. You’re not quite ready to give up doing a job you love. not yet.


Fired! On my first day. Game over. Do you want to play again? Of course, but now I’ll make smarter choices.

And… I was asked to leave the Dream Team and see if things would go better with another team. THE END.

“If at first you don’t succeed, stubbornly try again and again”, that’s my motto. So, one more try.

Aha! We come to a part where my mission is described as a user story with acceptance tests. That will help me to understand better what’s expected. I restart the book and start working with the team. I flip backwards and forwards as the book directs me to see the consequences of my choices. It’s getting smoother. And then there’s a conflict with one of the team members. At the end of the 5 days I present my recommendations. And then… nothing happens. THE END.

This agile coaching lark is harder than it looks.

This is frustrating. I’ve only scratched the surface of the book, read a few chapters and each time I reach a dead end. Reminds me of some projects I’ve been on.

And then I have a brilliant idea.

What would Portia do?

I’ve been lucky to work with Portia and see her at work. I will restart the last time and at each choice ask myself “What would Portia have done in this situation?” Portia would

  • talk to everybody to understand what motivates them
  • help the team to make their own decisions
  • reach agreement on the value we’re creating
  • get a good understanding of where we are
  • define goals together and clarify them with testable acceptance criteria
  • take some time to reflect regularly
  • help the team to create and explore options
  • lighten up the mood with silly exercises like “profile cards“, cookies and team lunches

I can do that. It’s just a matter of taking a bit more time before making a decision. Let’s start again, from the top.

Pinocchio-Blue-FairyThis time, with the help of Portia (sometimes in the role of Jiminy Cricket to keep me on the straight and narrow, sometimes as the Blue Fairy who grants wishes and saves the day) I progress through the book. There are still a few choices, but fewer and fewer.

The team starts working together to visualize their situation. Faced with the enormity of their task, they feel demoralized. We come up with three options to deliver value and involve the Product Owner.

And there it gets tricky. If I’m not careful, the unspoken simmering conflict between team and product owner/management erupts again: the company needs more than the team can deliver; the team blames the product owner for imposing unrealistic scope and deadline. THE END.

And that’s where it usually ends, but there’s another option. There’s always another option.

Instead of saying “It’s impossible to deliver this scope by this deadline!” you can ask “What do we need to achieve the goal before the deadline?” Two other agile teams “Predator” and “Green” can help the Dream Team. The teams apply Real Options to decide on the day when they have to decide. Meanwhile they create and explore more options to achieve the company’s goal: different ways to select scope and divide the work between the teams.

Finally, a happy end

From there it’s relatively smooth sailing. By now I see the trap on page 216, where I fail to ask the team to review and improve my recommendations because I’m rushed, coming by a mile. If only it were this easy in real life to take a step back for a moment and take the time to think…

And then we arrive at the final chapters: the team present their delivery options and their improvement actions. Everybody’s energized to work on those actions. I don’t know if they’ll live happily ever after, but the adventure continues.


Observations and recommendations

  • There’s a list of recommended tools on page 203. Appendix 5 contains the coaching tools used in the book. It would be useful to have some links where I can find out more about each of the tools. Maybe something for the Agile Adventure site?
  • I loved seeing the Current and Future Reality Trees in use. It would have been great to see a “Conflict Resolution Diagram” be used to bridge the gap between root causes and improvement actions. What are the underlying conflicts that have led and kept the team in its unhappy situation? Maybe something for the next agile adventure?
  • Flipping back and forth between chapters isn’t always practical in a paper book. But you can have your cake and eat it too. I bought both the paper and e-book version: the e-book to play, the paper book to loan
  • There are a few illustrations in the book: current/future reality trees, profile cards. A few more illustrations would have made the story a bit more vivid: what does the kanban board look like? What does the team area look like? No need to make it into a graphic novel. Henrik Kniberg‘s “… from the trenches” books are a good example of how illustrations can make the story more vivid.

Done. What’s left on the holiday reading backlog?

Some more light reading, because I don’t want to be that agile coach who hasn’t written production code for a decade.

ebdojo_xlargecover elixir_xlargebetajaerlang2_xlargecover lotdd_xlargecoverellnestam_cover150

Can anyone recommend a good e-book about Clojure that covers core.async?


Conf Agile France 2011: Résolution des Conflits

Résoudre les conflits sans compromis

La semaine passée j’ai présenté comment résoudre les conflits avec le “Diagramme de Résolution des Conflits” à la Conférence Agile Paris. La présentation est disponible ci-dessous. Plus d’informations sont disponibles sur le site Agile Coach.

A la fin de la présentation il y a deux questions pour voir si vous avez compris la leçon:

  1. Est-ce qu’il est possible de former un gouvernement belge avec cet outil? Si oui, pourquoi? Si non, pourquoi pas?
  2. Est-ce que vous pouvez résoudre ce conflit récurrent entre Product Manager et Développeurs:
    • Le Product Manager a besoin d’estimations et de planning très détaillé et fiable pour publier une roadmap qui dit quand quel fonctionnalité sera livrée quand ET livrer ces fonctionnalités comme promis
    • Les clients, qui souvent sont des grandes entreprises avec plusieures filiales dans les monde et beaucoup d’utilisateurs, ont besoin de cette roadmap pour planifier quand ils vont implémenter une nouvelle version
    • Les Développeurs sont “passés au Kanban”: ils ont arrêté de faire des estimations ou des plans. Cela prenait beaucoup de temps et ce n’était jamais correct.
    • Les Développeurs “éliminent le gachis” parce qu’ils doivent aller de plus en plus vite pour satisfaire les requêtes d’un nombre de clients qui toujours croissant.
    • Tout le monde veut livrer les fonctionnalités au client au moment où les clients attendent ces fonctionnalités.

Vos réponses et questions dans les commentaires…

D’abord essayez de clarifier le conflit.

Puis, découvrez les suppositions derrière chaque étape du raisonnement.


I presented an interactive tutorial on how to apply the “Conflict Resolution Diagram” at the French Agile conference in Paris. You can see the English version of the presentation at the Agile Coach site.

At the end of the French version of the presentation there are two tests to see if participants understood the tool:

  1. Can you use this tool to form a Belgian Governement. If yes, why? If not, why not?
  2. Can you resolve this common conflict between Product Manager and Developers:
    • The Product Manager needs detailed estimates and accurate planning because she has to create a long-term roadmap which spells out which features will be delivered when AND deliver those features when promised to keep customers’ trust
    • Customers, who are typically large multi-site companies with many users of the product, need the roadmap because they need to plan when they will roll out which version throughout the enterprise
    • Developers have “gone Kanban” and have stopped estimating and planning because the estimates took too much time and were incorrect anyway
    • Developers stopped estimating and planning to decrease waste so that they can keep up with the increased demand for features from the increasing user base
    • The whole company wants to deliver the features customers ask for when customers expect them.

Answers on a postcard or a comment…

First, try to clarify the conflict.

Then try to find the assumptions behind each step of the reasoning.


Lean Product Development at Lean & Kanban Belgium 2010

Parallel evolution

Last Thursday and Friday I participated in the Lean and Kanban Belgium 2010 conference. I was scheduled to present a session on Friday morning, so I could go to many sessions on Thursday.

Every session that I attended on Thursday said many things I wanted to say:

  • Sandrine Olivencia talked about challenging the team for continuous improvement
  • Dave Nicolette talked about the dysfunctions around budgeting and the need for IT to integrate, not align, with the value stream
  • Anthony Marcano and Andy Palmer explained how analysis can be implemented as a pull system
  • Ryan Shriver essentially said all I wanted to say about finding the real goals of our users and quantifying their needs
  • John Seddon told tales about really understanding value demand and taking a systems thinking approach to the design of work in his usual, inimitable style

What was left to say? At the end of the day I could scrap about 3/4 of my talk. The good news is that many people are independently reporting that these techniques and approaches work. And they can show results.

In the end, there was more than enough to fill an hour. After the presentation several people asked questions and discussed what I presented.

p.s. I followed Dave Nicolette‘s advice to grow a profitable consultancy: coin a new acronym. I give you “IDD”. You’ll have to watch the presentation to know what it means. And you’ll have to pay me big bucks to come implement it in your organisation 🙂


Agile 2010 session materials online

I co-presented three sessions at Agile 2010. The materials for these sessions are now available:

I hope you enjoyed the session or get some useful ideas from the session materials. Let us know how you’ve applied these tools.


Lean & Kanban Europe 2010

I’ll present “Lean out your product backlog with lean product development and business analysis techniques” at the Lean & Kanban Europe 2010 conference.

The session will show how using business analysis and kanban techniques we can create a flow from business goals to implementable user stories with acceptance test, focus on value-delivering capabilities and involve the whole team in product development.

Lean & Kanban 2010 Europe Speaker