Agile as a Technology
Agile as a Technology
The author sees Agile as another technology because it's a new way of doing things. What questions should be asked when you replace an old technology with a new one?
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
I have started listening to Beyond the Goal: Theory of Constraints by Eliyahu Goldratt.
In the first chapter, Goldratt has come up with an explanation as to why, if tried, his Theory of Constraints has failed. He doesn't mention this (he keeps saying that everyone who has tried TOC has succeeded), but I think his argument can be applied to Agile and DevOps and any other radical system, process, or framework in any industry that fails to succeed. This is my interpretation of what he says.
The first thing he asks is the following:
Technology can bring benefits if and only if it diminishes a limitation.
Note, that the statement does not say that technology that does diminish a limitation will bring benefit. This is why I have emphasized the "can." Its is not a will.
Before you agree or disagree with the statement, Eliyahu does not say what the limitation is. It could be known or unknown. If it is not known, then is the statement still true?
What is a limitation? It's something that prevents us or limits us from doing something. When we as humans hit a limitation, what do we do? Give up and do nothing? Not likely. We work around it. We develop policies, rules, measurements, processes, etc. to accommodate the limitation.
Let's say we introduce a technology that eliminates this limitation. Yay! It's gone. What happens if we do not change the policies, rules, measurements, processes, etc. that were developed to accommodate the limitation? Well, not a hell of a lot. Despite the fact that the limitation has been removed, we act as if it is still there. The limitation is virtually still there.
As an example, Eliyahu brings up the MRP (Material Resource Planning) software industry. Before MRP software was developed, it was typical for a factory of 300 workers to have about 20 staff work on their material requirements planning. Calculations were tedious and error-prone because they were done manually. It would take about a month to work out the requirements. Orders for materials were done monthly.
Let's say that you are a customer and made an order for 100 widgets. The factory would receive your order and it would go into the system. The calculations would be made and if you were lucky, the materials for your order would reach the factory in a month. Then, you'd have to wait for the factory to make your widgets and then, finally, you'd receive them. If you missed the monthly cut-off, you might get the orders fulfilled in two months.
Then, the first MRP software was developed. One of the first companies to use MRP software was Black & Decker in 1964. At the time, MRP was in response to the Toyota Production System which was barely known in the west at the time. Black & Decker did so well with MRP, they became one of the most profitable companies in the world. You have to remember too that at the time, software was done by punch cards, not terminal screens like it is today. We're talking a very basic system compared to what is available today.
It took time, but by 1975, about 700 companies worldwide were using MRP software. These companies were getting the same results as Black & Decker. Reduced inventory, more profitable results, etc. At this point, the rest of the world started to notice. More and more companies wanted MRP software. So, by 1981, about 8000 companies were using MRP software. Then the murmurs of not getting the same results started to happen. Most of these companies didn't get the magical results. By 1984, this turned into a scream. 90% of companies that used MRP software were not getting the benefits. In some cases, companies were worst off.
No one at the time knew why. The going theory at the time was that in order to get the benefits, your inventory needed to be 97% or higher in accuracy. No one's inventory is that accurate. Next, it was that you were not trained correctly on how to use the software, so vendors started selling training. An industry of certified implementers was developed. Still, many businesses were not seeing the benefits. It became so bad that the cost of the implementation wiped out any savings (if there were any).
Since then, we have moved on to MRP2 (which is where I started my career in the mid to late 90's) and now ERP systems.
So, why did the early pioneers succeed where the later adopters didn't?
Eliyahu has a theory, which he admits he didn't think of at the time all this was happening.
What is the most important part of the data? It's the orders. The new recipients of MRP software forgot about this. What they did was run their MRP system overnight once a month, so the customer orders were still fulfilled a month or two later. It was if the limitation of the calculation time was still there. The procedures and processes were not changed. There was no net benefit.
That is not to say that there wasn't any benefit; they no longer had 20 people taking a month to do the calculations because it could now be done overnight. However, this benefit does not lead to the magical profits the early adopters were getting. Why did the early adopters get the benefits? These were the more forward-thinking companies. They ran their systems more frequently (fortnightly, weekly, or every few days). They were able to get their orders in sooner, get their products made sooner, and get the end result into the customers hands sooner.
Eliyahu has come up with four questions to ask when looking into new technology:
- What is the power of the technology? This is an easy question to answer. Just speak to the vendors. They will talk all day about the power.
- What technology does this technology diminish for us? This is harder. Try to identify what limitation is diminished. Remember that some are seen and obvious and some are not so obvious. You need to identify precisely what is affected.
- What rules, policies, procedures, measurements, etc. helped us accommodate the limitation? It gets harder and harder. Here, you have to identify what you do to accommodate the limitation. If you do not identify the rules, procedures, processes, etc., you run the risk of leaving them in place and you will find yourself still in the same position. In MRP's case above, it was processing orders monthly.
- What rules, policies, procedures measurements, etc. should we be doing now? Now that the limitation has been removed, how far can we go before we hit the next limitation?
How does this affect Agile? Well, I see Agile as another technology. It may not be a new piece of software, but it is a new way of doing things. If you are not careful to identify what needs to be changed from a traditional Waterfall implementation and if you just focus on the superficial (such as stand-ups, Kanban boards, and not focus on planning or retrospectives) where you try to continuously improve, then you are still working under the limitation or Waterfall.
Published at DZone with permission of Holger Paffrath , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.