While all teams face challenges, those challenges vary by the size of the team. Small team Agile best practices can help overcome many of the obstacles.
Some of the most common challenges for small teams include:
Not having the skills required to do the work needed. For example, due to the number of systems and complexity of current technology, multiple people are often required to complete a single task.
Being out of balance with other groups within the organization. Sometimes there is only one small team among many larger teams. Company-wide standards being developed tend to be for average team sizes, and smaller units often lack the bandwidth needed to complete the required workload.
Their size allows no redundancy within the team, which makes supporting 24/7 systems nearly impossible.
They lack mentors. Not having mentors robs team members of the ability to advance their skills or their careers quickly.
Definitions:
Refactoring: The process of restructuring existing computer code—changing its internal structure—without altering its external behavior. Its main purpose is to make code more understandable, reduce complexity, eliminate redundancy, and provide a more maintainable codebase, all of which can lead to fewer defects and ease future enhancements. Refactoring often involves reorganizing code; renaming variables, functions, or classes; breaking apart large functions or classes; and other such changes.
Ideal team size: The ideal size for a Scrum team is often cited as between three and nine members, excluding the Scrum Master and Product Owner. This recommendation comes from the Scrum Guide, the foundational text for Scrum written by Jeff Sutherland and Ken Schwaber. A team of this size is optimal because it reduces communication overhead; increases cohesiveness, efficiency, and agility; and allows for the work to be distributed across enough skill sets but not so many it’s hard to manage.
Self-Organizing Team: Refers to a group of individuals who manage their own work and make their own decisions about how to achieve their goals, rather than being directed by managers or following a prescribed plan. These teams are given the autonomy to decide how best to accomplish their work within the constraints provided by the broader organization or framework. The key characteristics of a self-organizing team are autonomy, collaboration, cross-functionality, responsibility, continuous improvement, empowerment, and feedback. In Agile frameworks, the belief is that when empowered and trusted, self-organizing teams can be more adaptive, responsive, and innovative in solving complex problems compared to traditionally managed teams. This is because they can leverage the collective intelligence, skills, and insights of all team members, making decisions closely aligned with the work’s ground realities.
Going from Suck to Awesome
Suck– Not knowing who is on your team and what roles they play.
Still sucks – Knowing who is on your team but not having enough members to self-organize.
Sucks a little less – Having dedicated roles of Scrum Master and Product Owner helps balance out the team. I would rather have a slightly smaller team and have these roles. If they can’t be dedicated, then at least knowing who is performing the work makes a big difference.
Awesome – A team with the ideal number of members who all know who’s on the team and what roles they play.
Small Team Agile Best Practices
Small teams bring with them unique challenges and constraints when applying Agile concepts. Fortunately, there are several small team Agile best practices for handling small teams and overcoming these obstacles.
Approaches for a Missing Product Owner and Scrum Master
If dedicated Product Owner and Scrum Master roles are missing from the team, individuals can pick up the roles on a part-time bias. This approach isn’t without flaws.
The first flaw is that if you don’t have full-time positions performing the role, the team members likely filling the role haven’t been adequately trained. I face this situation all the time. Unfortunately, it slows down adoption because the team member acting in the position not only has to do their role and a new role, they don’t know how to be a Product Owner or Scrum Master.
The second flaw is that individuals tend to favor the role they prefer or are better at, so they’re not as focused on the position they don’t like as much.
As an Agile coach, you can fill in the gaps and take every opportunity to train individuals. After some point, it makes sense to send people for formal training. My general rule is at the six-month mark. After six months, if the team still doesn’t have dedicated resources and is still small, I will send the person acting as Product Owner or Scrum Master to formal training.
At this point, they will be very familiar with the terminology and techniques, allowing them to soak in 100% of the training quickly.
It’s also important to select two people to occupy the two roles. A single person shouldn’t have both the Product Owner and Scrum Master roles. The roles represent different needs and individual bias, and time constraints will make it hard for a single person to fully represent both positions.
Approaches for Too Few Technical Resources
If there’s a low ratio of developers to Product Owners or Scrum Masters (typically only one or two developers), then the Product Owners and Scrum Masters can perform additional tasks that are more technical.
Functions such as testing and deeper requirement gathering can be of great service to the team, especially if there’s a low developer-to-Product Owner ratio. These tasks may take the Product Owner or Scrum Master longer than somebody trained in the technology, but remember, we are most concerned about team velocity vs. what any one person can produce.
Taking on such tasks can free up developers to perform more programming. This type of cross-training is especially useful as it makes teams more durable. (More on this in future postings.)
Consider a team comprised of a backend developer, an Android developer, an iPhone developer, a Scrum Master, and a Product Owner. At face value, it might seem logical to allocate an equal one-third of the technical workload to each during planning. But let’s delve deeper.
If you were to ask a developer about the time they spent coding for a task that took two days, they might say it took them three hours of actual coding. This raises the question: what were they doing with the rest of the time?
Delivering a piece of code involves many tasks beyond just coding. Tasks could include:
Research
Developing test cases
Refining requirements
Addressing licensing issues
Getting approval for purchasing software
Preparing a demo video
Or documenting the process.
The key takeaway is that all team members should have the versatility to contribute, even if not within their primary domain or with full efficiency. If teams resist this multi-faceted approach, it might indicate a lack of cohesive teamwork.
To illustrate further, imagine four individuals stranded in a desert with a broken-down car, one of whom is a mechanic. Would the others simply sit idle as the car is being repaired just because they aren’t mechanics? No. One might assist the mechanic, another might search for a cell signal, and yet another could assess available supplies. The essence is that everyone has a role to play, and collaboration is paramount.
Planning Strategies
Additional planning may be required around specific team members if they are out sick or on vacation. (See blog post Vacations, Vacations, Vacations.) When teams are small, a single missing person can grind the whole team to a halt.
Consider dependencies when planning. Also, have the person who will be out of the office work closely with the team on any dependent work that requires strategic timing for when they can complete their tasks. Sometimes the difference between getting work done right before and right after a vacation can cost the team two weeks.
The Scrum Master and Product Owner should learn each other’s job. This will help keep the team moving forward if one of the Scrum Masters or Product Owners is absent.
Be realistic when researching and writing up stories. Not having a full-time Product Owner will probably mean stories aren’t as detailed. Remember, the stories must have enough detail so the team knows what the goal of the story is. Because the team is small, direct communication typically isn’t an issue, so team members can resolve story ambiguity amongst themselves.
Applying Automation
Don’t skimp on automation. It sounds counterintuitive, but spending time on automation can really pay off for small teams. Automation is a great way to have others do more because the skill requirements are baked into the tool vs. individuals. This will allow, for example, tests to be run by anyone because they are automated.
Automation will also keep the systems flowing if somebody is unavailable. I love automation because it creates standards and repeatable processes.
Growing the Team
It may be possible to “recruit” from other parts of the organization. Expanding the team with non-technical people from different parts of the organization is a creative way to grow without technically growing.
Look at finance, operations, etc., for individuals who want to learn and be part of your team. You will be surprised how helpful others can be with some training. I once did an R&D project for Google and was amazed at their team’s diversity. (One of the members was a professional card player before joining Google—seriously!)
WARNINGS!
Don’t share the Product Owner and Scrum Master roles. (Yes, I’m repeating this in case you missed it earlier.) It is essential to develop both of these roles, and the best way to do this is to select different individuals for each position.
Give the developers a break occasionally. Small teams can suffer from burnout. Remember, the Agile Manifesto states that work should be sustainable. Let the developers do some refactoring to clean up their code every once in a while, or dedicate a main portion of a Sprint to tech debt or training. Non-developers can use the time to better plan for future sprints.
Small Team Agile Best Practices Conclusion
Small teams are a reality. Just because a team is small doesn’t mean you can’t use best practices to create a high-performance team. I would rather work with a well-formed small team than a typical large team any day.
If a small team performs well, there are many opportunities for growth, including management noticing their productivity, increased demand for their products, members from other divisions wanting to defect to the smaller team, etc. Many of the best high-performance teams I have worked with start as very small teams of just two or three members.
In the future, I will address the opposite issue of small team Agile best practices: that is, what to do if your team is a little too big…
Comments