Our Global Agile Transformation Journey – Part 8

In?Part 7 ?I shared with you what happened when I informed the clients of the changes I had made.

This week, I am going to share with you our top observations during the transformation — observations from me and leadership team. Enjoy.

Scrum Master Down

When the London teams initially selected their scrum masters, one of them was a little reluctant to take the role but decided to give it a go and see if he liked the position as well as what it takes to be a good scrum master.

After a couple of months, he decided he no longer wanted the role which created an open position for someone to fill.

Our default behaviour as leaders would have been to select someone, but instead, we stuck by our new principles and let the team choose their new scrum master.

We asked all the teams for volunteers, and two people stepped forward.

But There Can Only Be One

The two candidates were interviewed by the team, and after careful consideration, one was selected. Both candidates were given feedback from the team on how they came to the decision.

Post this decision, the person who was not selected as the team’s scrum master came and spoke to me. He stated that although he was disappointed that he didn’t get the role, he thought it was a fair and transparent process, and fully understood the reasons why the other candidate got the role.

The Team Disruptor

As I remember it, attrition was low throughout the whole transformation journey.

There was someone, however, who came to see me and handed in their resignation about two months into the transformation which surprised me because my observations of him was that of very engaged.

He explained that he fully understood and was behind the reasons for making the change but wanted to be a fulltime architect and that role did not exist for him here.

When he left, we hired a replacement. As I remember it, the replacement was interviewed and selected by one of the leadership team and not by the team itself.

The replacement was an excellent developer, but when she joined the team, conflict erupted, and the team’s velocity and morale were impacted. The team seemed to be back in the forming stage.

She found it hard to work in a self-organising team and just wanted to be left alone and get on with her tasks.

The scrum master tried to facilitate the team change and move the team forward, but this just caused more conflict.

Upon an escalation from the scrum master, one of the leadership team intervened and resolved all areas of conflict and the team eventually moved forward together.

Lesson learnt –

1. Ask the team to interview and select the candidate.
2. Ensure the candidate better understands the way we work at the interview stage.
3. Facilitate the insertion of a new team member and coach through any conflict.

Breaking Down the Silos

One of my favourite observations from the transformation was a change in the behaviour of the team members. One in particular.

This developer was a recognised expert in Oracle. Not only in our team, but across the organisation. The DBAs and other teams would often ask for his advice.

Before the transformation, this developer would sit down at his desk with his headphones on all day and plough through his database development tasks.

Unbeknown to us, this same developer went home and wrote Java code.

After a few months into the journey, this same developer –

• Rarely put his headphones on.
• Mentoring others in the dark art of Oracle development.
• Worked on tasks in Oracle, Java and HTML 5.
• Was energised and highly interactive with his team members.
• Was in my eyes a different person.

As leaders, we tend to silo people into their areas of speciality. From my own observation and reflection, this is a massive waste of human potential.

Quality Fest

Although I put in our transformation vision an aggressive goal for automated testing, this is something I didn’t think would happen without management interaction. It hadn’t occurred for years, so why would it now.

But responsibility had changed. Testing was now the responsibility of the teams and not an independent QA team as before.

Now the teams were planning for their testing as well as automating it because they can and wanted to.

But something else happened. The teams started to set quality metrics in terms of code testing coverage, complexity, maintainability etc. As one team set a bar, another team would set the bar higher. The teams were competing.

On top of their sprint commitments, one team wrote hundreds of functional tests which covered new functionality as well as legacy functionality they had written before the transformation. This same team delivered their software to a dependent programme where no issues were found in UAT or production.

Raising the Bar Higher

The teams then started to think about how they were going to test the tests.

I spoke to a developer one morning before everyone got in the office and asked him what he was up to so early. He told me that he was trying to design his code to have fewer paths of execution. This way, he had to write fewer tests.

There was one thing that was missing though. The testers were highly experienced at writing tests that the developers wouldn’t necessarily think of, especially negative test cases. I spoke to the independent QA lead, and we agreed that a tester from his team would join each agile team to help the developers write their tests as well as the product owners with the acceptance criteria for the stories. They would then spend any spare time doing exploratory testing.

Another's Perspective

Here are the favourite observations from a member of my leadership team.

Letting Go

As a manager, who was used to making decisions for his organisation, it was quite a shock to let go of that responsibility completely. It required trust and faith in the knowledge that to allow the team to decide essential items, they got to own it and make it successful.

When I occasionally slipped back into deciding for the team, I could immediately see the impact It had and over time learnt to ensure teams had their autonomy. It required two key elements:

• Firstly, being able to listen. As a manager and product owner, it was essential to take on board feedback from the team and tackle those concerns head-on.
• The second element was trust. The team needed to know that they could push back on anything and not be overruled or have their comments adversely impact them.

Key Man Dependencies

About two releases into the transformation, the only subject matter expert (SME) for one of our critical applications went on leave, and something happened in production that caused the application to fail.

I was just about to find the SME’s mobile number and call him up on his vacation when someone mentioned that another developer might be able to help as they paired together on the story.

Within fifteen minutes, the issue was resolved, and I avoided having to disrupt someone’s holiday.

Over time the benefit of individuals being able to expand in both technology and functional knowledge has been outstanding. There was also a lot of push back from developers who were specialists, and I thought we might lose them due to the agile transformation. Fortunately, most of them saw the benefits and have grown into specialists of a wide range of technology. The growth of those individuals has been remarkable.

Healthy Friction

Once the culture and working ethos had been adopted and ingrained into a team, it is such a pleasure to work with. It becomes such a partnership where everyone is driving for a common goal and benefiting from team input and healthy friction.

Actually, heathy friction is my favourite thing about the transformation. I absolutely love knowing that my request to a team is not going to be accepted and that I am going to have to negotiate some compromises as a result is a better product. Again, the team need to have trust to know they can push back, but it always ensures we get a better solution and do not implement wasteful change.

I think at the start of the transformation; it was quite challenging to change my behaviour and allow time for the team to mature.

Having the agile coaches was essential to be able to self-correct and understand the reasonings.

What's Next

In Part 9, I will share with you the outcomes of the transformation.