Why Teams Should Be Small

Size DOES matter.

In a post by Steve Denning in an article on Forbes, he coins the term “The Law of The Small Teams”. He claims that in order to be agile, an organization has to embrace the law of small teams. This post expands on his viewpoint explaining the practicalities of what exactly makes a small team agile and why. I don’t intend to restate what he has already mentioned, so please do read the links to his articles for more on his perspective.

What makes a small team agile?

Most organizations don’t start off their agile journey with a fully autonomous and cross-functional team — one of the characteristics of an agile team. Actually, most organizations don’t reach this goal after years of practicing agile.

Simply having a small team does not make you agile.

The smallness is important of course, but what then makes a small team agile if it’s not the size?

Breaking down the elephant

A team, is a group of people with either diverse, or similar skills. Most organizations I’ve come across organize teams according to skills, keeping the developers in one team, and requirements in another team.

But first, let’s look at what skills are usually needed in a big organization to deliver a product to the end-user — from inception to end — on a generalized level.

Usually, some kind of analysis and feasibility study is done to determine what to build. In a traditional organization, this was the role of the business analyst, sometimes the business owner, other times marketing or the product manager. In a more agile environment, the role is the responsibility of the Product Owner. Each organization calls it something else, but the skill — not the role — required is to analyze the business and discover a need that can potentially result in revenue.

Next in line is someone who is able to make it look good aesthetically, and make sure it is easy to use. The designer or UX team is usually responsible for this, sometimes the business analyst, but the main skill required is that of design.

Then someone needs to look at the entire system as a whole and figure out how best to design a solution that will technically work well, without breaking any of the already existing parts. This can be a dedicated architect, or a senior developer, sometimes the development manager. Regardless of who has the responsibility, the skill set required is that of a strategic thinker with the ability to envision the big picture of a technical solution.

The developers then drill down and ground this vision into functional software, using a set of technical skills like programming in a specific language,TDD, or other skills depending on the technical environment.

A tester zooms out again looking at the big picture again, making sure that the integrated parts work well together after it has been unit tested by the developers. Typically, the skills required at this stage is a methodical approach to work, high attention to detail, and the ability to analyze and isolate issues, all while keeping in mind the customer expectations and needs.

Finally, someone needs to communicate the message to the user and make sure that what they receive they can use. These people are usually good with words and writing and typically called a technical writer.

Same-same, but different

Each person has different skills. Sometimes the person specializes only in one area like programming in one specific language. Other times a person is good at more than one skill, like programming and design and maybe architecture design.

It thus doesn’t make sense to use a generic role to decide on the team layout for an agile team. Rather, it makes sense to look at the skills required for each product being developed. Often, small teams focusing on roles and not skills will be less agile.

An easy check to verify whether your team meets this requirement, is to ask whether you have all the skills you need in order to deliver a product?

If the answer is no, it does not necessarily mean that the team is not agile, but it will necessarily mean that your cycle time will be longer and your efficiency lower, making you less agile. More about this topic in a later post.

The one person team

One of the most common dysfunctions in organizations is what I call the one-person-team. In these “teams” people share desk space and they report to the same line manager, but each has their own agenda and there is as little as possible collaboration between team members.

Typically they will each pick a task and only take responsibility for their task. When another team member has a problem, they will shrug their shoulders saying it’s not their problem. They care only to do what they have to do to get a bonus, or not to get fired. No more, no less.

Simply putting people together in a small team does not make them agile.

But what then does? This is best answered with a quick exercise and going back to the essence of agile, namely that of the value of having different perceptions.

Who has the best efficiency?

When you look at the diagram below, Team A represents a one-person team, where work is passed in a waterfall approach from one person in the team to the next. Team B is a cross-functional agile team, where each person has a different skill-set, with some overlap. Team C represents a big organization with many products and large teams.

Now, imagine these three teams were to describe what they see around them to a blind man. Which team has the most comprehensive view, with the least amount of waste?

If you answered Team B, you are correct.

In Team A, because of the lack of collaboration, each subsequent person views the story from his or her perspective only. Valuable insights are lost, and errors or a under-developed skill might be easily hidden. That might mean that technical debt are being introduced without anyone noticing. There is typically overlap with two people doing the same work, and parts not being looked at by anyone at all, but because they don’t talk to each other, no-one notices until it’s too late.

Their perspective can be described by one person that is only able to see what is directly in front of them, with little view to his sides, and none of what is behind him.

Team C, on the other hand, is so crowded, that the people in the middle can’t see anything outside the circle. A lot of time is wasted trying to convince each other of their viewpoints, and more confusion than clarity is created by the amount of varying viewpoints. Or, as per Jeff Bezos two pizza rule, the number of interactions are too many for communication to be effective if there are more people in the team to be fed with two pizza’s.

Even though they should be able to see more, the many contradicting views results in so much ambiguity that in the end everyone is confused, most of all the blind man.

Team B, however, each has a unique and valuable viewpoint, with no obstructions to obscure their view. They are able to clearly see the entire product, with each viewpoint adding a unique perspective that helps build a better product.

They have a 360 degree view of what is around them, and describes accurately to the blind man what they see with little to no ambiguity.

Conclusion

The law of small teams is useful because it is the most efficient way of creating a function or a product, without any waste.

The main question that you need to ask to evaluate whether your team is cross-functional, is “Do we have all the skills in the team to deliver the product?” Having only one set of skills in a team will slow down the cycle time, with the more skills outside the team, the slower the product’s cycle time.

An agile team combine different and unique perspectives to form a complete picture, with the least amount of waste.

Originally published on Medium: https://funficient.medium.com/what-is-agile-anyway-part-2-6a0934681ca6