Manage Objectives, Actions, and Uncertainty in Scrum

Loving Kindness and Wisdom

16 September 2013

Glen Wang
Ericsson


This article provides a simplified and commonsense perspective to understanding Scrum.

Everything in Scrum can be summarized this way:

Manage.jpg
 
This model associates common sense and general work/life experience with Scrum. Common sense is always a part of Scrum. Common sense rules all. Use common sense when rules are at odds with your particular context at any given time. It boils down to this: objectives, actions, and uncertainty need be managed.

The common sense of objectives:
  • You need have objectives, and you should own your objectives. In the old way of working, only the project manager knew the objectives clearly; team members just followed instructions from the project manager. In Scrum, objectives are transparent to everyone and are typically in the form of the product backlog. The Scrum team as a whole owns the objectives, but the product owner is the focal point for managing objectives, as a father manages objectives for his family.
  • Objectives are about values created by people, and they serve people. That's why the Agile Manifesto stresses individuals and interactions, working software, and customer collaboration. It's about the kindnesses that people do for people.
  • Objectives need refinement. Objectives can't be written at one time. That's why Scrum has user story writing workshops and product backlog refinement events.
  • Objectives need to be broken down. Epics are split into stories. Stories are split into tasks. The product backlog is split into a series of sprint backlogs. The sprint backlog is the output of sprint planning.
  • Objectives need be verified. The product increment is the implementation of the sprint goal and the Definition of Done. All of these are verified in the sprint review.
The common sense of actions:
  • What: You need understand exactly what to do. The sprint backlog is what to do in Scrum.
  • When: You need understand exactly when to do. The sprint itself as a timebox is when to do in Scrum.
  • How: You need understand exactly how to do. The team is cross-functional, so it has the skills for how to do. It is self-organizing, so it can manage to do without instructions from others. And the team is adaptive and responsive to changes.
  • Why: You need bear in mind why to do. Progress is always monitored toward the sprint goal. This is the first purpose of the daily Scrum.
The what/when/how/why to do is the wisdom to implement the objectives. The self-discipline in it increases the chance of the objectives' completion. As another side of wisdom, we have to consider uncertainty.

The common sense of uncertainty:
  • Every activity includes uncertainty. The team inspects every activity, including sprint planning, the sprint itself, the daily Scrum, sprint review, and retrospectives.
  • Uncertainty needs to be managed. The ScrumMaster's responsibility is to make sure the team always inspects and adapts. An individual's uncertainty-management mind-set is his/her inner ScrumMaster.
  • The possibilities and consequences of uncertainty need be managed quantitatively. The daily Scrum is a chance for uncertainty management and replanning every day. The purpose of such quantitative uncertainty management is to make sure the sprint goal has a better chance of being achieved. This is the second and most important purpose of the daily Scrum.
Scrum is about self-discipline. Self-discipline and freedom are two sides of a coin. Freedom helps self-discipline, and self-discipline creates freedom. Objectives are about the kindness that you create, giving value to society and making a living for your family, through your product development. Actions and uncertainty are about the wisdom to implement objectives. Objectives reflect your inner kindness. Actions and uncertainty management reflect your inner wisdom. You must love both kindness and wisdom. Scrum makes it possible, as Scrum is about people and human nature.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.3 (3 ratings)

Comments

Mishkin Berteig, CST,CSP,CSM,CSPO, 9/16/2013 8:11:10 AM
Nice article. I really like the chart you have included. I have a little feedback because some people may only look at the chart without reading further:

1. The chart does not have anything about obstacles. The way you have presented Scrum in the chart it seems like a typical management framework instead of a framework for creating high-performance teams. The handling of obstacles is an important facet of creating high-performance.

2. The artifacts often are used for multiple purposes. For example, the Sprint Backlog is used for both managing goals and action.

3. The Definition of Done is only marginally about objectives. It is much more about action and uncertainty. I believe it is in the wrong place on your chart. If it was about objectives, then the Definition of Done would be controlled by the Product Owner. In fact, the Definition of Done is much more in the hands of the Team and the ScrumMaster who are responsible for expanding it as quickly as possible to allow product increments to be shipped every Sprint. The gap between the current Definition of Done and "Done-Done" is a measure of uncertainty.

I hope these comments are helpful. I always enjoy your writing!
Glen Wang, CSM, 9/16/2013 9:36:32 PM
Mishkin,

Thanks for your comments! It’s helpful.

I just want to share my understanding regarding your comments. I think there’s no absolutely right or wrong, depending on how people accept it or not.

• As for obstacles, I prefer to a mindset of “walking on the eggshell”. (如临深渊如履薄冰in Chinese) With this mindset, I think people can do good.
• As for DoD, it’s the extension of acceptance criteria pretty much from quality perspective, so I put under the “objectives” category.

Thanks,

Glen
Glen Wang, CSM, 9/16/2013 10:38:31 PM
@Peter Stevens,

Thanks your comments!

Agree that "common sense" is a word should be carefully used. I may use the world intuitive.

Scrum is new or old? It just makes some good way of working visible.

Thanks,

Glen
http://www.linkedin.com/groupItem?view=&gid=37413&type=member&item=273952837&commentID=164345160&report%2Esuccess=8ULbKyXO6NDvmoK7o030UNOYGZKrvdhBhypZ_w8EpQrrQI-BBjkmxwkEOwBjLE28YyDIxcyEO7_TA_giuRN#commentID_164345160
Glen Wang, CSM, 9/17/2013 8:59:59 PM
Glen,

I would add Definition of Ready.

~~~~~~
Definition of ready needs to be developed by the team. Backlog goes through several states:

1. Initial story
2. Story is prioritized into next release
3. Story meets INVEST criteria
4. Story meets definition of Ready developed by team.

Regards,
Jeff Sutherland
Amit Kajgikar, CSP,CSM, 9/18/2013 1:17:26 AM
Hi Glen,

Realy nice chart!!

regards
Amit
Tom Mellor, CST,CSP,CSM,CSPO,REP, 9/22/2013 8:20:21 PM
Interesting table and article, Glen. I personally don't see Definition of Done as simply an objective, but rather the discipline to abide by sufficient standards. I relate it to Shuttle astronaut and speaker Mike Mullane's talks he has given around the "normalization of deviance" (http://mikemullane.com/speaking-programs/countdown-to-safety/.) He recounts that NASA had the standard for Apollo manned missions of "we won't launch until proven safe." Later, in Shuttle era, that standard morphed into "we won't launch if proven unsafe." He asks, rhetorically, which standard the astronaut in the vehicle would want. We know what happened under to more recent instantiation.

We face the same challenges in software product development - though hopefully we don't often place people in danger if we deviate from standards. More often we create products that fail to delight and that are difficult to maintain. We often deviate to make dates and/or budgets. As Ken Schwaber said in his 2006 Google Talk, "it is in our bones" to cut quality to make a date and it usually happens out of fear.

Scrum seeks to at least mitigate and hopefully obviate this behavior by the DoD and by sustainable pace. Tom DeMarco insists you need "slack" time to improve and many organizations won't tolerate that, either. The idea that people would have any "idle time" on their hands is abhorrent to many.

All 3 roles have to be involved in transparency. I think the entire table needs to be reworked, but it is a start. I'm not sure any PM ever knew objectives better than a team, but I also speculate they might have rarely been in synch about them and both may have had their own interpretations of them.

Uncertainty surely needs management, and that is why Dave Snowden and Mary Boone created the Cynefin framework for decision making they described in HBR: http://www.mpiweb.org/CMS/uploadedFiles/Article%20for%20Marketing%20-%20Mary%20Boone.pdf. Complex work (as well as Chaotic events) are instilled with uncertainty and the best approach to complexity is to "probe-sense-respond" which is exactly what Scrum provides (and so do other similar frameworks such as XP, etc.) So, we might expect to see something about that behavior in the explanation of the table.

Adaptation comes in 2 perspectives in Scrum: team process and product (which is considered to be an "artifact" in Scrum. Definition of ready includes having a "3 Amigos Meeting" or something similar where the details of the story, including acceptance tests, are discussed and agreed upon.

The table is a first good pass, and like anything "iterative," it can be adapted. Thanks for the thought generator, Glen.

You must Login or Signup to comment.