With Renatio we developed our agile coaching while doing it. We introduced teams into an approach that was focused on 5 key targets :

1. Establish a direct connection with the external user/customer
2. Create truly cross-functional teams
3. Focus on products instead of projects
4. Include product management in the team
5. Introduce design thinking

Would one call this agile coaching ?
For sure some key strongholds of agile are in scope here. It’s an enormous challenge to get all five of these targets realized. And, we have to admit that we were not always able to do so. But in the last 6 years a big maturity leap took place in our teams. Even with a few of the targets established we saw an important decrease of lead time, increased flexibility and increased quality. This sounds very agile to me.

Yet, we want to warn for inflated expectations when it comes down to agile coaching.

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.

We agree wholeheartedly with this, and have even 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, we 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? We would expect each and every agile coach to be different, just as we 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 we 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 speciality, and supporting each other in that.

That being said since 2007 we have been leading quite some transformations with companies such “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 we 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 agiletransformations 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)

To summarize; the Renatio team has a pragmatic approach to agile coaching. We think it’s focused on 5 key targets. And we argue that specialization is allowed in agile coaching. Next to that, we strongly defend an agile coaching that can mature over time, while doing it. No agile heroes required!

Previous publications

Upcoming publication: [07.07.2020]
“Define business value in agile”