Making Sure They Do It the “Right Way”

In a Certified Scrum Product Owner class I was teaching recently we got to the part about how it was up to the teams to figure out the best way to solve the business problems presented in the User Stories. We discussed the logic behind this and everyone seemed to be in agreement that it made sense that the people who do the design/coding/testing on a daily basis were the ones most familiar with the technology, the environment and the context of the needs of the end user and that it made sense for them to find the best way to meet the needs of the end user.

It was all going just fine until one of the participants in the class asked a very simple question…

“How do I know they are going to do it the right way?”

The question came from someone who was moving out of the role of lead developer into a Product Owner role.

The short answer, “You don’t. You have to trust them.”

He winced. And this is where things got twitchy. The person asking the question understood that he was supposed to trust. The problem was that understanding this intellectually, and actually doing it were two completely different things.

“Yeah, I know… but really… how do I know they’ll do it the right way?”

We talked about shaping the scope with the Acceptance Criteria, and talking with the team about any known challenges they were going to face, but that at the end of the day, it was the people doing the work that were going to have to be given the freedom to find the best way to solve the challenge placed before them. The “… but really…” question was raised a few more times and it seemed like there was a fading, desperate hope that there was going to be some secret magic answer or trick that would resolve the fear that “they” might make a mistake. Unfortunately, there is no magic answer to this. The simple fact is, “they” might solve the problem in a way that met all the needs of the User Story and it’s Acceptance Criteria but it might not be in line with how the PO would have solved the problem on his own. There is the chance that the solution the PO had in mind might have been a better way, but there is also a possibility that a team of talented, skilled individuals, working together might come up with a solution that was as good, or possibly better, than what the PO was envisioning.

If the Team delivered a solution that met the needs of the story but was somehow still not what was needed, this would become apparent during the Sprint Review meeting when the work was shown to the Stakeholders. One of the benefits of working in short iterations is that we can find problems and learn from them quickly, getting better every step of the way – both in delivering value and in working together. The longer the PO and the Team worked together, the better they get at defining and working on the User Stories.

For this particular PO, and for many people who are moving towards Agile, being open to the possibility that others may have solutions which are as good as, or better than we have isn’t an easy pill to swallow. One of the dysfunctions inherent in a traditional approach is that a command and control way of working was put in place because of the the assumption that if we don’t tell people how to do something, they’ll do it wrong.

But what if they won’t? What if they’re as smart, or smarter than us? Are we willing to let go and accept the risk of trusting again? It’s easy to say yes, but actually doing it – that is much harder. It is also one of the most challenging parts of making the switch to Agile.

Regardless of whether you are a member of the Team doing the work, someone playing the role of Product Owner or ScrumMaster, recognizing the places where the fear of trusting creeps in, observing your reaction and finding a way to take the chance of trusting people again is always hard. And it isn’t just about trusting others. We also have to learn to trust ourselves to make good choices and allow for the possibility of making mistakes and learning from them. How else are we going to get better?

Regarding the light bulb, Thomas Edison is often quoted as having said:

“I have not failed. I just found 10,000 ways that won’t work.”

If Edison had not been given the chance to find the best way to create his version of the light bulb our world would be very different than it is today.

The Scrum Guide says “Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.” This may well be true, but for Agile to sink in and really take root, those three pillars have to stand on a solid foundation of trust. What we trust in is not that people will always be “right”, but that we will run these experiments and learn every step of the way.

And who knows, there is always the chance that the Team may surprise you by coming up with a solution that is even better than the one you had in mind.