January 1, 2011

Wearing the Right Hat

A Scrum Product Owner at a client of mine once told me he didn't trust development to build what he wanted built. Sadly, I find this quite common with the more technical POs. The lack of trust was largely due to his negative experience with some other dev team at a different company. His concern was that future value would be blocked by using a simplistic approach now. This PO therefore stepped way over the PO/DEV responsibility line into specifying some of the "how" for a set of stories.

Lack of trust is a significant issue. I could have told the PO that he needs to be able to trust the team. I could have suggested he create opportunity to build that trust, or change the team. Either way, that would take some time and we can work on that. But that's not the focus of this post.

And I could have explained emergent design and the danger of over-architecting things now. I could have told him YAGNI, but have also said that it is okay to share the big-picture vision with the dev team. That it's okay for the dev team to think about where they are headed long term as long as they "pay as you go" and not design and build too much up front. But that's not the focus of this post either.

The focus of this post is that I told him it was okay for him to not trust the developers for now and that it was okay for him to step over the line.

Now, before you take away my Agile Badge, let me explain myself.

product owner hat architect hat
Product Owner Architect

I told the PO that if he is technically capable and can pull it off, then he can AT THE APPROPRIATE TIME review development's planned approach and make suggestions. I told him he can have a PO hat and an architect hat, but that he can only wear one at a time and he needs to wear the correct one at the correct time. He must wear the PO-only hat and only the PO hat during the planning game. Once the business requirement is sized, split, resized, scheduled, and planned, he can visibly remove his PO hat and put on his architect hat during the design and tasking part of the sprint.

In this case, I told him that I believe he is wrong and most likely doesn't need what he was requesting and that what he was requesting will greatly complicate the design and require much much more code than necessary. There was a better approach. Nevertheless, I didn't tell him not to put forth his ideas. For me, it's just a matter of timing.

What would you have done?

No comments:

Post a Comment