Business Case: PO and Dev-Team not in agreement about Dev-Qualities
Hi folks,
I have a special case in my company. I, as a Scrum Master, have to find a solution between the PO and the Dev Team for the following situation. At the last retro there was a discussion between the dev team and the PO what dev quality topics are and what are not and if they belong in every sprint or not. Today the PO the dev team and I sat down to find a solution for this. There was a quick agreement in the beginning what dev quality topics are: Namely, everything that the dev team defines as such. We initially thought that we were in agreement on that.
Then we talked about the fact that not every sprint contains dev quality topics. From a pure agile point of view this is true, because putting fixed stories into an agile sprint is not the best practice. The PO's argumentation was, then the business people could say, we want to have x number of features every time in a sprint, etc. But I could also understand the point of view of the dev team, because they don't just think up dev quality topics and add them for fun, but they have a real business value, which is not always visible from the business point of view. There was a concrete example, which showed that the dev team built a dev quality topic into the user stories and only the solution of this had a sustainable business value. The past has now shown that the omission of such dev quality topics have led to concrete firefighting sessions, so that days, nights and weekends had to be worked through. And this state of affairs should not happen again, which the PO has of course also acknowledged. Finally there was a main problem in my opinion.
The dev-team said to the PO you have to give us the trust that we are allowed to decide ourselves if we pull a dev-quality topic into the sprint or not. If yes, then we can work on it, so that such firefighting sessions do not occur again, because there are too many skeletons in the closet in the form of bugs or performance problems or whatever. On the other hand, if you say no, then we won't take responsibility for such emergencies coming up like in the past, but then we won't work through nights or weekends either. However, the PO wanted to know, if the dev team pulls quality issues into the sprint, what concrete business value they have then.
The dev team said that you can never answer that concretely, but that refactoring or whatever has a business value in the short or long term, but you can't name it concretely. I think the PO lacks confidence in the dev team. But I also understand that he wants to stay agile and not make concrete measurements. But without that I don't think we will get to a solution.
What would you suggest in this situation?
What would you suggest in this situation?
You haven't mentioned the Definition of Done even once. Why not? Why obfuscate Done with language like "dev quality topics"? The Definition of Done is a commitment, and the Scrum Guide makes the accountability for achieving it clear.
IMHO As much as the PO has the final say about the order of the Product Backlog, he is not an owner of the developers. In fact, only the developers can forecast what can be selected to the Sprint, so if they assess that i.e: "We can only consider only A and B, C will not fit and it is wishful thinking that it is possible. There will be some quality concerns to address alongside, etc." then the PO can only negotiate around that constraints, he can not and should not force the Developers to be blind feature factory.
There are many examples where business blinded often by $$$ has forced non-acceptable compromises, one of such widely known last years may be Boeing 737 MAX 8 - which cost not only billions of $ in losses, but also took its death toll.
The Developers are right, they should be trusted about what they decided, however, the PO is also right about the need for communication of such things. If everyone will have the courage to be open to share such business or quality needs, concerns, or constraints. Without hidden agendas, but with respect to each other, then maybe it will be possible to plan sprints as a cohesive team, not as a client (PO) and delivery (developers) separated things? 🤔
If you need an example of a (quality) effort that is hard to measure short therm or even hard to directly link with the (sometimes unexpected) results, that might help:
- People usually brush their teeth regularly - what difference it will make if they will do it once a month for 2 hours vs twice a day for 2 min?
- *In both cases they spent the same amount of time.
What, exactly, are "dev quality topics"?
As Ian mentioned, quality should be part of the DoD.
As per the scrum guide, quality should never decrease during the sprint.
Although you haven't expressed yourself clearly, I believe that you mean addressing technical debt when you say "dev quality topics", and not scrum team improvements discovered during the sprint retrospective. If this is true, then technical debt should be transparent by being placed in the product backlog, which is what seems to be happening.
Piotr is right when he says that the PO cannot tell the Developers what to do, and that it is the Developers that select the PBIs from the PB that will relate to the sprint goal. As one of the POs accountabilities is to maximise value from the work that the Developers do, then he is in his right to negotiate with the Developers in order to try and get a technical debt PBI into the sprint backlog, as rectifying technical debt will increase value in the long term.
If the Developers have found that they need to add automation in order to prevent some of the technical debt, then hopefully the organisation will agree to purchase said technology.
Engineers should be given broad leeway on how they build items which have been prioritized by the Product Owner for the benefit of the business / client. This is similar to an architect and builders coming together to design a structurally sound building, but the day to day work is left to the engineers and construction crew who is trusted with making the product (building) a reality.
I think that, among other things, one of the main problems for the PO is the value of processing the technical debt in the long term. He doesn't see the business value right away and I think he lacks confidence in the dev people. Not necessarily trust, but he wants to sell mostly features.
And his argument was that you can't constantly edit things that customers don't see.
What would be a good measurement to come to an agreement. How can I as a scrum master put this into numbers or tangible values that are a good solution for everyone?
If the PO runs through this sites PSPO learning path (at the very least read the recommended PO book), they will understand how technical debt will effect the Developers work as well as the quality of the increment.
Technical debt, like new features, have 2 values...negative and positive. For features there is a negative value for as long as it is not available to the stakeholders and positive when it is available. For technical debt those values reverse...negative as long as it exists and positive when it doesn't.
The key is to identify the values for technical debt. Many times the presence of technical debt makes it more difficult for the development team to deliver new functionality. So taking the positive value of the new functionality and adding some multiplier to indicate the extra time it would take to deliver with the technical debt in place is a negative value for the technical debt. Then take that same positive value for the new function and apply a multiplier to show how much faster the functionality can be delivered without the technical debt. There is a positive value for the technical debt.
That is only one technique and probably not the best. But often framing the value of addressing technical debt in the impact it has on delivering new functionality is the best way for a Product Owner to understand the importance of addressing it. Another is to show how the technical debt is leading to defects, impacting performance, or anything else that impacts the stakeholders satisfaction with the product and service that can be provided.
Once the Product Owner starts to understand this, it will be easier for them to recognize the value in addressing technical debt.
And his argument was that you can't constantly edit things that customers don't see.
Snappy comeback would be that you are constantly editing the code that updates the database and customers can't see that. You are constantly updating the code that passes a data value from the User Interface to the database and customers can't see that. You modify the code that extracts data from the database, formats it and prints the reports the customer uses but they can't see all the code behind the report. In fact, the majority of the work that a software development team does is not seen by the customers. All they see is the presentation layers but an application can't exist with only a presentation layer.