Under The Hood

Leading Continuous Digital Transformation

Agile, Customer Experience, Leadership

Forget Agile – Welcome Value Driven

 

During the past six months, I have been heavily involved in different development projects in which we have studied organizational agility.

It has been very interesting, and I have learned a lot, but also noticed that there are different understandings about what the agility actually is. In many cases it has started from development where people have taken some agile practices in to use.

While they have worked with those and got positive feedback about it, they have started to look for ways to expand these practices. Sadly, this has led to failure, as most of these practices are only suitable for small teams or specific purposes. There are some models that are said to be scalable or suitable for large organizations, but the model or tool or process is not fixing the core issue.

I have now worked with several organizations and, based on my experience,

Agility is only possible if there is a will and capability to trust people enough to become agile.

An organization 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 has been understood and the customer value is the main driver of the work, agility comes as a natural part of the work.

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, organization and other parts of the company.

We built a value driven organization about 10 years ago. We had an old-fashioned team organization that had a lot of difficulties coping with a fast-changing customer environment.

To overcome the challenge, we turned the static team organization 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 in how to quickly recruit new personnel, but kept around 30% of the personnel as consultants in case we had to reduce the capacity. Our people managers were working full time adjusting the organizational setup and operational managers were constantly adjusting their setups towards customers.

Our organization 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 as well. Our efficiency boosted up significantly. One of the core issues with the success was that managers were expected to do fewer things, but they were expected to do them well.

In team organization, the manager used to be the bottle neck in many cases, as that role possessed all the accountability and too few resources to facilitate all of the work expected.

In the beginning we had long discussions with the managers about their roles, indicating that they needed to give up certain duties within the new setup. Most of the managers took this as an opportunity and delegated those aspects of the work for which they had no passion.

Many of the managers in the previous setup had become managers because of their capabilities as a specialist. Almost all managers from that group wanted to lead operations and were happy to give away the role of people development and line management. It was much harder to find suitable people managers who devoted their time to growing people.

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

We turned this static organization into a value driven fast moving hero factory that could rapidly adjust itself to changing customer needs.

We also developed a method to empower small scale development within production teams. We noticed that many production teams had great ideas about how to improve the work.

The challenge was, that there was no time or money dedicated to this aspect. When there was time or money, we normally started something new instead of completing the task in hand.

We had a lot of improvement initiatives that had been started, but very few real outcomes. We sat down and started to discuss how to overcome this issue. We ended up implementing a practice where the product owner had a rolling budget for 5-15 days, depending on the size of the product, that they were allowed to use for development.

The catch was that they were only allowed to start a new initiative if it fitted into the rolling budget. If one already had work that was fulfilling the budget, they had to complete it before they were allowed to start a new one. This meant that there was a pressure to finish and produce outcomes before rushing in to new things.

Furthermore, the product owner had full control over what things were done in this development. The main challenge with the setup was the lack of resources. We tried to work this as a part of normal operational and project organizations, so that whenever someone had spare time, they could use it for development.

If I’d had the experience that I have now, I would have dedicated time for development that would have rotated around different people. It is good to rotate people in different jobs within any organization 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 your appreciation of 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 core meaning of a value driven way of working. Suitable tools and processes will then be chosen to support your value creation.

All Work that is Not Bringing Value is Waste

In a 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 the diesel engine in cars was a huge hit a few years ago due to low consumption.

Now, in some countries, it is proving very hard to get rid of cars with diesel engines due high pollution and usage restrictions). The value you have or create might change overnight due to external reasons (in any direction).

According to 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 commodity 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 very many cases, in traditional organizations, 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 what the value is from customer’s point of view is the core requirement when developing services.

This is when one needs to prioritize what should be developed next. For a person it is much easier to choose one or two things from the list that are more beneficial than to try to reorder the whole list. Also there is no value in listing issues that will be achieved later and are irrelevant to this stage. They are already part of the backlog. The only thing one needs to know when beginning any development is what brings the best value now.

If the understanding and knowledge of customer value is lost, in the most extreme case, the majority of the development is targeted to minimize the costs. Normally this kind of development does not bring any new or additional value to the customer or it’s end user.

Sadly, in many cases, management sees this as a quick and easy option to gain given 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 something of value to your customer, your full concentration has turned inward to yourself.

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

All work that does not bring value is wasted.


This text was written by  Tuomo Koskenvaara.  He is leader and professional with about 20 years’ experience and success in technology business. Follow him on Linkedin.

Leave a Reply

Theme by Anders Norén