An Agile Journey (well Falmouth and back) Part II
Welcome to a short series of blogs reflecting on AOTB (Agile on the Beach) 2021 held in Falmouth in early September. From the sessions I attended I have chosen to distil my musings into three topics:
- Velocity & value – are we really measuring the right things?
- No ‘I’ in team? – a continued shift to embracing individuality
- Wagile – pure Agile is (mostly) a Utopian dream
This is the second blog in the series and focuses on the value perspective of the velocity v value debate.
Defining Value
So how do you define or measure value. Certainly, what it is not, is how many stories or story points you manage to deliver i.e. your velocity. You can go very quickly in completely the wrong direction and whilst everybody works hard you deliver no actual real value into the business.
The definition of success or value should be a business metric. A reduced number of support issues, better sales, automation of a manual process, cost saving etc. Try and make your acceptance criteria relate to the value or impact on the business – at least at the higher epic level.
If you cannot quantify in business terms the problem you are trying to solve, or target you are trying to reach, you don’t understand the domain and business dynamics of your customer well enough.
Those of a certain age (like me) will certainly be familiar with the classic swing diagram
Of course, in Agile with truly multi-functional teams there should only be one view – no separate silos within the organisation. However, rarely do you get truly multi-functional teams, and it is critical to understand what the client wants and make sure there is a consensus single view.
I have had the pleasure of working with our partners at Pilot Works and they have a very interesting mantra comparing discovery and delivery which was presented at AOTB. It cuts right to the heart of the difference between velocity and value.
Discovery | Delivery |
Build the right thing
|
Build the thing right
|
Delivery and the monitoring of velocity are about – ‘building the thing right’. Discovery is about research, value and ‘Building the right thing’.
Most projects (or products) end up being compromised by the amount of discovery you can do before you start formulating the solution, but it is important you understand your market and the problem you are trying to solve before you engineer a solution.
Of course, discovery and checking you are going to deliver value is not a one-off activity. The real essence of Agile here is to use ceremonies (sprint demos, sprint planning and retros) to validate you are delivering the expected value. These Agile ceremonies are a route to course corrections as you learn things or even allow the opportunity to ‘fail fast’ if the landscape has changed drastically and the value is no more.
In terms of demos, I usually prefer to review functionality and ‘value’ in smaller more focussed working groups where interactivity and conversation (that word again) is easier. End of sprint demos can then be more of a PR exercise to stimulate reaction and generate awareness in a wider audience.
We have had demos where we have stimulated interest elsewhere in an organisation as they have similar issues or goals. Iteratively building on the original product has allowed us to meet other needs within the business with only minor changes or additions in underlying product functionality.
Final Thoughts
In conclusion I would say that I don’t see velocity and value as mutually exclusive but different perspectives on the same thing.
- Get your Discovery right and you maximise your chances of delivering value to the organisation.
- Get your delivery right and you minimise the time and cost to deliver that value.