¶94 Product Wake
All good things must come to an end.
...your product has striven to succeed and may even have enjoyed a long life—or perhaps not—but in any case, the ¶7 Scrum Team has achieved the ¶39 Vision or its relevance is past, or it becomes obvious that the product will not achieve its Vision, or people agree that the Vision is so misplaced as not to further pursue it.
Killing off products is often what organizations are worst at. Few living things are immortal, and the cycles of nature ultimately bring great works back to the dust from which they arose.
People become invested in their creations, almost as if they were their children, born out of love and noble aspirations. This happens at the level of individual visionaries (like ¶11 Product Owners) but also at the level of entire enterprises or communities (like the Saturn automobile, or the Philadelphia Giants, or Nokia, or the Lisp programming language). It’s always possible to put enough energy into a system to fight entropy, but at some point, the energy and cost expended aren’t worth the limited harmony that the product contributes to the environment.
You’d like products to last forever, but growth leads to clutter, and humanity learns in jumps and stages that usually leave the creations of human endeavor obsolete. You could perpetuate them into the future but the benefit and utility sometimes don’t cover the pain and effort to sustain them.
And endings can be painful. To end a product is to bring an end to the livelihood of many. The demise of a product can leave the bereaved in a state of denial, and closure comes hard. Yet to heroically strive to keep the product afloat is usually futile and results in repeated increments of layoffs and death by a thousand cuts.
Often, when ¶89 Value Areas diversify within a product or as the result of a ¶90 Value Stream Fork, a product’s demise might give rise to its own successor. Even though the product may disappear along with its old identity, the market need may persist.
Therefore: At the end of its life, give a product a decent burial. Bring development efforts to closure with finality and dignity. Keep everything transparent so that the demise unfolds in line with stakeholders’ expectations. Create a transition of good grief.
Hold a retrospective to reflect on the product’s place in history and to archive key learnings. One wonders if NeXT (a company founded by Steve Jobs in 1985) consciously archived the technology that would pop up in Apple a few months later. If there are bright spots in the product’s history worth celebrating, by all means celebrate them.
Scrum doesn’t say when to kill a product’s development, but it does tell us that the Product Owner is accountable for value. The Product Owner should be the final decision point, though the need here is strong for as broad a consensus as possible. ROI is one consideration. And timing is everything: it’s good to kill a product before it ends a slide into negative value from which there is no return. Data, forecasts, and analytics can help, but it is not easy to dismiss the valid place of feeling and experience in these decisions.
Google in particular has been good at killing off low-value lines of business, such as Google Video, Google Desktop, Wave—no fewer than thirty-seven products at this writing. This is not to say that they maintain only a nose-to-the-grindstone, near-term profitability focus—they continue to explore self-driving cars, energy-producing kites, and a host of other high-risk ventures.
Death isn’t always about killing: in the norm, it’s an everyday part of life. Sometimes what were once good products simply come to the end of their useful life. Customized software to support a town festival is retired after the festival is over. Such ends-of-the-road are particularly worth celebrating and reflecting upon.
Try to bring finality to the demise. Be done and move on. This pattern is named for the ceremony that the team might hold to bring the demise to closure, and such a ceremony can help a team and its people move on. Look for opportunities to apply the talent in new or existing products—both the Product Owner and ¶19 ScrumMaster have responsibilities here, to support the individuals on the team and help them to their transition to a new station in life.
That a product comes to its end doesn’t necessarily imply that its Scrum Team will split up. Teams often stick together across product developments within a corporation and sometimes across companies. See ¶15 Stable Teams.
¶53 Money for Nothing has much in common with this pattern, because it might bring development to a “premature” end in light of optimizing overall value. See also ¶125 Failed Project Wake.
Footnotes
- [38]
-
Bill Gates. Interview. Academy of Achievement. http://www.achievement.org/autodoc/page/gat0int-1, 2010 (accessed 27 August 2016).
- [39]
-
Carl Hofman. “Elon Musk Is Betting His Fortune on a Mission Beyond Earth’s Orbit.” Wired.com, http://www.wired.com/2007/05/ff-space-musk, 22 May 2007 (accessed 27 August 2016).
- [40]
-
Julie Johnson and Dana Hull. “Musk’s SpaceX returns rocket for perfect upright landing.” In The Seattle Times, http://www.seattletimes.com/business/boeing-aerospace/musks-spacex-returns-rocket-for-perfect-upright-landing/, 22 December 2015 (accessed 27 August 2016).
- [41]
-
Tonys Chocolonely Annual Report. https://tonyschocolonely.com/storage/configurations/tonyschocolonelycom.app/files/jaarfairslag/2017-2017/tc_jaarfairslag_2016_en_totaal_01.pdf, 2017 (no longer accessible; accessed 6 June 2018).
- [42]
-
Jake Knapp (Google Ventures) et al. “The Design Sprint.” http://www.gv.com/sprint/, n.d., no permalink, accessed 2 November 2017.
- [43]
-
Ken Schwaber. “Sprint Burndown.” Web.archive.org, http://web.archive.org/web/20010503112119/www.controlchaos.com/sburndown.htm, May 2001 (accessed 2 November 2017).
- [44]
-
Jeff Sutherland and Ken Schwaber. The Scrum Guide. ScrumGuides.org, http://www.scrumguides.org (accessed 5 January 2017).
- [45]
-
Wikipedia. Orienteering. https://en.wikipedia.org/wiki/Orienteering, July 2018, access 11 August 2018.
- [46]
-
John Thomas and Ashish Kumar. “Google’s Scaled Trunk-Based Development.” PaulHammant.com, https://paulhammant.com/2013/05/06/googles-scaled-trunk-based-development/ (accessed 2 November 2017).
- [47]
-
“Challenger Explosion.” The History Channel. http://www.history.com/topics/challenger-disaster, n.d. (viewed 14 August 2018).
- [48]
-
Alistair Cockburn. “Origin of the term Information Radiator.” Alistair.cockburn.us, https://staging.cockburn.us/origin-of-the-term-information-radiator/, August, 2017 (accessed 8 June 2018).
- [49]
-
Wikipedia, “Wideband Delphi.” Wikipedia, https://en.wikipedia.org/wiki/Wideband_delphi, September 2017 (accessed 2 November 2017).
- [50]
-
Bourree Lam. “The Wasted Workday.“ In The Atlantic, 4 December 2014, https://www.theatlantic.com/business/archive/2014/12/the-wasted-workday/383380/ (accessed 2 November 2017).
- [51]
-
James Grenning. “Planning Poker or How to avoid analysis paralysis while release planning.” https://wingman-sw.com/papers/PlanningPoker-v1.1.pdf, 2002 (accessed 2 November 2017).
- [52]
-
James Grenning. “Planning Poker or How to avoid analysis paralysis while release planning.” https://wingman-sw.com/papers/PlanningPoker-v1.1.pdf, 2002 (accessed 2 November 2017).
- [53]
-
“Agile Practices Timeline.” AgileAlliance.org, https://www.agilealliance.org/agile101/practices-timeline/ (accessed 2 November 2017).
- [54]
-
“The impact of agile quantified.” ProjectManagement.com, http://www.projectmanagement.com/pdf/469163_the-impact-of-agile-quantified.pdf, n.d. (accessed 13 November 2016).
- [55]
-
Russel L. Ackoff. “Thinking about the future.” Blogs.com, http://ackoffcenter.blogs.com/ackoff_center_weblog/files/ackoffstallbergtalk.pdf, 2005 (accessed 2 November 2017).
- [56]
-
“Hawthorne Effect: interpretation and criticism.” Wikipedia, http://en.wikipedia.org/wiki/Hawthorne_effect#Interpretation_and_criticism, May, 2018 (accessed 8 June 2018).
- [57]
-
Jeff Sutherland and Ken Schwaber. The Scrum Guide. ScrumGuides.org, http://www.scrumguides.org (accessed 5 January 2017).
- [58]
-
Jeff Sutherland. “Enabling Specifications: The Key to Building Agile Systems.” ScrumInc.com, https://www.scruminc.com/enabling-specifications-key-to-building/, 2 June 2012 (accessed 5 January 2017).
- [59]
-
“Design structure matrix.” Wikipedia, https://en.wikipedia.org/wiki/Design_structure_matrix, 17 February 2016 (accessed 2 November 2017).
- [60]
-
Jeff Sutherland and Ken Schwaber. The Scrum Guide. ScrumGuides.org, http://www.scrumguides.org (accessed 5 January 2017).
- [61]
-
Jeff Sutherland and Ken Schwaber. The Scrum Guide. ScrumGuides.org, http://www.scrumguides.org (accessed 5 January 2017).
- [62]
-
Richard Kronfält. “Ready-ready: the Definition of Ready for User Stories going into Sprint Planning.” Blogspot.dk, Oct. 2008, http://scrumftw.blogspot.nl/2008/10/ready-ready-definition-of-ready-for.html (accessed 1 November 2017).
- [63]
-
Jeff Sutherland and Ken Schwaber. The Scrum Guide. ScrumGuides.org, http://www.scrumguides.org (accessed 5 January 2017).
- [64]
-
“Velocity vs [sic.] Load Factor.” C2.com, http://wiki.c2.com/?VelocityVsLoadFactor, 16 Feb. 2000 (accessed 19 June 2017).
- [65]
-
Jeff Sutherland and Ken Schwaber. The Scrum Guide. ScrumGuides.org, http://www.scrumguides.org (accessed 5 January 2017).
- [66]
-
This simulation was a predecessor of: John Sterman, David Miller, and Joe Hsueh, “CleanStart: Simulating a Clean Energy Startup.” MIT Management, Sloan School, Leading Edge, https://mitsloan.mit.edu/LearningEdge/simulations/cleanstart/Pages/default.aspx, accessed 1 April 2019.
- [67]
-
Parkinson’s Law. Wikipedia, https://en.wikipedia.org/wiki/Parkinson's_law (accessed 2 November 2017).
- [68]
-
Jeff Sutherland and Ken Schwaber. The Scrum Guide. ScrumGuides.org, http://www.scrumguides.org (accessed 5 January 2017).
- [69]
-
Ward Cunningham. “EPISODES: A Pattern Language of Competitive Development.” http://c2.com/ppr/episodes.html, ca. 1995, accessed 17 April 2018.
- [70]
-
Lord Baden-Powell. BiographyOnline.net, http://www.biographyonline.net/humanitarian/baden-powell.html (accessed 9 June 2018).
- [71]
-
Manifesto for Agile Software Development: Principles. Agilemanifesto.org, http://agilemanifesto.org/principles.html, 2001, accessed 23 January 2017.
- [72]
-
Chuck Rossi. “Rapid release at massive scale.” In Facebook Code, https://code.fb.com/developer-tools/rapid-release-at-massive-scale/, 31 August 2017 (accessed 4 October 2018).
- [73]
-
“Google Chrome.” Wikipedia, https://en.wikipedia.org/wiki/Google_Chrome#Pre-releases, 6 June 2018 (accessed 9 June 2018).
- [74]
-
Wikipedia: Elephant in the room. https://en.wikipedia.org/wiki/Elephant_in_the_room (accessed 28 January 2019).
- [75]
-
Chris Matts. “Why business cases are toxic.” The Risk Manager, https://theitriskmanager.wordpress.com/2017/08/20/why-business-cases-are-toxic/, 20 August 2017, accessed 7 April 2018.
- [76]
-
David Glance. “The psychology behind Apple’s fans. Blind loyalty or just wanting to belong?” The Conversation, https://theconversation.com/the-psychology-behind-apples-fans-blind-loyalty-or-just-wanting-to-belong-31671, 14 September 2014 (accessed 9 July 2019).
- [77]
-
“Haste Makes Waste: When You Over-Staff to Achieve Schedule.” Compression Quantitative Software Management, n.d. (before 2012), http://www.qsm.com/risk_02.html (accessed 12 April 2017).
- [78]
-
Carl Erickson. “Small Teams Are Dramatically More Efficient than Large Teams.” https://spin.atomicobject.com/2012/01/11/small-teams-are-dramatically-more-efficient-than-large-teams/, 11 January 2012 (accessed 13 April 2017).
- [79]
-
Henrik Kniberg. “Spotify Engineering Culture Part 1 (Agile Enterprise Transition with Scrum and Kanban).” YouTube.com, https://www.youtube.com/watch?v=4GK1NDTWbkY (accessed 28 January 2019).
- [80]
-
Cesário Ramos and Sandra Roijakkers. “Thales Surface Radar Case Study.” Less.works, https://less.works/case-studies/thales-surface-radar.html, 2015 (accessed 2 November 2017).
- [81]
-
Korn Ferry Institute. “The Happiness Metric.” Briefings Magazine, 11 May 2012, http://www.kornferry.com/institute/423-the-happiness-metric (accessed 17 February 2017).
- [82]
-
John Hagel, John Seely Brown, Alok Ranjan, and Daniel Byler. “Passion at work: Cultivating worker passion as a cornerstone of talent development.” Deloitte.Com, Deloitte University Press, https://www2.deloitte.com/insights/us/en/topics/talent/worker-passion-employee-behavior.html, 7 October 2014 (accessed 2 November 2017).
- [83]
-
Jacob Shriar. “Why Measuring Employee Happiness Is A Huge Mistake.” OfficeVibe.com, https://www.officevibe.com/blog/measuring-employee-happiness-huge-mistake#fn-5054781-1, 2 August 2015 (accessed 17 February 2017).
- [84]
-
Christiaan Verwijs. “Agile Teams: Don’t use happiness metrics, measure Team Morale.” Agilistic.nl, http://blog.agilistic.nl/agile-teams-dont-use-happiness-metrics-measure-team-morale/, April 2014 (accessed 2 November 2017).
- [85]
-
John Hagel, John Seely Brown, Alok Ranjan, and Daniel Byler. “Passion at work: Cultivating worker passion as a cornerstone of talent development.” Deloitte.Com, Deloitte University Press, https://www2.deloitte.com/insights/us/en/topics/talent/worker-passion-employee-behavior.html, 7 October 2014 (accessed 2 November 2017).
- [86]
-
“The Scrum Guide: An interview with Jeff Sutherland.” StickyMinds.com, https://www.stickyminds.com/interview/scrum-guide-interview-jeff-sutherland, 21 October 2014 (accessed 2 November 2017).
- [87]
-
Jeff Sutherland. “Agile Performance Reviews.” JeffSutherland.com, http://jeffsutherland.com/2006/11/agile-performance-reviews.html (accessed 27 January 2019).