Agile Baristas

How many baristas should a team have? The answer will depend on the team, of course. So let's assume it is a stereotypical digital product development team that converts caffeine into code and user experience. How many baristas do groups like that need??

You might say that the question is silly. Has anybody heard about baristas on an agile team? Surely, they don't need any baristas!? Anyone can make coffee. They can make their own beverages, don't they? OK, but would that still be true if I told you there was a proven link between the team's coffee quality and customer satisfaction? If it were so, how many baristas would make sense to have on a team??

Team

Before we answer this question, let's look at what teams are and how they work. Typically a team is a small group of people who collaborate to achieve shared goals. Teams in the agile delivery context are the basic units of delivery. There is no 'I' in 'team', and no individual should be assigned any work directly. Why? Because "only teams can tackle the complexities of the challenges brought by an interconnected world". It has a lot to do with cognitive capacity and context switching, but before we go there, let's look at it from the numbers perspective - the strength is, after all, in the numbers!

Often, a team is more than a sum of its parts. This is because of the trust on which teams are built. Instead of each team member making their own cup, they can take turns ensuring everybody is sufficiently hydrated while minimising disruptions. In fact, there is often no need for communication, coordination, or formal agreements in established, high-trust teams. In such teams, everybody knows each others' drink preferences and patterns. They sense who needs a drink, an extra bit of sugar and who has a moment to make it. Things like that just happen, so perhaps there is no need for a barista after all??

Trust

Anthropologist Robin Dunbar proposed in the 1990s that the most relationships we can maintain are around 150. This was an extrapolation from his research on other primates, and the exact number is now often disputed. But the principle he described remains true. We can have only a handful of "close friends", people we trust a lot. We can then have two or three times more "good friends" we trust and a few times more "friends" we trust a little. We can observe this pattern in our personal and professional lives. Teams with more than five members often struggle and split internally without ever reaching the Tuckman's performing phase.?This is especially true for low-trust, unstable environments.?

So perhaps a small, high-performing team doesn't need a barista, but a larger, not so well performing team could use the help of one? Here we have the first paradox. We could improve the team's capability by adding extra specialised members, but by doing so, we make trust more difficult, limiting the team's productivity.?

Productivity

Since we are at it, what is productivity? It would be a mistake to simply say that it is the measure of how much we produce. Instead, we should think about it from the perspective of our objectives. "Productivity is the act of bringing us closer to our goal". In this context, efficiency is the ratio of time when we are productive vs the total time we have. Being busy is neither indicator nor a substitute for productivity if it doesn't get us closer to our objectives.?

The productivity of a team depends mainly on three factors. Firstly, its ability to work on the most important things first. Prioritisation! We are all doing our best all of the time. The only way to maximise the value output is to ensure that we work on what gets us to the goal the fastest. The challenge here is that what it is can change without notice and outside any prioritisation schedule. Work of the highest value yesterday may be of little value today and no value tomorrow. The best prioritisation can be undermined by the time it takes to deliver.?

This leads to the second factor influencing productivity: the rate of value flow. Rate not volume! We need to shorten as much as possible the time it takes from deciding to work on something to when it is delivered. This will most likely mean that we will do less and feel less busy because we will need to reduce, not increase, our efficiency to optimise the flow rate rather than volume, but the value delivered will increase, which is what really matters.?

And this brings us to the third factor: focus. The process of converting caffeine into a user experience is knowledge work. How effective we are is constrained by many factors, including our skills and experience, and most notably, our cognitive capacity - our ability to consume, retain and apply knowledge. This ability is in very short supply, and we must use it wisely. While it can be slightly increased with caffeine, it can easily be destroyed by interruptions and context switching.

Teams have cognitive capacity too. It is the sum of its members' brain power, increasing linearly as the team size grows. But at the same time, a higher and higher proportion of that brain power is utilised for communication inside the group. This effort grows exponentially. So there is a team size, typically around 5, where adding more team members reduces the available cognitive capacity rather than increasing it.?

We want our team to be productive, so it should be relatively small, focused, not too efficient, but well aligned to the business need.?

Are we ready to answer how many baristas it should have??

Professionalism

We started this thought exercise by asserting that the team would produce a better quality product for its customers if it had access to better coffee. Even a single barista brings to the table their professional excellence. They will do what they do best: serve exceptional coffee. The other team members will enjoy the improved quality and spend more time on what they do best.?

Or will they? There is a risk that the team's coffee consumption will increase. The coffee is tastier and appears free - it just arrives, but this is not the main problem. We have introduced a new, proud professional to the team. Just imagine the additional requirement gathering, user research, feedback collection, show and sampling sessions, and, of course, the improvement of the beverages served. All because we have a dedicated, passionate professional who cares about that part of the delivery process. But how does that extra internal quality impact our productivity - the ability to deliver value??

I call this the overinflation of professionalism. Some may call it the pitfall of local optimisation. It is related to Parkinson's Law - an adage reminding us that work tends to expand to consume all available resources.?

Let's weigh the pros and cons. On the one hand, we have the promise of improved delivery. On the other, the risk of delayed deliverables.?

Does it mean that professionalism is getting in our way? If we aim for some utopian best product ever, focusing on the quality of the output and the delivery process, then no. The more professionalism, the better. But if we want to deliver more value to our customers quicker, we must consider productivity. We have to look at the balance between quality and cost. We have to align our efforts with the need of the customer, not ours and accept that artisan coffee, while satisfying, might sometimes be just a little over the top.?

Topologies?

But I'm not suggesting we should deny the team what they need! 'Team Topologies' is a way of thinking about and organising team interactions. A cafeteria would be an example of a platform team that can provide essential services to other teams. Platform teams free up the capacity of delivery teams by offering their standardised, cost-effective services. Of course, it introduces some inter-team dependency, but as long as the service requests are small, primarily non-blocking and promptly delivered, the occasional wait might not be a problem.?

And if the delivery team cannot afford the wait or consider it too disruptive to their flow, they can turn elsewhere for help. An enabling team consists mainly of professional baristas who continuously experiment, innovate and excel in coffee brewing. They explore the ever-changing industry best practices and help the organisation prepare for the future. In addition, they are experts at identifying skill gaps in delivery teams and fixing those problems by upskilling, short-term support and professional advice.?

Both the platform and the enabling type teams offer support to help the delivery teams meet their needs, so they can focus on the needs of their customers.?

Autonomy

But doesn't it go against the agile, lean delivery principles? Shouldn't the teams be cross-functional and autonomous? Of course, they should, but it doesn't mean they must be experts in everything and totally detached from others.

The idea is that the teams have enough expertise to effectively deliver value in their context. That they can autonomously optimise how they work. There are no extra points for doing so in isolation.?

Let's say we had baristas on the team. Would we expect them to grow coffee plants and roast the beans? Would we expect them to forge the metal for an espresso machine? Or would we prefer they take on dependencies from coffee roasters and espresso machine suppliers? In fact, since coffee production is not an essential part of the team's mission, shouldn't the whole process, including the barista, be outsourced to the cafeteria team??

Dependencies like that don't reduce autonomy as long as we don't distribute the responsibility for the outcome. It is the delivery team's responsibility to meet their user needs. If they can do so by getting reliable services from the platform teams and timely support from the enabling teams, there is no good reason not to do it. However, taking on service dependencies doesn't free the team from its responsibility. If the cafeteria is closed for the day, or the queue is temporarily too long, they will have to make do with making their own brew. The quality of their experience might be temporarily lower, and the effort might be higher for a moment. Yet, they will still be able to continuously deliver value for their customers, which is what really matters.?

So... no baristas in a digital product delivery team.?

We are all baristas

With one question answered, we suddenly have many more. The argument with baristas could be repeated for any profession involved in digital product delivery. And there are many. I could easily count two dozen.?

This is the second paradox we have to solve. We value the quality of the things we build and pride ourselves on our professionalism. Yet we have just established that there is no room for a barista on a team! In fact, delivery teams, to be effective, have to be so small that there is no room for most of the professions needed!?

The agile mantra that the teams have to be cross-functional and the cliche about T-shaped individuals stem from this fact. They point at a solution high-performing teams have been using for some time. Such groups don't need representatives of the professions as their members but a shared willingness to take on just enough responsibilities for those professional areas to deliver value for their customers.?

In Team Topologies, teams like that are known as stream-aligned. They focus on the customers' needs. Their understanding of the problem domain, not the technical expertise, allows them to maximise both the work not done and the value delivered. They are the Pareto engines of any business. They consume services from the platform teams (cafeterias), get support and advice from the enabling teams (the baristas extraordinaire), and, when needed, get help from the complex subsystem teams (specialists that fix coffee machines when they break). But most of the time, they prioritise the work, choose the right level of quality and excel at delivery.?

Stream-aligned teams are ultimately responsible for the delivery. With the proper support, they are unstoppable. Problems cannot block them. After all, hurdles don't stop hurdle runners. They are just something to get over and continue towards the shared objective.?

Scaling

But the teams have to be small, and our projects and challenges are so big! How can we scale??

We often imply 'up' when we talk about scaling. How will we grow the team to meet the demand? We talk about the economy of scale, implying that more is always better. It inevitably ends in frustration. What we get is the exponentially increasing overhead of communication and enterprise governance.?

Fred Brooks noticed it in the 1970s. Adding people to a late software project makes it later, he wrote. That's because it's a thought, not muscle work we do. We are not adding hands to a rope that needs pulling but opinions to a debate that needs resolving. There is plenty of evidence that it is as true now as it was half a century ago. We have mathematical models to explain the phenomenon.?

In our type of work, we should scale 'down' to find the economy of small scale. Small backlogs are obvious to prioritise. Small problems are easy to solve. Small asks are quick to respond to. Small failures are easy to recover from. Small is fast, and many small wins quickly add up. Less is more.

But what can we do with the huge demands and long backlogs full of enormous and very important asks? Considering the barista dilemma above, there is only one way to go. Scale down! Scale it all down to match the optimally sized teams. We are not understaffed. We are overambitious and not focused enough on what matters the most: collaboration towards shared objectives.?

Avoiding a barista-shaped silo

Collaboration is not simply working alongside each other for the same customer. Taking turns to work on the same widget is not it either. Instead, collaboration means working together on the same problem towards a shared outcome.?

Dividing the work by profession is tempting. Let the specialists do what they do best. Nobody but the barista touches that espresso machine!

But what if they are not in? Could we use it? Should we wait? They might be back tomorrow! Will they be upset we did their job? Let's wait.?

This approach prevents collaboration and denies the team the benefits of teamwork. Instead, team members' diverse experiences and perspectives are siloed in their individual professional portfolios of tasks. It's local optimisation. The quality of each separate part may be excellent, but what about the outcome? Often too late and not as good as it could have been.?

It gets worse. Often professionals in the teams work alone on their tasks. That limits opportunities for professional growth both within and across professions. Moreover, it makes the 'team' fragile with fragmented knowledge and absence-induced delays.?

Wrapping up

Organisations are constrained to produce designs which copy their communication structures. As a result, large, complex teams deliver large complex solutions. By ensuring good communication between everybody in the business, we ensure our systems are massively interconnected and intertwined, challenging to build, maintain and change.?

We should engineer our interactions to collaborate without coordination and deliver coherent solutions without agreement. We must divide our objectives into distinct value streams along which the teams can align, and we should let them do their best while offering the tools and support they need.??

We must show restraint in tackling inefficiencies. Some duplication of small efforts is much better than the effort it takes to completely eliminate the duplication.?We must show restraint in tackling imperfections. Perfect is the enemy of good. Deliver, evaluate and iterate. Incremental value stream the agile way.?

#agile #productdevelopment #teamwork

REFERENCES

The concepts presented above are not original. They are based on at least half a century of our collective software engineering and digital product design experience as an industry. It is an attempt at presenting the collection of adages, phenomena, research and more popular writing in a concise, relatable form. In our industry, we often forget that we could be standing on the shoulders of giants. For more detail, please see the articles, books, and conference talks by Kent Beck, Tom DeMarco, Vasco Duarte, Eliyahu Goldratt, Henrik Kniberg, Kevlin Henney, Allen Holub, Andy Hunt, Timothy Lister, Stefano Mastrogiacomo, Cal Newport, Alex Osterwalder, Manuel Pais, Mary and Tom Poppendieck, Matthew Skelton, Dave Thomas, and probably many others.?