Boris Steiner

One of the most often used skills and stances in the daily life of a Scrum Master probably is coaching. I'm talking coaching as in the definition of e.g. the Agile Coaching Institute

Late in the second day of my PSM classes, I usually do an exercise with my students about skills and traits.

Technical debt seems like a topic that resides completely in the domain of a Development Team. They are responsible for delivering a potentially releasable Increment after all. But might there be more to it for a Product Owner? More to know, more to deal with, more to take care of it? In my opinion there is! In order to help here I want to give you a better understanding of the term - even if you are a non-technical person. More importantly, I’d like to outline a few ideas what to do about it! So buckle up, we are going to take a trip down memory lane … What is technical debt? Imagine those days when you were living in a shared flat. Maybe when you were studying, starting your first job or similar. I don’t know about your general rules concerning cleanliness and tidying up. But what I can recall from those days were mainly two occurrences of a properly cleaned place: you have just moved in together with some other people and the previous residents left everything spotless you have been living there for a while, someone felt that it was time of getting stuff in order and you were doing exactly that In both cases we are now talking about a flawless environment. Everything is properly stored away, nothing is lying around, there’s no dust whatsoever, and the trash has been brought outside. The place is so clean, you could eat from the floor - if you wished to. Isn’t this great? But then it happens. You wake up one morning, are ready to head out for your day and you just want to have a quick meal. So you get a plate out of the cupboard, a knife out of the drawer, cheese and butter from the fridge. You cut a slice of bread, spread the butter and add the cheese and pack it to go. Since you are in bit of a hurry, you put the plate and knife into the sink, forget the cheese next to the fridge and rush out of the door. Then your flatmate enters. Also a little hungry. Not in such quite a hurry though so there is time to make an omelette. At this point in time, two things are likely to happen: It might be a little bit harder to make the omelette because some of the utensils (say the knife or his favourite plate) are not available or not in the perfect condition for immediate use When cooking is finished your fellow flatmate might not feel such a big urge to clean up. Hey there’s dirty dishes in the sink. This might be cleaned up later together with the pan, bowl and everything else that has been used for the omelette. Spoiler alert: It won’t happen. We call this the “broken window effect” Fast forward in time. Your kitchen looks like a mess. The sink is full of used dishes. Trash in every corner. There are no clean tools to be found anywhere. That piece of cheese back from the days has grown a fluffy pelt and smells a little bit strange. The place is in no condition to prepare food anymore. At least not without a very big effort and compromising on the quality and hygiene of the food being prepared. Imagine preparing a meal in this kitchen. How would you feel as the person needing to work in this environment? How would you feel as someone whose meal is prepared in this environment by someone else? Why should you as a PO be concerned about it? What happens in the kitchen is the equivalent to what happens in your product development process and environment. If you continuously focus on fancy meals (that great new feature you have been thinking of) and never take care of cleaning the kitchen or bringing your tools in order (working on product quality and development processes) you will end up with a big problem on your hands. Not immediately. Those things start small and in the beginning they won’t hurt. But in the long run, compromising on quality almost always takes its toll. It will get harder and harder to work on valuable new features (green) over time because you have accumulated so much technical debt (red). And once again: At first this won’t hurt. It might even feel good because of the faster feature development. But this is more illusion than reality! The impact of technical debt starts small and evolves exponentially (blue). Unfortunately, already Benjamin Franklin knew: The bitterness of poor quality remains long after the sweetness of low price is forgotten. And just to be perfectly clear about it: The one thing you should not compromise on - if you are aiming for professional Scrum - is quality! How does this relate to Product Ownership? As a Product Owner you are the one responsible to maximise the value of the work, your Development Team does. Of course there are a lot of ways to do this and one blogpost can’t possibly explain them all. The message here is: If you are defining value for your product and come up with ways how to measure it, don’t forget about this aspect! Depending on your context your mileage will obviously vary but a healthy product is the only one that will create value for you sustainably. Put very simple and straightforward: You can not create a valuable product if you are accumulating technical debt. Period. Having said that, what can be done about it? How can you know, you have a problem here? Some things can be felt, some things can be measured. Both ways apply if you want to find out if you have a problem with your kitchen a.k.a. product development environment. We’ll make our way starting from soft indicators to measurable ones: 1) Gut feeling Let’s be honest. In most cases we know that there is a problem in a given situation. We might not be able to pinpoint its exact cause and reason but we know damn well it exists. How does this apply to product development? Have you ever been hesitant as a Product Owner if you should release your product to the public? That moment where it just did not feel quite right? I mean the features were all there, but something felt odd and you almost were afraid to reveal this version of the product to the masses. Or that Sprint Review where you had been inviting all the important stakeholders to try out new features and gather their feedback. You and the Development Team were really proud of them and you all had worked a lot together to get this great new version of your product out of the door. There only had been some minor glitches but the Development Team was absolutely confident to get rid of those. Sure, John - one of the team members had his concerns but he is a pessimistic guy, right? Which brings us to the second point … 2) Listen to your Development Team You are working together with your Development Team on a daily basis? Good! You are promoting your vision for the product and rally them behind it? Great! You are exchanging ideas about further development and technical implications? Excellent! But remember John? How often is his urging voice heard? Might it be even beneficial to have a critic within the team? How often do you spend time with your Development Team talking about your quality expectations for the product and hear them starting a discussion about the implications for their Definition of Done? Open your ear for those voices as well! Establish a general understanding of this topic. This might be a technical education opportunity for both the team and yourself! As a Product Owner you do not need to know how to write a unit test or how to automate a build pipeline. But it won’t hurt to understand what those terms mean, how they could be beneficial to quality and how to balance the efforts required with those that go to feature development! 3) Metrics The strength and beauty of Scrum is grounded in its empirical approach where we aim for making things transparent, inspect them closely and adapt our future course based on what we find. Applying this to the topic of technical debt means we need to find out what to inspect if we are searching for signs of it and how to make this transparent. One approach that might be beneficial here is Evidence-Based-Management (short EBM). It aims for establishing metrics that matter for actually delivering value. If you are interested in details, I suggest to start with the EBM-Guide as a resource. For the sake of our kitchen cooking scenario let me introduce a few metrics that might be worthwhile measuring when trying to reveal traces of technical debt: There are also deeply technical ways to measure the amount of technical debt in a product. They vary depending on context (software, hardware …) and therefore I won’t dive into details but if you are working with a professional Development Team they will either know how to do this or whom to ask for help! Pay attention to one thing though: Always treat every metric as what it is. A measurement that needs to be interpreted. Otherwise you might fall into the trap of Goodharts Law which says: When a measure becomes a target, it ceases to be a good measure This means: Be careful not to establish only one metric, jump to conclusions too early and for sure don’t punish transparency. If you do, you’ll inevitably end up with a (social) system that optimizes towards a metric by cheating. What to do about it? What’s the implication for you as a Product Owner and your work? First of all: Be aware of the fact, that technical debt exists. Your product might already suffer from the loss in quality. You might not feel the impact yet, but it will steadily grow if you do not deal with it and you will pay the price in the long run. That price is sacrificing quality for short term shininess. This is not a good approach if you want to create long-term value. The one thing you shouldn’t compromise on in professional product development is quality. There might be valid reasons to do so - like getting faster feedback or outrunning the competition. Be careful though, take a very conscious decision and make sure you ready to pay back those technical debts in the future! This means when ordering your Product Backlog make sure to take this into account when you determine value for certain items. See if they come with a cost and if this has an impact on value. Second: Decide how you want to measure technical debt in your context. Is gut feeling enough or do you need a more data driven approach? How do you want to inspect? What is your measure for value? How can you make the implications of technical debt transparent? What might be customer related metrics that you can put in place? Third: Check the warning system you have established, interpret its signs and decide how to deal with it. Work closely together with your development team to find out if they are aware of this and how to align it with your vision for the product. See that the quality standards you expect reflect in their Definition of Done. Support them if they need help from the outside to educate in techniques that prevent technical debt. Adapt on what you learn and make educated decisions about taking on or getting rid of technical debt. And spread the word to other fellow Product Owners: Your Development Team is responsible for delivering a potentially releasable increment of “Done” product. But when it comes down to maximizing value of the work the Development Team does - which is your job as a Product Owner - you should be aware of the fact that high value and low quality don’t go very well together. Scrum on!

When it comes to Product Ownership, there are a couple of things that are essential to get the job done right.

The other day I had a conversation with a colleague. He was looking for an opener for a talk - something catchy to illustrate to his audience (mostly finance and banking) that there could well be a need to change their current ways of working.

Being a Scrum Master requires to take many different stances and approaches when working together with teams and individuals. Two of them that are probably used most are “Coaching” and “Mentoring”.