Another post "why Agile does not work" (with pictures)

A couple of years ago, I met a relative. My poor cousin (CEO of the insurance company) sold Agile Silver Bullet and was very sorry. He said something like:

This is cheating! We changed the whole workflow. We invited consultants. We hired these master PMs. And nothing works! There is no result. There is no responsibility. All I get is excuses.

I forgot how I answered, but I know how I would answer today. I would draw a few pictures and would not even mention the word Agile. There are several key concepts that I will need to tell him.

1. Flow Efficiency

First, if we look at the lead time - the time from when we come up with the idea, until it reaches the customers - you will notice that most of the time is spent on “waiting”. 15% flow efficiency (working time / run time) is normal. Horror isn't it Nevertheless, we will focus on what is (relatively) visible ... very little time is spent directly on the work. The best companies have reached 40%. Conclusion: to move faster, you need to eliminate waiting time.


')

2. Unplanned work and multitasking

It is not uncommon for a team to be paid 75% “for the benefit” in combination with unplanned work and task switching. The team can not even pay in principle. This is literally a premium and is often never tracked in the accounting system. Most likely, the team will complain about what is happening (this is a terribly boring situation). The team will ignore for a long time and will accept the harsh reality.

Now imagine this “collective service”, the team is responsible for solving production problems or for providing new infrastructure while carrying out “projects”. And here you have a problem.

Conclusion: Identify the means of unplanned work and determine the economic implications of using collective services. Collective service has an intuitive sense, but it often causes costly pre-planning.

3. S, M and L

This is a pretty fun trick. Schedule deadlines for large, medium and small work tasks. Try to rise above yourself and focus on the elements of the client’s actual value, and not on the tasks. In many organizations, you will notice that the “size” of work does not affect the deadlines. Why? Too many other factors affecting the duration of the completion of the work (eg initial data provided by the customer; unplanned work; much work in the process, etc.),

4. Realization of advantages

So much effort has been spent on reducing what I call the “delivery risk”. This definition makes sense if you deliver individual projects, and the client pays cash on execution. In SaaS (software as a service / software as a service) we are not paid when we deliver work. Payments are charged over time. I call this “profitable risk” (the risk that a job will fail).

For large organizations, it is customary to use Agile, but as such, financial advantages are not observed. Why? The development is faster, but it can not affect: 1) making the right decisions; 2) process for the realization of benefits. The whole point of Agile is to reduce the risk. In project work, this risk can be expressed as a problem: “on time / within the limits of volume”. In the production of the product - "this thing, ***, does not work." This is the whole mistake when ordering when “accepting” one of these risks is “accepted”. There is no benefit!

Many companies use the model on the left. Few agree with the model on the right. When they get crappy results, they try to push more effort into the system, which entails a world of pain.

5. Unmanaged complexity

So in the end, take the normal coordinate function and pass it through your product development system. Without multiple component management / refactoring / automation, it will take more time to complete this function from year to year. Even if your team will remain the same. What happens from the 3rd day to the 6th week is unheard of.

Agile

Why I choose Agile. Agile is useless on condition that it is not a catalyst for continuous improvement. Scrum and SAFe are useless, provided that they are not catalysts for continuous improvement. Why? Because the factors that slow you down are only partially explained by the fact that you run, record user stories and make two-week demo versions. I would say that these things are relatively minor (as soon as you immerse yourself in the idea of ​​gradually reducing risk).

To "be flexible", you need to spend a lot of money and energy on:

• Doing work that really matters (benefit) means doing less.
• Automation, tooling, deployment pipeline, functional allocation, etc. (DevOps)
• Change management culture
• Customize how you finance initiatives. Transition to phased funding based on objectives and goals against project financing
• Resource allocation to overcome difficulties (regular reorganization of code and architecture change)
• Comparison of cost flows and the processing of your business by an environmental service
• New view on shared service

There is no miracle cure here. Work needs to be done. Beware of those who say otherwise.

Translation: Vlad Dubovsky