“Darling, I scaled the team” – How to Grow From 1 to 40 People in an Agile Development Project (Pt.1)

About this Blog Post Series

In April 2012 I started a new customer project for Novatec and back then I had no clue that eight years later we would still be engaged and that this would not only turn out to be a huge success for all parties involved but also a treasure for so many learnings on various topics from agility, agile scaling, technology and methodology modernization up to migrating an application with 9 million users to the cloud (while in parallel modernizing the tech stack) without any user taking notice. I would like to share some of these learnings with you in what I hope to become a series of blog posts.

Note: I don’t want to go through long clearing processes on the customer side, so in order to avoid any legal issues, I’ll try to keep the business purpose and other specifics as abstract as I can. I think it won’t impact the whole story too much.

Agile scaling – Photo by Markus Spiske on Unsplash

The Prequel

It was an evening in late April 2012 that I got a call from a manager at a big German corporation we have been successfully doing a consulting and development project with for two years until then. He was in his car and in between the parking sensors beeping like crazy he told me that he urgently needed support in developing his product vision of a connected car application backend. The timeline was tough as he had a goal of releasing the first productive pilot six months later in October 2012.

So, we sat down some days later to discuss his vision and goals and we ended up signing a contract.

Agile Empowerment

The whole endeavor was still in a build-up phase on the customer’s side. Besides said manager, there was his boss, a senior manager, and two of his employees plus one business analyst from one of the corporation’s subsidiary companies and that was it. I was the first external person to join the project. In the past, all of the involved people had not worked with agile methodologies so we started discussing agility, the right approach to work on this project, Scrum, the team setup, the work model and so on, and so on. My consulting colleagues gave Scrum trainings for the future Product Owners and the customer management, we started writing the first epics and user stories and I got my hands dirty writing the first pieces of code.

Agile Task Notes – Photo by Kelly Sikkema on Unsplash

The First Team

Our first estimation was that we would roughly need four people to be able to release the desired prototype six months later, so I gradually engaged my colleagues Philipp P., Christian and Paoli in the project over the course of two months. None of us had worked together before but since we all shared the Novatec values, it was easy to get along and to work towards the same goal: Release a high-quality pilot to customers (actually our customer’s customers) until October.

In this phase, my role was somewhat divided between being a coach to my colleagues in terms of software engineering and implementing software for customers, being a coach to the customer with respect to agility, being an architect who needs to have in mind that we build a pilot which, if successful, needs to be extended for a much bigger purpose, being a Scrum Master to the team, being a coach to the product owners and of course being a Software Engineer.

Side note: I know that the combination of these roles is not very beneficial and that the ideal setup of a Scrum project looks a lot different, but it is in our DNA to look for pragmatic solutions and my personal paradigm is: as long as it works for all people involved, we go for it!

The Setup

Since the customer didn’t have any agile experience until then, they relied on us in this area. So, we agreed on the team setup with me being the Scrum Master and one of the customer’s employees fulfilling the Product Owner role. We defined a Sprint length of two weeks and decided to follow the Scrum guide on all events which means we had timeboxed dailies, a Sprint Review and Sprint Planning every two weeks, a retrospective and also a refinement meeting every week to discuss the user stories the product owner had in mind with the team.

Technology- and methodology-wise there were some restrictions. The customer had their own data center where we needed to run the product and that also meant that we would have to stick to a certain technology stack consisting of IBM WebSphere Application Server 7, IBM Integration Bus, IBM WebSphere Portal, consequently the Java EE 6 stack and so on. Not really our idea of the perfect technology setup to run this product, but there was not a lot of room for discussion back then and since we had been given a timeframe of six months, we worked with what we had. At the same time, we openly discussed with the customer that this was not an ideal setup in our opinion.

Methodology-wise it was set that the application would run in the customer’s data center and that we (being the dev team) would not be given access to the prod environment or any higher stages. We were allowed to request some VMs for a dev and test environment and to run our build server but that was it. Everything beyond that was sacred Ops-Land handled by the customer’s trusted operations partner. Which meant that we could set up Continuous Deployments for our dev and test stages but had to build a package including (the famous) installation and run guide for all higher stages up until prod.

First Scaling

Even though it was not the perfect setup in our opinion, it was beautiful times. Working in a pragmatic way with not too many people involved meant that decisions didn’t take long and also the customer relied on us and gave us a lot of freedom, so we made progress really fast delivering value to everybody’s satisfaction. However, the customer being a big corporation and the project being strategic also meant that growth was only a matter of time – both on the customer’s and as well on ours.

In order to meet the critical go-to-market date for this pilot in October and to cope with new ideas developed by the customer as well as keeping up with their Ops team growing, we decided that adding more people to the team would be necessary. Between June and August 2012, we included four more team members Julian, Andreas, Philipp B. and Uwe in our project.

Thereby, our dev team grew to eight people and despite things working out still fine, we  realized that some processes already took a lot longer than before. I think it goes without saying, that having eight people speaking in a daily Scrum meeting is different than having four people speaking.

Pilot Release

In October of 2012, we hit our first big milestone: Our product went live. We actually pulled it off! Within six months, we developed a new product from scratch that our customer could roll out to their employees and customers. The pilot ended up serving around 8.000 users to their full satisfaction.

As I am writing this, I still get goosebumps. After six months of hard work, we could see the value that we created by seeing real users working with the software that we had implemented. And besides the success in business, we were very aware, that we achieved a lot on the side. Us growing together as a team was one part of it.

Next Up

In the next blog posts, I will cover how this pilot project turned into a strategic project and how we scaled from eight to forty people. In the meantime, I would love to hear from you: Did you experience similar situations or projects? What were your experiences with starting new projects, setting up teams and scaling them?

Update: Read part 2 of this series here: https://www.novatec-gmbh.de/en/blog/darling-i-scaled-the-team-how-to-grow-from-1-to-40-people-in-an-agile-development-project-pt-2-from-8-to-16/