News

I have already explored two reasons that might lead people give up on agile. The first was losing their focus on being good at what they do and the second was implementing agile approaches as a goal rather than a means to an end.

This time I thought I would look at another common situation – when becoming more agile is probably a good idea, but the people who want to implement the change are in fact reproducing the old way of working that they want to get rid of.

My slightly weird theory is that people want to change, but the way they are currently interpreting the world gets in the way.

A primer in super-advanced neuroscience

Supplemented with elastic muscle engineering

There is a saying that “seeing is believing,” which is normally used to suggest scepticism and the view that I will be convinced by the evidence I see.

However, according to my pop psychology understanding of neuroscience, the evidence we all see depends on what we expect to see, which is based on what we have seen before.

For example, when Europeans first arrived in Australia, they saw kangaroos for the first time. You probably know what a kangaroo is and you probably know that a kangaroo is not a deer. For one thing, kangaroos bound along in large leaps and have huge back feet.

But the Europeans had no concept of a kangaroo because they had never come across one. So if you look at the first recorded (European) descriptions of a kangaroo, one author mentions seeing a deer, another describes wallabies as kind of cats.

Later I guess they realised they were not looking at deer or cats, but there was still something about kangaroos that made no sense.

If you or I jump instead of walking we will get very tired because we burn a lot more energy. So it makes sense that a kangaroo would only travel short distances at high speed before getting tired, especially if they are taking giant leaps at every step.

In fact, though, the kangaroo’s jumping is specifically designed to save energy. The whole point of jumping is to recycle energy so that the kangaroo can survive in an arid land and travel long distances to eat and drink.

Kangaroos are actually pretty bad at moving slowly and so they hobble along on two giant legs and two tiny ones, or they use a giant tail as a third leg or crutch to hobble along. You can check that here.

So the real skill of the kangaroo is not sprinting short distances, it is maintaining speed over great distances. Jumping actually allows to kangaroo to recover energy each time it lands, so that each future jump requires relatively little energy.

Enough about Kangaroos. How does that relate to agile?

So what does all that have to do with agile? Am I going to claim that the secret of agile is to bound like a kangaroo so you can maintain high speed over a long distance instead of sprinting and tiring? Or maybe that agile teams find it hard to go slow and look a bit funny as they hobble along?

No, I just like talking about kangaroos.

Anyway, let's get back to looking at why agile approaches are failing in many organisations.

When the Europeans saw a kangaroo, it was quite natural to see it as a deer like thing, since that is what they were familiar with. It took a long time to actually work out that a kangaroo was a very different beast.

In the same way, when people in organisations first encounter “agile” they need to make sense of it. So they compare it to what they already do, which helps them make sense of things and is quite a natural approach to take.

But this can also hinder understanding.

A stand-up looks a lot like a status meeting, so the team report their status each day, taking 45 minutes to get through everyone. But a stand-up is not a status meeting (at least not one for managers). It is about each team member understanding where the team impediments are and whether they need to interact with others.

Then the team sees a showcase – which looks like a roadshow for stakeholders to get excited, or another status meeting. But in fact, it is a feedback loop for the team to improve its planning, so it is good to show bad outcomes.

The product owner (PO) looks a lot like a subject matter expert (SME) and stories look a lot like requirements. So instead of the team adopting a rich storytelling tradition, they get the PO or a BA to write stories. It seems to make sense but it is actually an example of adopting existing practices rather than making the leap to become agile.

Even IT people see agile as a better way to write code and it makes sense in that way, but that attitude means that “the business” need to get work ready for the team to keep moving and “done” means the code is good. This means the team is writing good, irrelevant code. But worse, then need to finish by the end of the sprint so they cannot test everything at the end. Testing falls by the wayside.

Then the team realise that they are quickly building irrelevant code that is untested and cannot be deployed. The “PO” feels harassed as she is forced to keep writing stories without a chance to talk about quality or pause for breath. The team are doing the complete opposite of agile and yet it looks as though they are doing agile and it is failing.

Coaches can be good

This is where a good coach can help the team. Not by teaching simple techniques like standing up in the morning for a meeting but by helping the team interpret what agile means and where it fits in. You could call this helping with a “new mindset.”

The coach can help people see the connection between agile techniques and the things the team is already doing. The coach can also help the team understand where an agile approach is absolutely NOT the same as what the team thinks it is.

You do not need a coach to gain this learning, but it helps to have someone who can step back and see reality in a different way. It also helps if that person can explain new things in a way that makes sense. In the same way, a scientist who understood kangaroos could have explained a lot to the European arrivals simply by having a different knowledge base.

But teams can make this leap on their own too.

People work it out at a team level

Once the team starts doing some of the agile practices they start to feel uncomfortable. They are trying to do the right thing but they are struggling to get it to work.

The business stakeholders don’t have time to help, testing is not working and the team seem to be stuck in a lot of meetings.

This is a key point of transition though – if the team do not feel this dissonance (discomfort) then the odds are that they are not really changing the way they work at all.

Anyway, there are two ways out of the discomfort – one is to plateau. This means that the team stops changing and things eventually go back to what they were like before. The team are unhappy with things but comfortable with their sorrow.

This is the first point where many agile transitions fail – because the new way of working is literally not making sense to them and they are feeling more stressed.

This is also a point of failure if the team has employed an evil coach. In this case, the coach will see the team reverting to old ways and will come and scold them. The team are failing to adopt good agile and must be doing something wrong. The coach has seen this before (or thinks he has) and knows what to do. He drives the team harder and rallies them with tales of paradise. But since none of this makes much sense to the team the coach may as well be shovelling the tide back into the ocean to stop it coming in.

Of course, that is not what we want. It is better if the team can work through the dissonance and some things make no sense for a while … then suddenly in an epiphany, they come together. Then things are making sense for a bit and then there is dissonance again and then another epiphany.

Both a coach and a retrospective can help here. But the main thing is for the team to work together and continue to question while continuing to try to make things work.

8 weeks or so later the team will have found a new rhythm (or cadence). I have no evidence for the 8 weeks but I am confident the team will find their rhythm. But they will also have new potential gains as (seemingly) new impediments and constraints become visible.

This is the next point where some teams grow tired. They are actually doing a good job of understanding their constraints and working within them. They should be proud.

But they know what agile should look like and it is not them. So they become discouraged. But this is unhelpful and it is like assuming that they should move like a deer when they are a kangaroo.

Outside constraints and the context that the team is working in should inform the adoption of agile approaches far more than some video of a company in another country, in another time, adopting what seemed to be good.

Again a coach can help here, helping the team recognize the progress they are making and also helping them to give themselves permission to slow down if they need to in order to get work done without stress or to speed the change and push through the stress.

Evolution favours the lucky

Many teams make it this far and things are good for them – they will even say that they would never go back.

But they are sometimes a small part of a large organisation and this is where they sometimes feel too much guilt. They are doing good work and their stakeholders are happy, but they are still stuck with the disconnect between how they operate and how the organisation operates.

This is actually quite natural but for some reason, people seem to feel guilty.

But the team is also a bit fragile here because of two ailments that large organisations typically suffer from:

• Restructures;
• Clonification

Restructures are a real problem for agile teams who have found a niche in a larger organisation.

A new boss or becoming part of a new team can unravel all the changes that the team has made. In fact, you could argue that since the team are operating in a new context, they should undo some of the changes they adopted. But it also means that people who see the team and don’t understand agile are likely to make judgments based on their misunderstanding.

But even if the team does stay intact then their stakeholders might be restructured. The team had a great business sponsor, stakeholders who worked well with the team and so forth. Then things change and the team needs to fill the gaps.

In some cases, I have seen teams doing good agile and then forces outside their control changed the world and the team stopped. I am not sure if I would call this “walking away from agile” but it does create a source of frustration.

So once you are reasonably agile I think part of the focus should be to talk openly about how to maintain and increase your resilience to adapt to change. Perhaps providing evidence of value or working well with other teams as things evolve.

Finally, there is another ailment – clonification. This one is so bad that it is not even a word. I made it up to describe the habit we all have of wanting to copy what is working well.

Let’s assume that the team is doing well with their agile work. Their stakeholders are happy, the team is engaged and we can see real value in what the team is doing.

Well, we should probably have more of that then.

We decide to clone the team by creating new agile teams. This is honestly a good idea, but again we make the mistake of not seeing what really created the success. We take what worked for one team and hand it to the next team.

It makes sense that the same things will work because they are good and it makes sense that the next team will learn faster because the first team did a lot of the hard work. But unfortunately, the new team is not the old team any more than a kangaroo is a type of dear.

There are many things they have in common and many lessons we can take from the first team, but we also have to allow the second, third and future teams time and space to make sense of things for themselves. It will help a lot if they can actually see something working in their organisation but they also need to be able to experience it to get up to speed.

But there is another form of clonification that is also dangerous. We see agile working at a small scale so we implement it on a large scale.

I am not against doing things at scale, but again we have a challenge. When people envision agile at a large scale they once more interpret it based on what they have seen.

Some people scale agile by reproducing everything they already have in an “agile way.” So they have the agile PMO, the agile steering committee. the agile handover from the project team to the product team (er production support).

Other people look at each part of agile and scale it. Scrum teams have a sprint that works well, so we could have a mega-sprint that duplicates this but is 12 weeks instead of 2. Scrum masters are great so we should have a mega-scrum master. It is all quite logical and it should work the same way.

Back to the Kangaroos

But I should warn you. There is a physical limit to how big a kangaroo can get while still being able to hop along at high speed.

The sophisticated engineering of the kangaroo muscle and bone structure only works when the weight is lower than the force the kangaroo can absorb and push through its muscles.

There are stories of giant kangaroos in the ancient past, but it appears that they walked around slowly rather than bounding along quickly. It appears that they were optimized to forage more effectively before Australia became so arid, rather than to move great distances at speed.

And there may be a reason why giant slow-moving kangaroos that were delicious to eat became extinct.

I am honestly not sure whether there is a similar limit to how big an agile team can be. But in my final article in this series, I will ponder a theory that scaling agile often fail because people think it is something that it is not.

You cannot just keep doing what you are doing and rename everything agile, but nor can you simply take a framework that makes all the agile practices giant and hopes to move at the same speed, with the same energy conservation that you had with small empowered teams.

Posted by James King
Copyright © James King