Alex Hudson

Thoughts on Technology, Product, & Strategy

A short review: The Agile Team Onion

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.

Previous

Next

The ongoing poverty of the Docker environment

2 Comments

  1. Hi Alex, thanks for posting it and it’s great to get some feedback 🙂
    I appreciate that you like how short it is – I wanted to get something focused, quick and free out after putting my paid for book (Building Successful Communities of Practice) out in Feb.
    I’m glad you have bought up customers, I’m going to talk about users here rather than customers (something the Agile Manifesto doesn’t do). Many of the teams I work with are big on user needs and ongoing user research, this has been a big feature of digital delivery in UK government for the last few years, so for me it’s implicit, seeing your comments makes me think I should have more been explicit. I have mentioned user research being part of the core team and I would assume that they/the team were engaging with users on a regular basis.
    The Agile Team Onion is something that I’ve been using with some teams and I’d really appreciate hearing how it works for you or others (the users), then of course, iterating it.

  2. Alex

    You raise a great point, too: I talked about the customer and the ideal of having them there and being able to work with them directly, but that is absolutely an ideal. Once you have a broad enough set of users you’re faced with a variety of problems – maybe they’re potential users in the future, you still need to take them into account somehow. Maybe you want to do a great job on accessibility, in which case you’re trying to take into account needs that very few users would have (which is a little anti-agile in many ways). So, of course, the interaction a customer or user might have within a team could vary massively depending on the precise circumstances – and it’s probably more common, especially when you’re trying to address the general public or mass market, that you’re going to be very research-driven in order to be representative. My bias is start-up and MVP, and in that scenario the initial focus is much more narrow. Thanks!

Leave a Reply