Our Global Agile Transformation Journey – Part 4

Our Global Agile Transformation Journey – Part 4

In?Part 3 , I shared with you how I got buy-in from senior IT management and my leadership team for the agile transformation.

Today, I am going to share with you how we organised the agile teams.

The Dream Team

The team has evolved from the merger of two teams and the creation of another.

  1. The GUI team which used the C# and .Net tech stack.
  2. The middle tier and database team that used the Java and Oracle tech stack.
  3. The release team – A deployment and infrastructure support team.

The team –

  • Was split across five regions – London, New York, Singapore, Mumbai and Pune.
  • Had a matrix of stakeholders – front office, sales, middle office, operations as well as dependent IT program managers and their subsequent stakeholders.
  • Was structured as team leads, project managers, business analysts, lead developers, developers and testers.

A Staged Rollout

As the team was so large, based in different locations and with only two agile coaches, we decided to rollout out the transformation in stages with London first followed by the rest of the world.

The release team would not change at the moment.

Self Organising Teams

I asked the agile coaches about how we should organise the teams. They told me that we should let them self-organise.

The leadership teams had always been responsible for organising their teams. I started to feel uncomfortable. This was a feeling I was going to have to get used to over the coming months.

“Surely everybody will just pick their mates to work with,” I said.

One of the coaches said “Probably, but there is an acceptance criterion that needs to be met.”

The coaches laid out the following criteria –

  • The team size should be seven plus or minus 2.
  • The team should be able to deliver a single business feature across the whole tech stack.
  • Roles were Product Owner, Scrum Master, Team member. We would look at who would be the release train engineer later. The agile coaches would perform this role initially.
  • The teams should select their own scrum master.

I asked, how do we know the teams have got the right skillsets to deliver a feature front to back?

The coaches said that this would be added to acceptance criteria.

We sat down and designed the additional acceptance criteria of each team and created and distributed a survey across the global team asking how each person rated themselves across the tech stack as well as their component/business knowledge.

Product Owners

We debated a lot about what a product meant in my area and agreed that value was aligned with each business area that we faced off to. If work spanned across these business areas, the product owner with bandwidth would align with this work. Any conflicting priorities across product owners would be resolved by myself, and the business governance if needed.

We currently had project/relationship managers who were aligned with these business areas, and they should become the product owners.

Good decision?

Architects

As part of the transformation, I wanted to ensure we had an architecture backlog that would be prioritised alongside the business features to ensure we constantly evolved the architecture, brought down the technical debt and focussed on software hygiene.

I also wanted someone experienced to collaborate with the teams to ensure the architecture was moving in a single strategic direction and ensuring decisions from deadline pressures did not impact the technical debt.

Ok, leadership control finished. Now over to the agile coaches and self-organisation.

Day Zero

We scheduled four meetings with each location – London, New York, Singapore, India.

The first was London. I stood up Infront of the team in London, around 50 people.

I presented my vision to the team and how I came to the conclusion on how we should move forward.

There was a lot of silence and confused faces.

I then introduced them to the agile coaches, who would be providing them with agile/SAFe training, team coaching and 1-2-1 support throughout the change.

I explained the rationale behind the product owners and architect and who had to been chosen for these roles.

I then stated that the leadership team and I had cleared our diaries so we could answer any questions they had.

We communicated the same vision to the rest of the global team and stated that they would continue to work as-is for now.

No alt text provided for this image

Personal Change

It was a tough day with lots of questions, concerns and also excitement.

You could already see who the change champions were going to be.

Each person was going through their own personal change curve, and it was up to myself, the leadership team and the agile coaches to help them along the curve.

There were going to be many 1-2-1 meetings over the next month or so.

I went home exhausted to get some rest.

Coming Up

The next day was day 1 of our challenging but worthwhile transformation. It was also the day when I started the cascade to each of the business and IT stakeholders. There was going to be some really difficult conversations ahead.

Find out more in?Part 5 .

Nicholas Foster

Sharing what I’ve learnt about creating career success, fulfilment and balance.

2 年

要查看或添加评论,请登录

社区洞察

其他会员也浏览了