This is a quick and pithy review of Emily Webber’s free e-book, “The Agile Team Onion“. At about 20 pages of content, it’s a concise enough work itself – I personally appreciate the laser-like focus on a single subject; in this case, it’s thinking about the various factors that affect agile team make-up, sizing and interfacing with other people and teams.

A few negatives first, to get them out of the way. The big one for me is that the book is silent on the customer. This is a hobby-horse of mine, because I see this constantly: teams will have some kind of “stakeholder”, “customer champion”, or other stand-in for the real thing. I call these roles “decoy customers”: it distracts us from noticing that the team doesn’t actually have real contact with a customer, and (more importantly) these people are often more chicken than pig. Sales may be important to them, for example, but they’re not fundamentally representative of the users.

In my opinion: teams that do not have constant customer interaction (or, worse, are one or more steps removed from the customer) will build more features that customers do not value, than ones who do have that interaction.

Looking at the agile manifesto, we see the word “customer” appears twice (notably, in the first two principles) and “business people” only once. I’m not sure that’s deliberate, but I like that ratio. It’s sad in a sense that many manifestations of agile, such as scrum, don’t recognise the customer as a specific role in the team – I think that’s an oversight, brought about by the agile principles not really calling it out. The agile manifesto places great emphasis on “customer collaboration” and responding to change, and the best way I know to do that is to have customers actively engaged with the team in multiple ways.

Second, while the book places great emphasis on Dunbar’s number (rightly so), I think it misses other reasons to think about small team sizes. Small teams will communicate efficiently, as the book states, but they will also produce artefacts that are:

• limited in scope in terms of their overall complexity (and therefore are likely to be more amenable to testing, service-oriented design and less likely to be too-tightly coupled)
• abstracted from the overall design of the organisation.

That second point is subtle, but important. Conway’s law states “organizations which design systems [..] are constrained to produce designs which are copies of the communication structures of these organizations”.

Small agile teams that are fundamentally multi-disciplinary transcend the strict chain-of-command organisational boundaries, and allow end product (the software) to be designed in more broad, abstract ways. Do we break free of Conway’s law entirely? No, of course not: small teams with well thought out communication lines to other teams they rely on look an awful lot like microservices, so it’s no co-incidence that service-oriented architecture is all the rage, but there is a lot to be said for loose, independent coupling through well-designed APIs: I think this is effectively the software equivalent of the organisational structure that Webber argues in favour of.

So, onto the positives, and there’s a lot to like about this short book. As I said before, I think the brevity is highly appreciated, and there are plenty of points in here which should get people thinking about how their agile teams function currently.

Recognising silo thinking is absolutely crucial. I think everyone notices this in different ways according to their experience – mine is hearing within programme teams that certain features or requirements had been mandated by “the business”. Of course, I never managed to find out who that shadowy cartel was made up of – suffice to say they communicated solely through intermediaries – but it was a classic information silo in the way Webber describes.

I particularly like the accessibility of this book. I may well end up giving this to teams to help them think about their own team design – and I think this could be a useful tool to re-enforce self-organisation – but actually, I’m very interested to start sharing this with people outside of my agile teams. Not everyone understands the reasoning behind the team design and make-up, and there are some great easy-to-understand points in here which communicate this very well.

There are lots of useful questions in this book, which will really aid people both in the division of pigs/chickens, but also ensuring influence is measured and/or limited as necessary. There is always a massive risk of people senior on the organisation chart attempting to throw their 2p in at opportunities given to them, and being clear about who the decision makers are, how decisions are made and communication, and (importantly) when not to take decisions, is a very powerful tool that teams can use to shield themselves.

All in all, I’ll be recommending this book to people thinking through these problems: there are a lot of resources focussed on “how to be agile”, but very few on the “who”, and although I think that’s a relatively limited problem, I also think it’s crucial to get right.