Sunday, September 8, 2013

Flexible Agile Coaches have a greater impact

A.k.a. How separating implementation from outcome can lead to better results

Flexible Agile Coaches, Scrum Masters and Change Agents have a greater impact. Flexibility in how their goals are achieved; allows them to deliver more changes and more effective changes. Overall this results in them having a greater impact. They do this by separating the ‘what’ from the ‘how’ and focusing on ‘what’ they want to achieve not 'how' they want to achieve it. This flexibility allows the Agile Coach to move around obstacles to change, instead of having to remove the obstacle. 

Going around an obstruction

I.e. having permanent monitors on the walls displaying a live stream of production metrics, office news, etc is great for increasing information dissemination. However an increase in information dissemination could be achieved via numerous other means: face to face updates from leadership team, simple prints outs updated every day, e-mails, news page on the wiki; RSS feeds etc. 

It is easier to implement a change when you are not wedded to how you want to achieve your goal. I have found that ‘letting go’ of my chosen approach leads to better results. 

The implementations that are not mine; come from talking to the stakeholders about the goal. The stakeholders regularly suggest alternative approaches that still lead towards the goal. The important difference is that they feel ownership over the alternative approach. This ownership builds acceptance and stickiness of the approach; which provides a great foundation for future changes.

What can you do?

Once you decide what you would like to change; work backwards to figure out what your goal is. Think about what benefits you expect to come from applying the change. This will lead you to your real goal.

e.g. You have heard that test first approaches are beneficial. You would like your teams to start using Test First for all of their development. So Test First is your ‘How’. 

Now it is time to find out the ‘What’. Think about the benefits of implementing Test First. Perhaps you could read some blogs to find this out. Your thought and research leads you to consider the benefits as (builds shared understanding, improves code quality, reduce waste by building just enough software to make the tests pass). From there you believe that Improving Code Quality is the benefit that you are primarily interested in. That means that ‘Improving Code Quality’ is your true goal.

With your goal identified, your focus should move to achieving the goal; not necessarily implementing your suggested approach. Work indirectly towards your goal. If barriers pop up don’t try to steam roll them, instead change direction slightly while still heading towards your goal.

e.g. Test First is receiving a lot of push back. However in your discussions regarding Test First, several people indicated that they would be accepting of using Code Reviews. Make use of their interest in Code Reviews. Help them to implement code reviews and reap the benefits that come from Code Reviews. Achieving some success via code reviews is more useful than fighting tooth and nails to implement test first straight away. Through this process you will have built up some trust with your stakeholders and should be in a good place to help them with their next move towards Improved Code Quality.

Examples of Goals with different approaches

Improve ownership of the product

  • Encourage and support staff adding User Stories to the backlog.
  • Inform staff that management expects them to take ownership of their product.
  • Encourage Product Owners to ask for input from their team when creating User Stories. 

Improve code quality

  • Enforce code reviews
  • Implement test driven development
  • Tighten the coding standards
  • Promote collaboration between coders and testers.

Fewer interruptions for Stand Ups

  • Ask people to walk around stand ups
  • Stagger stand ups so that they do not block the corridor at the same time.

Increase reliability of team delivering their sprint commitments

  • Ask teams to commit to less stories each sprint
  • Management to put pressure on teams to deliver their sprint commitments
  • Ask teams to hold Backlog Refinement meetings

Trying it out for yourself

Please think about separating your ‘What’ from your ‘How’, next time you make a change. Let me know how it goes for you.