<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=4958233&amp;fmt=gif">
RSS Feed

Distributed Agile | Thomas Behrens |
09 July 2019


I have engaged with several Product Owners; most of whom are our clients, but some are colleagues at Endava who fill the role of the Product Owner for our clients. The latter set-up requires a lot of trust and I have illustrated some of the enablers that create and support a relationship of trust on both sides in a previous blog post.

This post is not about the pros and cons of different team set-ups. It is about growing people into Product Owners. Product Owners come from various backgrounds (see [1]). For the purposes of this post, I am focusing on Product Owners that have a background in agile business analysis. If you trust the relevant sources [2,3], the Product Owner is so multi-skilled that they appear to be "Superman". There is no guide to becoming Superman. Therefore, I frequently have discussions with my junior colleagues about how to develop the skills required of a Product Owner. Surely, there are some soft and hard skills you must learn, like stakeholder management or creating a convincing product vision. But most of the time, product ownership is about making decisions to move the product forward. While working with many successful product owners, I have observed an approach that effectively supports decision-making. You can practice this approach ‘in the small’ long before being in the role of a Product Owner, e.g. when acting in the capacity of an agile BA, working as part of an agile delivery team.

The aim of my present post is to define this approach and illustrate its application in a fictitious example from one of our key domains: Payments.


Imagine you are a business analyst working with a highly competent Product Owner to develop a portal for merchants to manage their credit card payments. The initial goal of creating the portal is to save costs. This remit was given by the COO and the CPO (1) of the company to the Product Owner. The Product Owner has worked out that self-service over a web channel will be a large contributor to reducing merchant servicing costs, helping to reduce the overall customer servicing costs of the organisation.

That's the context, so here is the approach:
Step 1: Go breadth-first and explore options to achieve your objective and decide on one!
Step 2: Go deep with the chosen option to create value!
Step 3: Observe and revisit your decision!

You might argue that this has already been done by the CPO and PO. The objective was to reduce the costs, the decision was to focus on self-service and now we just build it. That's simply wrong. The principle of conscious and responsible decision-making applies at any level. Or, as they say: "One man's floor is another man’s ceiling". In this sense, the steps in our approach are applicable on all levels of the delivery chain, from the vision to the running software that can be used by your customers or provide insights about your customers. The same approach is relevant across the organisation from the CEO to a person in the team designing the tools for the delivery pipeline.

Let's continue our story to make it more tangible: Now you, the BA, dig deeper into the recent tickets from the client’s service desk dealing with all service requests from their customers. You find out that there are about 50 different self-service cases that are candidates for implementation, so do you:

◻ Provide a detailed analysis of all the 50 options, so they can be implemented (good old times).
◻ Go to the PO and ask her what to do (not my problem).

Tick your answer! If you are presented with the options formulated so simplistically, no-one would tick either of the boxes. Still, I regularly observe tendencies to do one or the other or sometimes both of these things (you can actually tick both boxes and follow them one after the other).

So what should be done instead? If you apply our approach: you (1) go breadthwise and enumerate all 50 options and come up with some classification criteria. You can use or derive some of the criteria from the objective to reduce the overall costs: "What are the most frequent cases?" "Which are the ones taking up most of the service desk team’s time?" "Which ones can we perform as self-service over the web channel, because of the required authorisations?". (2) Having assessed all of the cases based on these criteria, you decide that the self-service case to start with is the adjustment of the shipping address for a payment terminal that needs to be delivered.

Once the decision is made on this level, you work with the team to (2) go deep with the chosen option to quickly realise some value. And as you progress with implementing this option, some more options arise on the next level (the other man's floor): "Do you verify the new payment terminal address, or not?" "Which roles are allowed to change the delivery address?" Various different team members will be able or feel empowered to make these decisions.

Option Universe
FIGURE 1 - Option Universe

So, the first self-service case "Change Terminal Delivery Address" gets built and delivered. The customers are using it heavily. Is the story over? Not in all cases. We are talking about products not projects. It is not about the feature that you released, it's the ongoing relationship with your customer that this feature establishes. (3) Observe and revisit how your customer uses your features. Terminals slowly get replaced by mobile devices that are already owned by most of the merchants. There is no longer any need to ship terminals. You want to remove the function and clean up the technical (and in this case the feature) debt that you created and keep your product maintainable.


Let's reflect a little on our invented story. True agile analysis is an enabler that supports the approach we describe above. Daniel Kahneman created the acronym WYSIATI – "What You See Is All There Is" [4] to describe the cognitive pitfall when our brains create a seemingly coherent story based on information of unknown quantity and quality. The positive effect of step (1) is it enables us to make decisions in the VUCA (3) of our everyday world. But on the other hand, it creates a framing effect towards the information that we see, which can lead to overconfidence and a danger of making the wrong decisions quickly. There are two ways to avoid this: (a) we need to make sure we are getting all the information by stepping back and taking time to ask the not so obvious questions, such as "Which support cases can we perform as self-service over the web channel?". Alternatively, (b) we need to ensure that if we make the wrong decision (quickly, saving some analysis time), the situation can be recognised, and the impact of the mistake, corrected quickly. But remember, you need to make (or at least recommend) a decision. Your contribution decreases if you passively elicit requirements and ask others to make decisions.

During the execution of step (2), agile analysis helps us to handle edge cases and errors by thinking through how we enable a machine – who cannot deal with VUCA – to realise what your customers need. You cannot avoid these cases and need to think them through, because if you don't, you’ll find that ten days of development saves you one hour of analysis! But keep your eyes open, because in some cases you can follow the steps again on this level, creating more options based on creativity or experience. For example, you can embed Google Maps to select a delivery address rather than requiring it to be typed in manually. Some of these decisions will not be separately releasable, but they will help us to release (the rest) faster.

Step (3) adds a new dimension to agile analysis: time. Classical business analysis was done in the change – operate cycles, where time is frozen for the change cycle. In a product delivery model, as shown in the example above, where terminals cease to be shipped because terminals cease to exist, we need to learn (to progress) and then unlearn (to adjust). For me personally, this is one of the toughest lessons learned: we know that today the world is no longer black and white, but shades of grey, but we now also have to remember that the dark grey of today maybe the light grey of tomorrow. This evokes the concept of "strong opinions weakly held" [5]: Have a strong opinion in order to make progress, but hold the opinion weakly in order to improve or correct or even revert the initial solution. Continuous delivery must start with the requirements; it provides the platform to make mistakes fast and correct them, or to adapt to a changing world.


I recommend you read the context of my little example as: "We need to improve the self-service capability to reduce our operational expenses for customer care. Here are some further constraints …. Go and figure out how!" For the individual like you and I, working as we have described in this context, this means taking ownership and accepting responsibility for delivery of the product. Most of us know what to do, but we often need the discipline to do the more difficult thing that we are afraid to do, than doing the easy thing that we would like to do.

The Product Owner provides the overall context for her product with a set of constraints and objectives through the "Product Vision". But, by using decision making skills of a Product Owner yourself, you can refine their vision into further constraints and sub-goals and make (or at least propose) further decisions to move the product forward. Over time you will gain trust and experience and your area of influence will grow. We should give up on the idea that more senior people make smarter decisions than the people who work for them, especially in their own specialist subject matter. Giving up this legacy thinking will lead to empowerment of people like you in the right place, where the knowledge is, versus senior management, who will not be contributing to good products by making these decisions "in the small".

So please give this thinking a try and practice some product ownership in the small. It will help you to become a great Product Owner in the future.


(1) Chief Product Owner
(2) For example, if we need a physical signature for legal reasons, it might be better to defer this case
(3) Volatility – Uncertainty – Complexity – Ambiguity, online here


[1] "Where do Product Owners come from?", Scott Ambler, 9th July 2018 – published here
[2] "Agile Product Management with Scrum", Roman Pichler, Addison Wesley, 2010
[3] "The Professional Product Owner", Ralph Jocham, Addison-Wesley, 2018
[4] "Thinking Fast and Slow", Daniel Kahneman, Penguin Books, 2011 (pg. 85-88)
[5] "Strong Opinions weakly held", Paul Saffo, online here

Thomas Behrens

Group Head of Analysis

Thomas is Group Head of Analysis for Endava. He has over 25 years of experience in software development which he has gained in various sectors including investment banking, telecommunications, mobile payments and embedded systems. He is focused on setting up distributed agile software development teams and shaping the business analyst force at Endava. When he isn’t doing that, Thomas can be found delivering training or speaking at conferences.


From This Author

  • 05 January 2021

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 3

  • 22 September 2020

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 2

  • 11 February 2019

    Distributed Agile – Closing the Gap Between the Product Owner and the Team



  • 13 November 2023

    Delving Deeper Into Generative AI: Unlocking Benefits and Opportunities

  • 07 November 2023

    Retrieval Augmented Generation: Combining LLMs, Task-chaining and Vector Databases

  • 19 September 2023

    The Rise of Vector Databases

  • 27 July 2023

    Large Language Models Automating the Enterprise – Part 2

  • 20 July 2023

    Large Language Models Automating the Enterprise – Part 1

  • 11 July 2023

    Boost Your Game’s Success with Tools – Part 2

  • 04 July 2023

    Boost Your Game’s Success with Tools – Part 1

  • 01 June 2023

    Challenges for Adopting AI Systems in Software Development

  • 07 March 2023

    Will AI Transform Even The Most Creative Professions?

  • 14 February 2023

    Generative AI: Technology of Tomorrow, Today

  • 25 January 2023

    The Joy and Challenge of being a Video Game Tester

  • 14 November 2022

    Can Software Really Be Green

  • 26 July 2022

    Is Data Mesh Going to Replace Centralised Repositories?

  • 09 June 2022

    A Spatial Analysis of the Covid-19 Infection and Its Determinants

  • 17 May 2022

    An R&D Project on AI in 3D Asset Creation for Games

  • 07 February 2022

    Using Two Cloud Vendors Side by Side – a Survey of Cost and Effort

  • 25 January 2022

    Scalable Microservices Architecture with .NET Made Easy – a Tutorial

  • 04 January 2022

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 2

  • 23 November 2021

    How User Experience Design is Increasing ROI

  • 16 November 2021

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 1

  • 19 October 2021

    A Basic Setup for Mass-Testing a Multiplayer Online Board Game

  • 24 August 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 3

  • 20 July 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 2

  • 29 June 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 1

  • 08 June 2021

    Elasticsearch and Apache Lucene: Fundamentals Behind the Relevance Score

  • 27 May 2021

    Endava at NASA’s 2020 Space Apps Challenge

  • 27 January 2021

    Following the Patterns – The Rise of Neo4j and Graph Databases

  • 12 January 2021

    Data is Everything

  • 05 January 2021

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 3

  • 02 December 2020

    8 Tips for Sharing Technical Knowledge – Part 2

  • 12 November 2020

    8 Tips for Sharing Technical Knowledge – Part 1

  • 30 October 2020

    API Management

  • 22 September 2020

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 2

  • 25 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 2

  • 18 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 1

  • 08 July 2020

    A Virtual Hackathon Together with Microsoft

  • 30 June 2020

    Distributed safe PI planning

  • 09 June 2020

    The Twisted Concept of Securing Kubernetes Clusters – Part 2

  • 15 May 2020

    Performance and security testing shifting left

  • 30 April 2020

    AR & ML deployment in the wild – a story about friendly animals

  • 16 April 2020

    Cucumber: Automation Framework or Collaboration Tool?

  • 25 February 2020

    Challenges in creating relevant test data without using personally identifiable information

  • 04 January 2020

    Service Meshes – from Kubernetes service management to universal compute fabric

  • 10 December 2019

    AWS Serverless with Terraform – Best Practices

  • 05 November 2019

    The Twisted Concept of Securing Kubernetes Clusters

  • 01 October 2019

    Cognitive Computing Using Cloud-Based Resources II

  • 17 September 2019

    Cognitive Computing Using Cloud-Based Resources

  • 03 September 2019

    Creating A Visual Culture

  • 20 August 2019

    Extracting Data from Images in Presentations

  • 06 August 2019

    Evaluating the current testing trends

  • 23 July 2019

    11 Things I wish I knew before working with Terraform – part 2

  • 12 July 2019

    The Rising Cost of Poor Software Security

  • 09 July 2019

    Developing your Product Owner mindset

  • 25 June 2019

    11 Things I wish I knew before working with Terraform – part 1

  • 30 May 2019

    Microservices and Serverless Computing

  • 14 May 2019

    Edge Services

  • 30 April 2019

    Kubernetes Design Principles Part 1

  • 09 April 2019

    Keeping Up With The Norm In An Era Of Software Defined Everything

  • 25 February 2019

    Infrastructure as Code with Terraform

  • 11 February 2019

    Distributed Agile – Closing the Gap Between the Product Owner and the Team

  • 28 January 2019

    Internet Scale Architecture