When Agile Coaching Stalls – Dealing with Counter-Agile Managers, Cultures and Other Agile Anti-Patterns in Your Host Organization
I worked in a large organization on an agile transformation project within one (non-IT) department. The stint was successful as a learning experience for the coach but arguably less so in terms of the progression of the agile transformation in the department. I and a number of coaching colleagues tried to do two things – improve team practices/cultures, and also to scale. We ignored the general agile advice not to scale until we got the team level right – a mistake of course. This blogpost will look at some of the reasons why this coaching engagement was challenging and draws some conclusions about setting up for success early in the process.
So, I was coaching and scrum mastering a number of teams working on the company’s brand, products, and services including the customer-facing mobile app. Note that this was an Australian company, so the cultural context is quite different from Indonesia.
Coaches were employed as “agile project managers” – an anti-pattern if there ever was one. You can often make too much of a job title, and I don’t really care about them, job titles and designations shouldn’t impact on your ability to function as an agile practitioner, but it was revealing in terms of middle management’s understanding of Agile. The biggest problem though was that the Agile PM roles reported to a middle-manager in each of the various areas – although coaches were encouraged to talk and collaborate, the coaches reported to separate managers who had very different attitudes to Agile and what the role of the coach was. This was a problem, more so than that of the job title.
Senior Leadership Attitudes
Senior leadership’s attitude was positive. Their vision was to go from being an adequately functioning department to a great one, and they saw Agile as a critical part of this. They were fuzzy on the details but willing to listen to advice from the Agile coaches. The main challenge in this area was helping them to move to a “less-is-more” approach – do less work but of higher quality. They wanted this, but planning made this difficult, and at the team level teams tended to try and deliver everything within a body of work – because there was no internal prioritisation until they ran out of time and cut whatever was left. This prompted us to try to scale – at least from an overall work visualisation perspective at the portfolio level this worked, but beyond that we were not very successful at our scaling attempt.
At the local level the teams were practicing a form of Scrum – previous consultants had instituted a basic Scrum-like framework for many of the teams. Training had been minimal, so teams thought that doing practices was “being Agile”. There were other issues: teams had no real product backlogs and did not track deliverables even on the sprint board. Teams had high level backlogs with deliverables kept on separate spreadsheets, not visualised anywhere. Sprint plans were largely an exercise of team members writing all their anticipated tasks for the sprint period on cards and trying to estimate (in hours) each task to do a kind of sprint capacity plan. Teams didn’t really understand the concepts of visually tracking deliverables or backlogs beyond the current sprint. The teams also had a belief that their current approach was “best practice” – another anti-pattern. I was never sure whether the previous coaches had confused them in this way or it was something they had conflated from other management languages. This made them sometimes reluctant to experiment and also made them look at me strangely at times for suggesting changes. Product owners were non-existent or ineffectual.
Nevertheless, teams soon were able to contemplate changes after I reintroduced them to the concept of inspect/adapt. Their retrospectives were actually pretty good – they enjoyed them and made constructive suggestions. I instituted record keeping for retros and insisted on checking on any actions/improvements instituted by the next retro. Progress was… well, OK. Part of the problem was that on being hired, I was told that all change must be gradual as teams had had a major reorganisation six months before, so major change was not recommended. (In hindsight, I should have ignored this stipulation.) Teams were also overworked – they tried to do everything. There was limited backlog visualisation, so there was no prioritisation. Eventually, I was at least able to get them to think about 90 day forward plans with deliverables and dates as a backlog – this helped them to some extent with planning, resourcing, prioritisation of deliverables and then with sprint planning. Hopefully, they are continuing this practice today.
Coaches were also required to work as Scrum Masters – this could have been OK, but the medium-term plan should be for SMs to come out of the local ranks. Previously scrum masters were local – but as marketers, the local scrummasters realised quickly that they were judged on their individual delivery, not their Agile practices, so they lost interest. As a result, I was working as a scrum master for 3-5 teams. Keep in mind that this is not software development, so it’s not like needing to be deeply immersed in the work of a development team – nevertheless, this was just too many teams. Scrum ceremonies could be scheduled and managed, but having a good knowledge of what was happening to each team became impossible. Some middle-managers saw our work as facilitating Scrum ceremonies only – so surely we could do that for ten teams right?
What Worked Well
Visualising backlogs through 90 day plan views – this was actually effective in allowing teams to understand work coming up and prioritise deliverables to an extent. This meant teams that adopted this approach could track delivery of campaign assets and make a call as to what to include and what to discard. At the portfolio level, we had success in generating high level backlogs and deliverables over a three month forward view. Tribes and squads worked to an extent – it meant we could engage other team/divisions early, and it exposed the problems of hand-offs, waiting and prioritisation to inspection and adaptation. Less progress was made on actual adaptation though. On the plus side, teams actually executed Scrum meetings effectively, solving problems and working together. Retros were also good in terms of identifying problems and bottlenecks and trying to solve them. I managed to get some teams to move more towards a ScrumBan approach, and to use a 90 day plan view of deliverables to help them with planning and to use for sprint planning.
Overload and middle-management command-and-control ultimately killed this work for this coach. My manager actually told me that being a scrum master for one team should be 0.1 of my effort – this manager simply calculated the time required for all the scrum ceremonies and calculated that I could, therefore, scrum master as many as ten teams if I did nothing else. But also slow progress on scaling and changing team practices meant that ultimately the coaching team was seen as not adding enough value. I shifted to another area where Agile was better understood – which for an Agile coach must be regarded as a failure – I failed to adequately change the local understanding of Agile enough.
Self-Reflection and Improvement
Agile coaches can and should always consider their own professional practice – we inspect and adapt the work of others, so we should try to do the same for ourselves. An overload of scrum-master work meant that it was easy to neglect the bigger picture on the grounds that I didn’t have enough time. There’s also a trap for coaches (or anyone) in bigger organisations – it’s easier to hide, and to just go about your daily business, keeping busy. Always ensure that you keep your focus on your main goal as a coach, improving work practices, challenging ineffective ones and being a catalyst for positive change.
There were structural reasons why I was not successful as I could have been but did I do enough to change the game? Coaches have a limited amount of initial social capital – if you don’t use this wisely, it can swiftly become depleted and then the coach is on the slippery slope to ineffectiveness and an early end to coaching contract. In hindsight I would have worked harder and closer with this manager to overcome obstacles – it may not have worked but it would have been worth trying.Building better alliances with senior #agile champions leverages #agilecoaching. Click To Tweet
A coaching colleague in this same organisation was much more successful at setting the ground rules in her area – “I am here to help your team to improve their Agile practice, not anything else”. This coach had taken a low performing team with a domineering manager who thought he understood “Agile” – he didn’t – to a place where they were at least practicing a functional form of scrumban, so she had a good amount credits in the bank. She was also very successful at setting up a portfolio 90 day planning board, so managers and leaders could forward plan and prioritise – this is important in complex environment where dependencies between and across teams cannot be eliminated.
So How Could Things Have Worked Better?
- Ensure that coaches report to one central Agile champion to whom they are accountable – not to middle managers dispersed through the department. If you can’t get this set-up on entry, things could be difficult down the track.
- Work on mindset and culture at the team level. Ensure they understand there is no “one right way” – their role includes changing and improving themselves
- Don’t try to scale before getting mindset at the team level right (I know right?).
- Fight attempts to broaden the role of the coach to be a delivery resource – coaches are not deliverers, except in terms of improving team practices and mindsets.
- Ensure that senior leadership in the host organisation understands your value – so make sure to work with them on their Agile practices and understanding also.
- Preserve and build your social capital in the organisation. Yes, this is political, but also necessary if an Agile coach is to be effective and remain effective through the duration of contact with the client.
- Don’t be scared to act and make strong decisions about how you act, even if some stakeholders don’t like this. In the end, a timid Agile coach won’t succeed.
Leave a Reply