Introduction

Long-lasting improvement doesn’t come from adopting new practices, but instead from adopting new ways of thinking and behaving. We have created a series of templates to support these new ways of thinking and behaving. These templates are described in our courses and are available for download to Premium Content subscribers.

There are three categories of templates

• Mindset templates
• Team Agility Scorecard
• Team approaches and team practices

Mindset templates

Here are the templates for the mindsets of Team Agility. Talk about these templates with fellow students on the Team Agility channel of the Forum.

Outcome-Based Thinking mindset

The Outcome-Based Thinking Mindset template supports the shift in thinking required from merely working on a literal reading of a backlog item to understanding the intention (the outcome) of the backlog item.

Definition of Ready and Definition of Done template

A Definition of Done mindset is one of not starting the implementation (or even the next step in a workflow) until you’ve determine how you will know you are done.  This includes not only immediate functional acceptance criteria but can also adhering to standards and regulations, and meeting non-functional criteria such as creating or updating documentation and obtaining approval from specific stakeholders.  We have found that starting work before making these criteria explicit is one of the leading causes of unpredictability and re-work.

A Definition of Ready mindset is one of not starting the implementation (or the next step in a workflow) until you’re ready to get it to Done. Over time, a team’s Definition of Ready will expand to incorporate additional readiness elements that the team has found to cause failure, rework, and other types of waste when not attended to.

The Team DoR-DoD Template is focused on what a typical software development team may need but it can be applied to other types of backlogs such as shared services and operations backlogs, program and portfolio backlogs.

MBI Mindset exercise

A Minimum Business Increment (MBI) is the smallest chunk of work from which we can realize business value. An MBI Mindset is one where, to obtain a specific goal or outcome, we always attempt to discover and select the minimum scope needed to realize the desired goal/outcome.

In the context of an MBI, this means we apply the MBI Mindset to every scope element initially defined in the MBI, as far as we go down. That means it applies to the “features” or “epics” or “very large stories” that make up the MBI, as well as to the smaller team backlog items that contribute to those. It even goes as far as the actual implementation: a programmer will constantly challenge such things as how much code is really needed (such as number of methods) in order to realize the goal/value or how much testing is really needed. This is the antithesis to Waterfall/big-batch. It is the antithesis to gold-plating.

In lieu of a template, here is a thought experiment to help you and the team to explore and discuss how to apply the MBI Mindset to current work.

Scrum Objectives worksheet

The Scrum Objectives Worksheet lists objectives for the different roles, events, and practices in Scrum. Some of the objectives are specifically tied to a characteristic that is desirable within Scrum. Example: The cross-functionality of the Development Team. Use this worksheet to understand a specific role, event, artifact, or practice from the perspective of its objectives. By better understanding all the objectives behind it, you can assess whether you are “doing it right” or have perhaps missed something in your adoption or implementation of Scrum.

Teams sometimes resist adopting or sometimes decide to abolish one of these without realizing the complications that may arise when any one of the objectives is no longer met. Using this worksheet can help highlight the objectives and re-adopt or even address them as needed.

Team Agility Scorecard

The Team Agility Scorecard is a matrix to help you score how well different aspects of Team Agility are being done in your organization. Use it as a road map to guide improvements for an Agile team, to choose what to work on next.

Team approaches and practices templates

The components of a good Scrum/Kanban Board

Scrum and Kanban originators have different mindsets about the visibility of work. Scrum is described as an empirical process without there being a consistent flow. This is why it uses tasks on stories – because then each story can have a unique workflow.  Kanban is more directly based on Lean. In particular, systems-theory, the value of visibility of work to collaborate and the value of a standard workflow on which to make continuous improvement. Kanban’s perspetive on team boards can easily be adopted by Scrum teams and is usually always beneficial to do so.

Choosing practices

Think of Scrum as the top shelf of a large toolbox. Everything you need to start with is there. You only need to go into the larger part when one of the topmost tools is having a problem getting the job done. When a team is faced with a challenge in following Scrum, they go to the toolbox to ask, “What objective does this practice meet?”, “What decision have I made?”, and “Is there a better way to do this?”

A formalized way of doing this is to ask the following:

1. Are you having challenges with the practice because it is being done poorly? If Yes, then inspect and adapt and see if you can do it better. If No, continue.
2. Is there something else in the organization that is causing us this problem? If Yes, then see how to fix that or at least influence the fixing of it. If No, then continue.
3. Is the ecosystem that the team finds itself in causing the problem? That is, are people not colocated when they need to be or are required skills missing? Can you improve on this? If yes, do so. If No, continue to see if another practice that works within this ecosystem will work better (see next step).
4. What else can we do that meets the same objective of the practice? If there is something else you can do, then try that. If not stick with the practice until you learn more.

Retrospection: After Action Review

The After Action Review (AAR) is one helpful tool for retrospections. It helps a team learn from their experiences in order to gain immediate, concrete improvements in performance. An “action” is any major or routine activity or event that a team of people undertakes, especially those events that they or other similar teams will likely repeat in the future. AARs are used throughout industry, military, and public services. It is a general purpose tool for many situations.

Guardrails at the Team Level

The Guardrails at the Team Level helps the organization understand how to work together at the team level. They are a set of agreements on how to help teams align with the organization. While each company will have their own goals and strategies to achieve their vision, we have seen these six “guardrails” to be essential in creating alignment across an organization. How they are manifested, however, is different at the different levels of work. These checklists are also useful in retrospections to help focus team members on following the guardrails.

Read the Checklist for the Guardrails at the Team Level article.

Dot Game

The Dot Game is a training exercise to help teams understand the basics of flow and how to apply Lean principles to Work-in-Process (WIP).

Read the description and process for running the Dot Game article.