Considerations around agile coaching and agile transformation approaches

A reflection on agile coaching

As a curriculum only tells as much based on the various chapters in a career journey, I am taking the liberty below to highlight both past coaching experience, as well as to clarify my coaching approach.
A team, or organisation, wants to derive benefit from “agile approaches”, or get better at doing so, and as such wants to bring in a coach who knows how to help them in this pursuit. An agile coach in other words. They want, and expect, that the person is able to bring with them a focus on using agile philosophies to achieve improved outcomes in terms of software delivery and teams. Much of the controversy with this stance is that “agile” is not a goal, but a means to an end. So, the argument continues, we shouldn’t be coaching “agile”, rather we should be understanding what the person/people/organisation wants to achieve, and work with them to achieve it. I agree wholeheartedly with this, and have even written/spoken a lot about the folly of having “agile”
as a goal, whether it’s “being agile”, “doing Agile” or “working in an agile way”. It’s always important to identify the actual outcomes we’re aiming for and work towards them — “agile” is way too broad in scope and interpretation for that purpose.
However, I think it’s ok to say an agile coach “coaches agile”. Once a football coach is embedded in a club, they are no longer thought of or referred to as a “football coach”, just a coach. They are not teaching the players how to play football, they are trying to get the best out of the players and the
best results for the club. The same ought to go for an agile coach. They are a coach whose leaning, skills and experience are around agile principles and techniques. This does not make them a one-trick pony. On the contrary, “agile” encompasses almost every aspect of software/product development, from a
process, practice and human interaction standpoint.
 

Another thing to point out here is that I would not expect that each and every agile coach knows every aspect of agile and related philosophies, and has worked for years in “agile environments”. Why do we expect an individual agile coach to embody so much? I would expect each and every agile
coach to be different, just as I would expect each and every developer, business analyst, tester, product owner — or any other role you care to mention — to bring their own unique blend of experiences, number of years of experience, theoretical knowledge, practical skills, and other human
qualities and attributes to the table.

Football clubs know this. They don’t hire one coach. They have goalkeeping coaches, striking coaches, defensive coaches and more. Teams of coaches. Some young and relatively inexperienced, with no trophies to their name, and some older who have won silverware in different leagues and countries.
Each coach specialising in different areas of the game of football. In the software arena, agile coaches might specialise in technical practices, organisational change, team performance, facilitation, and more. Why should we expect every single coach to be able to do all of those things?
As such I have been supporting smaller and larger agile transformations, where the first transition to agility took place back in 2007 when I was responsible for the delivery organisation of an agency called "One Agency". We knew that for a Dutch insurance company there was no way we'd meet the
deadlines by organising our delivery in the traditional waterfall way. Back than I figured out what I needed to do, and what was expected of me, as I went along. I was a million miles from being the finished article, and the reality is there is no such thing. Anyone who thinks they are the finished
article, or even believes it’s possible to be that, in almost any discipline, is likely to become increasingly less effective.

I think we often (wrongly) elevate coach roles in software development to be the exclusive domain of folks who’ve been there and done that over at least 10 years in the industry. Instead, in my view, we ought to be looking at what the coach’s role is — what it is there to achieve — rather than put the
individual on a pedestal, with unrealistic expectations, as someone who is going to create benevolent disruption and magic. We should all be working and growing together, regardless of our role or specialty, and supporting each other in that.
 

That being said since 2007 I have been leading quite some transformations with companies such as "Goudengids", "Bridgestone Europe", "Colruyt Group" to a lesser extent by mixing and matching agility principles with the Colruyt Software implementation methodology.
However in the last 6 years, a big leap in maturity of the agility model was made by comprehending that whenever a typical agile transformation only takes place in the IT delivery teams, that only limited results will be reached. Going agile very often is considered as the team of developers, their
managers, and their manager’s managers. Most of the cases, no changes occur in how efforts are funded, their approach to product, or their approach to design.
 

Way too often it is sold as the silver bullet approach to software development that would remedy “being slow” and “not being able to pivot to get important things done”. 

What’s not to like? Faster. Agile! At Scale! 

What's really missing in this approach is:
1. Teams not having a direct connection with the external user/customer
2. No truly cross-functional teams (including designers, marketing, data science etc. not just
developers) owning a product… Not an Agile “build” phase in a predominantly waterfall process.
3. Products not projects. Starting together. Working together.
4. Product management not being part of the team…Not external to the team passing
requirements to a product owner.
5. The depth of design involvement in problem/solution exploration, and facilitating the team in its
approach to design (#2 extended)
 

In the last 2 agile transformations I lead, the focus has really been on business agility as opposed to Agile. Very often agility is referred to as Agile with a capital "A", meaning a noun, leading to the understanding that it is a recipe that when followed from A to Z will lead to magical results.
Whereas it is the agile coach to lead to insights in problem statements based on simple to understand KPI's, in order to trigger usefull discussions whereby teams start to recognise, understand bottlenecks and are triggered to look and especially take ownership of solutions. Where the role of the agile coach
is to trigger these discussions, and to provide options for the team to start experimenting until they own the solution. Giving them a toolbox of tools.
 

The past 2 agile transformations at "Ahold Delhaize group" and "Brussels Airport" have been based on a method that we developed using existing methodologies. 

Downstream (=the IT production factory), primarily a mix of Scaled Agile Framework, Scrum and Kanban. Using SAFe to plan the future, organise
collaboration, Scrum to bring cadence and Kanban to organise flow & understand past performance. Allowing to lead to recalibration and optimisation in the product increment meetings (SAFe).
 

Upstream (= the order book for the factory) using a similar 3-monthly cycle as put forward in Scaled Agile Framework. Using Design Sprinting for both roadmap development and Product Increment preparation as leading methodologies and basic transparency and product board principles to allow
teams to gradually define bottom-up understanding of business value.
As opposed to roadmaps being driven by the HIPPO principles (highest paid person's opinion) This approach has led to very predictable results, based on an active hands-on coaching approach that implied embedding into the teams and supporting them in achieving the set business goals
based on a more efficient way of working.