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

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

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

I forgot how I answered, but I know how I would respond today. I would draw some pictures and not even mention the word Agile. There are several key concepts that I will need to inform him about.

1. Flow Efficiency

Firstly, 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 / runtime) is normal. Horror, right? 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: in order to progress faster, you need to eliminate the waiting time.

2. Unplanned work and multitasking

It is not uncommon when a team is 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 then you will have a problem.

Conclusion: indicate the means of unplanned work and determine the economic consequences of using collective services. Collective services have an intuitive meaning, but it is often the cause of costly pre-planning.

3. S, M and L

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

4. Realization of benefits

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

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

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 a system that entails a world of pain.

5. Unmanageable complexity

Well, in the end, take the usual 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 remains the same. What happens from day 3 to week 6 is unheard of.

Agile

Why I choose Agile. Agile is useless provided that it is not a catalyst for continuous improvement. Scrum and SAFe are useless provided they are not catalysts for continuous improvement. Why? Because the factors that slow you down are only partly explained by the fact that you are running, recording user stories and doing two-week demos. I would say that these things are relatively insignificant (as soon as you plunge headlong into 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, snap-in, deployment pipeline, functional highlighting, etc. (DevOps)
• Change management culture
• Set up how you fund initiatives. Transition to phased funding based on goals and objectives versus project financing
• Allocation of resources to overcome difficulties (regular reorganization of code and change of architecture)
• Value stream mapping and environmental processing of your business
• A new take on shared service

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

Translation: Vlad Dubovsky