Are you…Doing Agile or Being Agile?

Before you read this article, I’d like to make it clear that our intent is not to ridicule or be disrespectful to those doing amazing work and doing agile transformations. People like Clarke Ching and Russ Lewis I know do incredible work in this space, I'm sure you are too. The case discussed below is based on actual events and the data in our research was captured over 55 different agile products.??The global research discussed was conducted by the Standish Group based on digital agile delivery between 2011 and 2020.??All views and opinions are always respected in our posts.??But if you’re squeamish, maybe best look away now.?

Are you…Doing Agile?or?Being Agile?

I phoned up my local gym and asked them if they could teach me how to do the splits…they asked me how flexible I was. I said I could do Tuesdays or Thursdays. Like flexibility, Agility in organisations can often be misunderstood too.?Many claim they are doing agile. But like going to the gym, it’s no guarantee of being agile.?

Doing Agile – A Case In Point ?

When an organisation complains of poor product delivery, rising costs, and late running projects, often leaders jump to the agile framework as the solution.??More often than not, it is a proxy for change. New activity?surrounding the work camouflaging the lack of change in?the work.?????

This business was poor at releasing new products to market. Competitive advantage was being lost. Customers and shareholders were, to say the least, cranky. The agilest’s were wheeled in and agile was done to the business. It’s a seductive solution is because of the visible pomp that comes with it.?

To start, new cadences and events were introduced. The first you’ll know of as a sprint. In a sprint, the team would come meet to plan an arbitrary ‘time boxed’ window for working. Two weeks, where they’d work quite fast. The perplexed leader later commented, ‘I thought we were already working hard, now it seems we’re just trying to shoe horn and break up pieces of work into a ten day window, before taking a breather.’?

But the argument by the consultants, was that work was now sized through a mechanism called ‘story points.’ The team decides and learns how many ‘points’ they can deliver each sprint. They can then predict what they’ll complete in the next one. At the end of the two weeks of flat out running, everyone comes back together to add up their points and then go again. If high levels of points are allocated to each work chunk, the team can claim that they did, for example, 10,000 points that week, which admittedly sounds quite a lot. But as you’ll see later in this paper, the number of story points completed gives no indication about how long work really takes or how many of the right pieces of it are done.?????

The solution…erm, didn’t actually change anything.

There were two glaring issues with the solution:???????

1. Nothing about how the work was being done (planned, designed, managed, or executed - the kind of important stuff) had been changed.
2. The reason that nothing had changed, was that no time was taken to understand the reason why the products weren’t being delivered quickly in the first place.

Meaning the old way of working stayed the same, but it now had a few balloons and ribbons wrapped around it.

As a boy I used clothes pegs to pin playing cards to the front forks of my bike, the cards would flick over the spokes sounding like a motorbike engine or old lawnmower, depending on the age of the cards. Like agile I was certain that they made my bike go faster, they didn’t, but there?was?a lot more noise.??

The consultants, celebrated a quick win based on the new ceremonies, with teams of people ‘talking to each other more’ but much like where the emperor in his 'show and tell' revealed his new attire, it was obvious when you looked, he was still quite naked.

Addressing the real issues in late running product delivery?

What do I mean by not changing the work??

If you’d studied the reasons for late delivery of the product you’d see:?

1. Work was being done out of sequence; capacity, lost as the wrong work was being done at the wrong time.?
2. Too much work in the system, meant that the choices around what work should be done were being done incorrectly, stressed about being late, the team would choose the easy work first to demonstrate lots of progress. But all the difficult work, still to be done, was left till the end, making the delivery run late.?
3. Work was regularly blocked, when this happened a developer would put the work down and go to another piece of work, again capacity lost as more work was done out of sequence.?
4. Tasks were often difficult to understand, if a developer didn’t know what to do then they’d put the hard one down pick up one they could understand.?
5. The team had regular due dates to hit, instead of being encouraged to work faster, people would work to the due date, meaning that work would expand to fit the time allocated and would never deliver early.??

When we looked at work design in the sprint, it contained the same issues as before but now it was done in two-week increments, with a bit more chatting.??A study of the sprint performance showed:??

1. 42% of the work was removed from the sprint before the end of the ten days (despite all the careful planning). Then a further 20% was not completed at the end of the sprint.??All of this work was then put back into the backlog and DIFFERENT work put into the next sprint, meaning that once again random work was chosen for each sprint, meaning the same issue was prevalent. Work was done out of sequence and capacity lost.?
2. Blocked work was still put down and new work picked up.?
3. Work was still described badly. So the easy work was chosen in place of difficult to do items.?

Oh well, we still had the metrics they’d developed to look at, by this time I was actually rooting for the poor chaps.??

Let’s have a look and see what the agile team came up with.?

Measuring what?doesn’t?matter?

Goodhart’s law,?says that what you measure might not be a direct representation of how well things are actually going, maybe you’ve heard of this phenomenon in other teams or organisations? [sic] Good measurement practise should start with the system’s purpose and let the metrics emerge from there.?

The purpose of this system ‘to deliver the right product, to the right customer, on-time and efficiently.’?But wait, none of the new metrics provided any insight or decision making ability against this purpose.?

• Sprint Burn Down: Having allocated points to each piece of work, there was a daily graph showing the number of points that were completed. Was it the right work, in the right sequence, was it done the way the customer wanted it??Who knows??
• Velocity: This data shows us the difference between the number of points completed vs the points estimated. Was it the right work? Still don't know. We found people cherry pick the easier work to help get though more story points.?The hard sometimes, more important work, is left to the end of the project.?It then may have to be de-scoped to meet the deadline.??
• Utilisation: Are our people busy??Are they busy on the right things, who knows? People cheat you know to meet the numbers. Creativity being used to create Jira tickets to allocate points for creating Jira tickets, hey points mean prizes!

We knew the measures in the previous system were not helpful. Once per week the project manager would ring round everyone and ask them if they were on time, they said they were, until they weren’t.??So, whilst there were, now, at least, some new measures, unfortunately, none of them were any better.?

To summarise, there are two issues with the change.?First, nothing was actually done about how the work was designed, managed, or executed. The equivalent of having a sick patient, arranging a placebo drug, and getting them some streamers and a kazoo, in the hope that this will make them well. Then arbitrary metrics captured the speed of abstract pieces of work - like knowing the patient was being driven in an an ambulance at 100mph but not knowing whether they were going to a hospital or or not. ?

Many teams argue that they are?doing?agile.??And they’d be right; ceremonies, sprinting, story points, burn-down and velocity are all facets of agile.??But with nothing changing about the way the work is done, how it flows through the organisation, or how it responds to customers - it seems obvious that they not?being?agile. Further, at least in this case, nothing was done, to change the construct of the business, meaning that the functional platform and team design, targets & SLAs and activity focused leadership all went unchallenged.?

Putting our money where our mouth was, we took out some insurance – start with study

When we were called in, we started by capturing data on the current performance of the system and the reasons for the failures.?

We found that small pieces of work (3-8 story points) which should have taken a few days were taking an average of 47 days and larger pieces which should have taken around 20 days were taking upwards of up to 250 days.?

Figure 1 – The actual time taken to deliver a selection of low point stories

As we suspected, work was being done out of sequence, there was no real sizing convention, capacity was not in-fact considered, scoping and planning of the work were done by the wrong people.?

At the point that we took over the product delivery project, nothing had been delivered in two years and the market launch was now running nine months late.?We changed the work, how it was planned, managed, executed and measured, the products were delivered in full, months before their original due date.

And, further, to cement the change it became apparent, wider conditions of the system had to be addressed.?So, the client got to work building teams that could build and release products independently of other teams.?She understood the need to reconnect development teams back to operations, so that she could take signals from operations with which to build new products and then test them there before releasing back to the market.?

Metrics would now be end to end in operations and development teams.?They’d show the throughput of new product delivery, the amount of work in progress in the system and if projects with a hard due date were running late, and what to do when they were.?Even the annualised nature of projects was challenged (this is a work in progress).?

Working to address these issues is a profund change for leaders, their day job changes they tell us, ‘From attending meetings and adding up pieces of work done, to fixing problems for front line teams and shifting the business from a factory based design to a flow based organisation'. Their role becomes purposeful again.

It was at this point the client said to us, it seems clear that ‘I’m no longer doing agile…but I’m certainly being agile.’?

She was very happy.??

What to do next

If you want to check if you’re doing or being agile do this:?

1. Go into the work and study it. Follow how work arrives at your business and follow it through to being delivered.?
2. Look at how many pieces of work are launched vs the number delivered; check the time it takes to get to market.??
3. Look at the number of pieces of work in the system and if your teams are working on the right work.??
4. Count the number of pieces of work each team member has to work on.?
5. Understand what happens when someone gets blocked.??See how often work cannot be completed due to poor information flow.?

Once you have this information call us, we’ll tell you what to do next.?

Note - There are some leaders like Steve Jobs, that have become celebrities and icons.??There are others like this lady, or L Barrett, D Jenkins, F Adam, R Beaven, J Watts - that go about their work quietly, passionately making life better for those around them – here’s to them.?

There’s one final thing I’d like to say again. We passionately want to help.??When I write these pieces know that I’m coming from a place of humility, building on those that have gone before me, in the hope that we can help you build better organisations for your teams, your customers and your leaders. I realised early in my career, to my detriment, that it’s all too easy to be disrespectful and critical of the good work others have done.??I’ve been on the receiving end of enough rude and critical leaders in my career to know that I’d never want to be that person.?

If we’re not connected please send me a connection request so I can DM you.?

This article is based on an idea by Andy Penman and was written by Andy Penman and Stuart Corrigan.

#projectmanagement #agile #agileprojectmanagement Dr Russ Lewis ?? Clarke Ching - the 'bottleneck guy'