11. June 2020
6 min

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

In this second part of my blog post series, I will show you how we scaled from eight to sixteen people in 2013 after releasing a pilot application the year before. Despite coping with certain project management challenges, we also needed to find a way to efficiently distribute our workload.
Team Building Workshop in 2013 with 10 members

After growing the team to eight people, I will tell you in this second part of my blog post series, how we doubled the team size within one year scaling from eight to sixteen people. In case you have not done so yet, you can read the first part of this blog post 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-1-first-six-months/

 

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.

 

After the Pilot Comes the Product

By successfully launching the pilot to production in October 2012, we gained the customer’s trust to keep working with us in developing “the real deal”: An application that was supposed to be rolled out to millions of users worldwide two years later in September 2014, providing them a huge set of B2B- and B2C-features in the area of connected vehicles.

When a project becomes strategic at a big corporation, it goes without saying that more people want to have a say in it and thus, the number of people involved in the project grew drastically. New departments were founded, many business areas like marketing, sales, retail, manufacturing and others became involved because they had requirements for the product to be developed and also, other suppliers got engaged in the project.

So instead of working closely with five customer employees and managers, we were suddenly facing an organization of around 50 people who were involved, which meant that we not only had to speed up development to keep up implementing all the features requested by several business areas, but the overhead in communication and coordination also grew significantly. Furthermore, we had just released the pilot and besides making sure that it runs to all users’ satisfaction, there were still features to be developed for this pilot as well. Long story short: we needed more people!

Scaling up to ten

For reasons of risk mitigation, the customer involved other suppliers besides Novatec and separated responsibilities. Our team was supposed to develop a core backend system in the area of context- and user management and service activation while other suppliers were supposed to develop other backend systems, frontends and apps for the end-users as well as internal users.

In the course of this, we transferred Philipp B. to another team staffed primarily by another supplier as his expertise was frontend- and especially mobile app development.

To cope with the loss of one team member and to prepare for the expected growing workload, we gradually involved Tino, Daojun and Patrick in the time between October 2012 and March 2013.

Note that the Scrum Guide (https://www.scrum.org/resources/scrum-guide ) defines the ideal development team size to be between three and nine people:

Fewer than three Development Team members decrease interaction and results in smaller productivity gains. […] Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful.”

By scaling our team up to ten people, we violated this recommendation.

 

Team Building

I am pretty sure a lot of you know the theories of team building like Tuckman’s seven stages of group development (https://en.wikipedia.org/wiki/Tuckman's_stages_of_group_development).

He states that with every change of a team, you’ll have to go through all stages again and since we were constantly changing the team, we were aware that scaling up from one to ten people within around a year would be a challenge and could lead to some distraction. So, we wanted to address issues before they even came up. Thus, we decided to hire an external coach and got the team together for a team-building workshop for two days (in nature, far away from any office) in which we got to know each other on a personal level, learned that we could rely on each other by solving challenges our coach gave us and simply had a great time hanging out together over barbecue at a campfire in the woods.

Until today I am convinced that this event was very valuable for all of us and was one of the keys to being successful in our project.

A team of 10 people walking along the street

Team Building Workshop in 2013 with 10 members

Water-Scrum-Fall Overhead

Note: The project setup I describe here is absolutely not what we would recommend, but it was beyond our influence, so we did our best to find a way to cope with it just like we needed to do with the technological and methodological prerequisites we were given.

 

I will not go into detail about the whole project planning in this post because I would like to focus on the team development in this blog post series. However, I think it’s important to have an idea of how the project was coordinated and managed on the customer’s side because this had a big impact on the tasks and challenges our team was facing.

While our team was working agile with Scrum, the customer’s organization as a whole was (and until this day still is) run in a very classic waterfall style. We called this setup Water-Scrum-Fall because our Scrum approach was surrounded by the customer’s waterfall. This alone provides enough material for another blog post (series).

So, what did this Water-Scrum-Fall look like? All requirements which came up with respect to the product to be developed were summoned in huge business requirement documents (BRDs) and change requests (CRs) by business analysts (Water-) which we then had to break down to Epics and User Stories implemented by us (Scrum). Despite us delivering increments after every Sprint, they were only automatically deployed by us to our test systems. Deployments to the higher integration stages including our product and all other systems developed in parallel, were only done every three months or so for pre-defined integration milestones when all systems involved needed to be ready for integration (RfI). After these integration deployments, a dedicated team started testing the developed features manually (-Fall).

This surrounding waterfall meant a lot of organizational overhead for us in transferring the waterfall to the agile world and back:

We spent a lot of time translating the BRDs and specifications created by the waterfall to epics and stories we could work with. Also, we needed to discuss and agree on API specifications before we even implemented them, so that other systems, which were not developed in agile fashion, could integrate with our system. We also spent quite a lot of time developing mocks for the other systems so that we could still test every commit despite the other systems not being integrated until months later.

Also, the hand-over back to the waterfall caused a lot of effort for example in writing installation-guides and runbooks so that the Ops team could do the integration deployments.

So, on top of starting to work on the first product release and further developing and maintaining our pilot product, we needed to cope with this overhead as well and we did so by integrating more people in the team. Until the end of 2013 we gradually integrated Diana, Michael, Carlos, Duygu, Murat and Johannes in the team, thereby increasing its size to 16 people.

 

Split Up and Focus

As mentioned before, the Scrum Guide recommends a team size of three to nine people. When we hit the mark of twelve members in the middle of 2013, we realized that we lost velocity. Meetings and Scrum events took us much longer, keeping everybody informed about everything became a challenge and given the fact that we were responsible for several more or less decoupled business areas, we decided that it was time to split up and focus. Our aim was to find a team structure which would allow every team to focus on their part of the work while still keeping the information flow up between them. Furthermore, we needed to find a structure which allowed us to further scale and to include four more team members until the end of the year.

Here is what we came up with. The illustration shows the team structure as of end of 2013, so it includes all 16 team members:

Structure of a team setup with 16 people in a specific software development project

Team Setup with 16 People

  • The Pilot team signed responsible for further developing features for the product pilot we had released in October 2012 as well as maintaining and supporting said application.
  • The Service team took care of developing features for the service activation part of our system. (Note: Service in this case refers to connected car services which can be used by the end-users).
  • The User team signed responsible for developing the user- and context-management part of the new product.
  • My role had changed in this whole transition and I didn’t belong to one particular team but took care of the overall processes and management.

With this setup, Epics and Stories could be routed to the responsible team and they could focus on developing their features without being overwhelmed by topics which didn’t affect them. Each team had their domain and their focus-area.

While Scrum dailies and refinement meetings were done on a per-team basis, we still hosted one Sprint Review and Sprint Planning meeting so that everybody was up to date on the overall progress in developing the product. Retrospectives also included all teams in order to learn from each other and constantly improve our overall performance.

Also, each team sent one person to the other teams’ dailies in order to listen in and transport relevant information back to their own teams.

Next Up

In the next blog posts, we will read how the product went live, how we migrated the pilot into the final product and how the overall team size scaled up from 16 to 40 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?

 

 

Comment article

Comment

  1. Borja Aguado Badillo

    Interesting article. Growing is always a challenge and it is an incredible professional experience. In my opinion the biggest challenge comes from about 50 people, when you start having different groups or not everybody knows everybody.

    Another interesting point you describe is Tuckman’s stages and fast-growing companies. In that kind of teams is extremely difficult to have teams together long enough to get to performing stage and that creates a permanent feeling of under-performing.

    My favourite though is the Water-Scrum-Fall section. All companies I know has gone through that phase! It is not perfect, but I have to admit that it was fun when I was there!

    Thanks for sharing a good luck in your journey.