Coaching does not come ready with prescriptive and well-defined steps, there is no one size fits all solution. Every team is different, individuals within teams are unique and collaborate in their own ways with other individuals, within their team and without.
To be a good coach one must observe, align, facilitate, and support.
Rushing in without context and instead relying on past experience is a recipe for failure. If there were a perfect way for all teams to conduct themselves it would have been written about and sold, making the author a large amount of money and eliminating the issues that plague software development and delivery. There is no silver bullet and there is no grand conspiracy to hide the solution from you and your organisation in an effort to sell more books on the topic – the truth is these authors of popular methodologies are selling their best guess at what is likely to work in some cases based on their past knowledge and experience.
To say one methodology is the single best approach, is contrary to being agile and pragmatic.
When you get out of bed in the morning and throw on your clothes in an automatic fashion you might find you have put your shirt or blouse on back to front, or that the combination of clothing you have chosen doesn’t quite look right. Instead of continuing to make fashion faux pas you are likely to buy a mirror as a remedy, realising that it is not a solution but a sort of ‘coach’ to help you reflect on your situation from a different perspective.
A good coach is like a mirror, they do not come with preconceived notions about what is right or strongly held opinions on bad practices. The coach facilitates a team and its individuals to view how they do things from different perspectives, bring light on the not so good aspects while supporting the team in identifying better ways of working.
Knowing and understanding the subject material allows a coach to understand where a team is currently and what can help us improve, plateaus are inevitable and coaches are there to help us stay motivated.
Agile software development is deceptively simple. You just choose something is to build, building over a short period of time, reflect on that building period and repeat this process into your product is ready ship. If agile software development is that easy, why do so many teams and organisations get it wrong?
Most teams that start adopting agile methods generally see improvements early on, while some teams get stronger and stronger with every iteration. The majority of agile offer development teams struggle at some point early on and crumble, favouring to blame the organisation or the client, or the particular flavour of agile they are currently using. Maybe we should be doing XP or Lean instead, we all know management will support our “being agile” by ditching the methodology that is not working well for us and being fluid enough to pick up the next buzzword methodology, but they will only support that decision once.
The next time you decide to move onto another methodology management will quite rightly question, “What is going on?”. All management care about is delivery of a quality product for their client because that is precisely what’s the client cares about, I think it is important to remind ourselves at this stage that agile methodologies are for the clients and stakeholders, not for the development team. Although the development team leverages agile principles to produce and deliver a product, we deliver these products using these principles to over deliver to our clients by demonstrating that the modern way of working is far better than the old way we are trying to get away from.
“That last methodology we tried wasn’t quite right for our team, this new methodology we’re going to use is the gold standard. Lots of influential people are writing blog posts about it and it has a really catchy name.”
Agile methodologies are starting points. They are not inflexible documents chiselled in stone like a set of commandments. The whole point of agile is the try something for a short period of time, reflect on what you tried, and do something about what is not working.
Inspect and adapt
Coaching is all about finding better ways to do things and getting those new things in place, running them through a feedback cycle and iterating. To do this you need to understand the situation.
An agile coach does not have all the answers but they have the knowledge and experience of working with many different teams, with proven outcomes where a combination of observation, experimentation, and time will enable the team to hit on the right approach.
Every person in a team and an organisation is different, you cannot prescribe what should do in a particular situation. Your goal as an agile coach is to effectively read the team dynamics and understand how that team operates so you can facilitate productive growth of the teams collective output to best serve the client and stakeholders.
Showing people how to be agile isn’t enough, the principles are so simple even a five-year-old can understand. Delivering agile requires an individual or team to change the way they work and think about software development and delivery. One team may require you to actively showed them how agile practices work, while another team will benefit from you listening and asking questions instead of offering solutions. Getting a team to the point where they asking these questions of themselves is a good marker to prove coaching is paying off.
Good coaching is sequential and patient. Rather than creating a whirlwind of information in an attempt to quickly solve an underlying problem, step-by-step efforts to build a team up gradually (taking care not to overwhelm) have a better chance sticking in the long run.