Product Owners, engineering decisions, and 'technical debt'

When you’ve got a software product, it is composed solely of items like the code, static assets, supporting architecture and infrastructure (hereafter referred to as 'the tech'). These items are often thought of as being a necessary part of the product, but really they are the product and trying to separate them is a logical fallacy similar to trying to separate the food from a meal.

I think it's worth pausing and thinking about that for a second because it is an important concept to understand and embrace: in a software product the "tech" is the "product", and vice versa.

Things that are truly good for the tech are ultimately good for the product, and for the product to succeed the tech must itself succeed.

So why then, do team continue to treat the two as entities that are somehow distinct? Even the notion of things like 'tech debt' shouldn't exist. Let's explore that…

Of course code, architecture, infrastructure, etc. matter but not for the sake of themselves; none of these things can stand alone. If things are unstable, unscalable, or difficult/slow to update, that directly impacts the product value that can be delivered. ‘Technical debt' therefore, is more accurately labelled as ‘product debt', or even just 'debt'. Technical issues that have no impact over the product (or the future development of the Product) are completely irrelevant. There are surely no exceptions to this.

If a codebase requires refactoring because making changes is error prone and therefore slow, this has direct influence over the product value that can be delivered. If issues such as this go unaddressed, the rate of product value that can be delivered will decrease (probably exponentially) over time. If product value cannot be delivered, that's a product concern first and foremost.

It’s probably not for the Product Owner to specify specific implementation details, but they do have a very significant stake and interest in how their product is built since the decisions made can have significant influence over the success and possible speed of iteration.

A common over-simplification is that the Product Owner has responsibility over “what” and the Development Team have responsibility over “how”, and while this may be true at a very high level, The Scrum Guide reminds us that "The Product Owner is responsible for maximising the value of the product and the work of the Development Team". If architectural and 'debt' style tradeoffs will influence the delivery of value, the Product Owner should be part of such decisions. They may or may not have the technical knowledge (or the interest) to know whether a Product should be written in Python or C#, but they may care about the advantages of each. They may also care whether a new feature is implemented in a generic way, or hard-coded, especially if there is a big difference in implementation time.

I think that many of these issues have roots in legacy ways of working where there was a more distinct divide between Product Management and Engineering disciplines, and where product changes were captured in lengthy and detailed specification documents. In the agile world, where we’ve come to value things like valuable working software, and individuals and interactions we can do a lot better than handoffs of specifications. We can communicate, collaborate and negotiate with honesty about different solutions and the pros and cons that they bring because we’re now one team with one goal.

We must never lose sight of the importance of good technical practices, but only in so far that they can support the product. "Being agile" is never an excuse for cutting corners, but it does challenge our long-held beliefs about how teams can work together to satisfy our users and customers through early and continuous delivery of valuable software.

Six phrases of agile doom

The words we choose, often communicate more than the words themselves

With this in mind, here’s six phrases that are often red flags when used in agile projects. Their use is more often than not a sign of underlying issues that will impede a team’s ability to truly perform.

1. “We’re doing what works for the team”

A noble expression which on the surface might seem to be exactly what agile is all about; responding to change and adapting to the circumstances.

But, does it work for the customer, or for the business, or for the stakeholders? What ‘works for the team’ might be building up large amounts of un-shippable work, or working on features that simply aren’t the stakeholders’ priorities.

Could something else work even better, but require a bit of effort? Doing ‘what works for the team’ is often synonymous with resisting change, or a lack of understanding of the landscape. It reminds me of being a child and trying to fix a relative’s computer when something is obviously wrong with it, but they resist change because they are comfortable with what they currently have, flawed as it may be.

Agile practices and techniques typically shine a very bright spotlight on problems. For example, Scrum won’t fix problems with weak product ownership, but it will make it very obvious. Many teams choose to switch the spotlight off rather than fixing the issue. If hiding from problems is what ‘works for the team’ then there are definitely significant problems underlying.

2. “We do [/don’t] do this because we’re agile”

“Agile” doesn’t tell teams what to do, so quite simply should never be used as justification for doing something. Yet, it often is.

“We’re agile, so we don’t write documentation”, or “agile says we should estimate user stories” and many other variations echo through the hallways of many companies, both large and small.

“Agile”, or more accurately the agile manifesto does outline some values and principles, and of course teams should use these to help guide them but they are not in themselves justification or reason.

3. “Sprint Demo”

What if the Sprint Review was an opportunity to do more than just inspect the increment? What if teams could also use this to look at the Product Backlog, and work with stakeholders to better understand what to do next? What if they could look at the market and see how it has changed, and make decisions based on that? What if the Development Team provided some insight into their work, which could then be understood by stakeholders and improvements to their interactions made as a consequence?

Good news, the Sprint Review is all of those things. Teams mustn’t miss this opportunity if they want to be successful.

4. “That’s an idealism”

While some companies release software to production many times a day (some do it many hundred or even thousands of times a day), others continue to insist that it simply isn’t possible for them to release more than once a quarter.

At its core, agile is all about ‘working software over comprehensive documentation’, and so it is little wonder that almost every agile practice that you come across is rooted in the real world, in real teams, doing real work, for real customers. They’re not born out of University research departments. So when people insist that it simply isn’t possible to deliver working software at least every Sprint, or that stakeholders will never be engaged with the team on a regular basis, their competitors continue to surge ahead.

5. “Our goal is to do the Sprint backlog”

If this is your thinking, just do continuous flow because you’re missing one of the most fundamental parts of Scrum. Sprint Goals represent the valuable increment that teams are working towards, and when the increment has value no greater than the sum of its component parts, Scrum is likely not an effective way to manage a complex project.

6. “Scrum says…”

Similar but still different to #2, this is a great indicator of a lack of knowledge and understanding of Scrum within a team.

There are times, of course, when a team or team-member needs to have the rules laid out in front of them, particularly if they are just beginning their agile journey (‘shu’ stage where simply following the rules is the best option), but generally speaking once a team starts to mature, teams are coached and guided through underlying principles, concepts and values. They should be committed to their decisions and to their process, which they are unlikely to be with purely a rulebook to guide them.

So, when teams choose to skip their Sprint Review, a good Scrum Master won’t simply open the Scrum Guide and recite that “a Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed”. Rather, they will explain why this event is valuable, and the potential consequences on the team’s ability to inspect & adapt, and on transparency, if it were to be skipped. They will also recognise that when a team is thinking about skipping something like the Sprint Review, it is probably a sign that the event isn’t working, and the root cause isn’t the event itself but rather something deeper: maybe it’s just being poorly run, or maybe — in the case of the Sprint Review — there are no stakeholders engaged with the project, or maybe the team simply cannot deliver a ‘done’ increment within the Sprint time box so there is nothing to review.

These phrases are not guarantees of problems, but they are often very good warning signs and allow for a very quick assessment of team health.

Everything should be “pulled”; 3 top tips

Pull is often seen as an attribute of Kanban, but it’s something that needs to be present in almost every agile team, regardless of their chosen working practices.

As work progresses through the system — from a concept in somebody’s head to working software in front of the user — it needs to be pulled from one step to another.

It’s quite common though for work to be ‘pushed’ in some key areas. The impact that pushing work will have varies across teams and products, but it can be anticipated as being synonymous to pushing work in Kanban: amongst other things it risks creating bottlenecks while providing no guarantee that anybody even cares that the work is done.

Here’s three key areas to consider:
1. The development team pull work from the Product Backlog during Sprint Planning. Nobody, should have pre-selected the work prior to this session. This is of course distinct from prioritisation, which is the responsibility of the Product Owner, and any other backlog refinement activities.
2. Product Owners (and customers) should be pulling work to production. It may be the engineer who pushes the button, but it should be initiated by demand. If nobody is pulling the work then there is nothing to suggest that the work was valuable.
3. There is a caveat around information radiators, such as Sprint Boards or any progress updates that a Product Owner shares. Things should be transparent across the team and the business and this is unlikely to be achieved if information is only made public when it is explicitly asked for — in this case, the organisation’s value of openness and transparency is the pulling force. Transparency is a value, while ‘pull’ is a practice. Values should always trump practices.