Category: Scrum Caretakery

Posted on by — 2 Comments

A Professional Organization Defines Quality

An often observed problem of Scrum adoptions is the isolated way that Scrum Teams operate, being or acting as if detached from the wider organization. There are several possible causes, one of them being the disconnect between people creating standards and people implementing upon those standards.

An organization that thrives and depends on software products and services can be expected to have a definition of product qualities in place, and to express such through standards, guidelines, rules, service levels and other expectations. Scrum Development Teams, consisting of professional product developers, are an integral part of an organization, rather than being isolated gangs of thug coders within the organization. Such Development Teams can be expected to adhere to overarching product standards.

It explains why, on the topic of the creation of a definition of Done, the Scrum Guide says (see http://www.scrumguides.org/scrum-guide.html#artifact-transparency-done):

“If the definition of “done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product.“

If, as can be expected, the minimal definition of Done is provided by the organization, a Development Team can still complement it with context-specific elements; the product, a release or technology.

If organizational guidelines are not provided, a Development Team should, as professionals, create an appropriate definition of Done for their development. How else does a team know what work to do, what tasks to undertake, if it doesn’t know, and have a shared understanding of, the characteristics of the Done or end product? How else can Product Owners and stakeholders know what quality they will be receiving? Quality should not be their concern, or their primary focus. Market reception, business opportunities, offered functionality should be.

The lack of such standards or provision of them is therefore also best raised within the organization to serve wider organizational improvement. Remember that such improvement will also benefit others within the organization.

Scrum can be a lever for organisational improvement. Scrum Master is a servant-leader role for the organization too.

Often organizations provide a list of guidelines that is presented as ‘minimal’, yet proves to be unrealistically long and heavy. This again is a great area for conversation, improvement and removal of organizational waste. The organization might have not adapted their standards and expectations to the reality of iterative-incremental development, or their standards might for a long time have not been matched against actual implementation of them. ’Standards’ might be in place that were created as part of long, sequential processes where quality problems typically accumulated heavily before they were detected. As the people maintaining standards typically do not engage in creating quality upon those standards they start adding demands to the expectations that prescribe the delivery of proof that ‘quality’ is created. They started confusing defining quality (‘what’) with evidence of quality ‘(how’).

Avoiding the conversation is not helpful. Self-organization is not an excuse to do so. A Development Team might push back toward a realistic definition of Done with arguments on how they will actually build in quality, Sprint after Sprint after Sprint. A feedback loop from practice to theory is best established. It is important, and often surprisingly revealing, for the people creating standards to experience what practical application of these standards entails, or what waste is in them when iterative-incrementally delivering versions of releasable product.

Quality, in the end, is in the product, not in paper documentation. Paper documentation allows lies and illusions of quality, working software doesn’t.

Posted on by — 2 Comments

Scaled Professional Scrum – Nexus (Nederlandstalig)

Op de Scrum.org  website publiceerde ik recent de whitepaper “Scaled Professional Scrum – Rationale of the framework” (PDF).

Hierbij vindt de geïnteresseerde lezer dit document in (een licht aangepaste) Nederlandstalige versie terug als “Scaled Professional Scrum – Whitepaper (Nederlandstalig)”.

Achtergrond:

Scrum is een framework voor complexe productontwikkeling.

  • “Scaled Scrum” omvat elke implementatie van Scrum waarbij meer dan één team een product realiseert.
  • “Scaled Professional Scrum” omvat elke implementatie van scaled Scrum die bouwt op de fundamenten, principes en waardes van Scrum, met inbegrip van software development professionalisme.

Het framework voor Scaled Professional Scrum van Scrum.org biedt de ruggengraat waarop organisaties hun productontwikkeling op basis van Scrum kunnen opschalen mèt behoud van de eigenheid en de voordelen van Scrum. Het framework bundelt de practices, ervaringen en inzichten van een wereldwijd netwerk van experten, waaronder Ken Schwaber en Jeff Sutherland, co-creators van Scrum.

Het kloppend hart van Scaled Professional Scrum is een Nexus, een ‘exo-skeleton’ voor Scrum. Een Nexus implementeert het Scrum proces zodat 3-9 Scrum Teams zo efficiënt mogelijk gezamenlijk aan één product kunnen werken.

Nexus_Titled_Transp

Het Scaled Professional Scrum framework bevat 40+ practices. Elk van deze practices, indien met kennis en kunde geselecteerd en geïmplementeerd, kan de werking van een Nexus optimaliseren naar een specifieke context.

Posted on by — 4 Comments

Introducing Scaled Professional Scrum – Nexus

Scrum is a framework for complex systems development.

  • Professional ScrumScaled Scrum is any instance of Scrum involving more than one team creating and sustaining a product or system.
  • Scaled Professional Scrum is any instance of scaled Scrum that thrives on Scrum’s formal rules and roles, complemented by software development professionalism, and Scrum’s values and principles.

The Scaled Professional Scrum framework of Scrum.org provides guidance to organizations engaging in efforts to scale their product development done through Scrum. The framework cohesively integrates practices, experience and insights gained from efforts to scale Scrum worldwide, including the substantial efforts that involved Ken Schwaber and Jeff Sutherland, co-creators of Scrum.

At the heart of Scaled Professional Scrum is a Nexus, an ‘exo-skeleton’ for Scrum. A Nexus employs the Scrum process to inter-connect 3-9 Scrum Teams building one product.

Nexus_Titled_Transp

The Scaled Professional Scrum framework holds 40+ practices. Each of these practices, if chosen and used against context, augments the operation of the Nexus.

The whitepaper “Scaled Professional Scrum – Rationale of the framework” (PDF) is now available through the Scrum.org website.

At the “Scrum Day Europe” event of July 2 in Amsterdam I introduced the Scaled Professional Scrum framework of Scrum.org and the Nexus in my opening keynote. Find the presentation at SlideShare. The recording of the session is available at YouTube.

Posted on by — Leave a comment

Traces of Scrum (Scrum Days Poland)

On May 28 and 29 the first Scrum Days Poland were organized. A great team made it happen, gently directed by two friends of the Scrum.org trainer community, Kate Terlecka and Tomek Wlodarek. Kate and Tomek were so kind to invite me for two sessions at the event:

  • In the executive track I spoke about ‘Empirical Management’. Find the slide deck at SlideShare.
  • For the main event I was asked to do the closing keynote, which was about ‘Scaled Professional Scrum’. Find the slide deck at SlideShare.

Apart from these sessions, I was asked for some thoughts on Scrum by different people:

1/ On behalf of the organization, Paweł Feliński checked in with me on some topics with regards to Scrum, and the adoption of Scrum:

2/ Leszek Pietrzkiewicz went around asking some people, including myself, to ‘describe’ Scrum in one word:

3/ Leszek Pietrzkiewicz asked me ‘Why do Scrum?’

4/ Andy Brandt, another Polish Professional Scrum Trainer, asked me some questions about Product Ownership, questions he typically gets from the attendants of his PSPO classes:

I applaud the local organizers for setting up such a great conference. I am grateful for being at the conference, meeting people and expressing the above thoughts. Traces of Scrum.

Posted on by — 9 Comments

Done is a crucial part of Scrum, actually

If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a Done Increment in a Sprint. The typical term in Scrum to describe the state of software being releasable is “Done”. All that this state of releasability encompasses is captured in the “definition of Done”.

Done Increments are THE way to achieve agility through the empiricism of Scrum. 

Empiricism

The empiricism of Scrum, the process of regular inspection and adaptation, only functions well upon transparency. Transparency is having insights into reality but is is additionally upheld through standards and agreements, against which inspection and adaptation happens. The definition of Done is such a standard. The definition of Done is part of professional Scrum development. Other standards, like development and engineering standards, might even be derived from the definition of Done.

The frequency of the inspection and adaptation should be high enough to be able to act in the moment yet not too high to preserve the ability to get considerable amounts of work done.

The definition of Done serves empiricism

The definition of Done should be shared, explicit, clear and concise.

A Development Team will use the definition of Done to consider the amount of work to be pulled into a Sprint during Sprint Planning.

The evolution of an Increment is managed via collaborative inspection and adaption of the actual development work against the forecasted Product Backlog and the Sprint Goal; at least on a daily base, possibly sooner. A Daily Scrum assures that the people accountable for the actual development optimize their work plan against new insights and achievements. The definition of Done supports identification of work remaining to get the software to “Done”.

No later than at the Sprint Review, the Increment is collaboratively inspected and adapted with the stakeholders. This inspection opens up the opportunity of incorporating feedback from these stakeholders to identify what is most important to do next. Purpose is the open identification of what is important to do next, not hindered by unknown, unpalatable, unestimatable remaining work.

Releasing the software closes the feedback loop to the market and the users of the software. Releasing sooner is better in order to remain in line with external expectations and experiences. It is the only way to ultimately validate all assumptions (of functionality, and others) built into the product. Not being able to release an Increment at the end of a Sprint, or sooner, impedes agility. The decision of releasing an Increment by the end of a Sprint is a Product Owner decision, as the sole representative of users and stakeholders on the Scrum Team. The Product Owner’s shipping decision should not be constrained by ‘development’ work.

Undone software is best not released. There might be situations in which undone software is consciously released. An extreme crisis maybe? The least to do is make the undone work transparent via Product Backlog, knowing and understanding that any estimate of such corrective work is probably totally off and the nature of the work unplannable. This ‘registration’ does not render an undone release any more professional, and probably the crisis you are hoping to solve with the unrelease, will re-appear because an unrelease will not fundamentally solve it. Unreleases backfire. Probably better to Scrumble.

At the Sprint Retrospective, the Development Team might inspect and revise its definition of Done; incorporating new insights, new expectations, higher standards. Ownership over the Definition of Done lies with the Development Team. It is their accountability to develop software that lives up to the definition of Done. In many organizations the definition of Done is likely to be derived from organizational standards for development quality. A Development Team will enact them, expand them. If “done” for an increment is not a convention of the development organization, the Development Team will create their definition of Done, appropriate for the product.

Regardless, the definition of Done provides transparency over the state of an Increment at the Sprint Review, where this state optimally reflects ‘releasable’.

Done is a crucial part of Scrum, actually

Although no official artifact, the definition of Done is a crucial part of Scrum in upholding transparency over the state of releasability of the software created. No transparency means no meaningful inspections, and no meaningful adaptations of Product Backlog through stakeholder feedback upon review or through user feedback upon release.

In the last updates to the Scrum Guide (most recent: July 2013) the definition of Done was given considerably more attention. Rightfully, as “Done” is absolutely crucial in Scrum.

Here’s how I stressed the importance of Done in my book, “Scrum – A Pocket Guide“:

The empiricism of Scrum only functions well with transparency. Transparency requires common standards to work against and to inspect upon. The definition of done sets the standard for releasable.

 and

The definition of done is essential to fully understand the work needed to create a releasable Increment and for the inspection of that Increment at the Sprint Review. The definition of done serves the transparency required in Scrum in terms of the work to be done and the work actually done.

Posted on by — 3 Comments

Branching Done

I was recently contacted by a senior executive of a mid-sized company that is evolving their product development to Scrum. He explained a situation he had been in and wanted my opinion. He accepted me to share his story here (with some abstractions, and calling him Jim) in an open-ended way, inviting the reader -much like he did- to reflect on the purpose and accountability of the Scrum Master and how that role is needed for… well, many reasons still.

Jim’s company started out doing Scrum on some smaller, carefully contained projects with individual Scrum Teams developing clearly separated products and product areas. Through these projects they discovered how iterative-incremental product development increased transparency, and how disciplined engineering practices allowed them to excel. Where Scrum in the beginning was much seen as mainly for IT people, they soon found out the need for a mandated Product Owner representing the internal business and the user base to the teams. They felt that hiring a Scrum Master with three years of experience had been really helpful.

One of these early projects was recently expanded to two teams. Both teams work on the same product and draw work from one and the same Product Backlog. The Product Owner and the Scrum Master perform their roles for both teams.

Jim contacted me after he was invited to and attended the second Sprint Review after the expansion to two teams.

At this Sprint Review the two teams took 60 minutes each to walk everyone through the software functionality they had created. Each team showed the work from their separated code branch. By the end of the Sprint Review, Jim inquired about releasing the software, but got an unclear answer. In the end it boiled down to the teams promising they would have a look at it, and discuss it with the release department who hadn’t been involved so far.

Jim felt like not straining the teams more but an uneasy feeling had crept in. After all, one of the reasons why they started adopting Scrum were their long release cycles, and unclear release dates. It had led to many customer complaints and even losing a couple of important customers.

When he asked for my advice I told him only I was very interested to hear about the conversation I suggested he set up with the Scrum Master. He seemed a bit surprised when I started talking about the role of the Scrum Master.

How about you? If any, where would you situate the accountability of the Scrum Master in this?

Posted on by — 3 Comments

Scrum, actually

Scrum, actually, has been around for a while. Scrum emerged in the early 1990’s through the work of Jeff Sutherland and Ken Schwaber. They packaged their practices into a cohesive set of rules and roles and named the entirety „Scrum“. The term, actually, was inherited from the ground-breaking 1986 paper The New New Product Development Game. The reference to the game of rugby reflects the importance of team engagement.

Scrum, actually, has had a stable core since its first public presentation in 1995. The essential definition of Scrum was codified in the Scrum Guide in 2010. This definite body of knowledge describes all parts of Scrum, and the rules that tie them together. Scrum is defined as intended and designed, i.e. a cohesive set of rules and roles implementing empiricism for complex product development. The rules and roles described in the Scrum Guide gain full clarity when read as an expression of the Agile values and principles.

Scrum, actually, is intentionally kept low prescriptive. Scrum sets the frame for people, teams and organizations to create, maintain and sustain complex products. Scrum does not replace people’s intelligence and creativity, merely guides the work. Scrum’s basic rules are immutable. Flexibility comes from the zillion variations to apply the rules, selected and tuned to context and circumstances. Hacking the basic rules of the framework breaks the cohesion, and disregards one or more principles and foundations upon which Scrum is founded.

Hacked versions and implementations of Scrum are possible. Isolated use of Scrum’s terminology or practices is possible. They might work. They might be fun. They are not Scrum.

Scaled implementations of Scrum don’t change the fundamental rules and roles of Scrum, nor the underlying principles. They only require different tactics. Instances that change the core of Scrum are not Scrum.

Scrum, actually, in itself is not the purpose. Scrum is a tool. Scrum enables people to live the art of the possible, to make the most out of every single day constrained by their means, to maximize the value of their work in the face of uncertainty. Scrum can wrap many development and organizational practices, tools and techniques. Scrum creates the capability of continuous adaptation in a environment of constant change, regardless whether that change is caused by our own will or by external turbulence. Scrum turns complexity from a threat into an asset.

Scrum, actually, propels agility through releasable Increments of software. A releasable Increment is available by the end of a Sprint or sooner, not later. A Sprint takes no more than 30 days, and is often shorter. Frequently an updated, improved version of software can be made available to its users and consumers. Feedback from actual use can be gathered to drive changes, improvements, enhancements. Assumptions are turned into learnings, ultimately into a pivot if required.

Scrum, actually… is a means to an end, a tool designed for a purpose: people, agility, value.
Posted on by — 10 Comments

Releasable in Scrum, actually

Scrum asks for a releasable Increment of product to be available ultimately by the end of every Sprint. A Sprint takes no more than 30 days, and is often shorter. A releasable Increment might be available sooner than by the end of a Sprint, not later.

The purpose of this rule of Scrum is to provide the Product Owner with the opportunity of bringing an updated, improved version of product to market every 1-4 weeks, or more frequent. It is how Scrum implements the first principle of Agile software development:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (source: Principles of Agile Software Development)

Replacing the past wording of ‚shippable‘ by ‚releasable‘ reduced the room to avoid the rigor of releasing to the market frequently, but just shipping an Increment within the organization, the avoidance that abates the benefits and agility needed. The Scrum Guide adds the prefix ‚potentially’, to clarify that Scrum does not say that every Increment must be released. I prefer to leave this prefix out, because ‚releasable‘ in itself is clear enough. Otherwise “Released” would be required as the Increment’s state by the end of the Sprint.

Scrum lays the actual release decision with the Product Owner, as the representative of all (i.e. internal and external) stakeholders. The Product Owner’s decision is not to be limited by technical or engineering aspects. The product Increment is useable. If released, it does not break. That is the accountability of the Development Team. The Product Owner is accountable for assessing whether the Increment is functionally useful.

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. Only members of the Development Team create the Increment. (…) This Increment is useable, so a Product Owner may choose to immediately release it. (Source: The Scrum Guide)

A Product Owner, being an entrepreneur, understands that no release means no feedback from the market place, no feedback from actual product usage. It means no validation of the assumptions built into the product, reduced learning, postponement of much anticipated improvements. In a way, it blindfolds development.

If a Product Owner decides to release an Increment, it is released. Preferably instantly. No additional work remains to do so. All work that mirrors ‘releasable’ is captured in a definition of Done. Defining “Done” creates transparency:

  • Transparency when forecasting work deemed feasible for a Sprint
  • Transparency when inspecting an Increment
  • Transparency over development progress
  • Transparency regarding the daily work required to have the software in a state of Done

Scrum, as a framework, can wrap various development strategies that increase the capability of creating a releasable (“Done”) version of product in a Sprint; pair programming, test-driven development, ATDD, BDD, Continuous Integration, DevOps, Continuous Delivery, Continuous Deployment. (note: Scrum promoting the Product Owner as the gatekeeper to release might influence how Continuous Deployment is organized.) Feature toggling is certainly an architectural choice that enables higher Product Owner dynamism.

Software being releasable, no later than by the end of a Sprint, is Scrum’s gateway to (business) agility. By the end of every Sprint, or sooner, an updated, improved product can be released to its users and consumers. Feedback can then be gathered to be incorporated into the Product Backlog, and ordered against all other product ambitions.

In Scrum, actually… releasable means all work done to release to the market. Instantly.
Posted on by — 5 Comments

Agile and Scrum, actually

In early 2001, with the creation of the Manifesto for Agile Software Development, the adjective ‘agile’ obtained a specific meaning in the context of software development. The manifesto, commonly known as the Agile Manifesto, holds 4 value statements with 12 principles behind it. In these values and principles the signatories of the manifesto captured the mindset, the DNA, common to their approaches to software development.

Over the years to follow, Agile became a proper noun, capitalized, pretty popular and ultimately big business as the methods for Agile software development were increasingly adopted. Success obfuscates and diminishes actionability, it seems. Today “Agile” is all over the place; coming in many flavors, wrappings, definitions, interpretations, and discounted. “Agile” sells. It is probably the most used prefix for roles, jobs, positions, functions and phases found in the software industry. The fact that Agile is a set of values and principles is easily ignored, as are the actual values and principles themselves.

Correlating ‘scaling’ to Agile has a similar neglect. Tactics change with scale. Strategies change with scale. Values and principles don’t change with scale. Claims and statements on the need, the ability, the inability, the whatever to scale Agile are plainly besides the point. Values and principles are agnostic of scale.

Agility, as an extension of Agile, refers to the state that people, teams, organizations hope to achieve by adopting Agile development processes. Agility, as such an extension, is a state of high responsiveness, speed and adaptiveness; a state of constant invocation of change, evolution and improvement. A state of agility enables people, teams, organizations to better deal with the natural complexity and unpredictability of the work of software development itself, the organizational context within which it happens and the external circumstances faced. The adoption of Agile indeed is an important foundation for this (business or enterprise) agility.

Scrum emerged in the early ’90s from the work of Jeff Sutherland and Ken Schwaber. They formalised and turned Scrum into a cohesive set of rules and roles for complex product development, that was formally presented to the public for the first time in 1995. The definition of Scrum, its rules and roles are described in the Scrum Guide. Both co-creators of Scrum are signatories of the Agile Manifesto. The values and principles of the Manifesto for Agile Software Development underpin the Scrum framework which thrives on empiricism and self-organization. Scrum is better understood when seen through the lens of the Agile Manifesto.

As with Agile, the Scrum Values and Scrum’s fundamental roles and rules as described in the Scrum Guide don’t change with scale. But scaled implementations of Scrum require different tactics in implementing the rules.

In Scrum, actually… Agile is the DNA driving the behavior throughout the software development ecosystem.

Agile and Scrum, actually, are two inseparable ingredients in a software development ecosystem.

Posted on by — 2 Comments

Meetings in Scrum, actually

Scrum has no meetings, actually. What we call ‚meetings‘, even in the Scrum Guide, are planned occasions at which people meet, where meeting (the activity) takes place.

Scrum’s meetings are not about reporting, status, bureaucracy, spilling ink, documenting the past. Scrum’s meetings have a purpose. Scrum’s meetings are about collaboration, discovery, opportunities, conversation, ideas, constructive disagreement, looking forward to the (near) future. It’s why Scrum offers opportunistic events more than obliges (what we generally know as) ‘meetings’.

Scrum’s events provide people with an opportunity to incorporate change into the daily work, instead of locking it out. The old notion of ‚change’ dissipates. Change becomes natural, the regular way of doing business, even a welcome source of ideas and innovation. Change is used in a team’s or an organisation’s advantage.

Scrum’s events serve the empiricism that Scrum brings to software development. Empiricism thrives on inspection & adaptation. Inspection & adaptation happens at a frequency, in regular intervals. Adaptation only makes sense when inspection is done against reality, when the actual situation is made transparent.

  • Scrum’s events define the frequency at which inspection and adaptation takes place.
  • Scrum’s artifacts hold the primary information to inspect and adapt.
  • Scrum’s teams are the inspectors, the people accountable for performing the inspections and adaptations.

Empiricism in Scrum

In Scrum all work is organized in Sprints. Sprints deliver releasable Increments of software. A Sprint is a time-boxed feedback loop in itself, a container event containing the above Scrum events.

Deciding over Sprint length is a different decision from the perspective of inspection and adaptation. The Sprint length determines the frequency at which stakeholder input is formally gathered and shared with the full Scrum Team. It’s the minimal frequency at which organizational or market changes can be incorporated, the last possible moment to decide on releasing software to collect feedback so it can be adapted to, to decide what the most valuable work is to work on next. When Sprints are too long, important opportunities that require adaptation may be missed. When Sprints are too short, the ability to get significant work done might be lost.

The time-boxes for all events, as set by Scrum, provide focus. It avoids the creation of waste. It focuses people’s minds on collaboration and importance.

Scrum frames the creativity of people. Scrum provides boundaries that re-inforce self-organization. Scrum says not how to run the events. Scrum defines the input to the meetings, the expected outcome and a timeframe.

In Scrum, actually… meetings are opportunities where people meet to change their mind.