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
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.
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.
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:
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.
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.