A year and a half ago, I was hired to help scale a development team of 5 to many more.
They hired me to test, but paid me to help scale up. After 18 months of influencing, coaching, working in the shadows, joining the rave party and meticulous change management, I can proudly say we’re much further than I anticipated. This blogpost explains part of this story.

A Quality Assessment

Vernon Richards, who has supported me throught the assignment, had done one of his signature Quality Assessments for this client. One of his outcomes was that they needed someone to help them out with improvements in process, growth-mindset and systems thinking. That person was me.
Together, we set the other outcomes & ideas of his assessment into place. Slowly, but steadily.

The CTO bottleneck

As the company was still on the brink of scaling up and the CTO was very hands on and in control, our primary mission was to take him out of the process. Not bruskly, not unnecessarily risky but controlled, transparant and with respect to the tremendous work that was being done every day by this person.

My process was roughly like this:

1. Appreciating the process that is in place
2. Create awareness of the problem
3. Name the problem, impersonally
4. Communicate an ideal, vague vision
5. Implement, step by step.
   1. Enable people to set small steps
   2. Be an empowering ally
   3. Celebrate wins, loudly

The Rave Party

1. Appreciating the process that is in place

Starting to test with the team was a crucial moment for me to establish that I was here to help, to be a teamplayer and to be part of the group. The team released multiple times per day. The process was chaotic, fast paced and resembled, in my experience, to a rave party.

I decided to roll with it. Several days, weeks,… I jumped from ticket to ticket, PR to PR, docker environment to docker environment, database to database, to provide quick feedback, move it to the next stage of the process and see it being shipped and re-tested again in production. It was the wildest and most fast-paced way of working I had seen.
Stuff went wrong sometimes, but we could quickly handle this.

It was awesome. Heartbeat-acceleratingly, high dopamine awesomeness. So what’s wrong with that?
Well,… it doesn’t scale, for one, and it’s not very human-friendly, among other reasons.
The process had its issues, but it was highly effective nonetheless. I was a fan of the way of working, the enthusiasm, the personal touch. It worked for this group of people, marvelously.

I was hired to make the process ready for bigger, more inclusive groups though. I endeavoured to gradually change it. A more controlled, paced and human process is now appreciated even by the hardiest of the hard workers.

The First Retro

2. Create awareness of the problem

The human-unfriendliness of the problem wasn’t how we approached this. Since the team consisted largely of young developers who were more than happy to throw all their brainpower to the problems they faced, it was the scaling issue we chose to address. This issue was the one creating most pain for the developers and especially the CTO.

Every PR that went to production was reviewed, merged and re-tested in production by the CTO. He did an awesome job at this, but there were several painful side-effects.

• Feedback in the form of ‘We’ve built the wrong thing’ came way too late.
• Big PR’s were postponed until eternity.
• PR’s that weren’t handled immediately began gathering dust.

Effectively, 10% of all work was disappearing. That was half of a developer’s time going to waste on this issue alone.

In the first retro we organised we started naming these issues, presenting the supporting data and making the issues visible. We continued doing this on many occasions. There’s no point in only stating feelings or uncertainties. Get data, show problems as they are and the negative impact they have.

The Endboss

3. Name the problem, impersonally

The CTO understood he was the bottleneck. He didn’t like it, but he saw no other way than to be the one in the middle. This was not a process, testing or technical issue. This was a trust issue. Very human, very real.
There’s nothing to gain in villifying this person. He was doing massive work and it was up to the rest of us to gain his trust.

We named him Endboss. Endearingly.
The Endboss phase was added to our Kanban board. It was the phase where the ‘yay’ or ‘nay’ was given for a PR to see the light of day. The developers, the tester, the analysts,… We all worked together to train up our PR’s to such high quality that it could survive the endboss. It wasn’t an ‘us vs. him’. It was Us, helping each other become the best versions we could be, to show that we’re on the same level he expected us to be.

It was important that this was not about the person, but about the concept. Getting everyone trained to efficiently ‘defeat’ the Endboss is potentially the single most valueable change that was introduced for this development team.

Feedback from testing or technical reviewing that was repeatable became part of a checklist.
And whenever the endboss DID slap our work backwards in some cases, this became an important learning opportunity.

Death to the Endboss

4. Communicate an ideal, vague vision

The concept of having an endboss does not scale at all. We wanted to get rid of the whole concept, but we couldn’t achieve that yet without losing time on poor quality. Not yet.
Scaling up became our primary focus and scaling up needs a livable pace, human interaction and people working together to achieve high value.

An Endboss phase doesn’t fit into the goal of scaling, but it’s an excellent way of framing your problem. It creates a training ground for people to be stronger and work together more closely.
Keeping the vision vague enough is important. If you have everything planned out and ready to be ‘implemented’, you’ll find few allies to help build it with you. Ask for participation, try out ideas, experiment, learn, adapt. Do this together, as a team. Find balance & find

Quality Coach Perspective

Quality Coaching is influencing systems to deliver better. Better, in the broadest sense. In our case, everything had to be more scaleable and in order to achieve that, we had to make sure our feedback circles were shorter and more to the point. Our developers started working more closely together and improved their output drasticaly. In the role of tester, I supported them in achieving this.

As a Quality Coach it’s easy to either lose yourself in working within the system (as a tester) or being outside of the system and directing (as a coach). Doing both was crucial in this context. I would not have earned the trust and respect if I hadn’t joined the rave party. I would not have had much impact had I not helped identify the next steps in improving our way of working and supported others in taking those steps.

What’s more?

A lot more happened on this project. It didn’t end with the Endboss phase, but it was a great start. We trained more Endbosses, we split up into teams with different Endbosses, we took out the CTO largely out of the process and are improving our pipeline to eventually get rid of our Endboss phase.
In further blog posts, I hope to outline our work in more detail.