This guest article is brought to you by Tom Hoyland, Agile Coach and builder of high performance teams. Tweet Tom @thatAgile or connect with him on LinkedIn.
In recent months, I’ve been working with a large organisation to build an agile team to deliver a digital services programme. I consider myself quite fortunate as I get to coach a team full time and help train organisations in building agile capabilities.
During training sessions, I usually focus on scrum values (transparency, inspection, adaptation), extreme programming principles and the headlines of the agile manifesto. These are empowering for delivery teams and unambiguous for organisations, outlining the commitment required to achieve agile success.
Whatever they call themselves – ‘digital hubs’ or ‘agile incubators’ – most teams I work with usually raise similar concerns half way through training –
“that sounds wonderful in theory, but how can we get a full-time product owner, our organisation is too busy!”
The importance of having a committed product owner available to a delivery team can’t be overstated. Good product owners provide a wealth of domain knowledge, articulating the relevance and importance of features. They help to unite teams, build user empathy and challenge teams to innovate. Full-time product owners provide fast feedback and high bandwidth communication, answering questions, serving up insight and experience to allow swift progress through ever changing backlogs.
In her book Coaching Agile Teams, Lyssa Adkins includes an excellent acronym for effective product owners – CRACK (Committed, Responsible, Authorised, Collaborative, Knowledgeable). Note that ever recurring word used in agile circles – ‘committed’.
But obtaining a committed, full time product owner isn’t always easy. Parent organisations are truly busy and it’s difficult to spare people…honestly! At the same time, the leaders of these organisations want to innovate, grow new capabilities and deliver products. They want both.
Part Time Product Owners
When product owners are provided they often to come with ‘constraints’. The most common of these is the ‘time commitment’ – where employees give a portion of their time to the agile team whilst balancing existing responsibilities. For ‘new’ agile teams and organisations, this can be better than nothing and such arrangements provide a glimpse of what high quality, real-time feedback and guidance feels like. Products are better, delivery is faster.
But this doesn’t tend to last, as part time product owners feel the pull back to the organisation, with business as usual and the ‘ever-present crisis’ drawing more on their time. Soon it’s business as usual for the delivery team too and customer collaboration reverts to scheduled meetings, sign-offs and requirements being drafted at a distance. Batch.
Proxies
Organisations try to overcome this by using a business analyst to act as a ‘proxy product owner’. Whilst they might have the time commitment and skills, they don’t always have relevance in the wider organisation or the contextual knowledge craved by responsive agile teams. Customer collaboration certainly doesn’t advance in these circumstances, nor does transparency. Products are still built at a distance.
When these situations occur, it’s common for organisations and teams to feel that ‘this agile thing isn’t working’ as they don’t see how a team can respond to quickly changing needs.
Word Games
Recently I had an opportunity to coach a team on how language changes the way we interpret the world and how we perceive artefacts used in product delivery.
Historically, organisations have provided users or ‘business people’ at the beginning of a project to help draft ‘requirements’, near the end during testing and then to help with the release process. Although the widespread adoption of agile practices has done a lot to increase customer collaboration and promote the importance of people and interactions, requests for committed product owners are still usually met with the perception and question –
“but do you REALLY need them full time?”
What’s wrong with requirements
I’ve found this viewpoint closely linked with a word we’ve used in project and software delivery for many years, and the behaviours we’ve associated with it – the ‘requirement’.
Speaking with teams at different places in their agile journey, I’m surprised by how many use the term ‘requirement’ and continue believe that requirements;
- once documented do not change, evolve or iterate
- will always be necessary for their organisation regardless of the organisations state, surrounding market conditions etc.
- will deliver the same value regardless of when they are delivered
Across organisations, requirements are still treat like valued, intellectual commodities, once written down – never forgotten – and transferable to teams like inputs to a manufacturing process. This concept is present in agile delivery too, with the establishment of a product backlog and the activity of regular backlog refinement.
In recent decades, organisations (especially those focused on digital transformation) have moved away from using the term requirement, replacing it with; user story, use case etc. There are many artefacts and names, but what hasn’t changed are the behaviours and characteristics we attribute to them. It’s still too easy for organisations to build backlogs and ‘throw these over a wall’ to delivery.
One of the reasons why organisations don’t see the value of providing full-time product owners is the belief that requirements behave in the ways described – are static, don’t decay or change. They are treat as commodities.
With this mind-set still prevalent, obtaining full time committed product owners is difficult.
Little Change – Big Result
To overcome this challenge, I’ve started coaching teams and organisations to replace the word ‘requirement’ with ‘decision’.
This might sound like a minor change or just pedantic semantics – but the effect is significant.
Rather than spending huge amounts of time working to separate the word ‘requirement’ from engrained beliefs, I’ve found it’s much more efficient to state –
” there are no such things as requirements, only decisions”
For some, this assertion can be a little divisive and provocative, but it is a means to an end.
When explaining the role of product owner, in addition to the usual details how ‘they hold the value’ and ‘help to articulate what should be built’, I started emphasising how they continuously make decisions for a team. They are ‘the decider’.
‘The Decider’
Using the plethora of information available to them, effective product owners make value judgements, comparing and prioritising items in a product backlog based on guidance from a team, feedback from the last item delivered and whether the organisation still values things as highly as they did a moment ago. They make decisions on a real-time basis, with every item in a product backlog (whether it’s a requirement, use case, user need, user story etc.) undergoing a thought process of asking ‘is this still the right thing to do based on what we’ve learned?’ and a decision of; yes, no or ‘we don’t know’.
As the definition of a decision is well known and accepted, leaders immediately understand that to make good decisions requires good information when you’re are making it. As one of the main information sources for making decisions resides within a delivery team, the case for working closely with them becomes more compelling. After all, why would an organisation make a decision without information?
When I ask “would you have made that decision yesterday if you knew then what you know now?” the response is usually an emphatic “No!”.
We know this to be true as conditions, organisations and the world can change quickly and these changes immediately alter the decisions we make. For this reason alone, effective product owners need to be close to their delivery teams so those teams can respond promptly – pivoting on what they’ve learned or persisting with their existing strategy.
Driving with due care and attention
In some cases, the term ‘requirement’ can diminish the level of responsibility organisations take in ensuring successful product delivery.
We’ve all heard the “they didn’t deliver our requirements” speech and the “we built what they said, but that wasn’t what they needed” response. Whilst many organisations wish to transfer the risk associated with delivery to other parties, it’s usually those same organisations who feel the impact of failed delivery the most.
By reframing requirements as decisions, the importance of customer collaboration is raised. For organisations, it’s easier to articulate the responsibility they have in ensuring what is delivered provides the greatest value when they are making the ‘decisions’. It puts them firmly in the driving seat of what gets delivered.
For delivery teams, a change to using this term creates a different dialogue than that of a ‘requirement’. As teams know their insights and experience are fed into decisions, they become more cohesive, are inclined to provide more options for delivery and can feel more invested in the products they ultimately create. Teams help to make decisions, whereas requirements are forced upon them.
Decaying Assets
I believe requirements are ‘assets’ in the form of decisions concerning what is important to an organisation at a point in time, based on the information, context and experience of the people making them. As circumstances change, just like physical assets, the value of requirements change.
When organisations fail to recognise this, it’s much easier to believe that these can be thrown over a wall to a delivery team and that an ongoing investment of time isn’t needed.
However, by reframing requirements as decisions that need continuous reassessment for maximum return on investment, the benefits full-time product owners bring to delivery teams become clearly visible to organisations.On the surface, this might sound like a small change or just a play on words, but regardless of where a team or organisation is on their agile journey, replacing ‘requirements’ with ‘decisions’ when engaging with teams and organisations can make a big difference.
Not only can this approach increase the likelihood of gaining full time, committed product owners to propel teams forward, but by paying attention to the language we use, it’s possible to quickly and efficiently change engrained mind-sets, helping organisations to move forward, respond and innovate.
Give it a try, see if it works. You decide.
This article was first posted on LinkedIn Pulse. It is republished with the permission of the author.