“SCRUM assumes that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression.”
One of the things that I like about Scrum is that its creators defined it knowing that no development process is perfect. The Scrum Guide does not tell us how to build software, rather, it openly acknowledges that building software is complicated and unpredictable. This may seem odd, with Scrum being thought of as a development process (it’s not). In a recent post to the Yahoo! Scrum Development group, Ken Schwaber stated that “we purposefully constructed Scrum with a lot of holes in which a person or team or organization has to continually figure out the best thing to do.”
So how does a Scrum team “continually figure out” how to do the best thing? To facilitate iterative and ongoing improvement, Scrum specifies that each Scrum Team hold a Sprint Retrospectives. Further, these retrospectives must happen frequently, occurring immediately following each Sprint Review.
It is often overlooked when starting out with Scrum, but I believe the Sprint Retrospective is the most important meetings a Scrum team participates in. While the Sprint Review is a valuable “public” meeting where working product is demonstrated to stakeholders and customers, the Sprint Retrospective is a “private” team meeting, allowing the team to safely discuss what’s working and want could be improved with regards to how they are delivering their work. In the Sprint Retrospective, anything that relates to how the team operates can be discussed and possibly tuned or improved. Up for debate could be how the team communicates, technology issues, done-ness criteria, or even choice of tools, as was recently discussed for one of our new Scrum teams in my organization (They reverted back to whiteboard task charts and spreadsheet burndown charts!).
What this ultimately means is that each Scrum team is evaluating, refining, and improving how they work together and build software every 2 to 4 weeks. Almost continuously improving throughout the life of the project! Over a 12 month project there can be upwards of 24 opportunities to “do things better” and improve how the software is built and delivered. Compare that to our our Waterfall-like development model where we generally conduct formal retrospectives twice, once after Beta and once after we release. In our current model, we, at best, have one predefined opportunity to improve our practices during the release, at Beta when there is usually no more than 3-4 months of (QA and bug fixing time) time remaining before the software is released. Process improvement is clearly not highly integrated into our Waterfall process.
With frequent inspection and adaptation we can become more efficient at building and delivering high quality software that meets or even exceeds customer expectation. So my advice is: take full advantage of your Sprint Retrospectives. As a Scrum team member, it’s your (frequent!) opportunity to make a difference...
kaizen (kaɪˈzɛn) - n a philosophy of continuous improvement
of working practices that underlies total quality management
and just-in-time business techniques [Dictionary.com]
No comments:
Post a Comment