Archive

Archive for July, 2011

Getting to Why and How

July 1, 2011 Leave a comment

My previous blog post “Making things happen” described a simple model for paying attention to significant aspects of change: Asking “Why” to facilitate common understanding and asking “What does this mean” to make change initiative personal and meaningful.

In this post I explain how I recognize Solution Trap and how I start discussions to get out of there.

Solution trap is a situation where group of people agree on change-related actions, but fail to agree about reasons (why) and concrete consequences of the decision (how). I call this a trap, since it is easy to fall into: solutions are good discussion topic without need to commit into anything. It is much harder to talk about reasons behind solutions (“why” or “organizational alignment“) and implications to daily work (“how” or “how my personal work changes“).

You may disagree with “solutions are good discussion topic without need to commit“. Yep, that’s a strong statement. But think about it: how often you have been sitting in a meeting and found out that other people talk about their problems & solutions and you are happy to find out you are not involved. If anyone asks your comment, saying “OK” is the fastest way out of the situation.

Recognizing Solution Trap

  • People are talking actions and goals that others have put upon them. “Management team wants us to automate all acceptance test cases
  • Actions have arbitrary or meaningless success criteria: “We need to change 35% of our teams to use Scrum by the end of the year
  • Actions are overdone: “We need to split all stories in backlog to less-than-Sprint size” (it would be enough to split coming 1-3 Sprints to this size)
  • Actions are underdone: “Product Owner joins Retrospectives of key teams” (why not all teams)
  • Different teams have different understanding of actions and goals
  • People feel disengaged from actions and goals: “It is not for us, someone else handles that” or “I think we’re doing it OK already, others need to improve

Common to all these discussion patterns is that topics and style reflect feeling outsider or not part of the issue. People are ignorant towards the initiatives.

Getting out of the pit: Start with Why?

  • Ask “Why” frequently enough. “Why do we have this meeting, what is the expected outcome“, “Why is this action taking place, what problem we’re trying to solve
  • Try to be constructive: asking “Why” in this context is not to challenge, it is about facilitating common understanding.
  • Ask high-enough “Why“, seek for purpose. If the discussion is about “Splitting stories to Sprint-size chunks“, then obvious question is “Why do we need to split“. I would go one step further and ask “Why are we using stories“, “What are we trying to achieve with splitting
  • Go around and investigate the different answers to your “Why” and use that information to see level of common understanding. E.g. “Seems that Product Owners know clearly the purpose of grooming sessions, but several team members did not see the point

Once “Why” part is solved, then it is time to move on to “How” (a.k.a “What does this mean to me“). While “Why” may be difficult, you can expect “How” leading into at least equally difficult and much more controversial discussion.

Getting out of the pit: Check What does this mean

Purpose of “What does this mean” is to create commitment, agree common working practices and test the initiative with real-life cases. I use the following questions

  • Check understanding: “What changes in your daily work when we start doing TDD?
  • Check what happens if actions are not taken: “What happens if some teams don’t commit to CI build daily?
  • Find out how everyone knows they are doing things right: “How do we know that Backlog items are small enough?
  • Find out how wide are the impacts: “What teams are affected if we move from component-Backlog to feature-Backlog?
  • Check what happens if new way of working reveals problems: “What do you do when CI build fails?“, “What if Sprint Retrospective outcome is a severe impediment that require management team actions?

Sometimes it is useful to document the outcome of “Why” and “How” discussion. And many times it isn’t. Power of discussion and common understanding is surprisingly strong, stronger than any PowerPoints or staff meeting talks.

Making things happen: The importance of Why and How

July 1, 2011 Leave a comment

In order to make things happen, organizations need alignment, common goal and commonly agreed ways of working. This is easy to remember sitting at my desk but difficult to keep this in mind in real-life coaching situations. There is trap and I developed a simple illustration to remind myself about it.

The height illustrates how easy/difficult it is to reach agreement for a question. Throw a ball in such shape and it tends to fall to gravitational minimum, lowest point. In decision making, such minimum is agreeing on “What”.  It is quite easy to reach common agreement on “What”, but this leads to obvious problems.

If “Why” and “What does it mean” are left with little attention, decisions become diluted, misunderstood and actions do not lead to the expected outcome. A very important role for a coach is to push the ball uphill, both directions, and keep asking: “Why are we doing this? What does this mean?”.

I learned right side of the picture a few years ago, coaching R&D teams in a large corporation. Middle management started to support Agile transformation and decided several actions for coming quarter. Actions were good: they were about using continuous integration, investing in test automation and improving quality of product backlog. However, one flaw in the plan ruined it: huge (hidden) disagreement on “What does this mean”. As a consequence, everyone was taking unaligned or conflicting actions. All was done with the best intention, but lack of commonly agreed working practices turned most of the effort wasted.

At that point I made this visible by asking: “What changes in your daily work when you <X>” (X is “do continuous integration” or “improve PBL in frequent grooming sessions”). The consequent discussions were sometimes unpleasant, but necessary to sort out the different understanding.

I was aware of the left side (“Why”), but a recent incident made the importance very clear to me.

I invited a meeting to discuss and agree working practices for invoice & cost follow-up in a government-funded research project that we were part of. Colleague of mine started meeting by asking: “Why are we part of this project?”. I was stunned! What a waste of time — I knew everything about the project and its importance. Very soon I realized not everyone knew about the project goals or purpose. And I did not know how others saw “the big picture”. Later on, many participants came to thank me how important is was to create common understanding about the task at hand: “I’ve been working 2 years on this and only now I understand why this paperwork is important and how my work relates to project goals!” And when everyone knew why we are in, lot of people started contributing to the project — even outside of their area of responsibility.

It takes attention and courage (and sometimes perseverance) to keep pushing ball uphill. But believe me, it pays off! Take a look also at another post: “Getting to Why and How

p.s. Final note to avoid misunderstanding: Asking “Why” in this context is not about Lean philosophy of “Challenge everything”. The point is not to attack initiatives or try to challenge their validity. Point is to facilitate common understanding across teams and get a common answer to “Why”. Through this common understanding people may decide to drop something, but more important is to reach alignment among all involved.