I disagree that quality is a nebulous term. I might agree that it is a relative term. This bit of code is of better quality than that bit of code and this project has certain aspects that make it of higher quality than another.
I would also suggest that the definition of quality in your project needs to be set up front with clear goals. Getting to the end of a release cycle and finding out what your definition of quality should have been, seems painful to me. So, I agree with you that quality has context in your specific project. I think Anne's question raised a lot of red flags because we have all been there and felt that pain. And most of the list reacted the same way, suggesting that adding another quality gate process to the end of a release cycle is probably to late in the game. The release process where Anne works is a pretty rigorous week long affair, with some pretty great people beating the application up. If bugs are still leaking out to the customers, especially regression bugs and unintended new feature type bugs, I doubt another quality gate prior to release will help. In that situation I would suggest reflecting on how the bugs were introduced and what engineering practices would have helped uncover the bugs faster and come up with a workable plan to get there. That plan is going to be tough and painful for the entire team. When you carry around years worth of technical debt and that debt is now causing you to ship increasingly buggier and buggier software you have to put a stake in the ground somewhere. Anne specifically asked about retrospectives, something I find a lot of value in (I am a total Diana Larsen fanboy). So I suggested some advice around that. OK this is to long and ramble-y, considering deleting it and working on some of my own self inflicted technical debt. Will send anyway in case someone wants to point out what a jerk face I am for reading a couple agile books and popping off about quality. 8p Bobby On Wed, Dec 22, 2010 at 9:25 PM, Justin Bozonier <[email protected]>wrote: > First of all this is a great question, one I've asked before too. > > Now that I am on a team I don't hesitate to call "agile" I can offer a > fairly unique perspective. Screw "quality". > > "Quality" is this nebulous term that I've used in the past after reading a > book about patterns and agile practices. We can't really proceed in this > discussion until we've defined it, so here is mine: > > Quality code doesn't exist, a quality product does. > > What I mean by this is as long as your code is able to be melded to > business needs on time and under budget and meet your business objectives > **consistently** then what the hell do I care about some dogmatic definition > of quality? > > Now to the question of when to bake it in.. Can you really imagine asking > your business.. When should I write code that will enable us to deliver on > time and under budget and meet your objectives? They'd say "That's what we > want!!!" :) > > So really the issue you're facing is a crisis of confidence in agile > practices. You're finding it hard proving a case for quality (or perhaps I'm > super imposing past lives ;) and good for you for asking because it's > painful and not many "Agilistas" talk in the concrete. > > Don't take anyones word over your experience without sufficient supporting > evidence. > > Look at the messages in this thread and focus on the advice from those who > actually had a dialog with you about your specific situation, getting to > know the constraints your business is facing. Those are the golden ones (I > already checked, they aren't here). > > The really hard answer is that it's going to take a lot of analysis, trial > and error from you, and creative thinking you won't find in an agile > consultant to be able to solve your real issues.. To be able to get at the > core of what the word "quality" means for your unique context. > > You're not crazy, nor are you "not getting it".. Developing and maintaining > a quality product is hard, talking about theory and poking at code is not > (not in that awkward uncomfortable way we hate at least). > > Good luck! > > Justin > > Sent from my iPhone > > On Dec 22, 2010, at 6:06 PM, Eric Ridgeway <[email protected]> wrote: > > BTW my previous comment was for the OP I realized it could have sounded > like I was talking to someone else > On Dec 22, 2010 7:39 AM, "Anne Wax" < <[email protected]> > [email protected]> wrote: > > What do you do at the end of a sprint or a release cycle to ensure > quality? > > > > We've seen some blogs that talk about stop-reflect-adapt and > > review-reflect-repeat. What do you all do when you have completed an > > interation or a release cycle to ensure your product's excellence? Do you > > step back to review and improve before moving on to the next cycle or > > project? > > > > What happens in "real life" and what is the ideal? > > > > Thank you, > > > > Anne > > > > > > > > > <http://www.agileweboperations.com/stop-reflect-adapt-the-3-steps-to-stop-writing-bad-code> > http://www.agileweboperations.com/stop-reflect-adapt-the-3-steps-to-stop-writing-bad-code > > > > > > > > > <http://www.agilejournal.com/blogs/blogs/all-about-agile/704-how-to-implement-scrum-in-10-easy-steps-step-10-review-reflect-repeat> > http://www.agilejournal.com/blogs/blogs/all-about-agile/704-how-to-implement-scrum-in-10-easy-steps-step-10-review-reflect-repeat > > > > -- > > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > > To post to this group, send email to <[email protected]> > [email protected]. > > To unsubscribe from this group, send email to > <altnetseattle%[email protected]> > [email protected]. > > For more options, visit this group at > <http://groups.google.com/group/altnetseattle?hl=en> > http://groups.google.com/group/altnetseattle?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<altnetseattle%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. > -- "The explanation requiring the fewest assumptions is most likely to be correct." - Occam’s Razor http://en.wikipedia.org/wiki/Occam's_Razor -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
