Many organisations have realised their initiatives take too long to deliver value to their customers and don't deliver in small chunks often enough. This realisation is at the core of the Agile movement - that moving to batches and quicker delivery produces better outcomes.
Working with large, global enterprises, I often hear them say how mature they are with this or that framework and that they've been doing Agile for five years. But when you ask what difference that has made on average value delivery cycle times or the amount of variation in those cycle times..... they go very quiet.
In my years of serving as an Enterprise Agile Coach, I have observed that what many organisations believe is the adoption of Agile is just a move towards busyness. People want to be productive, but if we cannot see the true value, we default to busyness over effectiveness, the plague of knowledge work.
"There is nothing so useless as doing efficiently that which should not be done at all" - Peter Drucker
Customer Value Through Agile Transformation
Delivering customer value early and often is the overriding measure of a good business outcome from embedding Lean and Agile behaviours. And, yet, it is the least likely to be achieved.
How often have you been in a conversation when someone says:
- This work-item has 'internal value'
- Our Product Owner is our customer
- It depends on what you mean by 'customer'
- We don't have to release until March, it doesn't matter
- Our customer doesn't want that many releases
- What do you mean by value? We're busy getting things done here
- We can't do real Agile here, we're different
- We get stuff ready, but it's the other team that deliver to the customer
I have heard the above many times throughout my career. Excuses can proliferate internally when organisations believe they have moved to Agile Project Management, but have really just created a culture of busyness. But while customer value is a difficult nut to crack, it is within reach through these important steps.
How to Identify True Customer Value?
Scaled Agile: Units of Value, Progress, and Work
Embracing Scaled Agile requires the recognition of where true customer value emerges in a work hierarchy. Then map this value to its child work items - in large systems, this may require the use of a bridging work type I call 'Unit of Progress'.
Units of Progress are tangible progressions towards a goal, or in this case the valuable parent. Think of them as the value you'd love to deliver to the customer if things were different. Here are some examples from different domains. The important point is authenticity in order to avoid systems of busyness.
Units of Value (UoV) must:
- Be operational (Go Live, Deployed, etc.) independently of each other and still offer value to the customer.
- Be sliced as thinly as possible and still satisfy the rule above - they must not contain more than 1 independently valuable customer proposition/capability. Units of Progress (UoP) must: