As for that waterfall, a prime example of Waterfall in action was the 5+ year long development cycle for automobiles at GM. The Toyota came along with their 2 year cycle and decimated the domestic lock on the industry. Take any purely command and control process that decides quality at the end of the development cycle and you'll find massive amounts of waste (in the example above, 3 years of waste!!).
If something is broken, write a test (if it isn't already) and fix it, then refactor it. If something gets the "copy and paste" treatment just once, refactor. Rethink the problem always, refactor when needed. If something isn't tested, write a test, possibly refactor again. Ask lots of questions, confirm functionality, write a test, refactor. Retrospectives are great for a whole team, including the clients/business. But discuss & pair up regarding what is currently going well or not going well. Make changes on the fly when they're needed. All these actions instill higher quality. As for "real life" and "the ideal", what Bobby said is one the money. Those often spell out impending doom and abandonment, followed by frantic coding and mishaps from management. At this point in my career I've seen those incidents come and go, it takes a steady mind and perseverance to push forward with a good process (Agile, Lean, Kanban, eXtreme, or whatever one wants to call it) and be ready and able to change it without much notice. Cheers & good luck on the project effort! Adron On Wed, Dec 22, 2010 at 8:16 AM, Bobby Johnson <[email protected]>wrote: > I agree with Ade. Quality is not something you ensure at the end of the > process in an agile team. That is a waterfall mindset. Quality is something > you have to strive for throughout the development effort. > > Having a productive retrospective is a great starting place, but there are > some caveats: > > 1. The team needs to be empowered to make change. > 2. The team needs to make commitments to implement changes that are > identified and agreed on by the team. > 3. Management has to support the teams effort to improve quality possibly > at the sacrifice of new feature velocity. > > Also trying to parse practices into "real life" and "the ideal" is giving > up before you even try. What I hear in this sentiment is, "I will pay lip > service to Agile practices, but when the rubber meets the road I will > abandon the practices and pump out whatever crap gets me over the immediate > goal line." > > And Hi, Anne! Good to see you posting on the mailing list. Hope things are > going well down in Olympia. > > Bobby > > Trying to parse things into "real life" > > > On Wed, Dec 22, 2010 at 7:39 AM, Anne Wax <[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.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]. >> 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]<altnetseattle%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. > -- *Adron B Hall* *Tech*: http://compositecode.com *Transit*: http://transitsleuth.com *Twitter*: http://www.twitter.com/adronbh -- 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.
