Wednesday 26 August 2020

Lead Time Driven Delivery - Part 3, Focus on results, not methods

Imagine you come up with a process change in your company, and you believe this process change is going to make things better. How do you verify that this process change is “Agile” compatible? Does change just need to sound and look good? What is Agile? If you really think about it, it is not immediately clear.

Scientist have created a simple framework to test plausibility of what is being said and proposed. All claims must be testable. Let’s say I tell you that I can jump 3 meters high, test is simple, either I can, or I can’t. Once test is conducted you will quickly find out that it was a lie, I can’t jump that high. If you have a COVID-19 cure and you are running clinical trials, you will measure average recovery time of patients without your amazing drug (control) and compare it against the group that is taking the actual drug, and you will look for a very significant average improvement. Things are not that simple when it comes to business, sociology, psychology and many other fields that have people element in them. For example, in the 20th century Freud ideas were treated as scientific. Freud was able to come up with a theory about someone’s behaviour and then fit it in to the situation so that it seemed to makes sense. If his theory worked it was because it worked, if it did not work it was because something was wrong with patient or some other theory of his worked better. Either way he was right. Fortunately for us, Karl Popper was around to introduce falsificationism to bring some sense in to the world. In over simplified terms, he said that a theory must have a clear test criteria for when it works and it does not work. If it does not have a clear test criteria than it is pseudoscience. Pseudoscience leave things vague enough so that it sounds like they might be true, and it leaves things open to interpretation, just think of Astrology, Hypnosis, Polygraph, Psychoanalysis ... (the list is long, I strongly recommend you Google it). At this point you might be thinking, OK, I get it, how is any of this relevant to software delivery?

Now let's come back to that Agile Framework process change. How do you test for Agile Framework compatibility? I can take a look at the Agile manifesto tenets. However, some of the statements there are not testable, some of them are falsifiable and the rest is list of working practices. However, it is just that, it is a list of working practices i.e. methods of doing something and not the results, this makes it hard to test. I don’t know if this is true for all Agile Frameworks, however most of them seem to suffer from same problem that they focus on method (how something should be done) and not the result (when an action is performed it produces a consistent result):

The increasing adoption of agile practices has also been criticized as being a management fad that simply describes existing good practices under new jargon, promotes a one size fits all mindset towards development strategies, and wrongly emphasizes method over results” - Wiki

It seems that Scrum, XP and other Agile frameworks are collection of working practices that seemed to have achieve good result in the organisation that it was rolled out in at the time. This can be a good thing as companies can take process of the shelf and just get started. In reality I have not worked for a company that has rolled out pure form of Agile Framework, there are always variants. Personally, I have seen some really good results by rolling out Agile and Lean working practices (even with the variants). However, I have heard of companies that have never seen their Agile process change investment pay back dividends or worse it has grinded their operations to a halt. One might say that in that case issue is with leadership of the organisation, leaders are not bought into the Agile framework and this is the cause of all of the problems. I don’t know if that is true, at some point you have to take a step back and just wonder why so many Agile Framework deployments fail all over the place. When you take paracetamol, it works (for most people), pharmaceutical companies do not say that patients that are not getting better are wrong and that their drug works in all circumstances. Surely the problem is that the solution that is being offered is wrong or is wrong for that company? Industry experts seem to be prescribing the same solution to everyone and then when there are no results, they point the finger at the leadership and never at the panacea. So why are we so fixated with the ceremonies, shrines and the dogma of how we work and not focus more on what actually produces consistent results?

Even if things don’t go wrong during the Agile Framework roll out, once the roll out is complete, then what? You want to instil culture of continuous improvement, but you are out of book, there are no more agile tricks are left up your sleeve. How do you achieve further improvement? If you start to implement changes how do you know that they are compatible with your existing Agile framework? Are your internal Agile purists (years ago I was one of them) going to become dissatisfied that you are changing this pure roll out? How do you know that your changes will improve the process and not make it worse? Also what about the rest of the company, how are they going to get better and integrate with your department Agile process?

It seems that there are three problems with Agile Frameworks:

  • They rarely get rolled out in pure form as organisation fail to fully embrace them
  • They don’t tend to consider the whole organisation, just a part of it
  • Eventually you run out of the book and you are on your own. Your investors will expect you to improve your operations further, further changes are hard to make as there is nothing to guide you

Companies should pick an Agile Framework (after all you don’t need to reinvent the wheel) that suits their organisation and once they hit a wall (and you have genuinely rolled out as much of the framework as possible) they should refocus on to the results. This might feel scary, this is because as humans we derive comfort from being told what to do by industry experts, conformity and sometimes superstitions. This is where that scientific and critical thinking can help you cut through the noise and help you to make your own decisions. Decisions that will help your company and your unique circumstances.

When you say we are going to change process from A to B. How do you know of this change will enable faster delivery? Proposed process change should have some of the following characteristics:

  • Removes number of handovers required to get something done
  • Shifts left work by enabling people upstream to get work done themselves earlier in the process
  • Reduces wait time to get something done
  • Reduces amount of disruption
  • Reduces the constraints
  • Improves individuals domain knowledge, moral or skill
  • Reduces unknowns, complexity or risk

Ultimately if you are not sure you can try the change and test it quantitatively by seeing if cycle time and lead time has reduced / increased. The main thing is that you can verify or refute process change as ultimate test is reduced average lead time.

Please take note, when it comes to results over methods, it is important to establish organisational values that will create boundaries of how far you will take the results over methods approach. Last thing you want is behaviour in your organisation that does not align with your organisational moral compass as "anything goes" to get the results, this is where your company culture needs to step in.

No comments:

Post a Comment