In most circumstances, we work in environments subject to commercial pressures. To survive, the organisations that we work in need to generate value of some kind. How we generate that value is called the Business Model. For example, we might generate value by buying goods from a supplier and selling them to our customers. In which case, we are following the “Sales Organisation” model.
Continuing with the same example, it’s easy to see how important it is that the value the customer is willing to pay us for it must be more than the cost to us of delivering it to them. Our return needs to be greater than our investment. If we consistently sell at a loss we will soon run out of money and cease to operate.
Obviously, cost and value can take many forms (more on that later) but the fact remains: survival is dependent on our investment being lower than our return. To satisfy our stakeholders, we are responsible for maximising the return on their investment (ROI).
Sometimes it’s just one customer, sometimes it’s many
Every software development team has customers. Sometimes it’s just one customer, sometimes it’s many and we often refer to our customers as stakeholders. Even when we have a single external customer, we too, are stakeholders. We are our own customer and there are other people in our own organisation, e.g. compliance, security, who are also our customers. We will, therefore, always have multiple customers and that introduces a whole heap of problems.
Each customer has their own set of values. In the sales model we discussed earlier, it is simple: you buy at one price and sell at a higher price (on a good day). In our environment, although we can usually estimate the cost of producing an item, it is much more difficult to analyse the value of an item. Where we have multiple customers, how do we decide whose need is greatest? How do we decide which piece of work will give us the most return on investment?
Greasing the wheel
In many traditional development organisations, developers are often left to fend for themselves. Although they may well have designated priorities handed down by their line-manager or team leader, they are also subject to the whims of ‘Squeaky Wheels’ (the wheel that makes the most noise gets the most oil) and Hippos (the Highest-Paid Person’s Opinion).
When this happens, developers will often do whatever guarantees their personal safety rather than what gives the company the best ROI. They can find themselves in a no-win situation where they have work requests from the line-manager but their line-manager’s manager is asking them to do something completely different.
Fortunately, Agile software development approaches have the answer for us. In a Scrum organisation it is understood that each team takes their work from a single list: the Product Backlog. The Product Backlog is, “an ordered list of everything that is known to be needed in the product.”
Maximising the value of the product
The responsibility for the Product Backlog and the order in which it is presented to the team, lies with a single individual: the Product Owner. As stated in the Scrum Guide, “The Product Owner is responsible for maximising the value of the product resulting from work of the Development Team.” In other words, the Product Owner is responsible for ensuring the items on the Product Backlog are in order of ROI with the highest ROI items first.
This doesn’t remove the problem of the Hippo and the Squeaky Wheel completely but it does remove it from the development area and put it in the hands of someone better positioned to deal with it. According to the Scrum Guide, in a Scrum organisation everyone must respect the Product Owner’s decision and no-one can force the development team to do any work other than that on the Product Backlog.
If the Product Owner does their job effectively, and the team sticks to the rules, they will maximise their ROI. If you want to work in an environment where you know the value of the work you’re performing, then a Scrum organisation is the place for you.
If some of the situations described above sound familiar to you, why not join me on one of my Agile Analysis and User Stories Workshops where you’ll develop the tools needed to create, refine and manage excellent user stories within the Product Backlog. View all upcoming Agile Analysis & User Story Workshop dates