DZone
Agile Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Agile Zone > Antipattern of the Month: Uncommitment

Antipattern of the Month: Uncommitment

If a team is new to Scrum, getting them to commit to the process can be hard. But commitment is a crucial part of the development process.

$$anonymous$$ user avatar by
$$anonymous$$
CORE ·
Sep. 01, 17 · Agile Zone · Opinion
Like (12)
Save
Tweet
9.81K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Image title

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

scrum agile Sprint (software development)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Making Machine Learning More Accessible for Application Developers
  • A Guide to Understanding Vue Lifecycle Hooks
  • How Does the Database Understand and Execute Your Query?
  • Best Practices for Resource Management in PrestoDB

Comments

Agile Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo