Forming Scrum Teams

The tongue-in-cheek fable of the chicken and the pig is frequently referenced in Scrum literature to distinguish between people who are committed to the Scrum (the pigs) and people who are only involved (chickens). The reason pigs are committed is they must be sacrificed for the meal whereas chickens are simply involved. When I was software engineer, we used to say, 'It's just us pigs here' when it was a group of software engineers together. Having transitioned to management several years ago, now I say, 'It's just us chickens here.' But I digress.

In this post, I want to discuss my logic for forming Scrum teams, a topic that I have hashed and re-hashed many times throughout my career. So, here I will explain the logic behind how I form software engineering teams.

The Agile Manifesto

The Agile Manifesto lists the following 12 principles:

1. The highest priority is to satisfy the customer via early and continuous delivery of software
2. Welcome changing requirements
3. Deliver working software frequently with a preference to the shorter timescale
4. Business people and developers must work together daily throughout the project
5. Build projects around motivated individuals
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development
9. Continuous attention to technical excellence and good design enhances agility
10. Simplicity is essential
11. The best architectures, requirements, and designs emerge from self-organizing teams
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

While these 12 principles define much of Agile in the broadest sense, there are variations in different Agile methods such as XP, Scrum, Lean, Kanban, etc. These methods are not meant to be followed dogmatically, instead practices within a particular method are meant to be guidelines. In this post, I will be focused on Scrum, specifically on some of the aspects of team formation. But keep these principles in mind as you read this post.

What Does Scrum Recommend?

The Scrum literature discusses team formation a lot. From this literature, it's easy to learn that there are  some key principles in Scrum focused around forming small, cross-functional teams. But Scrum best practices don't end there. There are many other aspects to building Scrum teams. In this post, I will elaborate on the following:

• Autonomous and self-organizing
• Team composition must be cross-functional
• Ideal team size

Autonomous and Self-Organizing

As stated in many Scrum publications including the Scrum Guide, a Scrum team should consist of a Scrum Master (SM), a Product Owner (PO) and Developers. Scrum teams should be cross-functional and self-organizing, i.e., they must be capable of delivering value each sprint and they are responsible for deciding how they work. This is what I refer to as setting up a team for success. It's the job of the leader to set up the team for success, not only in the structure of the team but also in communicating the expectations for the team. I have always defined expectations in black and white for everyone to see so there is no question about their responsibilities. (In fact, I have even implemented this model across all engineering teams for a product line by working very closely with my management colleagues. There must be consistency of expectations across all the product engineering teams. I cannot stress this enough.)

It is critical that the team members understand and embody their autonomy and empowerment to manage their own work. Typically an engineering manager is involved and accountable, but the team is responsible (from a RACI matrix point of view). In my opinion, the best case scenario is that the engineering manager is more of a coach and not micro-managing everything a team does. Team members must be coached to step up whenever they can and remember to bring everyone along on the journey. This requires well-structured and open communication across the team. Oftentimes, the Scrum Master is the person who guides the team most in terms of self-organization and responsibilities.  It is also important that team members understand the role that everyone plays on the team. Like a set of gears moving together as one, it only works if all cogs are operating correctly and together.

Self-organization is an important aspect for a team to operate well together. Team members cannot operate together without a shared understanding of what this means. In Scrum, this means the PO defines user stores for team and the SM leads the team members in breaking down those user stories into subsequent tasks for estimation and execution. The SM oversees all of this activity and works closely with the PO to determine priorities for the sprint. While people not deeply experienced in Scrum think this is too much for a team to handle or feel that the manager should drive all team activities, this couldn't be further from the truth. As with many things in software, concrete experience teaches a tremendous amount very quickly. As a people leader, it's very easy to see the differences between a mature Scrum team and an immature Scrum team. Like many things in life, reaching a level of maturity as a Scrum team requires proficiency and time, especially if new team members are added over time. As the Agile Manifesto mentions: 

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

I work very hard to build trust with my engineering teams as I believe this is the basis for building great teams. I always say that I hire talented individuals who are experts and then I give them room to get the job done. The bottom line is the team is accountable for delivering value every sprint and I have found that building trust is a requirement. I extend trust to them to get the job done and they teach me to trust them by consistently delivering value every sprint.

Team Composition Must Be Cross-Functional

As mentioned above, a Scrum team needs to be cross-functional so as to deliver value every sprint. As much as delivering value is a generic term, when developing microservices it means that the team can deliver, own and operate those microservices itself. The team should not need to rely on other teams for different job functions as doing so amounts to dividing up teams based on function. This type of team organization was an idea from the 1990s and Waterfall methodology that divided up teams based on job function, e.g., front end engineers in one team, back end engineers in another team, QA in it's own team, tech writers in their own team, etc. I've seen this before and it really falls apart quickly because departmental divisions do not work in an Agile environment. It's a mismatch of models. Agile is supposed to be iterative and incremental. When teams are defined by job function they are not set up to be incremental. A true Scrum team must be composed of the constituent parts to deliver the software owned by the team. This requires a cross-section of roles composed of all the necessary disciplines. As mentioned above, a Scrum team should consist of a Scrum Master (SM), a Product Owner (PO) and Developers:

• Scrum Master
• Product Owner
• Front end engineers (developers)
• Back end engineers (developers)
• DevOps engineers (developers)
• QA engineers (developers)
• Tech writer (developers)
• Manager

In the list above, I included a couple of roles that you don't normally see in a Scrum team -- a tech writer and a manager. I also break down the different types of engineers. So, let's discuss each one.

Tech writer: I include a tech writer in my teams whenever I can because I do not consider the product to be Done until everything is actually done including the coding, testing, documentation, performance considerations and operational requirements.

Manager: I include the manager because this person serves a vital role not only in terms of people reporting lines but also in terms of developing a contextual understanding of a team and its work. Speaking from experience, without a manager present, it becomes very easy for software engineering teams to get pulled in many directions. A manager can guard against not only this but also against members of a team reporting to numerous managers which can result in a lot of chaos. 

The other roles are simply a clarification on the types of developers. Furthermore, it illustrates the inclusion of the different types of developer disciplines -- tech writers, QA engineers, DevOps engineers, etc. None of these disciplines or roles should reside on other teams. When this happens, the team will not develop the right level of cohesion and trust necessary to become what Google identified as an effective team (this is a whole separate topic for another blog post).

Ideal Team Size

I have seen Scrum teams with three engineers and Scrum teams with 30 engineers. The goal should be to find an ideal size that works for the products being developed, but I do believe smaller teams are better. According to the experience of many Scrum practitioners, the ideal team size should be 6-8 engineers (give or take one or two) not to exceed 10. From my nearly 20 years of experience practicing Agile, the larger an engineering team grows, the more difficult it becomes to meet, to scope work, to keep track of work, etc. Basically, the larger the team the more complex and time consuming communication becomes. It's not called Agile for no reason -- software engineering teams practicing Scrum are meant to be nimble and iterate quickly. This cannot take place when too many people are involved. 

Consider Brooks' Law about software project management which says adding manpower to a software project that is behind schedule will delay it even longer. This maxim emerged from Fred Brooks eponymous book The Mythical Man-Month. Brooks explains that while cost varies with the number of men and months, progress does not:

“Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them… This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.”

This is further elaborated by examining the lines of communication for teams of different sizes. As explained in a blog post titled, Lines of Communication and Team Size: Applying Brooks’ Law: 

Most teams in large enterprises have between 10 and 20 members. Even at the low end of that scale, a team has so many lines of communication that progress is bound to be slow.

(source: Lighthouse)

Note the increasing number of lines of communication as a team grows. This is essentially the root cause of why teams beyond the Scrum recommended size become more and more ineffective as they grow. The drag in trying to develop a shared understanding of anything simply becomes more and more complex the larger a team grows. This is typically when people start to complain about there being too much administrative overhead. 

Conclusion

To summarize, if you want to set up your teams for success, then they must be autonomous, self-organizing, cross-functional and sized appropriately for the software being built. This is at least part of the recipe that has helped me to build what I mentioned above that Google calls effective teams. 

Resources

• The Law of Contraints and Brooks' Law
  
• What Does Scrum Mean by Cross Functional Teams?
• Cross Functional Doesn't Mean Everyone Can Do Everything