Agile Coaching isn’t about adopting Scrum or changing Ways of Working
It’s about solving problems
Why are we hired as Agile Coaches? Or why would you hire an Agile Coach?
Is it to “be more agile”? Is it to “transform our ways of working”?
As Agile Coaches, we are hired for our expertise, our knowledge and experience of agile methods, and of implementing them in organisations just like yours. But is that enough?
If you are an agile coach, you have probably experienced resistance to your suggestions. Have you tried to schedule daily team meetings in a team that wasn’t cross-functional, wasn’t self-organising, had multiple product owners, or sub-teams? Have you been frustrated at how few people accept your invitations to new ‘ceremonies’ or workshops? How difficult it is to set up a community of practice? Have you ever had someone say they are on board but then decline all your meeting requests?
In the organisations I have worked at over the past decade or so, I have been involved in numerous attempts at a “transformation”. In all cases, the objective is to transform the way work happens. More often than not, I am hired as part of a team tasked with rolling out an agile framework.
But in many cases, I have seen a fundamental problem — a disconnect between what the transformation initiative is attempting to change, and what the organisation expects to achieve from it. Changing the way we get work done does not always result in significant organisational benefit. Change, yes. Benefit, not always.
Ask the staff at any organisation going through an agile transformation to explain the reasons why it is necessary and what it will achieve, and my bet is most won’t be able to. Because the objectives are rarely communicated properly, if at all. It is not unknown for an organisation to embark on a multi-year, multi-million pound transformation programme with no concrete objectives at all beyond “be more agile.” And even when decent organisational objectives are defined, they are not cascaded down through departments, and teams, with the result that teams have change inflicted upon them, with no clear idea of why such change is required, and often in teams that should really be changing in a different direction.
When people don’t know why change is necessary, or they cannot see the benefits to it, they probably won’t change; at least not for long. People don’t mind change; they just don’t like being changed, and no-one likes to do something without a purpose. People will change their methods, practices and behaviours only when they can see there’s something better on the other side. And to get there, they need to understand what that will look like, and they will need to cross the “edge” of trepidation before they get there.
We can only coach people and teams when we all know where we’re going.
Everyone views a situation through the lens of their training and experience. Through our training and experience as agile coaches, we have come to see organisational problems through a lens of agile principles and practices. We have come to assume that when we are hired, we are hired to transform the organisation, to implement agile practices and train people in how to ‘improve’. Organisations have come to view agile as a silver-bullet to solve all their problems, or in some cases, as the scapegoat for future failures.
If our proposed agile transformation clashes with the organisation’s existing culture, is being resisted by the organisation-at-large, and does not have the necessary senior management support, is it possible that, with the best of intentions, we are trying to do the wrong thing?
This can manifest as “sheep dip” training (a very disparaging term, if ever I heard one), maturity models, (just as disparaging and almost always ineffective), and a consistent framework being rolled out to every team in the organisation… whether they need it or not.
I am advocating a different approach to agile coaching, one that focuses on solving specific organisational problems or achieving specific business objectives.
Agile methods came about in response to a set of related problems. The history of heavyweight bureaucratic plan-driven change processes is well covered elsewhere, as is the rise to global prominence of agile methods. But I fear that we have been creating almost as many problems as we are solving.
Agile methods and practices should not be the objective, but the means to an end. What end? Mostly, it’s about the organisation as a whole being able to adapt rapidly and seamlessly to new challenges or opportunities. If an organisation is impacted by the invention of a new technology, how quickly can it take advantage? When political upheaval approaches (say, Brexit) how will you be able to change focus and adapt? Does the whole organisation panic? Does it create a new department and move large number of people around, spend months analysing and planning? Or is it simply a seamless re-prioritisation and delegation exercise for every team?
If Business Agility is the objective, agile principles, methods and practices are a part of the solution. But what is critical is that the focus of the transformation remain on achieving the objective, not on implementing the whole transformation solution.
Don’t forget Kotter’s 8-step process, which applies very well to agile transformations. The third step, after creating a sense of urgency (which defines why you need to change at all) and building a guiding coalition (who will lead the change), is to form a strategic vision and initiatives.
Coaching without an objective is impossible, and coaching with a broad and vague objective is usually both costly and ineffective.
Only when we can coach teams towards a target, or at least a direction of improvement, can we be at our most effective.
Through coaching, we can help teams do things faster, do things differently or improve some specific aspect of performance.
In theory, Lean/Agile practices can make things happen faster by creating cross-functional teams with on-site customers, reducing or eliminating wasteful events or practices, starting earlier, iterating, reducing batch sizes, building in quality etc. But in certain limited environments, introducing agile practices and methods will slow progress, at least while people adapt, if not permanently. In others, agile might be inappropriate and could even make things worse. We won’t know the effect we create until we understand the situation and the objectives. The argument that organisations will be better when they change to agile ways of working should be used with care, lest we promise much but fail to deliver.
We can easily make things happen differently. But is that necessarily better? Again, only by understanding the problems, objectives and the situation can we tell what types of “different” will actually bring improvements. Otherwise, all we are doing is teaching.
As an example, I was once allocated to a team that had been using Scrum for nearly a year, and were doing okay. When I asked them what they needed and how I could help, they told me “Nothing, we’re fine.” Were they fine? Absolutely. Could they be doing better? Definitely. But unless a team wants our help, we’re the enemy and our change efforts are likely to ultimately be unsuccessful. We cannot impose change on those who don’t want it or need it or don’t recognise the benefits of change. Only when a team is ready to define what it needs can we truly coach them.
The primary reason for investing in agile coaching is to improve performance, however that is defined by the organisation and the teams. Whatever it is, the enterprise-level objectives for the transformation must cascade down to department level, where their context is added, and to team level where their specific challenges are added as well. These objectives become our objectives as coaches, how we know we are ‘Done’. This coaching ‘Definition of Done’ is what we capture in a Coaching Agreement (which will be the topic of my next post).
We need to adopt an approach which utilises the agile principle of simplicity to bring about the smallest degree of change that will go towards achieving a specific objective, iterate until the objective is achieved. Then select the next objective and continue the cycle.
This means that the client pays less money with a better chance of achieving genuine and measurable improvements. There are clear economic benefits to be gained from taking this approach. This principle can be used at every level of the organisation from the Enterprise as a whole down to a development team, or indeed to a single individual.
Our first rule of engagement might be defined as: “First identify and clarify the objective you will help the organisation or team to achieve, then help them make the smallest amount of change necessary to achieve it”. Let us not impose unwanted change just because we believe in it. Let us tie change directly to clearly-expressed organisational benefits.
