Our Agile Global Transformation Journey - Part 5

In?Part 4 , I talked about how I communicated my global agile transformation vision to the London team. This week, I am going to share 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.

Although I’m struggling to recall all the facts from 2013, I am enjoying reliving the journey. I hope you are too.

Agile Release Train (ART)

The leadership team and agile coaches sat down together to define the agile release train.

Although we’d done agile training, we hadn’t done SAFe training, so the agile coaches were cleverly moving our process knowledge forward in increments, so not to overloaded us.

They explained that in simple terms, an agile release train aligns a set of cross-functional teams to deliver defined increment value known as?program increments (PI) ?to our business clients.

It departs the station at a specific date full of passengers (functional changes/features to meet a specific business/technology objective) and arrives at its destination station to offload its passengers (deploy fully tested solutions) at a specific date in the future.

A PI is broken down into a number of two weekly system increments where at the end of each increment, the software has been defined, developed, tested and demoed to the business users who sign off it meets their requirements. It can if possible, be deployed.

The system increments are a number of development sprints usually followed by a planning and innovation sprint.

At this stage, we just needed to decide on the cadence of the PI. We can work the rest out later.

PI Cadence

I outlined that we didn’t have a standard release cycle due to the demands of our stakeholders.

Our two main stakeholder groups were –

• Our business users where we can control the UAT and release dates.
• Business and IT programme managers with their own committed UAT and release dates to their own stakeholders.

The coaches expressed the importance of cadence to ensure important events in the agile process, i.e. PI planning, system demos, inspect & adapt workshops, etc. all occur on a regular, predictable schedule.

This creates full transparency as well as lowering the cost by enabling these events to be planned in advance.

The teams also start to work to a standard rhythm and automatically know what they should be doing and by when. The coaches stated that the process eventually becomes a synchronised heartbeat across all the teams.

Taking into account our agile objectives as well as our stakeholder requirements, we decided that we would release to production every six weeks. If our stakeholders UAT and release dates did not align to these cycles, we would plan to release our changes to production earlier than they needed. To ensure the functionality was not used until tested/signed off, we would use two configuration switches. One switch to turn the functionality on in a UAT environment and another for production.

This was something I needed to discuss later with the stakeholders to ensure their expectations were managed and that we got their requirements in time.

System Increments

We then looked at how the six weeks would be broken down into two-week system increments.

I outlined our current develop/test/release/deploy process –

1. The teams would develop their changes on separate branches, and the QA team would test them manually.
2. When we are ready to regression test the system, the teams will merge their branches into the release branch. There was a significant overhead of resolving merge conflicts as well as the risk of breaking functional changes. The merge team would identify the risks and QA would then retest.
3. QA would then manually regression test the system and UAT the changes with the business.
4. The release team would then raise the relevant paperwork, get the required sign-offs and deploy the software into production with the help of production support.

The coaches stated that at the end of every system increment, the functional changes should be tested by the agile teams (automated and not done by QA), signed off by the business users and ready to deploy.

The coaches asked how long merging, regression and deployment usually took. I stated that it took about two weeks.

Hardening Sprint

The coaches proposed that one of the system increments should become a hardening sprint where the agile teams would help QA get the team ready for release.

I asked what the agile teams would be doing during these two weeks as it seemed as waste as they could be developing functional changes for the next release. The coaches stated that the teams would be –

1. PI Planning for the next release.
2. Merging and rerunning their automated functional tests after the merge.
3. Focussed on eliminating the hardening sprint by automating the regression testing that the QA team still had to do as well as moving us towards a Continuous Integration/ Deployment pipeline.

We should also eliminate the wasteful and risky activity of merging. All the teams should merge their changes to the release branch every ten minutes or less. I’m not sure if they saw the horror in our faces, but the coaches quickly jumped in and said – “we can discuss this later on down the road.”

I liked the goal of eliminating the hardening sprint by focussing the development teams on it. We had tried before to automate the regression with the QA team, but other demands on them took precedence.

Every release, we were continually paying a high amount of interest due to our increasing technical debt and lack of automated testing. It was time to start reducing the notional.

I was in, and so was the leadership team.

A program increment would be six weeks. – Two development sprints and a hardening sprint.

Advance PI Planning

The leadership team sat down with the project managers now product owners to determine which work would be done in London and which work would be done by the rest of world.

The project managers pretty much worked this way with the regional team leads anyway, so wasn’t a big change. We had enough of those going on.

The coaches worked with the product owners to define the business context for the PI as well as creating the EPICs & user stories.

We were not ready to start planning — time to start organising the teams.

Self-Organising Teams

The coaches took the teams off to a big meeting room to self-organise. The leadership team were not allowed to attend to avoid what they called – “influencing.” I did, however, ask afterwards how the coaches facilitated the exercise and how it went.

The coaches said that each person was given a badge displaying the skill ratings that they had given us from the survey.

On three of the walls was an A4 sheet stating the acceptance criteria for each team.

The teams were asked to organise themselves under each sheet of paper, ensuring they met the acceptance criteria.

The coaches then assessed the teams against the acceptance criteria and asked them to reorganise if they didn’t meet it.

It took a few iterations, but the teams got the sign-off. Apparently, it was fewer iterations than they were used to.

Scrum Masters

The coaches outlined the role of a scrum master, and the teams were asked to select a team member as their scrum master. Andy, Ian and Ainsley were chosen.

The teams were then asked to give their team a name – Zoo, Bolt & Everest were now ready to?form, storm, norm & perform .

The rest of the day was spent with the teams moving their equipment so they could sit together as well and setting up their scrum boards on the wall. Site management wasn’t happy with me as they had to update the desk plans and re-patch the phones.

What's Next

In?Part 6, 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.