8 Tips For Agile Coaches (AgileTODAY)

AgileTODAY 3A couple a months ago, Adrian Smith and I were asked to put together an article for the third edition of AgileTODAY to complement a workshop we plan to run at Agile Australia  2012. Adrian and I had a whiteboard session, and we put together these 8 tips which will hopefully help aspiring Agile coaches.

Introduction

The Agile coach is a critical role in helping leaders, teams and individuals understand, adopt and improve Agile methods and practice. For new and aspiring coaches, starting a coaching engagement can be daunting. It is easy to become distracted from the original mandate and get embroiled in the issues and politics of the team. The following tips were put together to help Agile coaches stay focused and achieve successful outcomes.

Start With The End In Mind

Before beginning an engagement with a team try to define success in terms of measurable outcomes and a realistic timescale. Share the outcomes with the team and sponsor to ensure there is a shared understanding of what you are trying to achieve. This will help clarify your role within the team and can help reduce any fears the team may have about the coming changes. Setting a clear end date will also ensure that both you and the team are clear that the team have to own and understand their way of working.

Be The Change You Want To See

Showing the team how it is done the first time then supporting them as they take ownership of the new way of working is a great way to bootstrap new practices and build trust in new practices. Role model behaviours you want to see in the team. If there are techniques or technologies you cannot model yourself, you may need to mentor an enthusiastic team member or bring in an expert.

Keep Your Distance

There is always a temptation to get involved and help with the team’s delivery work – especially when you see them struggling. While this may offer some short term help and can be useful as a learning exercise, it is unlikely to help in the long term. Becoming part of the team will also make it difficult to have tough conversations with team members, call-out unproductive behaviours and stay focused on your coaching objectives. Try to stand back, your role is to support the team and let them take credit for their success.

Ask The Team

The team has probably faced a majority of the issues long before you got involved. If they are to own the solution after you have gone, it is important to have them involved in the decision making process. Remember you are trying to help the team learn to work without your help. This sometimes means you have to let them make a decision that goes against your best judgement. Teams need to learn by their mistakes (and sometimes their idea works out which means you can learn something too).

Step By Step

People can adapt to change more easily when it happens slowly and they see how it aligns to an overall plan. Additionally, change becomes natural when you are able to create a safe learning environment for the team that encourages experimentation. Try to change the practices that are causing problems first replacing them with simple alternatives. If you take away all the old practices that a team depended upon they can lose their way and not see the dysfunctions for themselves.

Just The Facts

Asking questions is a fundamental skill for an Agile coach and can be used to drill down to the root cause of problems a team is facing. Don’t be afraid to ask “why” a couple of times to get to the facts behind a problem or to introduce the elephant in the room. As a coach you are in the privileged position of being able to raise sensitive issues and to legitimise discussion of difficult issues.

You Make What You Measure

Helping the team identify what is important (especially from a customer’s perspective), making it visible and updating it regularly will focus a team. Example metrics include: throughput, cycle time, delivered value and many others. The corollary to this suggestion is that you need to be careful what you measure because you can incentivise behaviour that has the potential to be counter-productive.

Agile Is Only A Means To An End

Although the Agile journey is important, Agile perfection is not the end goal. What does matter is delivering what your stakeholders want in a sustainable way. For this reason it is important to use Agile maturity assessments and other metrics with care. Helping a team become agile should focus on instilling Agile values and principles, while selecting and adapting Agile practices to help the team deliver.

Summary

Becoming an Agile coach requires a deep understanding of Agile, the confidence to drive change and a willingness for self-reflection. The role of an Agile coach is a rewarding one that allow you to use a wide range of skills across technical, social, business and communication disciplines.

8 Tips For Agile Coaches8 Tips For Agile Coaches

If you are interested in reading AgileTODAY, you can subscribe to the print copy or access the past issues online.

This article is also available on Adrian’s blog.

Episode 29: Offshoring at IBM

The Agile Revolution's avatarThe Agile Revolution Podcast

IBMCraig, Tony and Renee talk about the news Scrum Inc style, discuss the coolness of Lego for reporting, chat about Net-Map and discuss the state of IBM.

Quotes:

“Anyone who has never made a mistake has never tried anything new” – Albert Einstein

“The greatest waste is failure to use the abilities of people. Learn their frustrations and contributions they’re eager to make” – Deming

View original post 150 more words

Episode 28: Lean Starts Us Up and The Agile Top 20

The Agile Revolution's avatarThe Agile Revolution Podcast

Lean StartupCraig, Tony and Renee go all Lean Start Up and look at who made the Agile charts.

TheAgileRevolution-28 (43 minutes)

View original post

Episode 27: Retrospective Cookies

The Agile Revolution's avatarThe Agile Revolution Podcast

FortuneCraig, Tony and Renee sample some mmm… retrospective cookies:

Quotes:

“Value might flow. New products might flow. But does the learning your organisation makes flow from project to project?” – Michael Kennedy

“The more you create separate roots (value streams) the more you damage capacity” – John Seddon

TheAgileRevolution-27 (42 minutes)

View original post

Episode 25: Cultural transformations with Agile

The Agile Revolution's avatarThe Agile Revolution Podcast

YoghurtCraig, Tony and Renee debate the role of an Agile Coach and how cultural transformations fit in.

Quotes:

“Management does not know what a system is” – Deming

“The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small, manageable tasks, and then starting on the first one” – Mark Twain

View original post 38 more words

Episode 24: Ghost In The Room

The Agile Revolution's avatarThe Agile Revolution Podcast

GhostbustersCraig and Renee stand idly by while Tony has a rare rant on Agile versus KANBAN versus the world and they cover Stoos in depth.

Quotes:

TheAgileRevolution-24 (40 minutes)

View original post

Episode 23: Revealing Frequency Foundation

The Agile Revolution's avatarThe Agile Revolution Podcast

Frequency FoundationCraig and Tony listen to Renee’s revelations about the Frequency Foundation, and they talk about some Agile stuff too.

Please note the 2007 reference to the start of the organisation is incorrect. The actual date was in April 2002. 

Quotes:

View original post 35 more words

Episode 22: New Years Revolutions

The Agile Revolution's avatarThe Agile Revolution Podcast

PartyCraig, Tony and Renee get together before the Christmas and New Years break to catch up on all things Agile:

Quotes:

TheAgileRevolution-22 (47 minutes)

View original post

Episode 21: YOW Developer Conference Wrap Up

The Agile Revolution's avatarThe Agile Revolution Podcast

YOW! 2011Craig and Renee wrap up the YOW! Developer Conference and discuss the geek aspects of it and then how some of the conference related to Agile.

As a side note we plugged two other podcasts, Coding By Numbers, who were also at YOW and did a little bit more of a developer focus on the conference, and a plug for Agile NYC.

TheAgileRevolution-21 (25 minutes)

View original post

Lean Software Development Workshop with Mary & Tom Poppendieck

YOW! 2010I was cleaning up some old files, and came across my notes from a workshop I attended with Mary and Tom Poppendieck entitled Lean Software Development – Leaders Workshop at the YOW! 2010 Australia Developer Conference in Brisbane. Obviously the slides and commentary have a wealth of information, but here are some of the key takeaways I had.

  • stop doing stuff that does not deliver value, not laying people off
  • spend time doing the right stuff, not the wrong stuff
  • think systems, not software – Southwest think employees, customers and then shareholders
  • optimise the whole system (software is just a layer) – Amazon is structured around it services (2 pizza teams of 8-10 people)
  • a separate testing team is silly – just handoff / afterthought, need to build quality into your product
  • need to understand value before you deliver value – understand what your customers value, not what they want and build the right thing before building the thing right
  • setting up a new product is a set of learning loops
  • watch for what is making people uncomfortable
  • understand your customers not by bringing an idea but by taking the team to understand the problem
  • there is always demand in a service company – fix issues as fast as possible, but that is not the game
  • consumability – how much effort does the customer need to go through to get value?
  • customers decide value… and therefore decide waste
  • measure productivity on value delivered, not features
  • work in progress is waste – customers are not interested in your long list of things to do
  • good Agile teams have a low number of defects
  • map end-to-end flow to find the biggest opportunity in your end-to-end process
  • 40-90% of the cost is maintenance not delivery, the cost of quality is way higher than the cost of building quality in, don’t put defects on a list (track them, fix them immediately), root cause every escaped defect, determine why every one happened
  • problem with readable specifications is that the text is not refactorable – any text page will have hundreds of ambiguities
  • every organisation that calls itself professional should be doing TDD
  • legacy code is code without unit tests, use Martin Fowler’s strangler pattern or the Mikado method to refactor
  • expertise takes 10 years / 10,000 hours of deliberate practice, need a teacher to challenge, feedback and dedication (The Road to Excellence)
  • marketing leader – for a successful product you should be able to name this person
  • technical leader – keep two top engineers free to roam around and give guidance
  • Empire State Building – on time and under budget, had to manage the flow of materials not tasks, had two alternating mills to keep up schedule and remove failure point
  • people who have dome something before should know how to deliver within the constraints
  • when managing an organisation you need to manage the capacity, you need to have a stable flow
  • kanban – reduce work in progress to expose problems (don’t crash your boat on the first day, keep your limits high then lower your limits and remove your problems one at a time
  • kanban board – every column is handover to the next column, the next column (downstream process) gets to define done
  • 5 why’s – the cause of the cause of the cause of the cause…, The Team Handbook has good process improvement practices, as do the Six Sigma tools
  • delivering value – read Competitive Engineering by Tom Glib and Value Driven Development
  • product-centric development – 54% of Fortune 500 companies are heading in this direction
Here is a picture of an exercise we did to map the cycle time of a particular company (it highlighted some of the issues they are having around approvals).
From Miscellaneous

Finally, a huge thank you to Nick Muldoon from Atlassian who helped me out with a space on this course. Also to one of my colleagues who reminded me that we should ask forgiveness not permission when I was dealing with some competing priorities!