When Short Sprints Meet A Well Defined 18 Month Programme Of Work...

This is a classic of our modern times. An organisation decides it needs to invest heavily in updating a part of its business. It sets up a big programme of work to do so, and allocates a huge budget to it. However, the organisation has been hurt before in such programmes by slow delivery, massive complexity, poor quality and endless missed deadlines. So it decides that this time, the programme needs to be 'more agile'.

As a result, the programme's newly formed teams are called scrum teams, they are told to work in two week timeboxes, and everyone in a team has to stand up for 15 minutes every morning. No-one fully understands why they have to do this standing up part, but hey, it means they have jobs, so they go along with it.

The thing is, little else changes. The massive, multi-million programmes of work, generally called '<INSERT SERVICE NAME HERE> Transformation' has still been specified up front in great detail. There are still fixed delivery dates to meet, and in an attempt to make sure that they're being met, there's a whole raft of hierarchy, project and programme governance, phase gated controls and all of the rest. Even more happily, all of this work, governance, specification and control can now be tracked through a digital ticketing system. Because for the programme, digital ticketing systems are 95% of what agile is.

Sometimes though, the teams find that the work was more complex than they expected, or they get blocked by a dependency beyond their control, and they don't finish everything that they planned to finish within a sprint. This doesn't matter though, as they can just roll the unfinished work over into the next sprint, just like they did in the last sprint, and the one before that. After all, what matters is delivery, there's a bunch of stuff to do, we just need to be pragmatic and get on with it.

Sometimes the absurdity of this continuous roll over and constantly missed commitments becomes too much to bear, so the team stop calling themselves a Scrum team, and start saying they're 'Doing Kanban' instead. Because that way they think they don't have to plan or demonstrate anything ever either.

None of this is particularly the team's fault. All of these things are symptoms of the deep seated issue that exists within the work being undertaken. The work is being delivered in huge batches (so it moves more slowly through the system), none of the deliverables are up for negotiation (so the whole point of agility has been removed) and the deadlines have been fixed up front (by people who won't actually be doing the work, so have little idea how long it will actually take).

It's in this sort of absurdity that the word 'pragmatic' generally comes up the most often. The reasoning runs that we can do agile things up to a point, but we need to be pragmatic about them, and not let them get in the way of delivery.

Now, as I said as the start of this series of posts, I'm all in favour of pragmatism.

You can't change everything overnight, and sometimes specific situation require specific accommodations to be made. However, I think I fundamentally use the word pragmatism in a different way from the people who use it in this sort of situation.

For me, pragmatism is a well thought through consideration of the compromises being made, the reasons for them and the impacts they will cause, to see if the trade offs are worth it or not. They may be, they may not be, and these sort of calculations may change over time. That's pragmatism.

Indeed, if you google some dictionary definitions of pragmatism, you see it described as;

'an approach that evaluates theories or beliefs in terms of the success of their practical application'

or

'the quality of dealing with a problem in a sensible way that suits the conditions that really exist, rather than following fixed theories, ideas, or rules'.

I can see why people use pragmatism in opposition to newer methods of getting stuff done. Newer approaches of course look like theories to people that have never used them in practice before, whilst the more traditional approaches they have used for a while appear to be much more grounded in reality and practical application. However, this idea misses a hugely important part of what pragmatism is. Pragmatism is about success. Doing what works in a specific context. If a massive programme of work is delivering high quality work to time and to budget, then fantastic, the pragmatic approach is obviously to continue with how it is operating.

However, if the programme isn't delivering on time, or to budget, or to quality standards, then sticking with its current approach is literally the opposite of pragmatism. Pragmatism is about doing what works in a context, and you can't say you're being pragmatic if what you're doing isn't working. All you're being is conservative.

There are two things to fix here then, and one follows the other. The first is to agree that pragmatism is about doing what works, so people need to be honest about what is working and what is not working. The second is to agree that pragmatism is about taking theories and applying them in practice to see if they work, therefore being open to trying new approaches in the first place. Without trying something out, that thing will always remain a theory, and therefore never be allowed to be a pragmatic approach. It's essentially an odd mess to get into. A theory can't be pragmatic until it is tried out, but by resisting trying out the theory, you're not being pragmatic.

Perhaps then this is how we start to build a model for how old worlds and new worlds can or cannot combine. We have to agree that pragmatism means both trying things out, then doing more of what works and less of what does not. The combinations of approaches therefore have to be tested out in practice, and an objective review undertaken of whether they work or not. In essence, a standard, empirical, scientific approach. Otherwise all either side, the old and the new, are doing is clinging on to their pet theories. One side saying that their approach is the pragmatic one, the other side saying the same, but neither side actually being pragmatic in reality.

There's more to unpick here of course, but it's an interesting line of enquiry to go down. Does anyone have any thoughts to add to it?

(p.s. Incidentally, before anyone thinks I'm referring to any specific programme or event in this post, I'm honestly not. The above scenario is literally a pattern that I've seen play out again and again across many organisations over the years. I'm sure you could spot one right now in your own organisation too).

All this week I'll be posting examples of when old world and new world delivery approaches don't mix, in the hope of identifying some underlying principles that might help us to understand when to use just one approach, and when a 'pragmatic blend' might work.

You can read the introduction to this series here.