In my previous post, I talked a lot about Technical Debt and why killing it is important. However, how does one help a team to kill Technical Debt as a Product Owner?
Get Back To Basics
The first thing you can do as a Product Owner is start to get to know how the team is operating. Anytime I’ve been brought in to a Product or Project, I take around two to four weeks to observe how things are going in general. That may go against my personal belief of when you see a problem, solve it, but I think it’s important to understand team challenges and not just throw jargon against a wall because you’ll likely be met with some amount of opposition. Get to understand who the team members are! What are their strengths, weaknesses, and things they would like to improve! If you can find people on a team who are passionate for example about doing BDD, TDD, etc… and it’s not being done, you’ll likely fair better than convincing a team that these concepts are worth pursuing had they not been interested at all. Use your first retrospective with the team as a great conversation starter on things they think they can improve right out of the gate.
Ask About Things!
As you move along, you can ask about certain processes and best practices and what the team thinks about them. A lot of the time I’ve noticed with teams I’ve become embedded in is that they’ve never felt like they could get any improvements made so they never brought up those ideas. Examples are:
You’ll likely hear quite a few great ideas, and you are coming to the team with the voice of wanting to help them. This bleeds over a bit into what a Scrum Master should pursue for the team, but any responsible Product Owner is also looking for ways in which they can improve the quality and time to market of the features they are pursuing. Some cool things you can help a team pursue are:
- Test Driven Development - write the Unit Test for the code before you ever code, that way you have a metric for when something works, and code coverage for the future
- Behaviour Driven Development, or Acceptance Test Driven Development - think about the features functionality up front, write the acceptance or behavior tests for it, and AUTOMATE them so that you know when something breaks in the future. BDD or ATDD also help create living breathing documentation of how your solution functions, documentation being something a team USUALLY struggles with finding the right balance of time to create
- Pair Programming – Steve Ropa did a great talk on Software Craftsmenship (Craftswomen or Craftspeople non excluded of course) at AgileDC, and it really changed my perspective on pair programming. I would love to see more junior software craftspeople pair with journeypeople or masters to learn the craft, and ultimately get a great grounding before they are expected to produce code with more than 40% of their time.
Advocate For Fun Days
Technical Debt is one slice of the whole puzzle, and sometimes it may be hard for a team to put into words where they want to improve things. A very simple way of helping in this regard is just setting aside around 20% of the Sprint for either Technical Debt, or for just fun projects. Google used to do this freely in the form of 20% days, and Bob Galen just wrote a great post about what he referred to as Innovation Days or iDays. I truly believe if you foster a culture of innovation within Development, no matter the size of your organization, you are going to start seeing some very incredible things happen. The people on your team are likely incredibly smart, and can either think of cool little projects that would make their days easier, or potentially prototype a neat little application that can get turned into something usable by your organization in the future. I can think of a few concrete examples in that with a previous development manager, I worked to allow him the focus and freedom to completely refactor a major application such that development time would be expedited for his entire team, and as well kill a ton of the Technical Debt that abounded in the previous solution. At my current gig I am giving my team even more flexibility to do awesome things by putting together neat little scripts that make our integrations easier, or reducing code complexity by large amounts. Obviously this sacrifices a bit of feature development, but as we move in to the feature development it’s going to be MUCH easier and we won’t be working with a messy platform.
Encourage Knowledge Transfer And Learning
Another very important thing you can do is ask a team what they would like to learn. This can either be in the form of what technologies they’d like to play with to enable making feature development easier, or just code bases they would like to have exposure to within your organization. Keep the bus/lottery factor in mind! You want people to spread knowledge!
Why Is A Product Owner Writing This?
I’m writing this because it’s not just the Scrum Master’s responsibility to improve process. It is definitely the Scrum Masters focus to improve process, and help the team improve their health but as a great Product Owner, you can advocate for fixing problems for the team as well. Your number one goal is obviously to maximize value, but this is a grey area that some confuse with just getting a lot of features done. You can actually take a look in the abstract and help the team to prioritize improvements such that your longer term goals become much easier! As a Product Owner, you’ll obviously have to juggle the amount of investment that is made overall, for instance if you are involved in a very short term project, you may forgo some of the tech debt investment to get to market quickly. I would still advocate you give the team some period of team to innovate on their own with buy in from you as the Product Owner. You’ll likely start seeing some very cool things happen as a result!