Big enough title? Meh, that isn’t really related. 🙂 Please read on.
The latest little blurb back and forth in the ALT.NET Community on the ALT.NET Seattle Google Groups thread is about retrospectives and how to increase quality. I won’t post any direct messages but wanted to blog a bit about that.
My fellow coworker Eric Ridgeway mentioned, which I whole heartedly agree, one doesn’t wait until the end to make quality improvements. One focuses on quality at all times. This makes me wonder sometimes were the disconnect is for quality improvements. Even when asked sometimes, I’ll state something that is so simple as “always focus on quality” but then have follow up questions such as, “so when should we focus on quality?”
How did that not translate? I get lost when I get a statement made back as a question. I just stated the solution, the solution is to always focus on quality. When you write a test and watch it fail for lack of implementation and then implement it look to see if it is elegant. Look for the quality of logic and code usage. If it looks odd try to refactor it. If something is just being changed, check the quality. If you’re white boarding, ask yourself if you should be trying out some implementation instead of just white boarding. If you’re implementing but it doesn’t seem clear, ask yourself if maybe a white boarding session will work. If you find your daily process is hampering clear minded efforts to develop good software solutions, ask why the process is low quality and what would make it higher quality. If your team has low code coverage, or heaven forbid no code coverage, don’t wait, start doing something immediately. Stop non-quality development and start high quality development.
It really is that simple. There is no way that should not translate. Always focus on quality.
While reading this blurb on the ALT.NET Google Groups I got an alert for Rob Hirschfeld’s latest blog entry about Agile & Cloud Computing. In his latest blog post titled “Black Hat Feedback Essential For Cloud Success” he dives right into the process improvement and retrospective conversation. Rob points out a few reasons teams skip on improvement:
- All that talking and listening and improving takes time and attention.
- Post Mortem or “lessons learned” meetings that never make any difference because they happen after the work is done. (well, duh).
- No one has a methodology that makes the meetings productive.
- Lists with more than 3 items on them have too many items to be productive for improvement activities because of reader’s limited attention spans.
One of the quotes he pulls from Lean Agile advocates Mary Poppendieck and Eric Ries addresses this, “The secret to improving your performance is to regularly work to improve your performance.” This goes back to what Eric, many others, and I keep saying, “always work on quality, don’t wait until the end”. If you wait until the end, it’s already too late.
