DZone
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
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. 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 · Opinion
Like (12)
Save
Tweet
Share
10.14K 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

  • Front-End Troubleshooting Using OpenTelemetry
  • HTTP vs Messaging for Microservices Communications
  • Custom Validators in Quarkus
  • How To Choose the Right Streaming Database

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • 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: