White Paper
© 2003-2019 Gunther Verheyen – Ullizee-Inc, All Rights Reserved
(adapted from “Scrum - a Pocket Guide”)
What better risk mitigation strategy than the frequent inspection of tangible, observable work results? What better base for informed management decisions than reviewable versions of product? The time-boxing of Scrum makes us perform such observations regularly allowing us strategic decisions regularly. We prevent risks from materializing rather than managing them.
Scrum establishes an iterative-incremental continuum. This sheds not only a different light on how work is performed, but also on how risk is perceived, and tackled.
In Scrum all work is organized in time-boxed Sprints. Sprints are slices of time with a fixed start and a fixed end date. There are many advantages to the technique of time-boxing. A Sprint is a container that shields its inhabitants from external distractions. It maximizes focus on getting enough work completed. The time management technique of time-boxing bounds focus with regular reflections so lessons learned can be incorporated from one Sprint to the next. It helps establish a situation of more continuous flow across Sprints, while keeping open the opportunity to absorb more disruptive changes in-between Sprints, or willingly and radically change course towards new or more value in a next Sprint.
The tangible objective of Scrum is to create valuable, working versions of product (called Increments) no later than by the end of a Sprint. All development work is reorganized to optimize our ability to respond to and capitalize on business opportunities.
‘Value’ is the answer to user, market and business demands and the overall measure of progress and success. Value is an internal assumption until a product version is actually released to the marketplace. Releasing to the marketplace regularly is the only way to capture and adapt to feedback and signs of appreciation, or lack there-off, of the marketplace. Value is optimized across Sprints. Although value cycles might exist that span several Sprints, this does not lower the ambition of creating Done Increments no later than by the end of a Sprint. Technical risk, i.e. risks related to the actual implementation, is controlled by producing working Increments within a Sprint (not: across) based upon defined and agreed development and quality standards.
Bear in mind that, certainly in an IT context, risk is typically defined as something technical (Will the system perform? Is the system scalable?). It covers the aspect of a product being technically solid enough to be usable (Will it hold? Not break?). But a mere technical or development perspective on risk ignores the fact that the ultimate goal of Agile development is to provide greater satisfaction with end-users and customers, to ensure that the products are useful. A product being usable is just the beginning. Agile should enable us to focus primarily on the business aspects of ‘Risk.’
Any proper development process should address the risk of not being able to capitalize on unforeseen and previously unknown market opportunities, of not releasing product fast enough, of being subject to customer dissatisfaction, e.g. by releasing untested versions, the risk of releasing functions that are not what users expect or appreciate, the risk of lagging behind with regards to the competition.
Development in Scrum is best organized in a way that maximally mitigates that business risk. High-value needs are answered first. Product versions and updates are released quickly and frequently. They satisfy existing needs as well as include unexpected, innovative functions. They get users to pay for the product and optimize the stakeholders’ return. They are of high quality in order to minimize maintenance and support and optimize the Total Cost of Ownership (‘TCO’).
Scrum does not ignore the value of the regular IT activities (in the figure coarsely represented as “Analyze”, “Design", “Code” and “Test/Integrate"). But Scrum requires breaking up their sequential organization to a more dynamic approach against the ambition to realize benefits fast, and frequently. To produce releasable versions of product, no later than by the end of a Sprint, the work activities are structurally reorganized into concurrent development. The different types of typical activities are executed concurrently with daily replanning and re-alignment via the Daily Scrum. The goal is to enable flexibility and speed instead of blocking them. All disciplines are performed in a non-linear, incremental way, concurrently and on a daily basis, by cross-skilled teams with continuous collaboration and negotiation about emergent ideas, techniques and practices.
The goal of such an integrated, cross-functional approach is to build-in quality and to prevent defects, rather than attempt to establish quality by a bug hunting approach in a post-creation phase. It is imperative to turn the desire to release regularly into the actual ability of doing so, and firm up your ability to go to market, often and reliably. Quality cannot be added to a finished product. Delays and budgets grow well out of hand when a lack of quality is identified once the actual creation process is over.
It might take some time to experience the fact that the continuous learning from actual work results, innate in Scrum, actually increases control amidst turbulent enterprise, business and market circumstances. It is certainly a lot more effective than academic risk mitigation strategies and managed risk lists, that offer no more than an illusion of control.
It might take some time to shift the focus of management away from a predicted approach to risks and a feeling of security via judgments of the past, e.g. via actuals and time registrations. It might take some time to gain confidence from optimizing and releasing business value through valuable outcomes of time-boxed Sprints. It does take experiencing Scrum rather than considering Scrum or breaking Scrum to fit old structures.
(Note: this article was adapted from the chapter “1.4 the iterative-incremental continuum” from the 2nd edition of my book “Scrum - A Pocket Guide”).
