AUTHOR: Ryan Griggs, Scrum Master

Being 6.1 feet tall is great, I can reach most things and I can sit on most motorcycles without resorting to using my tiptoes when stationary. I also have some tall friends, one, in particular, is well over 7 feet tall and we share the same sentiments. However, he has a few scars in and around his head from all the doorways and low bridges he’s had to dodge in his life. For the most part, he was successful and has learned to duck below most doorways, but in some cases, he wasn’t that lucky.

I can only imagine that I would end up with my own assortment of bumps and scratches on my head if I magically woke up tomorrow being that tall…

Similarly, your development teams are their own entities and each will develop their own routines and ways of interacting with the world. The teams will invest time and effort into their collective character and it is the responsibility of the business, Scrum Masters and Agile practitioners to afford them the corporate culture and protection to maintain and develop the team’s collective self.

But, what happens when you do wake up in the morning bigger than you were yesterday? The following story is about change, excess and ultimately learning.

The Situation

I had the opportunity to work with 3 development teams at a large client. The floor consisted of just shy of 30 development teams. This story relates to 2 teams – specifically the “Space Lilies” and the “Dodgy Pirates”. Each team consisted of 6 or 7 individuals (QA’s, Front-end, Back-end, and Product Owners) and myself as a Scrum Master making up the final member on each team.

Our business Program Managers in conjunction with our Product Owners worked together to describe and translate business value features into user stories for each project. In theory, the company had a framework which would allow for the business to provide context or insight into the businesses road map and priorities for each project. In reality, the process was not regularly utilised, which made it difficult for the development teams to translate how their user stories and tasks related back to the business value.

The Change

Things changed with some of our bigger paying clients, and the Program Managers reprioritised the “Space Lilies” project to be completed ASAP ahead of the “Dodgy Pirates” project to help secure the client’s business.

Priorities change all the time and this in itself is not an issue, but we were pressured into combining the “Dodgy Pirate” team members into the “Space Lilies” so that we could accelerate development.

For the next quarter, we would operate as one large team.

Without a concise way to communicate how this change would affect the development cycle to the Program Managers, we found ourselves in a combined 13-person team with 1 Product Owner and countless expectations from the business to deliver. I noted some of the effects this change had on the team and individuals.

Some of the effects were:

• Meaningful communication became noise. Described in “Brooks Law” the number of communication lines exploded from 15 lines with 6 people to 78 lines with 13 people. This is an illustration describing the growth in communication lines when growing teams (source: GetLightHouse):

• Silos started to develop. Due to the number of communication lines and the amount of information that the team was trying to communicate with each other, people were subjected to information overload. When the individuals on the team realised that they could not cover everything they would naturally switch off or avoid work that was not directly impacting them. We were fortunate that no one on the team was off more than a couple of days during this time.

• Scrum ceremonies suffered:

• Stand-ups – the team did not have context for the vast majority of what was being shared by each individual and tended to lose focus. The 15min time box was usually missed.

• Planning & grooming – we spent a lot more time trying to decide how and what to deliver. The huge increase in potential capacity of the team meant that we needed to have an equally sized sprint backlog to support it. However, coordinating across functional groups became complex and ultimately the tasks and user-stories became very shallow, as we rushed to cover everything before the end of our time boxes.

• Retrospectives – we had to make the best of a bad situation. The team acknowledged early on that there was a problem with the size and number of team members. Acknowledgment of the situation helped frame our minds and emphasise empathy between each other.

• Reviews – it had become extremely difficult to deliver a working product by the end of each sprint. Co-ordination between individuals became complex and deploying code was time-consuming. Reviews became back-end ‘demos’ and front-end ‘mocks’ without a fully working system to show for the sprint.

• Delivery speed increased (sort of) – lines of code per sprint increased but not nearly as much as expected. Doubling the number of developers on the team did not translate into double the amount of delivered features. The Product Owner and I spent a lot of time managing our stakeholder’s expectations.

• Individual stress increased – the team was under immense stress to deliver, stress which heightened each time we missed our sprint goals. Bottlenecks formed on the QA and PO sides where essentially there was just too much information, the volume of stories, and interdependencies to process work for a team of 13 people. In addition, Program Managers became stressed and started to use the tools and processes the organisation had available to translate what the team was working on and how their tasks related to the business value.

The Result

The “Space Lilies” project was delivered to UAT by the end of the quarter and was deployed to production shortly after. However, the scope and number of features were heavily discounted to accommodate the inefficiencies we experienced.

The Learnings

I have always been a firm believer in balancing the theoretical (academics) with reality. In reality, not every organization is 100% Agile or 100% Waterfall, and as Agile coaches and Scrum Masters, we need to adjust to reality in order to help our teams navigate the demands placed on them, while at the same time, helping coach the business to understand how their choices affect the development cycle.

In this story, everyone that is familiar with Agile would have understood the red flags of running a big team. In reality, it is incredibly difficult to tell a board of business owners “No, we will not combine the teams into one big one to meet your deadlines”.

Instead, in this situation, we acknowledged the challenge and used the experience to help bring positive change to the environment.

Today, the individual teams are delivering more value in a shorter time-frame than they were before they were combined into the larger team. The teams identified a number of reasons for this, some of which were an increase in empathy, appreciation for the right sized team, and a shared level of comradery for getting the job done.

Similarly, there is an entirely new level of respect between the business stakeholders and the product teams with both sides embracing the associated tools and processes empowering both the business to report up effectively and the development teams to illustrate the cascade of adjustments that would need to be accommodated when business priorities evolve.

So…does size really matter?

Yes, but if it is forced on you, learn from it! ;)