Scrum language: Delivery and Sprint Boundary
Executive summary: Introducing the terms “Delivery Team” and “Sprint Boundary”, in order to help to understand and adopt the Scrum framework.
“Evolutionary adaptation, or simply adaptation, is the adjustment of organisms to their environment in order to improve their chances at survival in that environment.”
Evolution is not limited to biology. Adaptive changes happen in human culture and society all the time. It is the way forward. As such, language is also constantly evolving. Application is one of the triggers of adaptation; this can be nabbed quite well with professional terminologies.
Development vs Delivery
Scrum started as a team level agile framework for software development. Accordingly, groups doing the actual work within the Scrum teams were (and are) called Development Teams. The success of the framework inspired other professional fields to try Scrum. Their teams have taken over not only the mindset and the practices but the lingo too. Many beneficiaries from other knowledge works such as in Marketing, Design, Procurement, or HR for example are not necessarily doing any development in the traditional IT sense of the word.
Thus, the terms “Development” and “Development Team” are not universal enough anymore for the Scrum world of today. Also, those only getting familiar with Scrum might feel the term “Development” off-putting, even scary, if they cannot find something relatable in their own trades.
To resolve this, I use the terms “Delivery” and “Delivery Team” in my practice. I do think that this minor tweak of the jargon is something that makes Scrum sound more familiar for people outside IT and R & D, and helps them get acquainted with the framework quicker.
Sprint Boundary Events
Another terminology that I have been using in Scrum training sessions and live implementations as well is “Sprint Boundary” and “Sprint Boundary Events”.
On the one hand, the Sprint is the container Event for the other four Scrum Events: the Sprint Planning, the Daily Scrums, the Sprint Review, and the Retrospective. Thinking of the Events in this sequence helps to understand the significance of the Sprint itself: its time box is constraining the maximum time it takes to close the feedback loops on both the content delivered and the way the team delivers it.
On the other hand, what the Scrum Team experiences in their everyday work is that they start the delivery just after the Planning, and they stop to inspect and adapt when the Review starts. The Review, the Retro, and the Planning for the next Sprint follow each other gapless, in the sense that no delivery can happen between these Events. These Events form a tight group around the border of two consecutive Sprints. The name Sprint Boundary Events puts emphasis on the importance of this gapless continuation, strengthening the notion of the flow structure of the framework. Also, this naming puts a bit more individual focus on these Events.
Building on Peter Stevens’ Train and Track metaphor [1], we can think of the Delivery Teams of an organization as groups constructing trains and operating them in order to serve the passengers, while the rest of the organization is responsible for creating the infrastructure (tracks) for them so that the teams can make faster trains and serve their customers better. Scrum is part of the infrastructure and you can think of the Sprint Boundary as the railway switch: A major opportunity to inspect if we’re heading in the right direction and to change if need be.
Adapting language to its environment is often necessary to further the common understanding and applicability of concepts, thus helping the spreading and thriving of these notions. In this spirit, Scrum’s ongoing evolution should be reflected in its terminology too.
References
- Peter Stevens, Is your agile transition building a train but ignoring the track?, 2019
No Comments