In July 2016, the Scrum Guide was updated to include the five “Scrum Values” of commitment, courage, focus, openness, and respect. This addition was the only change, and the first one in three years, reflecting the significance which had come to be afforded to those values by that time. By making them explicit, it was hoped that teams would challenge their ways-of-working with greater confidence. These values represent a sort of moral compass, and hence a clear enumeration of them might improve decision-making.

Unfortunately, when compared to the nuts-and-bolts advice in the Guide concerning Scrum events, artifacts, and roles, a treatment of “values” is somewhat likely to be glossed over by readers. Values are perhaps rather too intangible and touchy-feely to elicit serious consideration or reflection on the part of team members. On top of which, don’t most of us like to think we’ve got this “values” stuff nailed anyhow? We freely recognize that there are other less moral people in our orbit who fail to live up to them. We, however, are virtuous. On those occasions when - arguably - we might not observe such values as scrupulously as we would wish to, practical constraints or pressures can be cited in our defense as just cause. While we wish for openness, for example, we also understand the occasional need for secrecy. We feel justified in writing ourselves a pass on "values" in the name of greater pragmatism. Isn’t the interpretation of all this “values” stuff just a matter of opinion anyhow?

The first of the Scrum values, commitment, is as prone to mishandling as any other. It can be interpreted so freely within an organization that it effectively becomes debased. For example, teams do not always own their development process and are often unable to bring a Sprint Backlog to completion without dependency or impediment. How then, can they commit to delivering anything of substance? Furthermore, the strength of product ownership may be weak. A team may sometimes be expected to commit to product outcomes while simultaneously providing cover for unrelated and unforeseeable support and maintenance work. What happens to their product commitment when major incidents then arise? The work planned into the time-box is no longer managed and curated by the team, but driven reactively by events. Any commitment to delivering a release-quality increment is essentially faked. Team members become party to this scandal on the grounds that this is the best they can do under the circumstances. Their “commitment” is no more than pixie dust.

In the release notes of the updated Scrum Guide, we are reminded that "People personally commit to achieving the goals of the Scrum Team." Commitment then is perhaps best seen as a quality to be demonstrated by individuals as team members, rather than abstracted away as a generalized team concern where it may find little traction. Ironically, however, attempts to improve any sense of commitment towards meeting a shared Sprint Goal may be derided as being “unagile.” In a dysfunctional environment, it may instead be the anti-pattern of uncommitment which is held to be exemplary. Shouldn’t team members be flexible about their commitments, it is argued, and shouldn’t they always be prepared to turn on a dime? Isn't that being agile?

The thing to remember is, commitment provides the very anchor point around which agile plans and forecasts may flex. That's why a Sprint Goal cannot be allowed to change during a Sprint while the Sprint Backlog, as a forecast of work for meeting the goal, may be replanned as needed. Commitment matters. Bear in mind that people are likely to be held to an original “commitment,” such as project work, even when they are subsequently expected to work on something else like a priority incident.

Where uncommitment reigns, little of substance is likely to be achieved by the end of a Sprint. Instead, each time-box marks the dreaded beat between one forsaken goal and another.

Uncommitment is Antipattern of the Month at agilepatterns.org

Uncommitment

Intent: Allow unplanned work into a timebox.

Proverbs: The sluggard who does not sow in season does not reap at the harvest.

Motivation: Team members who do not value the Product or Sprint Goal, or who are allowed to accept other priorities, may be tempted to admit unplanned work into a Sprint. This can include work from forceful parties which the Product Owner does not value. Product Owners who do not value the Product or Sprint Goal can themselves be tempted to trade unplanned work into a Sprint Backlog to the detriment of value produced.

Structure: Team members collaborate with each other in a workstream. The workstream may encompass either Business As Usual activities or project work delivered in multiple Sprints with Sprint Goals. However, product ownership will be weak and any Sprint Goals may be unclear. Team membership may be ill-defined and/or the backlog may not be respected by them.

Applicability: Clear goals and the careful management of time-boxes are central to Agile methods such as Scrum and DSDM. Business As Usual work can encourage uncommitment in so far as there may be no time-boxed goal to commit to. As such, Kanban teams can face unique challenges regarding product ownership, the replanning of work, and team commitment to any forecasts made.

Consequences: A Product Owner who does not value the product will have little incentive to help teams formulate Sprint goals, or to exert pull on a team for delivery. Team purpose and/or discipline will, therefore, be compromised. Sprint Goals may not be met, or the value delivered may be less than that expected. 

Implementation: Uncommitment can take either of two forms: uncommitment by the team to a forecast backlog of work, or uncommitment by a product owner to the product being delivered. The result is the same in either case: the planned backlog will be compromised and the expected value is unlikely to be delivered.

See also: Time Theft, Unbounded Team