Insights
How your organisation can deliver value through Agile, amidst the Noise of Busyness
Kenny Grant, UST
Agile Transformation is not just about a different delivery schedule and the adoption of Kanban or any other Agile Framework.
Kenny Grant, UST
A Change Leader, Coach, and Consultant - Kenny has been guiding organisations to build capability in realising the business strategy. With a background in Enterprise Architecture and Software Development, Kenny strives to enable better business outcomes, happier workforces, and higher performance.
In my decade long journey, as an Enterprise Agile Coach, I have arrived at the consensus that the early and the often delivery of customer value is the litmus test of the Lean and Agile DNA (or Project Management at an organisation) of an organisation, specifically large enterprises.
But more often than not, one of the biggest impediments to better outcomes with the Lean and Agile Project Management is the long lead times and large work-batches.
And before we realise, our teams, in their quest for productivity and purpose, fall back to a common substitute – Busyness!
"There is nothing so useless as doing efficiently that which should not be done at all" - Peter Drucker
My experience has taught me that in order to embrace Agile Principles, in letter and spirit, your Agile teams need to ask what difference have they made to on average value delivery cycle time or the amount of variation in those cycle times.
Agile Transformation is not just about a different delivery schedule and the adoption of Kanban or any other Agile Framework.
At a deeper level, it requires a transformation in our thought process and the setting of clear objectives.
And the most important objective, according to me, is the commitment to delivering true customer value.
The Journey to Value in Large Batch Systems
Let’s say your organisation has successfully re-organised around customer value-streams.
But being a large enterprise, you continue to commit the fallacy of delivering value to the customers infrequently and in large batches due to the following unique challenges:
- Your customers have no demand for frequent releases (happens often with B2B sales channels)
- Your customers operate in a highly regulated markets leading to high release (transaction) costs
- There is downstream immaturity e.g. early in the DevOps roadmap
- The domain of work results in inherently large value chunks e.g. ERP implementation or An identifier
The question now we need to ask is - "if we can't rely on the realisation of value as our primary goal, then what do we do to avoid building systems of busyness?”
This will enable us to embark on our Journey to Value in Large Batch Systems!
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:
Units of Progress (UoP) must:
- Represent a tangible step forward towards the completion of the UoV in terms of risk and capability
- Be of similar size as possible as dictated byAgile 'Backlog' good practices
Represent, as much as possible, proportionate progress towards completion of the UoV by unit. For example if a UoV has 10 UoP and 7 of those UoP are completed, it should be reasonable to say the UoV is 70% complete in terms of risk and capability.
Units of Work (UoW) must:
- What can we add here to follow the same flow as above?
System of Value Vs System of Work
In order to mitigate the pitfalls of systems of work alone, create decision-support systems at UoP and UoV levels. Networked Kanban solutions similar to this would be the preferred approach. My experience has been that creating a vocabulary of value rather than scale can help to accelerate towards customer centricity, e.g.,ERP Business Process Kanban Board rather than the Programme Board.
Summary
- Hold everyone to account to an authentic definition of 'customer value'
- There's no substitute to reducing cycle times to value - make this the primary goal
- Identify and manage 'units of progress' as a stepping stone to value where necessary
- Seek out where value emerges in the work hierarchy and manage accordingly
- Use visualisation and behavioural cadence to constantly drive awareness on whether people are discussing units of value, progress or work
Agile Transformation is within reach for every organization who follows the above framework.
To find out more, join Jon Terry, Chief Evangelist Lean-Agile Strategy at Planview, and me, on August 25, 2020, 9am CDT/3pm BST, as we further discuss the importance of aligning around customer value, from outputs to outcomes.