With Scrum as its leading method, the agile movement suggests a team size of 3 to 9. However, we see more and more environments in that our clients want to scale up to large teams that are clearly bigger. First of all, our initial question is always "Why?", with a few extensions.
- Are you happy with the current performance of the team and its effectiveness at turning business requirements into working software?
- Is the quality of the software delivered by the team consistent with or even above your expectations?
- Does the team work on the right features in order to maximize business value while producing minimal waste?
- Is the team able to spend most of its time with productive and innovative work instead of doing repetitive tasks that should rather be automated?
- Has the team been relatively stable with regard to its members during the last months or better years so there is a solid tried and tested foundation to build upon?
If the answer to any of these questions is "No", maybe you should rather improve the team's technical skills, processes, and product management before trying to increase its throughput by scaling it up at that immature level. But even if you want to scream "Yes, yes, yes, yes, and yes, but I still need more than that!", there are additional questions to ask. The most important one is: "Why do you not simply set up several teams with independent responsibilities?" If you are not able to come up with any good reason, try that approach first (see e.g. "Small teams are dramatically more efficient than large teams" for a bunch of reasons why). However, there are reasonable answers and here are at least a few of them.
- My product has, and should have, so many inherent dependencies that it is impossible to split up teams and responsibilities without massive inter-team coordination. Of course this is contrary to the microservices movement, but there are environments where this is, indeed, a valid assumption.
- I need to prioritize according to a feature's value, not the capacity of my teams. At some point, I might only have important requirements for a single component, but I will have a lot of them.
- For whatever reason, I want to avoid the "not invented here" syndrome and rather foster shared code ownership. One rationale is a temporary need to scale up without a challenging merger of teams later on.
So let us assume we got this far, and we still want to scale up one team. What now? How can we do that without violating the basic agile principles as laid out in the Scrum Guide? There are no blueprints or ready-to-use directions that explain how to build a “large team”. What we found out over the last years, however, is that you should manage your team as a networked system with built-in bottom-up intelligence. Therefore, we try to use these 5 ingredients we have identified for growing successful and big sized teams:
- Collaboration
- Common goal
- Leadership
- Trust
- Continous Improvement
1 Collaboration
Communication is one of the most critical team processes and the foundation for collaboration - and there are several things to consider to provide the right environment for good collaboration in large teams.
Build sub-groups – set the right focus!
In a big sized team you will normally have a wide range of different requirements you have to implement during an upcoming sprint. When you plan a sprint, try to find dependencies and synergies between stories and collaboratively group the stories accordingly. Each story group should be similar sized, e.g. with a similar number of story points. After you identified these story groups, find out which team member could participate in which story group. Ask the team who wants to join a particular group. It’s not important to have a good understanding about the domain of that particular story group – respect also that team members can learn something in a new domain and don’t forget to drive competence development when you plan your clusters.
Story grouping will help you during the sprint to have more focused discussions in the story groups – in the Daily meeting it’s just important to achieve a common understanding within the whole team about the dependencies and obstacles of the work in progress. In the Daily, normally you don’t need a focussed discussion on the challenges in each story group. Focus the discussion to identify risk as early as possible, so the team can use this information to organize around the identified problems.
And don’t stick to your planned groups for ages. If another group needs support due to risky challenges – ask the team if somebody can help. Don’t forget: despite the split into smaller groups, you are one big team with common objectives!
Provide transparency over channels
In the operational daily work, each team member should have a good understanding of colleagues' current tasks and identified risks or challenges - in particular to figure out where support is needed. Use collaboration tools and channels for the different issues you have, such as project management tools, instant messaging services or tools for absence planning. Consider that you want to provide your team the opportunity to work from home or to work together with colleagues from other continents.
Communication culture
In any team you will have meetings, and in most cases some of them are inefficient or redundant. A "Jour Fix" with a clearly structured agenda, but without any participation, can be as useless as an intensive open-minded discussion that goes nowhere. Instead, foster productive communication and make sure every team member understands the purpose and benefits of both structured and explorative communication. Esteem any contribution, but also help the team to figure out the right time for a particular piece of information or a certain question. This is helpful for any ad-hoc discussion, and it is crucial for regular meetings with many participants. Align rules for each meeting and work out common meeting goals that fulfill the team's needs. And while doing this keep at least one thing in mind: There are meetings in which the team is primarily informed and has the ability to briefly give feedback (e.g. the presentation of an extensive analysis' result for collecting feedback). And there are meetings which are all about discussions, brainstorming and interaction (e.g. the analysis itself). The former can easily be conducted with the entire team, the latter one should not because it usually does not scale.
The right focus for the right meeting
Normally we have two different kinds of meetings in the agile world:
- Non-regular meetings to support the daily work
- regular Scrum meetings
Non-regular ad-hoc meetings
When we step along developer offices it is easy to see which teams perform well. Performing teams distinguish themselves by sitting regularly together. In these teams, you will see highly concentrated and focussed people that are talking to each other about their challenges. No need to be worried if they are also laughing. If you observe this behaviour, you see a non-regular ad-hoc meeting. There are good relations in the team, so that the team will organize these discussions on demand, often at the end of the Daily. During these discussions, different views based on experience and skills are brought together, so that you will harvest most creativity to resolve business problems. The same goes for one of the most sophisticated, but also effective, forms of collaboration in modern development teams: pair programming.
Regular Scrum meetings
We usually use at least the following Scrum meetings:
- Planning
- Sprint Review
- Retrospective
- Daily
- some kind of Refinement (with or without Estimation)
At the end you have to find out how you can get as much impact as possible from these meetings for your team. There has been a lot of writing about these standard meetings, so we will not describe all of them in detail again. Just one general best practice identified for our teams: Don’t focus on people in the meeting, focus on the work. For example: We do not like to ask the people in the Daily what they did yesterday, what they plan to do for today and if there are any impediments. We are focussing on the tickets that are planned for the sprint. So everybody who worked on a particular ticket will share his progress and challenges. It is also good to have the tickets ordered by risk, so that it’s visible for everybody where support could be helpful. Of course, this requires all ongoing work to be visualized transparently - a desirable state in itself - and there should still be some room for general remarks if appropriate.
2 Common goal and shared vision
Having a common goal with a clear vision will give your team more orientation. Additionally, common goals will help to avoid situations in which managers simply delegate tasks, what often leads to frustration. In the agile world having common goals normally includes having clarity on the roadmap and release plans, the backlog items, the definition of done or a common understanding about quality. Having these goals in place will help to respond to unforeseen incidents and not wasting time while waiting for instructions. If a team agreed on a goal, everybody will feel committed to achieving it.
An important aside: To have a common goal does not automatically mean neglecting personal goals. Try to consider the goals and desires of each team member wherever possible. Make individual goals visible and encourage each team member to try to turn them into common goals. As a consequence, everyone will participate in rule- and decision-making. Just make sure that once an agreement has been achieved, there is no room for unilaterally deviating from it. While personal goal are important, they are always secondary to team goals!
3 Leadership
We strongly believe that leaders within a team are important for big sized teams. Just to avoid misunderstandings: you don’t need one leader – you need many leaders with different responsibilities. And your leader is not going to be the one making any decisions - he or she rather needs to consolidate all the small decisions and opinions of individual team members in order to make the team pull into one direction aligned with the goals set by the customer. That is particularly challenging in a large team with multiple ever-changing subgroups that all need to be respected and satisfied at the same time. In our opinion, the demand for leadership increases with the team size. But we are not talking about team leads or command-and-control project managers. We are talking about good leaders for a skilled team!
And how is a good leader characterized? Following the servant leadership concept, the leader should have the natural feeling that one wants to serve, to serve first. He or she should help the team to become more effective in decision making by fostering effective collaboration. This basic configuration will help to have a maximum positive impact while also using and spreading expert knowledge for his or her particular responsibility. The ultimate goal of great leadership in the agile world is simple: Every team member feels he or she is doing a suitably challenging job without any unnecessary distractions and interruptions getting into his or her way while contributing to a common goal. Achieve that, and you are doing it just right.
4 Trust
You cannot achieve your goals without a trustful environment. And one of the base conditions is to create a workspace with fault tolerance. Yes – welcome faults! Mistakes are the best chance to learn and to build up trust. In such a trustful environment you will increase the collaboration level significantly. In combination with trust, you could also think about respect. Respect the goals and needs of others and create places to give feedback. But it’s not only asking for feedback – you should also consider to provide feedback, so that your team can orientate. Define responsibilities as well as a common definition of done as a guideline, and respect them. Empower all members of your team and trust them - they will find the best way forward to achieve the goals.
The size of large teams makes trust even more important. It is impossible for anyone to track everything going on down to the details. Without a sufficient amount of trust, many team members will try to address their fear of wrong decisions made by their colleagues and interfere wherever they can nonetheless. And that is definitely not what you want when trying to scale efficiently. At this point, you might ask: can this still be shared code ownership? Of course! Shared code ownership is not about full control, it is about the ability to change and influence code in a positive way anywhere. And in self-organized teams, it is up to each individual developer where to contribute actively.
5 Continuous Improvement
In our projects we usually have the need for being agile, hence we need to inspect and adapt on a daily basis. Team setup, technologies, customer needs as well as organizational structure are in a continuous flow. You will not be able to define processes, responsibilities and team culture on a drawing board. You need to inspect and adapt wherever you can first! Find out what does not work, ask the team where it sees room for improvement and work out some options how you could do so.
Being ready for continuous improvement also means being brave. Be brave and take changes for what they are – experiments. Nobody knows if a change of plans will work. You can have endless discussions which option is the best one. You can find a long list of opportunities and the list of risks will not be shorter. In an unhealthy environment these discussions will run over weeks and nobody wants to take the responsibility for a change, so that the discussion groups are growing and growing. And when you will have the feeling that you have identified the best change – another bigger problem will come up, so that you stop the previous activities and restart the process once again. That is not agile. That is a waterfall approach to process management.
Instead, keep it simple! Empower the team to make decisions, let them think about options and motivate them to go for an option. Consider the chosen option as an experiment and a chance to find out whether it works. After a while you can ask for feedback, and you will find out if the experiment will become a new best practice or whether you still need to try alternative ideas.
Are you planning a project that seems to require more than a typical scrum team? Or do you already have a large team and struggle with it? Read more in our upcoming blog posts or simply find us at https://comsysto.com/leistungen/lean-agile.