Agile Coaching@Scale – A Case Study

It’s been a while since I posted. This post was 4 months overdue (very sorry to people who were waiting on slideshare). As a reflection of 2017, I had spoken at Agile France in December 2017 on agile transformation, a case study of my work in Asia. Mid 2016 – Mid 2017 was a trying year and possibly the first time I combined change management, HR and agile in 1 single assignment. On reflection, I used Agile France speaking opportunity to synthesise my learning. And honestly, if I were not selected to speak, I was not sure if I would have taken time to reflect and retrospect. (Yes, very un-agile of me.)

Unplanned Work

I was starting a coaching assignment in a bank and the original ask was to coach a few teams on agility. Most agile coaches will be familiar with this. Coaching a few teams in a large network of people meant that you can only be as agile as your system and lowest denominator.

Working up the hierarchy of problems, I met with the leader of the group who had also recently joined. His support for agility is not only unwavering but involved. And this began the journey to transformation.

The System Within The System

The group consisted of over 500 people who later grew to 700 people of largely contractors and project work. This meant contracting and re-contracting every 6 months with a break of possibly 3-6 months in between that made up a financial year. And they were supported by back end systems belonging to another unit and waterfall in their approach.

Sounds familiar? This is your typical agile sandwich, front and back of value stream in waterfall and agility in between. End to end cycle time of 18 months. Agility within those short 3-4 months of development. Here’s the composition: 6 months business approval and requirements writing, 3 months to recruit and kick off, 3-4 months of development, 4-6 months of SIT, UAT, release and deploy. That’s if nothing changes. (Budget, workforce, market, stakeholders). In today’s world, I’d say pretty utopia to expect no change.

Ca Se Fait Pas (We Don’t Do This…. Or Do We?)

If I had continued coaching as I intended, coaching 3 teams for 3 months, it would have taken years or a large team of coaches to get this many people to agility. And by the time I’m done with 3 teams to move on to another 3, they would be so frustrated by the hampering of the entire system that they would have reverted to waterfall or worse still, some hybrid of waterfagility (my new word) that combined the worst of both worlds because it’s way easier to pick up bad habits then form good ones.

In truth, I did it for 3 months before I realised that it’s not going to work. Every problem I solve for the 3 teams I was coaching was the problem I had to solve at platform level. So this was what we decided together, we will not try to perfect agility. We will take a release by release approach. That meant, everyone will be on the journey together and agility will be like a product release, release, learn and pivot, release, learn and pivot.

HR Biased

I’d admit, I have a people biased. That meant that I start most transformation with an organisation structure and development lens first. We formed teams first. It’s also what I found required for agile, we simply cannot function with project teams with large groups of people. The only difference, we form 65% full teams and as multi-discipline as possible to start with. Cross function teams comes later through resilience building.

Every initiative (I threw out the word project, along with many others like off-string, in-house) started with forming teams, inception and scrum. Every squad has to have a PO, BA, Scrum Master, Developers and Testers. Everyone was dedicated except PO and Scrum Masters who can be dedicated to 2 teams. Every squad has a name. And I cross checked names religiously to find no repeated names in 2 squads. (Imagine 15 names x 20-30 teams and long Indian names.)

With the roles defined, it also meant I could coach by roles. Every week, I spent 1h with all scrum masters and 1h with POs and BA in coaching sessions. We started with basics then moved on to more complex issues.

Tooling & Compliance

I believe in forming good habits at the start but not all at the same time. I was strict with the squads, they didn’t have to do everything, but some things were compulsory and non-negotiable from the start. Jira-Confluence was the chosen tool and everything had to be there. Since they were distributed teams, Jira is the source of truth for the work to be done. Although inception material can be on post its etc.

Quite early on, we tackled the problem of documentation. It wasn’t easy to change the way requirements were written and kept reminding everyone that we can be more compliant when documentation is actually what was built even though they were just in time.

Coaching @ Scale

There is no way humanly possible to ensure 500-700 people were coached. And there was no way I can attend all the ceremonies. Thankfully, we also didn’t start everyone together. On average, we have a new squad forming every 2 – 3 weeks. So while the next one is getting ready for inception, I focused on starting 1 “properly”. Let’s say cleanliness has degrees, there were dirty corners, hidden trash but overall, the house was neat and mostly clean.

There are 3 indicators I use religiously to know if the squads were having problems:

• scrum masters, POs, BAs missing weekly coaching sessions. When they don’t come for the sessions, they would send apologies due to conflicting meetings etc. It usually meant they have not been caught up but were caught up in a bad cycle.
• burn down starts to look like a burn up and then sudden dip end of sprint or not at all. Since everyone had to use Jira and I was strict with estimation standards and use of issue types, it was easy to see burn down charts of all the teams. Just from the burn down, I can usually tell if the team was over committing, not slicing down work, bullied by PO, skipping their ceremonies or sprints.
• scrum of scrums had the same issues repeated more than once. Since every week, scrum masters synch on issues and report out impediments, it’s also my opportunity to know where there are problems.

Every week was a habitual meeting with leaders 1-1 sessions. These 1-1 sessions combined with observations on team performance was how we know what problems to tackle first and predict what might come up.

As a coach, I used all my consultant cards to tackle the rest of the system including:

• business stakeholder requirements – I think a scrum master actually recorded me saying that this release can only take x points, it cannot take x++ and played it back to business. And x was a stretch leaving no room for unplanned work, full capacity and assuming component teams behaved.
• component teams and code drop – they can be as waterfall as they want but we will negotiate to death for weekly package and if not fortnightly and if not monthly.
• vendor teams to be co-located – finding seats and having ceremonies in the same location if they were in the same city / country
• audit and compliance – I kept asking, who’s rule is this and dig as deep as possible to the rule writer to have a conversation.

 

Reflections

In truth, I think I could have written a book just on the experience and learnings. I would probably not have 1 coach but have 2-3 and work as a team.

And in deeper truths, some coaches will this way of coaching without finesse, a bit of brut force. Some were appalled with the elements I used that looked like SAFe, some were puzzled by the lack of framework, and some were upset with some non-agile elements.

And I would still say, what’s the minimal viable version of agility? And iterating as we go.