Why over how (My look at Dude’s law)

When clients want to go agile, they contact me with how questions:
– How should we do set up a kanban board.
– What tools should we use.
– What agile methodology is best?
– How to do agile estimations?
– How do we start code reviews?
– …
Etc.
These are logical questions for people new to agile. I’m happy they ask them because I see what bothers them. Before I can answer such a question, I need to know why they want to go agile. Or what kind of problem they want to solve when they ask for the best digital kanban board. (This question comes up every x time on the different online media). I have nothing against a nice visual board. (I have friends among all tool suppliers) Having your CFD (or other visual management info)being generated is nice.
Only implementing that without knowing what you want is a waste of time and money. Before I start with such a client, I want to know why they want to go agile. By first figuring out what they want they, I assure that the energy is focused on their biggest problem. Especially with existing teams moving to agile, this is important.
Last year David Hussman starting giving buttons away with his dude’s law: Value = Why over How.
When I first saw it, I instantly ‘got’ the idea. Yes, that should be the focus of agile coaching. David comes from the music industry. New musicians focus on having a nice sound. Professional musicians first think about the mood of the song, the emotion they want to bring across and then work out the sound that fits it.
Now going back with the client that contacted me for the best digital Kanban board. They seem to understand the agile mindset. And yes, the team needs more visibility on their work.

Instead of proposing a digital board, I’m asking them to start with a physical board. I propose they create a burndown chart manually. What I noticed is that teams that do this manually for some time, actually care about a burndown chart. When it is generated for them, they see it as a management tool that they don’t care about. Yes from time to time a team is not interested in it and does not do the effort to update it. This could tell me that they are not interested in keeping their promise of finishing.  (a root cause analysis should be done to find the real root.) When the burndown is generated, the ‘nobody cares about the burndown’ problem is hidden. This is why over how at a deeper level. First figure out what kind of information radiators the team is interested in.

What I noticed is that most people who come with a how question, have not thought long enough about their problem. (Jerry Weinberg says that if don’t have 3 solutions have not thought long enough.)
The same thing can be said if I as a coach start answering how questions, it tells me I have not listened enough. People that have found the why, usually come up with their own answers to the how question.

A few years ago, a women I started coaching was frustrated because I did not gave her direct answers to her how questions. It was very tempting to give in as a coach and give her a solution. I did not. I helped her finding the why behind her questions. I got her connected with another PO in the same company. Although in the beginning they both felt their problems were different, in the end I think their why’s were the same. The hows were different because their teams were not at the same level of maturity.

This whole process goes slower. And some people get frustrated because they expect that this coach will now solve all their problems. I know I do help them solve their problems, only not by giving them a silver bullet or miracle pill. I help them to think and realize they know the solution. Which makes these people quicker independent from me. And thus liberates them from me…

This gives me the option to help other teams == this is long term thinking over short term.

Update: Thank you for Peter Forret to let me use this picture of him.
Update:
Agile practices that support Why over how:

  • Behavior Driven Development
  • Powerfull questions
  • PairProgramming
  • Root Cause analyses
  • Value Stream mapping

Yet another Update : books that learn you about why over how: