NINE MONTHS
Like many old, boring people, my favorite radio channel in the car is National Public Radio. Since I live in Dallas, TX, my local channel is KERA. Of all the shows in KERA, my favorite is a show called Think With Krys Boyd. Almost each show I listen to leaves an imprint on my mind and modifies the way I think. Perhaps one of the most impact-ful show I heard almost 9 months ago – in October 2016 – How Autonomous Cars Work.
THE SIXTH MINUTE
Around the 6 minute mark of the show, Kris explored a specific question that has been on my mind for 9 months. How might self-driving cars learn to anticipate some common patterns that we as humans have learned to intuitively expect based on what we have seen happen a million times before. For instance, when we drive and see a soccer ball roll onto the road, our intuition tells us that a child is likely to come running behind soon-after and that we should slow down. How might we build software in a self-driving car that can have this kind of intuition?
ONE NIGGLING QUESTION
For the past 9 months, this question has been niggling away at the back of my mind.
The scenario of software in a self-driving car having to respond appropriately to a soccer ball on the road reminded me of many conversations I have had with Ken Schwaber – the co-creator of Scrum and many of my colleagues in the Scrum.org Professional Scrum Trainer Community. With every passing day, software is becoming ubiquitious, permeating almost every aspect of our lives until we don’t even realize it is present. This presents opportunities and challenges.
The opportunities present themselves in our ability to stay connected with each other, and having intuitive software to solve problems which were previously frustrating. The challenges could be that undesirable behavior by the software could have severe and irreversible consequences on the lives and well-being of those impacted by the software. The soccer ball in front of a self-driving car is just one example. There are many more.
So what, you might be wondering…? What;s the big deal…? Let me share a confession…
TO SHIP OR NOT TO SHIP…?
Many years ago, I used to be a Software Development Manager. Whether I worked on a $10M product or a $125M product, one thing was guaranteed – as we approached the release date, there would be too many defects and not enough time. I remember fighting with my QA Colleagues as they detected defect after defect and blocked the release from shipping out, I have been guilty of fighting with them tooth and nail to justify why it was OK to ship.
At the back of my mind was pressure from my management and also the desire to just be done with the damn release, to be done with the death by daily defect triage, so we could just move on and get our lives back. I am not proud of these thoughts, I am just being honest.
It is possible that many other Managers who are in similar shoes today are reacting in similar ways.
IMPLICATIONS FOR SCRUM
The co-creators of Scrum intentionally created a key element in the Scrum framework to disable the practice of shipping software that can harm impacted communities – the Definition of Done. Here are some snippets from the Scrum Guide that explain this term…
Definition of “Done”
When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.
As you read the Scrum Guide, you will notice “Done” being referenced in every section – Theory of Scrum, Roles of Scrum, Events of Scrum & Artifacts of Scrum…
SCRUM THEORY & DEFINITION OF DONE
SCRUM THEORY – TRANSPARENCY: ‘Those performing the work and those accepting the work product must share a common definition of “Done”‘
SCRUM ROLES & DEFINITION OF DONE
THE SCRUM TEAM: ‘Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.’
THE DEVELOPMENT TEAM: ‘The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.’
SCRUM EVENTS & DEFINITION OF DONE
THE SPRINT: The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.
SPRINT PLANNING: ‘Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint.’
- The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
- The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
SPRINT RETROSPECTIVE: ‘During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate.’
SCRUM ARTIFACTS & DEFINITION OF DONE
PRODUCT BACKLOG: ‘Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.‘
SPRINT BACKLOG: ‘The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.’
INCREMENT: ‘At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.”‘
PROFESSIONAL SCRUM
To use Professional Scrum means to create “Done” increments of potentially releasable software at least once every sprint. One of the most important lessons I have learned from Ken Schwaber and my colleagues in the Scrum.org Professional Scrum Trainer Community is that being a Professional means never compromising on “Done” and blocking the release of “undone” software no matter the consequences.
SO WHAT….?
So what does this all mean and how does this impact you…?
The next time you experience pressure to release “undone” software, consider that it could be as risky as releasing untested software for self-driving cars. And that the child running onto the road after the soccer ball could be mine. Or yours.
Be a Professional. Choose wisely.
Comments