I recently had the privilege of working with a team as their Scrum Master. I was relatively new to the team members and don’t have a long history of working with any of them, so I was delighted when we got off to a great start. The team was open to trying new techniques and seemed to really enjoy the estimation processes we used.
I am a big advocate of Planning Poker and we used the technique to go through a hastily assembled backlog of work. The team really enjoyed the simple act of collaboratively discussing the work and found the process really helped steward the discussion along. A few days into the Sprint, we were having a an ad-hoc estimation meeting when a particular backlog item came up for consideration. The conversation went similar to this, although the names have been changed.
“I know how I want to do that work, but we won’t be allowed to do it that way,” John said.
“What do you mean?” I asked.
“Well, I know there is a better way to do this. It requires me to take an extra day to learn a particular scripting language, though. That means the Product Owner will tell me I can’t spend my time that way. She’ll just want the fastest solution possible, which means hacking it in the way we have done in the past.”
I replied, “Remember that whole discussion we had about empowered teams? It comes down to right now.”
“What do you mean?” asked John.
“I mean that you are in control of the quality bar. That’s what this is all about! If you know this is the right way to do the work, why are you even offering another option? Just estimate the work assuming you will do it the way you know is best. That’s why you are the expert here.”
He gave me a funny look. “Really?”
John’s manager was in the room, and actively participating as a Scrum team member. I turned to him, “Do you agree the right way to do this work is the way John is describing?”
“Yes.”
I asked, “Is there any reason he can’t do the work that way?”
“No.”
“Are you willing to hold off the P.O. and let the team study up on this vendor’s scripting language?”
“Yes.”
It is that simple, folks. This is what managers so, they help their people do the right thing. An this is what John owes his customer, the best solution he is capable of creating.
I understand there are times when fires must be fought, and when perfect is the enemy of good enough. I get that gold plating is a time honored dysfunction. I also know the best quality software I have ever seen was actively managed by the teams who created it. The teams themselves were in control of the quality of the product.
It was a good day at the office for me because John told me something toward the end of our estimation meeting that made my day.
“This is the first time in my 17 years in I.T. I have been trusted to do my job the way I know it needs to be done. I feel great.”
That is gold. That is Agile actually working.
You see, it does work 🙂 To me, the self-organization of a team, taking matters into their own hands is quite enlightening as well. I think this is the only way to achieve quality software.
good for you! I love that, “you are in control of the quality bar.” We developers are so used to being beaten down for every last nickel and dime, it’s too easy to think that means we need to throw quality out the window. But, of course, the truth is as you say – we’re the ones responsible for making sure our apps stay running and maintainable. That means making smart decisions now.