Artikkelit

Forget Agile – Welcome Value Driven

Maybe we should forget the word “Agile” and start referring to it as ”Value Driven”?


During past years, I have been part of development activities where we have studied organisational agility. It has been very interesting, and I have learned a lot, but also noticed that there are different understandings about what agility actually is. In many cases it started from development projects where people take some agile practices in to use.

After positive feedback, they started to look for ways to expand these practices. Sadly, there is a huge risk for this path leading to failure, as scaling an agile method to organisational level is not an easy task. There are some models said to be scalable for large organisations, but model, tool or process is not fixing the core issue. But the biggest problem is that a tool doesn’t make any organisation agile. I have now worked with several organisations and, based on my experience,

"Agility is only possible if there is a will and capability to trust people enough to become agile."
An organisation can be agile only if it has clear purpose and good understanding of customer value. This understanding must be top priority for all persons working in the delivery chain. If this is understood and the customer value is the main driver of the work, agility comes naturally.

Maybe we should forget the word “Agile” and start referring to it as ”Value Driven”?

If you keep value in mind, you can more easily expand the principle to operations and organisation. We built a value driven organisation about 10 years ago. We had an old-fashioned team organisation that had difficulties coping with a fast-changing customer environment.

To overcome the challenge, we turned the static team organisation into a flexible matrix where people were assigned temporarily to virtual teams. This enabled us to quickly adapt to a fast-moving environment and changing business needs.

For flexible capacity, we planned how to quickly recruit new personnel, but kept around 30% as consultants in case we had to reduce the capacity. Our supervisors were working full time adjusting the organisational setup and operational managers constantly adjusting their setups towards customers.

Organisation was on the move all the time and as the reason for the change was clearly communicated to all personnel, they felt that they were part of the game. Our efficiency boosted significantly. One of the core reasons for success was that managers were expected to do fewer things, but they were expected to do them well. In a team-based organisation, managers are often the bottle neck, as their role possessed all the accountability and too few resources to facilitate the work expected.

Many of the managers had become managers in the previous setup because of their capabilities as specialists. After long discussions about their roles, most of the managers took the opportunity to give up certain aspects of their work which they had no passion for. Almost all managers from that group wanted to lead operations and were happy to give away the role of supervising and line management. It was much harder to find suitable supervisors to devote their time for employee development.

We were lucky enough to find such people as they were the key element in this turnaround. Together with supervising managers and operational managers

we turned a static organisation into a value driven fast moving hero factory that could rapidly adjust itself to changing customer needs.
We also created a method to empower small scale development within teams. Many production teams had great ideas how to improve our work. The challenge was, that there was no time or money dedicated to this. When there was time or money, something new was started instead of completing the task in hand.

We had a lot of improvement initiatives started but very few real outcomes. As a way to overcome this, we ended up implementing a practice where product owner had a rolling budget for 5-15 days that was allocated to use for development.

josue-isai-ramos-figueroa-qvBYnMuNJ9A-unsplash
You can't build an organisation with one tool
They were only allowed to start a new initiative if it fitted into the rolling budget. If there was work that already fulfilled the budget, they had to complete that one before starting a new one. This gave pressure to finish and produce outcomes before rushing into new things.

Furthermore, the product owner had full control over what was done in these development projects. The main challenge was the lack of resources. We tried to do this as a part of normal operations, so that whenever someone had spare time they could use it for development.

If I’d had the experience then that I have now, I would have dedicated time for creating a system of rotation between people in development projects. It is good to rotate people within any organisation so that they can appreciate the demands of different roles. Naturally, people should do what they are best at, but it is also productive to experience different things and expand appreciation for the roles of others.

As stated, agility is not something that relates only to software development and it can be achieved without implementing certain processes or tools. You can begin being agile once you understand the meaning of a value driven way of working. Suitable tools and processes are then chosen to support your value creation.

All Work that is Not Bringing Value is Waste

In constantly developing world, one should always aim to create value. Due to changes around you the meaning of value will evolve. Something that was valued last year might become waste today.

As an example, diesel-powered cars were a huge hit a few years ago due to low consumption. Now, in some countries it is hard to get rid of diesel-powered cars due high pollution and usage restrictions. The value you create might change overnight (in any direction) due to external reasons.

In agile best practices, one should always drive towards customer value. To be able to do so, one should know what the customer value actually is. How do you define the customer value?

Value is normally defined as something that the customer is willing to invest in, either money or other resources such as time.
Some parts of the value are easy to evaluate (you can sell services cheaper than your rivals) and others are almost impossible as the measurements are not tangible (like buying a new sportscar for daily commuting).

In many cases of traditional organisations, the customer value becomes a reality that is distant from the place where the actual value is created. This can lead to a situation where the person creating the value has no understanding of it or can’t see the connection between the work and the benefit. In these cases, it is very hard, from the workers point of view, to align the work to create better value.

Understanding the value from customer’s point of view is a core requirement in developing services. This is when what should be developed next needs to be prioritise. It is best to choose one or two things that are most beneficial than to do a whole list of things. There is no value in listing things that will be achieved later and are irrelevant to this stage. The only thing to know when beginning any development, is what brings the best value now.

If customer value is lost, in the most extreme case the majority of the development is targeted to minimize the costs. Usually this does not bring any new or additional value to the end user.

Sadly, in many cases, management sees this as a quick and easy option to meet financial targets. At the same time, as one is tightening operations and minimizing development, everybody simply concentrates on survival. In this mode you are no longer thinking how to create value to your customer, your full concentration has turned inward.

When starting to invest in development, your main driver should not be profit or cost minimization but the customer value. All other things are by-products of doing something that the customer values.

All work that does not bring value is waste.

Tuomo Koskenvaara

Head of Business Technology Service Area, VTT
COO at Projektiammattilaiset CB and Co-Writer of Digital Tsunami Summit – Helping You Grow Your Business with Business Technology.

This article was originally published as part of making the book “Surfing the Digital Tsunami – a playbook of continuous business transformation”.