A little less conversation - a series of common misconceptions in agile teams

And what to do about them

This week’s newsletter address 3 common misconceptions about agility, and provides 3 tools for finding a better balance.

This week I interviewed

Tiani Jones

for the Agile On The Mind podcast. We covered complexity, the differences she’s seen working in software and manufacturing and about a million other topics. I’ll be releasing it next week, so if you aren’t already subscribed…

I’ll be hosting an online business model bootcamp on 9th April. If you’re thinking about starting up your own thing, this could be the session for you. Check it out on Eventbrite for more information and to book your ticket today.

---

A common misconception I see out there is that agility is always about more collaboration, more conversation, more interaction. More More More!

So when I go into teams they will say things like ‘I don’t like agile, I don’t like having to talk to people about everything all the time’, or managers will say ‘we like agile but we also can’t have the team deciding everything for themselves’.

In this post I want to outline some theory that might explain some of these misconceptions, and another way of thinking about how to address them with teams and management. I’ll drip feed some of my favourite techniques for addressing these misconceptions and challenges too.

At its core, agility is about helping an organisation adapt its ways of working to their problem domain. We don’t (and can’t) know all the important elements of the problem space we are working in, so we treat our work as an act of discovery and encourage the team to learn and grow with their findings. This will mean changing our minds with the new information, changing our plans, and changing our ways of working to make the first two possible.

This general approach has led to a few misconceptions about agile teams. I’ll give you a spoiler here, the answer to all of these misconceptions is balance. We need to find the right balance. Lots of the controversy I see in the agile world is about over-emphasising one side of an equation. By the end of this post you’ll have an idea about how to find a better balance.

I have a cognitive science angle on this conversation. Nothing in life is binary. In some views our cognition consists of opponent processing - the balancing of two opposing trade-offs. Working out how to navigate the opposing trade-offs involved in agility is a team-level opponent processing. Let’s see where it takes us.

Misconception #1: Agility is about the teams deciding everything

If you’re doing anything new, changing, or unknown, your main problems are probably complex ones (see Cynefin for more). In complex problems, we make progress by slow discovery of the problem, loose constraints and lots of adaptability. At a team level this means we need the team to be learning, sharing information and sharing their perspectives on the problem. Learning is done best in small pieces, so we encourage teams to try to do something small, simple and valuable and iterate rather than make a big plan for everything all at once.

We also want the team to share and improve the way the whole system works so that they can do their job as well as possible. So we empower good, honest conversation in the team. We rally against ‘command and control’ leadership in which the most senior person gets to make all the decisions about how everything works. We tend to emphasise delegated decision making and team empowerment. If I am the one doing the work, I know more than anyone about what’s getting in the way of me doing my work, as a result I should be able to decide how I go about doing the work.

Now, we can’t have *every* decision delegated to the team. Some problems have implications outside of just the team domain. In healthcare, imagine a hospital that allows every doctor to write their patient notes in whatever language they choose. It may make life easier for a non native English speaker to write in their mother tongue, but the whole system of healthcare providers wouldn’t understand each other when they read through patient notes. What is a local optimisation for one doctor or one team of doctors is a huge liability for the whole patient and hospital experience (I hope it’s clear that this example is only for something like patient notes and I’m not arguing that everyone in a hospital has to speak English at all times or anything mad like that). You would end up with chaos.

The other extreme is where people doing the work make no decisions. In a team where everything is decided centrally you end up with a very fragile system. The central decision makers can’t know everything about the frontline people’s jobs, so it’s inevitable that some of those decisions made centrally would get in the way of the people doing the frontline work. You may have experienced this before. Imagine a hospital in which every doctor wasn’t allowed to use their judgement about which drugs to give a patient, and they had to follow a strict algorithm set by a central team. It would also lead to poor patient care. Literal death by bureaucracy.

Like with anything interesting in life, the answer lies in finding the right balance between delegated and top-down decision making. Agility came along in a context where most of the important decisions taken in organisations were in a top down, authoritarian manner.

In software product teams that might be decisions like ‘which features should we work on?’, or ‘how should we do this work?'. So agilists have ended up spending most of their energy arguing for more delegated decision making to redress the balance. The problem is that now agility has become synonymous with full delegation of everything and that leads to our figurative multilingual hospital. Any responsible senior manager would push back on this.

Constraints are one answer of how to fix this. Leaders with visibility across teams introduce certain constraints, such as rules, guidelines and principles, and observe what impact those constraints have. A good example of this comes from the controversial world of Amazon.

Jeff Bezos’ (in)famous API Mandate set down certain strict rules about how teams should build their software at Amazon to make it scalable. It involved a series of rules about how the databases and applications should communicate with each other using certain technical guidelines.

It’s a little techie, but the first 3 points are some restrictions on how teams should handle their data.

The 4th point reads in part ‘4) It doesn’t matter what technology is used’

And most memorably the last point - ‘6) Anyone who doesn’t do this will be fired’.

They take their constraints seriously at Amazon.

Like or loathe Amazon and Bezos, their technology has changed the world. This particular top down constraint was effective and the memo sets out that balance between chaos and fragile bureaucracy. Here are some hard limits, within those do whatever you need to do.

A softer and more collaborative version of these ways of working can come from tools like Management 3.0’s Delegation Poker. This tool describes 7 levels of delegation which the team decide between them and the manager.

The levels are that for any decision the manager can:

1. Tell: ‘I will tell them’

2. Sell: ‘I will try and sell it to them’

3. Consult: ‘I will consult the team and then decide’

4. Agree: ‘We will agree together’

5. Advise: ‘I will advise but they decide’

6. Inquire: ‘I will inquire after they decide’

7. Delegate: ‘I will fully delegate’

The team (including the senior person that might be in a position to make decisions using their seniority or authority) sits together, maps out all the types of decision they have to make in the course of their work. They then go decision by decision and agree collaboratively which level they should use for each one.

This kind of collaborate approach treats the team like adults and it’s easy to facilitate (but if you’d like me to come and run it with your team hit me up).

TLDR for this section: Find a balance between full autonomy and full autocracy by deciding which things should and shouldn’t be delegated to the team.

Misconception #2: Agile teams spend all their time together

In a team that is learning and discovering effectively, the team will be adept at sharing the right amount of information, and collaborating well as they do the work. Agile teams make use of practices like Paired Programming in which two software developers work together looking at the same screen at the same time to write their code. It makes the most of both of their knowledge and experience, allows real-time error checking and is often more fun and social.

Similarly many agile practices will default towards group collaboration and decision making. In a well-meaning attempt to increase autonomy and create team buy-in, agilists can end up sounding like they are advocating for a situation in which nobody ever does focussed work alone, and every decision that is delegated to the team is made by everyone in the team.

That leads to complaints like ‘I don’t like agile because I like to work by myself sometimes’, which makes my heart sink.

Working with people all the time can’t be the right answer. Working with other people none of the time also can’t be the right answer. An intelligent team aims to find the right balances between working together too much and working alone too much. Some work is better done alone, some is better done in pairs. Mob programming is a practice where a whole software team will code together. Sometimes this is a good option, sometimes it isn’t. Help the team work out which balance is right for the kind of work they are doing.

Equally you have to consider the make up of the team members themselves. Some people want to work in groups all the time, others want to go away and quietly focus. Forcing someone who prefers to quiet-focus to collaborate in noisy groups all the time is exhausting for them. Forcing someone who prefers to collaborate in groups (like me!) to do quiet focussed work is stressful and less productive. The answer is to help the team find and agree the right balance.

If you’re leading a team in which this is a live issue, you might want to try to develop a working agreement with the team for these questions, using a group decision making tool like the Decider Protocol. This technique relies on gaining group consent (‘I can live with that’) for a proposal rather than a consensus (‘I will only accept my first choice option’).

I once led a team at giffgaff through an exercise like this and we got really specific with the policies. One person proposed a policy of

—> ‘We should always pair programme’

and that got amended to

—> ‘the default is to pair programme’

which turned into

—> ‘the default is to pair programme, but if the work makes more sense to do by yourself do that’

and then to

—> ‘the default is to pair, we discuss at the daily standup which work it makes sense not to pair on’.

The engineers came up with all the policies they needed to make it work. They included policies for breaks, exceptions, and maximum session length and wrote them all down and came back to them frequently. We ended up co-creating a collaborative, self-generated and clear agreement that addressed everyone’s fears about switching to a more collaborative style of working.

A similar conundrum can come up when it comes to making decisions about things that affect the team. If you have a question that affects everyone, the inclination could be to turn every conversation about that question into a group one. The problem is that there are many issues that affect your team and if - in the interest of inclusive decision making - everything becomes another group discussion that can leave very little time in the week for actual work.

Try asking the team ‘how much do you want to be involved in this decision?’. Maybe everyone wants to be in the room, and that’s fine. Maybe some people care more than the others and want to be involved in the decision and everyone else is happy to be informed of the outcome.

If it’s a complicated decision maybe a small empowered working group will go away and work on a proposal which they take back to the group. I’d highly recommend checking out Sam Kaner’s work in this area.

Don’t inflict collaboration on the people who don’t need or want to collaborate. Good agile leadership is helping the team find the right amount of collaboration, the right amount of togetherness, and the right amount of separateness.

Misconception #3: Agile is about experimenting with everything all the time

At the heart of a good agile team is the ability to inspect and adapt their ways of working and their approach to solving the problem. The world is complex and changing, so we need to be ready to adapt ourselves to the problem.

In a complex world we can’t be sure that our actions will have the desired outcome without undesirable unintended consequences (some unintended consequences are good, but let’s leave that for another time). So if we can’t predict the results of our actions, we try something and see what it does. We experiment.

A good leader will know that everything we try to do is a guess. It’s a guess that ‘if I do X then Y will happen’. This means that no practice is sacred, everything is potentially up for discussion and we have to always keep an open mind that our best ideas might be making things worse. Just because Pair Programming worked in my last 3 companies, maybe it won’t work here for reasons I couldn’t possibly predict.

A potential misapplication of this idea however is to say ‘if I can’t be sure that something that has worked in the past, today’s team should invent everything from scratch’.

This approach throws away the baby with the bathwater. There’s a big difference between saying ‘this technique has worked in the past so let’s start there and experiment with it’ (good approach) and ‘this technique has worked in the past so it will work this time and now we need to do it’ (bad approach).

When we fail to articulate this well to the teams and stakeholders, we give the impression that agile working is about there being no structure, no starting points, and no received wisdom. No wonder people balk at this.

On the other end of the spectrum you have so called ‘zombie-scrum’ in which teams might use agile-looking practices but never inspect and adapt in any meaningful way. Scaled frameworks like SAFe may give the promise of using all the received wisdom of agile practices but without enough of the experimentation and exploration. In this world ‘agile’ becomes another tool of oppression. No wonder people balk at this too.

Balance is key. Practices that have worked in one place may indeed work in another. The received wisdom in the evolution of the practice might apply to what we are doing here, or it might not. Real agility involves being able to sit with that uncertainty and see what unfolds.

We need to be able to teach, guide, and share things we know and encourage our teams to do the same - after all you’re probably not the only one in the team who has done this kind of work before. We also need to be able to hold on to our curiosity and openness and help our teams into a position where they can discover if something works for them or it doesn’t. It sounds simple, but it’s hard to practice in the cut and thrust of every day work.

In my mind Scrum can get the balance right if it is taught with this experimental mentality. It has a strong and defined starting point with feedback loops and small iterations to optimise learning. Through the process-improving Sprint Retrospective you get an opportunity to evolve from there. If a team wants to ditch the daily standup - sure! Let’s try it and see what happens. As good leaders we will be there to reflect back to them the results of their decisions by asking good questions, encouraging openness and helping the team visualise the intangibles.

So that’s that for now. What are the other misconceptions you see in the agile world around you? Are there any parts of this piece that stood out to you? If you’ve made it this far - good on you. Leave us a like and a comment and that will make me happy.