Willem Vermaak — July 19, 2019 — July 19, 2019
A while ago I was brushing the teeth of my 3 year old son when I thought of something. This little dude can walk, run, talk (A LOT!), climb, undress, etcetera, but somehow every morning and evening I’m brushing his teeth, instead of him doing it himself. This mainly has to do with the fact that I’m always short on time. At night he just needs to go to sleep quickly and in the morning we are rushing to get to the kindergarten. Whilst brushing his teeth I was thinking: I need to take some more time so he can learn how to do it himself. But then, I never take the time for him to do it. Yet, I’m still frustrated he doesn’t do it himself. Nice little vicious cycle right?! Well, this is very true for Product Owners and their Development Team(s) as well!
In my Product Owner courses, I jokingly call the Development Team the “tools” of the Product Owner. Like any craftsman creating something beautiful, the vision of the craftsman, combined with the right tools make something come to life. For a carpenter, this means using a saw, sand-paper, perhaps hammer and nails. For a Product Owner, this means having skilled people who can build the envisioned product.
It’s weird to me, is that unlike a carpenter, most Product Owners hardly spend any time on improving and maintaining their tools. They just accept they are there and expect it to work and just do what it should do. I see hardly any Product Backlogs that contain actual improvements for the skillset of the team.
When talking to Product Owners I mainly get 2 reasons for not doing this:
1. “There is no time. I just need to crank out work and steam forward. They (the Development Team) should improve, but they just figure it out.”
2. “It is not my responsibility! It is up to the team and/or Scrum Master to ensure they do personal development.”
The second reason is, in itself, fair enough. Yes, with true self-organising teams they should step up and ensure personal and team improvements over time. However, as Product Owner, you can also take ownership of this.
You can, and should, show the Development Team that you care about their wellbeing by making sure the Product Backlog contains work that is evolving around team (and tool) improvement. And I’ve found a way to visualize that.
In the past I used to draw this “Backlog Ordering Quadrant”:
It shows 4 types of work that a Product Owner most commonly has to deal with. Some work is visible to users (like the annoying cookie wall that has the “close” button very nicely just outside of my screen on my phone), whilst other work is not visible (4000 lines of spaghetti code that almost just work). Then there is work that by default has a negative impact (it will cost the Product Owner to deal with it and not deliver much) and there is work that (potentially) is valuable (like a solid architecture that will keep your website up when high traffic hits it).
I always felt this was an incomplete model. And that is not only because some type of work you could think of that is edge case (where does a spike fit here?). The problem that this model has, is that it is all about work the team does, but does not give room for that personal development I was talking about.
So, here is an updated model of the Backlog Ordering Quadrant:
I’ve made it vey nice 3D-ish and added Team Development and Experimenting. There you go! Now you, as Product Owner, all of sudden really do need to think about sharpening the saw. And besides having all those user stories, defects, technical tasks, spikes and what not on your Product Backlog, you now also need to add Product Backlog Items like “Hackathon”, “Development Kata”, and “Java training”. You need to keep room in the schedule for more experimentation (innovation) and team/personal development.
Off-course, common sense keeps being the main thread also here, so wether or not you will add all the separate courses each of the developers take to the Product Backlog, or just schedule less capacity in the Sprint Planning is really up to you and the Development Team. Remember that demanding everything should be on the Product Backlog regarding (personal) development goes against the nature of self organisation, so be smart about that.
What I do want you to do is have awareness that you as Product Owner are a key person in enabling team growth. If you show you proactively think about the wellbeing of your tools (NEVER CALL THEM THAT), and schedule room in the Product Backlog for development, experimentation and improvements, they will appreciate you more.
So, be the enabler of growth and maximise the value of the product, resulting from the work of your highly motivated, well trained and well equipped Development Team!
As for my son? I bought an electric toothbrush and he loves that thing! If it were up to him he would brush 16 times a day. I’m keeping peace of mind, opening up the schedule and ensure he gets the time to practice (and play). We are improving!
Business & Finance Articles on Business 2 Community
(46)
