Our Global Agile Transformation Journey – Part 6

In?Part 5 , I shared with you how we –

• Determined a release cycle that would meet our agile objectives as well as meeting the release requirements of our stakeholders.
• Prepared for our first agile planning session.
• Facilitated the teams to self-organise.

This week I am going to share with you how the teams turned painful day-long planning sessions into just a few hours, what they learnt and how they adapted.

I struggled writing this post as I found myself regurgitating the?SAFe ?documentation.

This word document stayed open on my desktop for days. I would revisit it each day but could not figure out in my head what to write about so minimised it.

I had to unblock myself!

After slapping myself about a bit today, I started to write whatever came into my head.

A lot of nonsense came out, but what I recognised was a theme. The same theme why I initially decided to create my career insights blog – to help others learn from what I have learnt and continue to learn throughout my career as a technology leader.

So, this post is about learning the team, and I went through during our agile planning sessions so you can take it forward into your career.

Anyway, that’s enough waffle, let’s get back on track.

Product Owner Bandwidth

At the start of our journey, any team could take any story from any product owner, which spread the product owners across multiple teams. It was agreed that each release, a product owner would be assigned to a single team eliminating the context switching overhead for the product owners.

The product owners also stated that they struggled to get their user stories done on time due to everything else they were doing and wanted the BAs to work for them –?organisational drag.

The BAs also felt a bit lost in the teams on what they should be doing, so we agreed that they would stay with their teams and support the product owners with the stories as well as support the teams with their understanding and functional test definition.

User Story Quality

The teams spent a lot of time in the planning sessions understanding and breaking down the stories to a position where they could break them down into tasks.

Before the next planning session, the teams would implement the three amigo’s meeting. The product owner, a team member and the scrum master would get together to ensure the user story was refined enough for planning and passed the team’s?definition of ready.

The product owners also started writing stories in pairs to validate and challenge each other’s stories.

Definition of Done

When we looked at the team’s task boards compared with our hygiene goals, there was inconsistency in what each team considered complete.

We explained this to the teams and asked them to collaborate on a?global definition of done?that will be adopted from now on.

Mindset

At the start, the coaches spent a long time on the team’s mindset e.g.

• They struggled to understand how to break the stories down into single threads of functionality that would run front to back across the tech stack and could be tested and demoed to the users, even if the demo was just the output from a log file.
• They wanted to break down the sprint into waterfall phases – analysis, design, code, test.

T-Shape Developer

In?Part 4 , I described how the teams were originally component and technology aligned, i.e. GUI (C#), Middle Tier Services (Java) and database (Oracle).

Now the teams consisted of people from each component and technology.

However, if a sprint required more effort on a particular technology, the other team members were confused about what they should work on.

The coaches shared with us the concept of a?T-Shape developer. A developer that could work across multiple technologies (the horizontal line of the T) and be an expert in one (the vertical line of the T).

Team members would be encouraged to pick up any work from the board whilst being mentored by the technology expert if required.

Productivity was slow at first, but as the team increased their capability across all technologies, so did their velocity.

It’s amazing how, as an organisation, we silo someone into a role of their technical expertise, i.e. the team’s Oracle guru also wrote Java in his spare time. Who knew?

Functional Experts

Occasionally functional experts would be needed to help out another team. During planning the teams would agree on how much time was required and also monitor this time reduced going forward as knowledge is documented and shared.

Production Issues

Production issues were originally assigned on a rota basis. During the agile transformation, the following saying was adopted –?

You crap in production; you clean it up!

The team would, therefore, plan some time post-release in their sprints to deal with any issues they’d introduced. It also put more mindset emphasis on hygiene goals.

Expedite

Work would often hit the global team that required it to be completed within hours, i.e. report for the regulators, external auditors, senior management etc.

When these requests came through, I would often think of a saying that a colleague of mine used to have printed on a sign on her desk –?

Your lack of planning is not my emergency!

But decided that I wanted to see this agile journey to the end, so each sprint we would ask one of the teams on a rotation basis to save some bandwidth for these ad-hoc requests.

Sneaky Product Owners

It came to the attention of the coaches and leadership team that the product owners would try and add scope to a committed sprint.

We agreed that it was up to up to the team whether they accepted additional scope into a sprint and if they did, what would move out to accommodate it. We also asked that this was tracked on the agile boards to see the impact on the team’s burndown.

The teams discussed the impact on the sprint in the retrospective to see what they wanted to do in the future.

Those Who Shout Loudest

Individual team members seemed to take over the planning sessions with their opinions. The coaches would help the scrum masters create a safe, engaging and encouraging environment, so other views were shared freely. It took some time, but everyone started to participate.

Conflict

During the planning sessions, I would observe the conflict between individuals in a team which, as a leader, I felt I should be managing. But observing these situations for a while, I realised the conflict was positive and that innovative solutions were being created off the back of it.

Did They Every Need Us?

The most significant learning for my leadership team and I was that we no longer added value to prioritisation, planning, solutioning and committing to deadlines. To be honest, we probably never did and just got in the way.

Although one of us still got involved in solutioning and probably still does. You know who you are – lol.

We could now focus on removing the team’s impediments and other strategic work.

Overall

In preparing for battle, I have always found that?plans?are useless, but?planning?is indispensable.

DWIGHT D. EISENHOWER

I was shocked about the amount of time the teams would spend in planning meetings at the start.

But after six months, the impact was substantial –

• Planning down to 2-3 hours each sprint – we probably spend more time planning a holiday which costs a great deal less.
• Visible progress daily with impediments mitigated in near real-time.
• 80% of the team’s commitments were delivered every release with known impediments and mitigation plans.
• Ability to adapt to change without a lengthy and painful change request process.
• The right people for the right job.
• No more priority escalations.
• Plus, a lot more that I will describe in a later post.

In Part 7 , I will share some stories about how the clients reacted to our agile transformation.