What have horses got to do with business value?

You have probably heard the famous phrase: “If I had asked people what they wanted, they would have said: faster horses”. This sentence has been put into Henry Ford’s mouth since the 2000s. It probably didn’t originate from him, but it fits perfectly with his Ford Model T, which triggered a revolution in transport and the manufacturing industry from 1908. This phrase is often used to emphasise that it is better to ask an expert.

I disagree with this for a number of reasons, see more on this later. In this article, I would like to use this example to illustrate the difference between output and outcome. These terms are often used in Lean-Agile courses. Output is the scope of services that, for example, an IT service provider provides according to the contract. Outcome is the proof of effectiveness that the customer must provide in the traditional service view based on the output: the value created.

If you ask people who have no experience with the agile culture after a training course what the difference is between output and outcome, they usually say that it is almost the same thing. Output is the basis, so to speak, and outcome is a kind of stardust on top of it. Yet the two terms are very different in essence.

Back to the year 1908: A traditional service provider asks the customer what he wants as a means of transport (output) and receives the answer “a fast, enduring horse”. The customer’s consultant tries to avoid grinning and then explains what is in his portfolio.

When a consultant for adaptive services asks what outcome the customer wants to achieve with the means of transport and the answer is: “I dream of a fast and enduring horse”. This horse vision is not perfect, but it is an alternative whose value can be determined. With the “fast and enduring horse”, value potentials can be identified. For example, the farmer can offer his products on more distant markets. With the value potential, alternatives can be put together and developed; whether the matter goes in the direction of the T-model is decided by further development.

This is precisely the difference when you traditionally ask for an output and do not encourage a discussion about the outcome. The reasons for this are manifold and can also be internal to the organisation if IT is only seen as a support function and people think they know enough about solutions from other sources. This means you have to live with fast horses.

I know ideas of “fast horses” well. It’s great when people dare to do this. If this turns into a discussion about values and proof of effectiveness, it brings to light a lot more suitable alternatives. This is where innovation can arise.

Kein T-Modell
Not a  T-Modell

No circular wait

Sometimes you find a very unorganised tool landscape at the customer’s that costs the organisation enormous resources on a daily basis and makes proactive work impossible. In particularly financially weak IT organisations, old tools are often held on to for too long; in relatively wealthy IT organisations, tools are purchased first and integration can then take place later.

Often, even essential information is missing in the processes, which would have to be entered twice between the tools or manually reconciled. In particular, things like manual tracking or monitoring are still manageable when there are only a few open tickets, but virtually explode when many incidents have to be processed.

The stories of how exactly these obstacles came about, why adaptation and integration failed, are often different. But what I see in common is that these organisations have learned to wait for each other. For example, an improvement campaign ends with the conclusion that manual processes cannot be replaced at the moment because another division will soon be introducing a new tool.

Or because the service provider will probably be replaced in a year and a half. Then you can still switch off the manual processes. Often there is a wonderful cycle of constant variation in which there are always new reasons to wait.

However, there are always possibilities to mitigate existing shortcomings. Especially if you know your organisation well, you can easily assess what is worth doing. The new HR tool will certainly take months to decide. But modernising the old leave process (on paper) and trying out the new process can be worthwhile.

I can only recommend introducing “No circular wait” as a rule or checkpoint. Nothing should be omitted just because you are waiting for others. In such a case, alternative solutions must be identified. You can always find a small sustainable improvement.

Primarily, small continuous improvements also help immediately. Secondly, they also increase the pressure to gradually get to grips with the big solution, e.g. the permanent and comprehensive replacement of a tool. In my experience, thinking in alternative solutions also changes the culture of becoming more innovative and creative. Let’s make it happen.

Impact Effort Matrix

P.S.: The circular wait solutions often reside in the blue quadrant, the transformation into manageable green solutions is difficult, but can usually be mastered iteratively.

New performance is what we need

I read a comment the other day that in addition to the whole discussion about New Work, there should also be a discussion about New Performance. Or another posting that you have to work besides all the New Work because you get paid for it. Either this is a new narrative to discredit New Work, or it is a misunderstanding. New Work is not an addition or benefit in the form of cosy offices and 4-day weeks.

However, if you are not familiar with New Work and have never met a team that uses these methods to increase efficiency, then I can very well imagine that this impression is likely to arise. New Work is not about performance versus benefits. Professor Peter Kruse once said that self-organisation is the highest form of professionalism. That really emphasises a core aspect of New Work.

For me, it was also quite a learning curve that began in 2016 out of considerations of efficiency in the team. Back then, I was a perfectly ordinary hierarchical team lead in a presales unit. I assigned people to tenders and prioritised their work. If someone fell ill, I had to organise a replacement. Back then, I couldn’t imagine what the team would look like after a few years.

Developing lean-agile methods with the team and increasing diversity in the team was a long journey with many setbacks and moments when I wanted to give up. But there were also moments when team members encouraged me. I remember small moments of triumph and a great moment of happiness after about 3 years.

It was a summer’s day when a colleague called me to say there was a new tender and she just wanted to inform me. She was obviously acting without a mandate. What she had done was an enormous organisational feat, as all the teams had a heavy workload. I called everyone involved and asked if they were in agreement, and they all assured me in unison that we could handle it.

At that time, we were managing around twice as much work as three years before. With good maturity in self-organisation, better methods of our own, less waste in the system, etc. By the way, we were also able to generate twice as much revenue in our division as three years previously. That is New Work.

New Work makes people happy because they are valued as a whole person with all their skills. Because you can achieve things in a team that you would never have managed on your own. Because you get inspiration and can contribute more intensively than you could have imagined last week, and much more too.

Sofas, table football, punching bags, fitness studio etc. are all nice and well, but have little to do with New Work. Such benefits are perhaps even better suited to no-compromise management. In this case, performance is more of a duty that generates output and not outcome.

Kran Hamburg Fabrik

Cargo Cult

On occasion, you meet companies that outwardly claim to be agile, but on closer inspection have hardly developed or want to develop an agile culture. Agile consultants use the term cargocult for this, when organisations introduce agile methods without any utility value, but rather for symbolic reasons.

Cargocult is originated as a religious movement on some Pacific islands, where for example parts of airports are replicated out of wood and the activities of an airport operation are symbolically imitated to bring about the return of the ancestors who will bring cargo. Cargo of the kind that American troops brought to the islands in masses during the Second World War.

In my practice, the vast majority of “Cargocult” cases in companies are different. In one situation, I saw that agile methods were introduced into IT. The employees were told about this literally overnight, had no training whatsoever, but were supposed to convert all ongoing projects to agile ways of working. As it was a hierarchically managed company, this was also applied to most of the ongoing projects. The management announced after 4 weeks that they were more agile and better than the industry leaders.

The change to symbolic agile working led to significant delays in all projects. There was puzzling and interpretation by project managers on agile methods, very often with a simple misattribution like: Definition-of-Done is our old familiar acceptance protocol after all. Astonishing nonsense arose, even repressions were to be enforced under the name of agility.

The nightmare story ended after 9 months, with the management lecturing about the inadequacies of agile methods. I was approached during and after this large-scale experiment, I talked to the people. The vast majority suffered from this nonsense. A few have always been politically correct and found all things proper.

It was clear to the majority after a short time that this way of working has nothing to do with agility. Their emerging resistance eventually led to the official termination of the whole exercise. But what about the supporters, did they believe in a cargocult? I rather suspect they wanted to decorate themselves with agile clothes. They wanted to tell the world that they were now also an agile organisation. Inside, everything should remain as hierarchical as possible.

It seems reasonable to conclude that they wanted to appear modern and were not at all serious about it. It’s more like a kind of symbolic agile work to pretend something to the management and the outside world. For me, the term Potemkin villages is more appropriate, as no one expects agile culture to fall from the sky at one time or another.

“New Work” Potemkin villages are, obviously, a pointless as anything. In all the examples I know, they don’t do any permanent damage, the employees are familiar with such nonsense. A few young employees will leave in the short term. By the way, these companies also introduce legally necessary framework regulations in this way. These usually end up in a corporate department, where there are always designated ISO officers.

So the question remains: why do they do this? I spoke with HR colleagues who are usually appointed to carry out such “new work” culture changes. They were annoyed by such projects, there is almost always a lack of support, resources and budget in their companies. A transparent communication about which goals could actually be achieved with the far too scarce resources never existed in their companies.

It would be nice if anyone would say. We just want to have that written outside on the door because everyone is doing it the same way these days. However, that’s not the case…

Oil tanker blurred photo in the sea

Agile kicks managers out?

I think there is probably no greater nonsense out there than the narrative “Agile is eliminating management”. In the social networks, I often read advertisements for consultancies and seminars such as: First slowly introduce agile and self-organisation so that you don’t have to abolish management straight away. Managers beware, you won’t have your job much longer!

All agile organisations I know still have a management, even the biggest and oldest agile pioneers in the banking sector. Agile organisations or parts of organisations on the way to self-organisation distribute management tasks differently than usual. This new kind of management is often much more meaningful and valuable than the conventional.

Let’s take a look at some of my experiences and the differences between before and after.

Before: The supervisor draws up a training plan at the beginning of the business year with monthly reports. Of course, there is discussion, but it usually stays with industry-typical trainings that don’t exactly fit the job. The training status is reviewed quarterly.

After: Service champions from the team set the trainings in the learning groups, have short feedback loops, create ad hoc trainings, everything is visually managed. The team leaders’ job is to encourage people, to nudge learning groups at times. Strengthening strengths works almost by itself in agile teams, but reducing weaknesses usually needs coaching from the team leader.

Before: In the case of customer escalations, large groups of senior managers sit together, daily reports are prepared and 60-minute jour fixes are conducted. Only 10% of the reports are really relevant, the meetings tie up resources unnecessarily. Some decisions are made on the basis of second- or third-hand information.

After: Relevant stakeholders incl. customer representatives focus on the most important values, supported by someone who knows Lean/Agile methods. The situation is visualised, everyone can see the current status. The team leader moderates, takes care of tasks that go beyond the team. The team leader often also ensures that decisions once made are maintained, some solutions do not work on the first day.

Well, I think I could fill a whole book with examples like that. In my experience, the different assignment of responsibility and decision-making creates a much better acceptance of the desire for continuous improvement. Management systems like Objectives and Key Results (OKR) almost kick into gear by themselves in such environments, whereas in hierarchical environments they stop at any political traffic light as soon as it is as low as yellow.

Leaders are challenged in their most important role when introducing agile or hybrid-agile working methods: as a protective function for the team. Also as a corrective, so that the newly shared responsibilities are well anchored and lived. If the team moves towards self-organisation, the team leader remains the most important interface and an essential coach. Both for the holistic view of the development of the individual and for the next development step of the team. Not to mention the resolution of conflicts.

I don’t understand why they scare people with the threat “soon no one will need you any more”. Changes are already causing many people to break out in a cold sweat, because the working environment will change. If I think about how I worked 10 years ago and imagine I’m in 2013 and now I’m looking at 2023. So without any prior knowledge now to look at agile presales and sales.

I would find many things great, for example the high efficiency in the team. Some things I wouldn’t understand, for example why visual management is so useful if it sounds like bureaucracy. And some things I would have a lot of respect for, e.g. the example above of putting out a fire together with customers in a room.

By the way, the idea for this article came to me when a co-worker asked for a job reference and I thought: OK, then you write me one too. That’s what we did. Unthinkable in a 60s hierarchy. In a self-organised team, it was a matter of course and a great experience.

I would like to take away your fears if you are thinking in the direction of lean/agile, we agile coaches are there for you. I would be happy to tell you about my first steps.

Blick ein Tal herunter