Otto Weininger quote

"All genius is a conquering of chaos and mystery." - Otto Weininger

Wednesday, December 12, 2012

Why do you hear "Schedule" when I say "Quality"?

I was sitting in on a release retrospective recently when the following situation occurred. The release had created too much technical debt and we were reviewing one of the newly introduced defects where the handling of transactions was incorrect, causing deadlocks in production. When I asked the obvious question, "How did this get through the code review?" one of the developers blurted out "We didn't have time to do all the code reviews!".

The thought that struck me was that no matter how many times quality is emphasized as the top priority, the team really thinks it's schedule. In my experience, and talking to people in the industry, this is a very common problem.

This is a SaaS company, and they depend on the software to generate revenue, so it is clear that schedule is always a consideration, but it can be very difficult to convince the team it isn't the primary consideration. And this was a good case study. The team had never asked for more time and had never identified that the code reviews weren't done. These are separate issues, so let me address them separately.

No Time

Developers (and testers, and product owners, etc.) are used to working in environments where the schedule is master. Where you get a bonus for releasing software on time, whether it's buggy or not, and chastised for releasing quality software a little late. It's hard to break that mindset. In order to do that I suggest the following:

1. The question "when is it going to be done?" should be the last question you ask, if you ask it at all. The more emphasis you place on the schedule, the more the team will believe it's what you care about and what you're measuring them on.

2. Focus heavily on "quality oriented" activities - code reviews, unit tests, performance tests, etc. And don't ask about these in a perfunctory manner - dig in. Ask to see code review comments (if possible these should be captured in the source code control system). Ask about any challenges people had writing tests for the new code - where there database dependencies?; how did we simulate "something" in the test environment?. Depending on the answers you get, you may be able to answer "when will it be done" by yourself. And you'll have better insight into where the team is putting their emphasis.

3. If and when the team asks for more time to insure that the story they are delivering is "Done-Done" (i.e. of high quality), give it to them without reservation. Don't make a face, don't roll your eyes, and don't be reluctant about it. I have had teams ask for more time for testing when in reality they needed more time to finish coding. This is not acceptable, partly because it will lead to short changing testing and code reviews, but mostly because it is a breakdown of trust.

Lack of Openness

Trust is a large part of any development project, but especially an agile project. Lack of trust hides information that needs not to be hidden and creates silence where conversation is critical. Trust goes hand-in-hand with courage, another key agile value. Team members need to have the courage to raise difficult issues, and the only way most team members are going to have that courage is if they trust the rest of the team, and management, to react appropriately. At least speaking for myself it can sometimes be hard to separate my gratitude at having the issue identified and surfaced with my frustration that it occurred, especially if it was preventable. But you have to focus on the gratitude and deal with solving the issue and moving forward. Save your concerns for later. These are often good items to deal with in the Sprint Retrospective.

In Conclusion

If the team thinks that the schedule is the most important priority you're at risk of ending up with poor quality, and a slipped schedule. If they understand that quality is the priority you'll have a better chance of hitting your schedule, as well as better quality. It seems like a "no-brainer", but if your team is hearing "schedule" when you say "quality" you need to ask what you are doing that is contributing to that. And this is your contribution to trust and openness. If you're doing something that is creating the wrong impression with the team you need to address it with them, acknowledge your mistake, and re-confirm your and the team's common goals.

- Posted from my iPad

No comments:

Post a Comment