One of the problems many teams struggle with when beginning to adopt Scrum is delivering potentially shippable increments of product at the end of every Sprint. Delivering a potentially shippable increment of code is one of the fundamental concepts of Scrum - a requirement that is specifically called out in the Scrum Guide:
Producing a potentially shippable product in 2 or 4 weeks involves a semi-radical mindset change to those used to building software in a traditional Waterfall-like manner. Making this mindset shift enables an organization to experience numerous benefits and efficiencies, from the ability to deliver software to customers at more frequent intervals, to being able to strategically pivot product direction while minimizing waste.
At first, most teams new to Scrum struggle with delivering software in this manner - our Agile Pilot teams were no different. The first challenge was integrating cross-functional team members, development, doc, QA, into a new team. Agreeing on the definition of “Done” helped with this. Another hurdle involved Product Backlog user stories - often user stories were too large, or difficult to break down into small single feature product slices. Backlog grooming quickly rose in importance for most teams. Team member specialization also presented challenges. Tensions around creating a shippable product often developes when team members such as QA and documentation have to complete there work the last day or two during the Sprint. At present this is our biggest challenge - the teams are still learning and adapting, as is the organization as a whole.
Over the course of a handful of sprints the Pilot teams put in a valiant effort, overcoming many of these challenges. Teams adjusted the way they worked, via Sprint Retrospectives, to address some of these concerns, and ended up producing high quality software and documentation. One of the Pilot teams even released the results of one of their early Sprints to customers via a Technical Preview (TP) pre-release program.
Last week I was fortunate enough to attend an executive briefing scheduled with one of our customers who has been participating in this Technical Preview program. As part of this TP, we supplied a documented script that the customers should follow; this script defined the usage pattern we used as a final test before releasing the product to this program. The customer, being a self-proclaimed power user, told us that he followed the script, but really wanted to see what else the product offered. He strayed off script and began investigating how the tool’s functionality could help his applications. I think a few jaws dropped in the meeting, as some were expecting the worse - straying off the prescribed path was an “all bets are off” scenario for pre-released software in our Waterfall development environment. Surprisingly to most, the unexpected happened: The customer told us that the software had all the functionality he expected and had very few bugs. Further, he stated that he was able to use the product to map how he would make use of it in his enterprise. He did mentioned, in a proud tone, that he found 2 or 3 bugs that he wanted to demonstrate to us. Sure enough, he brought up the software and proceeded to demonstrate how he used the software, along the way, attempting to show two issues he found. His subsequent focus on the issues, one minor (a browser-related issue), the other an issue he was unable to reproduce (but did note there was an easy work-around), didn’t minimized his earlier claim, now stuck in my mind: “the product had all the functionality [he] needed”!
It’s always great to see a Customer demo your software to you. Our Product Owner had an opportunity to gather real-world product feedback from a power-user customer, one who personally demonstrated how he would use our pre-pre-Alpha, but potentially shippable, version of our product. This customer’s feedback subsequently influenced our product backlog for an upcoming sprint - agility in action!
During this whole “customer demonstrating our product to us” segment of the meeting, I was smiling proudly: this was software that we, in comparison to a Waterfall-type release, had essentially “tossed out there”: no code freezes, no bug triage, no end-game QA bug fix cycle. It was product that was the Sprint 4 output from our new Pilot Scrum Team, software that the Team had deemed “potentially shippable”. And it was just that: potentially shippable.
“Scrum requires Teams to build an increment of product functionality every Sprint. This increment must be potentially shippable...the increment must be a complete slice of the product. It must be “done.” Each increment should be additive to all prior increments and thoroughly tested, ensuring that all increments work together.”
Scrum Guide: http://www.scrum.org/scrumguideenglish/
Producing a potentially shippable product in 2 or 4 weeks involves a semi-radical mindset change to those used to building software in a traditional Waterfall-like manner. Making this mindset shift enables an organization to experience numerous benefits and efficiencies, from the ability to deliver software to customers at more frequent intervals, to being able to strategically pivot product direction while minimizing waste.
At first, most teams new to Scrum struggle with delivering software in this manner - our Agile Pilot teams were no different. The first challenge was integrating cross-functional team members, development, doc, QA, into a new team. Agreeing on the definition of “Done” helped with this. Another hurdle involved Product Backlog user stories - often user stories were too large, or difficult to break down into small single feature product slices. Backlog grooming quickly rose in importance for most teams. Team member specialization also presented challenges. Tensions around creating a shippable product often developes when team members such as QA and documentation have to complete there work the last day or two during the Sprint. At present this is our biggest challenge - the teams are still learning and adapting, as is the organization as a whole.
Over the course of a handful of sprints the Pilot teams put in a valiant effort, overcoming many of these challenges. Teams adjusted the way they worked, via Sprint Retrospectives, to address some of these concerns, and ended up producing high quality software and documentation. One of the Pilot teams even released the results of one of their early Sprints to customers via a Technical Preview (TP) pre-release program.
Last week I was fortunate enough to attend an executive briefing scheduled with one of our customers who has been participating in this Technical Preview program. As part of this TP, we supplied a documented script that the customers should follow; this script defined the usage pattern we used as a final test before releasing the product to this program. The customer, being a self-proclaimed power user, told us that he followed the script, but really wanted to see what else the product offered. He strayed off script and began investigating how the tool’s functionality could help his applications. I think a few jaws dropped in the meeting, as some were expecting the worse - straying off the prescribed path was an “all bets are off” scenario for pre-released software in our Waterfall development environment. Surprisingly to most, the unexpected happened: The customer told us that the software had all the functionality he expected and had very few bugs. Further, he stated that he was able to use the product to map how he would make use of it in his enterprise. He did mentioned, in a proud tone, that he found 2 or 3 bugs that he wanted to demonstrate to us. Sure enough, he brought up the software and proceeded to demonstrate how he used the software, along the way, attempting to show two issues he found. His subsequent focus on the issues, one minor (a browser-related issue), the other an issue he was unable to reproduce (but did note there was an easy work-around), didn’t minimized his earlier claim, now stuck in my mind: “the product had all the functionality [he] needed”!
It’s always great to see a Customer demo your software to you. Our Product Owner had an opportunity to gather real-world product feedback from a power-user customer, one who personally demonstrated how he would use our pre-pre-Alpha, but potentially shippable, version of our product. This customer’s feedback subsequently influenced our product backlog for an upcoming sprint - agility in action!
During this whole “customer demonstrating our product to us” segment of the meeting, I was smiling proudly: this was software that we, in comparison to a Waterfall-type release, had essentially “tossed out there”: no code freezes, no bug triage, no end-game QA bug fix cycle. It was product that was the Sprint 4 output from our new Pilot Scrum Team, software that the Team had deemed “potentially shippable”. And it was just that: potentially shippable.
No comments:
Post a Comment