Agile Pain Relief | Glossary

10 Minute Build

Wed, 28 Sep 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

10 Minute Build is the idea that we should be able to build a system and run its test suites in 10 minutes or less. Fast build-and-test provides quicker feedback to the developers who wrote the code. It allows them to move on to the next thing - a new feature or improving the current one. Fast builds allow for multiple check-ins per person/pair a day, which in turn makes small check-ins practical. These smaller check-ins reduce the risk of team members stepping on each other's virtual toes and, with a bit of practice, allow them to develop a rhythm that results in continuous small improvements.

Fast builds are a stepping stone for Continuous Integration and Continuous Delivery.

In comparison, when builds are slow, Developers wander off to do new things while waiting (See: Multitasking), which results in increased cost to go back and fix defects when they're found later in the build, especially since longer builds are run less often so it will take longer to find errors.

Acceptance Criteria

Wed, 28 Apr 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import APRBlogIllustrationsNov2019AcceptanceCriteriaBV21024x607 from '@/content/glossary/acceptance-criteria/images/APR_Blog-Illustrations_Nov2019_AcceptanceCriteria_B_v2-1024x607.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Acceptance Criteria are used to ensure that a feature (or User Story) the team is building meets the needs of the End User. The common practice is for team members to collaborate on writing a series of examples that demonstrate the expected behaviours of a feature.

There is no required structure for acceptance criteria, although many in Behaviour Driven Development world use: Given, When, Then.

Given: My bank account has a balance of $100 When: I attempt to withdraw $101.01 Then: I get no money and error

When to create? Some teams do this in refinement, others right after Sprint Planning.

Who is involved: Team members (a minimum of 3 perspectives), Product Owner (sometimes a participant, sometimes as a reviewer), Stakeholders (occasionally as reviewers).

7 Tips for Writing Acceptance Criteria with Examples
Example Mapping (Draft.io)
Example Mapping (Inside Product)
Introducing Example Mapping
User Stories And Acceptance Criteria In The House </HighlightBox>

Agile

Tue, 23 Mar 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import AgileUmbrella21024x804 from '@/content/glossary/agile/images/agile-umbrella2-1024x804.png';

import HighlightBox from '@/components/global/highlight-box.astro';

Agile is a mindset for doing work in a team environment that improves teamwork, professional performance, and adaptability. The Agile mindset is focused on adapting to changing customer needs while still delivering a high-quality product, and is defined by the values and principles in the Agile Manifesto.

There is no single way to put the Agile mindset into practice, and numerous approaches have been developed. Scrum is currently the world’s most popular approach.

Common Misconceptions

Agile and Scrum are not the same things.
Your organization is never done becoming agile
Agile isn't about giving into change just because some asked
Agile isn't about Velocity ....

The Impact of Lean and Agile Quantified – Rally Research Study </HighlightBox>

Agile Architects

Fri, 09 Jul 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

An Agile architect is different from the traditional architect. They're not at the top of the pyramid, their collaborator, coach and partner. They're not the sole decision maker.

They help the teams discover, practices that maintain quality and stability across the wider organization. They coach the teams to reduce technical debt.

Coaching the Agile Architect
The Role of the Agile Architect
The Role of an Agile Architect
Kyle Gene Brown - Who Needs an Architect? </HighlightBox>

Agile Architectural Patterns

Fri, 09 Jul 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Patterns of Enterprise Application Architecture - Martin Fowler </HighlightBox>

Agile Architecture

Wed, 07 Jul 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Agile Architecture emphasizes the minimum amount of design upfront, and focusing on building something and evolving the architecture as our understanding changes.

Architecture in software development is often defined as relationships between the parts in a system. Traditional approaches to software architecture emphasize Big Upfront Design - get it right at the start. The problem, of course, is that requires us to foresee all architectural considerations (scale, security, fault tolerance, fault recovery) at the moment when our understanding of our problems is at its weakest. Agile Architecture allows for the design to evolve and adapt as more is learned about what is needed.

Key principles

We won't get it right on the first try, be prepared to iterate
Refactor
Focus on Simplicty
Make it Testable

(Hint: when searching for more ideas, consider using the term: "Evolutionary Architecture")

Software Development is Not a Form of Construction </LinkList>

An Agile Approach to Software Architecture
Architecture & Design
A Brief Summary of Evolutionary Design
Don’t You Have to LOGIN first?
Characteristics of Evolutionary Architectures
Conceptual Architecture
Is Design Dead?
Evolutionary Architecture with Patrick Kua (YouTube)
How the Guardian successfully moved domain to www.theguardian.com
James Shore on Continuous Design [PDF warning!]
Pimp my Architecture – Dan North (Presentation) He discusses an example of rearchitecting an application without rewriting it from scratch
Principles for the Agile Architect
Simplicity, The Way of the Unusual Architect – Dan North (Presentation)
Software Architecture and Related Concerns
Software architecture is failing
Software Design Guide -
Summary of Building Evolutionary Architectures -
When Feature Flags Go Wrong
Example - The Architecture of the Morrison’s OrderPad - a Sample application </HighlightBox>

Building Evolutionary Architectures – Neal Ford, Rebecca Parsons, Patrick Kua
Lean Architecture: for Agile Software Development –James O. Coplien, Gertrud Bjørnvig </HighlightBox>

Agile Business Intelligence

Fri, 25 Jun 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Business Intelligence (aka BI) is the dark art of extracting knowledge from a database in a way that humans can understand it. Agile Business Intelligence is the art of building the client's BI tools in an iterative and incremental fashion. Since BI work is usually done on top of a DataWarehouse and requires a chunk of upfront design, it is often assumed that we can't have Agile BI.

<HighlightBox heading="Resource Links" variant="resourceLinks"> ... from the people who have done it

Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing - Ken Collier </HighlightBox>

Agile Documentation

Fri, 26 Aug 2022 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Agile Documentation. Is it an oxymoron? The Agile Manifesto says "Working Software over Comprehensive Documentation". It doesn't say no documentation, and it doesn't say how much, if at all.

In an Agile world, we focus our work on delivering value to the customer, not on chronicling the process. At a high level, some teams maintain a one-page system design document. Other teams have used a whiteboard with a "best before" date and, once the whiteboard expires, someone takes a picture with their phone and wipes it clear. If the erased information is still valuable, several people work together to create a new version of the picture based on their current understanding of the system. The elegance is that it starts fresh and it is created collaboratively.

What about the user stories as documentation? They seem like documents at first. The challenge is that they degrade in value over time. They're just intended to be a placeholder that starts a conversation among the team members about the piece of the product that they're building. The problem is that a description that works well as a User Story, isn't meaningful months after the implementation is complete. We forgot the details and, in many cases, the original user story can no longer be found since the system that has been built on it obscures the original.

The acceptance criteria become low-level documentation. Teams that learn Behaviour Driven Development often use the examples created in that approach as their documentation. Even better, if they have mastered the art of automating their examples, they become executable documentation. Executable examples can be run, and if they pass then both the code and docs are in agreement. If they fail, then either the code or the examples need to be updated.

Instead of looking to add more documentation, seek to reduce the need for documentation. In many cases, it exists solely for the handoff to the next group of people (test, deployment, etc). Instead of creating a document; eliminate the handoff. Agile teams should include testing and, with the advent of DevOps they include people with knowledge of operations, so handoffs are eliminated.

Before agreeing to create new documentation, I prefer to ask team members these questions: "In 6-12 months will you be prepared to spend several hours updating this document?" and "How will you know when this documentation is out of date?"

If you expected a template, effective ones don't exist. Ultimately the team members need to negotiate amongst themselves with the Product Owner what documents they need, and what the minimum amount is that is required to do the job effectively.

Agile Contracts

Mon, 22 Mar 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro'

Traditional fixed price, fixed outcome contracts don't fare well in an Agile world. The traditional approach puts the emphasis on getting the details right up front. Agile Contracts acknowledge that it isn't possible to know everything at the start. They turn the procurement process into an exploration between the customer and the vendor.

Some characteristics of effective Agile Contracts:

Iterative Delivery vs Everything all at Once
Detailed Requirements aren’t included in the Scope
Build in feedback loops (hint: Sprint Review)
Flexible Pricing
Allows for Early Termination

Consider buying Sprints (or timeblocks), in which case changes don't come with additional costs.

$50 Million Phoenix Fix – Avoiding Disaster With Scrum </LinkList>

Agile Contracts: Creating and Managing Successful Projects with Scrum – Andreas Opelt, Boris Gloger, Wolfgang Pfarl, Ralf Mittermayr
Ten Agile Contracts – Getting Beyond Fixed-Price, Fixed-Scope - Peter Stevens
Valuing Agile: The Financial Management of Agile Projects – Alan Moran </HighlightBox>

Agile Engineering Practices

Tue, 04 May 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import AgileEngineeringPracticesMapSmall from '@/content/glossary/agile-engineering-practices/images/Agile-Engineering-Practices-map-small.jpg';

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

In my workshops, I often have people who are focused on the question: “How can I help my team go faster?”, or “How can we deliver this Product sooner?” Whenever anyone asks, my answer is always the same: “You must slow down to go fast.” I then often get some puzzled looks.

In software development, the single best way to improve quality, and eventually speed, is writing less code. Most of the time spent writing code should be to understand the problem and then find the simplest solution to it. The practices used to facilitate this in Agile software development are popularly known as Agile Engineering Practices.

Subscribe to receive your free copy of the Agile Engineering Practices and Their Effects Cheat Sheet.

The list of modern engineering practices includes:

10 Minute Build - Your application or product is finished building before ADHD kicks in. It's a form of fast feedback.
Collective Code Ownership - No one person owns the code, the whole team does
Pair Programming and Ensemble Programming - two people working on the code to improve its quality. When more of the team, both quality and throughput go up.
Behaviour Driven Development - writing acceptance criteria collaboratively, often writing executable test cases.
Continuous Integration and its big brother Continuous Delivery. Increase the frequency of integration to eliminate merge hell. When we can integrate frequently, then we can lean into Continuous Delivery. Hint: both require Trunk Based Development.
Trunk Based Development - Long-lived branches lead to merge hell.
Agile Architecture - Architecture still matters, we focus on emergent architecture over building the perfect plan.
Unit Testing - isn't about your test cases after you write your code. Nor is it about creating test cases with LLMs. Unit Testing is about ensuring you understand what your code is doing. Unit Testing requires Refactoring. Eventually, it leads to Test Driven Development.

Agile Technical Practices Distilled - Pedro Moreira Santos, Marco Consolaro, and Alessandro Di Gioia
Software Engineering at Google - Titus Winters, Tom Manshreck and Hyrum Wright (Caveat: we think Pair Programming and Ensemble Programming trump Code Reviews)
Clean Code Principles and Patterns: A Software Practitioner's Handbook - Petri Silen </HighlightBox>

Agile for Embedded Software

Mon, 08 Feb 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Embedded Software Development is about building software that is installed inside a device example: thermostat, car engine controller, planes, WiFi router, Bluetooth Keyboard/Mouse, Camera, Roomba Vacuums. Typically Embedded software works without a user interface and often without any human interaction. Embedded Software teams face challenges that other Agile teams typically don't face:

The software once built may never be upgradeable
It might run on a limited CPU and memory
It will have high reliability and predictability requirements

To face these challenges

Agile Game Development

Thu, 24 Jun 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Agile Game Development is different from classical software development. Building a game from scratch will require a broader group of people than we're used to: Artists (multiple kinds), Animators, Sound Designer, Game Designers, etc. In a normal Scrum team, we expect a high degree of Cross-skilling - e.g. a programmer learning the basics of Quality Assurance or User Experience work. It is unlikely that people will cross-skill from Programmer to Artist/Sound Designer in the course of building a game.

Agile Game Development With Scrum: Teams - a chapter from the book of the same title below
Game-Scrum: An Approach to Agile Game Development (PDF Warning)
Kanban for Game Development
Video Game Development with Scrum - a Dummies article </HighlightBox>

Agile Game Development: Build, Play, Repeat - Clinton Keith
Gear Up, 2nd Edition Clinton Keith and Grant Shonkwiler
Designing Games: A Guide to Engineering Experiences - Tynan Sylvester - Not an Agile book per se, rather a book on game design that uses Agile approaches throughout </HighlightBox>

Agile Government

Thu, 03 Feb 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Agile is about adapting to changing requirements and needs. Governments, just like anyone else, have to deal with dynamic issues as they arise and evolve, and things like climate change, COVID, and housing crises are just a few examples. The rate of change is increasing and a model (whether we use the labels of "Sprints" or "Limited WIP”) that allows for an Agile Government is required to handle the resulting challenges.

Agile Assessment Guide: Best Practices for Agile Adoption and Implementation - its a guide for auditors, but also helps implementers. There are also case studies embedded in the full report PDF
Agile delivery How to work in an agile way: principles, tools and governance.
Agile Government Handbook
Agile Government Center and Case Studies of Agile Government
Agile: How We’re Working Differently
GCHQ's internal Boiling Frogs research paper on software development and organisational change
Defining Agile Government - neatly lays out the challenges and points to existing successes
How can the Government be Agile?
The Public Guardian on agile development
Working together to help people with court fees

Cautionary Notes

A bleak outlook for public sector tech
Paperweight: a cautionary tale of onerous oversight </HighlightBox>

Agile Hardware

Mon, 08 Feb 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Agile approaches have taken over the world of software, because teams that deliver value sooner with higher quality beat the slow. Hardware teams face challenges software teams do not: Cost of Fabricating new hardware; Lead time for new parts; Cost of Change; Lack of test automation Infrastructure; How to iterate on hardware components separately; Compliance; Proof of Safety, Dependancies; ...

The world of hardware today resembles the software of the early 2000's - we had only a few early unit test tools (JUnit 3, CruiseControl, VisualSourceSafe/CVS/RCS - shudder).

We're not experts in Hardware Development so we point to the people who've done it.

Scrum for Hardware - Paolo Sammicheli </HighlightBox>

Agile Mainframe Development

Mon, 08 Feb 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Agile Outside of Software

Fri, 29 Apr 2022 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

In the over 20 years since the Agile Manifesto was written, we've seen Agile approaches applied in a large variety of fields outside of software development. Scrum has been used for sales, marketing, manufacturing, human resources, gas plant design and construction, academic research, schools... the list goes on.

Agile approaches lend themselves well to circumstances where:

we have cross-functional teams,
people are doing knowledge work (i.e. their work requires thinking, rather doing routine repetitive tasks),
adapting to change helps as opposed to just following a plan,
there is a common goal or purpose, often called a Product Vision,
collaboration would help the team.

In many of these examples, the groups don't use Scrum itself, rather they invent their own flavour of Agile that works for them. Things that come up time and time again include:

work in small chunks,
start with a rough plan and assume it will change often,
regularly examine what has been built and change the plan based on feedback,
give control of the work to the team,
make team improvement a core part of the work,
make improving communication and collaboration a regular part of the work.

What Are the Limits of the Scrum Framework? </LinkList>

<HighlightBox heading="Resource Links" variant="resourceLinks"> Interesting ways that Scrum and Agile have been used

ACADEMIC RESEARCH

HOME AND FAMILY

INFRASTRUCTURE AND OPERATIONS

Agile HR: Deliver Value in a Changing World of Work
Natal Dank, Riina Hellström - Agile for Non-Software Teams - Gil Broza - excellent solid work - Building a House in the Garden - Agile lesson from constructing a house - Yves Hanoulle - this is a completely different angle. His first two books are about office work, this book is about how Yves learned from Agile in building a passive house. Caveat: I have access to draft notes the author isn't ready to publish yet, and is taking note of emails to get a sense of its time to publish. - Hacking Marketing: Agile Practices to Make Marketing Smarter, Faster, and More Innovative – Scott Brinker - Office Lean
Ken Eakin - expensive, however it is also excellent </HighlightBox>

Agile Sales and Marketing

Wed, 02 Feb 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Sales and Marketing are challenged in the same way that software development was over 20 years ago. The work is often split over multiple groups, and individuals may be working on many things at the same time, with several competing deadlines. With all of the challenges the world of Sales and Marketing face, it's ripe for a change toward being more Agile.

Why Agile? Because both Sales and Marketing have changed massively in the past 20 yrs. We've gone from print media and mailouts, to online advertising, social media influencers and now AI. Agile approaches help teams adapt.

Most relevant Principles and Practices:

Work Iteratively and Incrementally
Cross functional teams
Learn from data ...

I've grouped Sales and Marketing together because many organizations in the Agile world discover that there is no reason for an artificial boundary between the two groups.

Hacking Marketing: Agile Practices to Make Marketing Smarter, Faster, and More Innovative – Scott Brinker </HighlightBox>

Agile Schools

Fri, 04 Feb 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Scrum in the world of work, allows teams to self-organize around a common goal (Delivering a Product). Scrum in education is about getting kids to self organize in teams to learn and deliver their own school work. Kids who haven't been molded for years by a traditional hierarchical control system seem like the perfect audience. They learn to be critical thinkers, question authority and explore.

The Agile in Education Compass moves the focus from: Prescriptive → Iterative Content → Culture Evaluation → Visible Feedback & Reflection Control → Trust Competition → Collaboration

Adapting Scrum to Managing a Research Group
Agile Based Learning: What Is It and How Can It Change Education?
Agile Research Consortium for Schools - a resource site focused on Agile Schools
A view into the future – using Scrum as a teaching tool
Agile in Education
Agile Schools: How Technology Saves Education (Just Not the Way We Thought it Would) – Steve Peha
Group Problem Solving and Challenge Based Learning
Learning Sprint in an Agile Classroom
Scrum Alliance Grandview Prep
Scrum For Schools
Scrum In Schools
Scrum in Dutch Education
The Hope School Agile Story (video) and their website: Blueprint
Using Agile Approaches to Improve Teaching, Learning and Education in Developing Nations
Using Scrum in the Classroom </HighlightBox>

Agile vs. Scrum

Mon, 02 Mar 2026 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

Agile vs Scrum is a common point of confusion. Agile is a set of values and principles. Scrum is a framework that is consistent with those values.

Agile is just the four values and twelve principles that were agreed to at the bottom of a ski hill in Snowbird, Utah, in 2001. Scrum is a specific framework developed by Ken Schwaber and Jeff Sutherland in 1995.

When you hear someone saying \u201cWe do Agile\u201d, they\u2019re saying something that is impossible. You can be Agile by embodying the values and principles. For example, \u201cResponding to change over following a plan\u201d or \u201cCustomer collaboration over contract negotiation\u201d.

When the Agile Manifesto was created in 2001, Extreme Programming (XP), Scrum, Crystal, Feature Driven Development (FDD), Adaptive Software Development (ASD), Dynamic Systems Development Method (DSDM), and Pragmatic Programming already existed. Kanban was adapted for Software Development from Toyota, by David Anderson around 2007.

AI and Skill Atrophy - Anti-Pattern

Tue, 24 Feb 2026 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro'; import DeskillingCLD from '@/content/glossary/ai-skill-atrophy/images/deskilling-cld.png';

We're losing skills because we don't use them, and we're not growing the developers of the future. What do we give up to LLMs?

When you use an LLM to make a decision you could make without the LLM, you gain a sense of false confidence. The easier it is to prompt an LLM to produce an answer, the less we develop the skill. This affects junior people more than senior people, since they have less overall experience to base their skills on.

In the academic literature, this is called Deskilling. In radiology, AI assistants help detect abnormalities in medical images. In theory, these detect problems faster and don’t get tired. (In practice, there are open questions about their effectiveness.) Too much reliance on AI leaves the radiologist unable to detect on their own. Bad enough for the senior radiologists, but even worse for new doctors. When the AI Assistant was used in the learning process, the new doctor didn't have as deep an understanding of what they were seeing.

This is a knowledge cliff, and the software industry is headed to one. (Hat tip to Brian Graham for the term.)

NASA has been through this recently; they want to build big rockets again. They have mountains of documentation (literally 2900 cubic feet), but they don't have the understanding and tacit knowledge to use it.

Effects of Deskilling

Team Impact: Reduced mentorship and knowledge sharing.
Long-Term Risk: Novel or unexpected problems can't easily be solved with AI, leaving people unprepared.
Cognitive Atrophy: Over-reliance on GenAI increases confidence in the AI while diminishing critical thinking skills.

Brian Graham offers a question list: before automating with AI, ask:

Knowledge assessment - do we understand the domain well enough to evaluate the AI output?
Is this a Core competency vs Background noise?
Failure Planning - Are we monitoring and prepared to reverse course if this decision fails?

The more we use AI, the more critical thinking becomes important.

Pilots have been through this before. With the advent of autopilot, instrument landing systems, automated flight management systems, etc., these systems have reduced the need for certain piloting skills. To combat this, they have increased the amount of training and simulator time for pilots to maintain their certifications.

I did not mention the 2026 Anthropic study: "How AI assistance impacts the formation of coding skills", because there are enough questions about the design and methodology that I don’t see it as a reliable source.

Knowledge Cliff Anti-Pattern - Building Better Teams - Brian Graham
Avoiding Skill Atrophy in the Age of AI - Addy Osmani
Deskilling and Upskilling with Generative AI Systems - Kevin Crowston and Francesco Bolici
The Impact of Generative AI on Critical Thinking - Hao-Ping Lee et al., Microsoft Research, CHI 2025
Does Using Artificial Intelligence Assistance Accelerate Skill Decay and Hinder Skill Development Without Performers' Awareness? - Macnamara et al., Cognitive Research: Principles and Implications, 2024 </HighlightBox>

Image: Agile Pain Relief Consulting, February 2026

Agile Anti-Patterns

Mon, 08 Feb 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import APRBlogIllustrationsJune2019AntiPatternsV5300x178 from '@/content/glossary/anti-patterns/images/APR_Blog-Illustrations_June2019_Anti-Patterns_v5-300x178.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

An antipattern is a recurring practice or behaviour that creates harm. In the context of Scrum and Agile, an antipattern would be something the reduces the team's collaboration, focus, quality etc.

Patterns, when applied well and not overused, provide a guide to solving repetitive problems rapidly. A good pattern provides enough background information to help you solve the problem, without asserting that it is the best or only solution in all instances.

Scrum, Agile, Kanban, and other frameworks and mindsets like them, are sets of behavioural design patterns. In Scrum, we have Scrum PLOP (Pattern Language of Programs) that documents known patterns of effective behaviour.

Examples of Anti pattens in the Scrum world?

Team members who're part of three teams.
Stakeholders demanding the team start a new Work item mid Sprint
Focus on speed over quality
Ignoring Technical Debt
Hardening Sprints

Below, you can browse through our growing collection of articles about Anti-Patterns – what causes them, and what you can do to resolve or avoid them.

Agile Bonuses - The Damage They Do
Scrum Anti-Patterns: The Hardening Sprint
Scrum Anti-Patterns: Large Product Backlog (published on ScrumAlliance.org) (download link for PDF version in case the Scrum Alliance link is no longer functional)
Scrum Anti-Patterns: Micromanagement
Scrum by Example – Scrum Anti-Patterns & Unplanned Work Disrupting the Sprint
GenAI, Systems Thinking, and Team Problems </LinkList>

Appreciative Inquiry

Wed, 02 Aug 2023 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import AppreciativeInquiry from '@/content/glossary/appreciative-inquiry/images/Appreciative-Inquiry.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Appreciative Inquiry is an approach to team development and organizational change that works by focusing on the strengths and positive aspects of the current system. This is in contrast to most approaches for improvement which get you to find out what is wrong with a system and then fix it. This can create ongoing negative mindset, with all of the problems the team or organization has. In addition, we can end up with a system full of band-aid fixes.

So Appreciative Inquiry takes the inverse approach and focuses on what we have happening that we can celebrate. Team members are asked to participate in four sections:

Discovery – Appreciating. Tell stories that illustrate what is best about us and/or our system. Sample questions: What do you remember most about our work? Where did we collaborate best? What strengths did you and others bring to our work?
Dream – Envisioning. (See: Future Perspective for Change: Why Backcasting Helps Get You Where You Want to Be). Dream about positive things that could happen. Sample questions: What would make you talk about our team to other people? How can we grow our team’s skills to take our next challenge? What will we do to celebrate when we succeed?
Design - Co-constructing. Discuss actions that we need to take to build the desired future system. Sample questions: What have you learned that could help us on the journey? What steps could you take to get us started?
Destiny – Sustaining. Consider what we need to do to build a learning culture. Sample questions: What mindset do we need to make this work? What new things will we try to make this work? What would you like to learn to be able to achieve our dream?

Strengths:

Collective visioning promotes alignment and common understanding
Focus on learning and adaption fits well with being Agile
Positive focus finds the good in situations
Emphasis on sustainability

Appreciative Inquiry can overlook some problems, so watch out for:

If people aren’t invested enough in wanting a change, this might be a positive, but ultimately unproductive, experience where nothing happens.
If there are challenging personality differences, they will get buried or ignored if the focus is solely on positive things.
Truly dis-engaged people might just disconnect from the process and tune out.

Appreciative Inquiry is often used in retrospectives, see our Guide to Effective Agile Retrospectives

Collaboration, Over Work in Isolation </LinkList>

Appreciative Inquiry
Appreciative Inquiry: Lift everyone's spirit with positive questions
Discovering and Building on the Root Causes of Success with Appreciative Interviews
Good/Bad vs. Appreciative Inquiry Retrospective
Powerful Appreciative Inquiry Questions For Positive Change
What is Appreciative Inquiry? (Agile Coffee)
What is Appreciative Inquiry? (David Cooperrider)
What is Appreciative Inquiry? (JD Meier)
When Is Appreciative Inquiry Transformational? A Meta-Case Analysis </HighlightBox>

Approval Tests

Thu, 06 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Approval Tests - Approval Tests with Llewellyn Falco
Approval Testing
Using ApprovalTests in .Net 17 Wpf </HighlightBox>

ARC Motivational Model

Fri, 02 Dec 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

ARC motivation model is part of Self Determination Theory, which shows there are two kinds of motivation: Intrinsic and Extrinsic.

Intrinsic motivations are ones that come from the person themselves — they enjoy completing the task. For example, in my own case, I enjoy writing glossary entries.

Extrinsic motivation comes from outside the person — perhaps someone else imposes a deadline on you for a task.

If we're already intrinsically motivated for a task and then extrinsic motivation is applied, it may diminish the individual's intrinsic motivation over time. This is a word of caution, but not all extrinsic motivation is bad. We simply need to be aware of what is affecting people and why.

ARC Motivation Model:

Autonomy - is the ability to act on our own values and interests. We need to feel that we have choices. This explains why being a bus driver is one of the more stressful jobs people have. A bus driver has their autonomy taken away by the limited ability to make their own decisions.
Relatedness - is our need to care about and be cared about by others. A connection without concern for the other person's ulterior motive.
Competence - is our need to feel effective at meeting everyday challenges and opportunities. It also comes from a sense of growth.

When we lose one ARC element, the others diminish as well. Examples:

If someone is micromanaged at work, they might suffer a domino effect. Their autonomy is limited which might prompt then to think, "Am I being micromanaged because I lack competence?"
When another team member makes a snide remark on the quality of your work (competence), it will affect your sense of connection (relatedness) with the team.

How can we support ARC?

Autonomy - Provide meaningful goals that don't conflict with their intrinsic motivations. Don’t gamify or provide bonuses. As soon as an incentive appears, the motivation becomes externally imposed (extrinsic). The work may get done but the individual will have reduced satisfaction with the work itself. Pressure to perform is, of course, even worse.
Relatedness - Give people the opportunity to connect; allow people to explore feelings in the context of work. Relatedness comes when you see the people around you as more than just doers.
Competence - Give your team members opportunities to learn. Allow room for experimentation. Don’t penalize people for reporting failures or challenges — instead, when they’re shared, give people the room and support to learn. Consider adding a question to Daily Scrum: What did you learn yesterday?

IMPORTANT NOTE: this is NOT the same as the ARCS model on students’ motivation and learning outcomes (Attention, Relevance, Confidence, Satisfaction). That is an excellent model to help school and university teachers make learning more effective, but it isn't relevant to helping with understanding motivational needs at work.

Autonomy, competence, & relatedness: the secret to work engagement Zen
Competence, autonomy, and relatedness in the classroom: understanding students’ motivational processes using the self-determination theory - Research Paper that shows the underestimated importance of Relatedness
Relatedness, competence, and autonomy
Self-Determination Theory, Motivation, and Your Classroom
Why the basic psychological needs autonomy, competence and relatedness matter in management and beyond

Self Determination Theory

Why Motivating People Doesn’t Work . . . and What Does: The New Science of Leading, Energizing, and Engaging – Susan Fowler </HighlightBox>

Blame Chet

Sun, 26 Oct 2025 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Blame is dangerous. It is contagious and brings out the worst in a team. In groups, where blame is often shared, people are less safe, there is less learning and innovation, and even productivity suffers.

From "Extreme Programming Installed"

Early on in the C3 project, the team was having a "discussion" about something that had gone wrong. Someone was trying to find out who had messed up. Chet got fed up with the witch-hunt and announced, "It's my fault." He took a card (we had a few around) and wrote "It's my fault" on it and signed it. Then he put it in his desk and told everyone where to find it if we ever needed someone to blame.

The original wiki, the Portland Pattern Repository, documents this as Don't Blame Just Do. If ever it finds the cartoon, that Dave Harris mentions, I would love to see it:

There's a cartoon which shows a nuclear power reactor, very busy, a wall full of read-outs and controls, guys in white coats all going about their work except for one chap. He's in a quiet corner, unshaven, reading a newspaper with a crate of beer beside him. The back of his chair reads "Fail Safe Man". On technician tells another, "If anything goes wrong, we can blame him."

By the time I learned the story many years ago, it had been reframed to the approach that, if your team is dealing with blame, stop. Send Chet Hendrickson an email saying, "I/We blame you for …" and Chet would reply, "I accept blame."

Chet Hendrickson had the wisdom to understand this in the mid '90s. Today, with the benefit of hindsight, I realize that Chet was anticipating all of the work in Psychological Safety.

Important Note - Chet is retired from accepting blame.

<HighlightBox heading="Resource Links" variant="resourceLinks"> Blame contagion: The automatic transmission of self-serving attributions - inspite of the catchy title the paper is readable. </HighlightBox>

Extreme Programming Installed - by Ron Jeffries, Ann Anderson, Chet Hendrickson </HighlightBox>

Behaviour Driven Development [BDD]

Fri, 23 Apr 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Behaviour Driven Development (or BDD) is an approach that gets team members to collaborate on describing the behaviours of the user story or product feature they're attempting to build. The behaviours are described with a series of examples, written in a language that users would be able to understand, that each prove one point about the feature or User Story. The examples can then be automated to provide acceptance tests that prove the expected behaviour, before the code is written. However, even if the examples can't be automated, there is great value in collaborating on the examples before the code is written.

BDD improves quality and reduce defects since it ensures that several team members agreed on the problem that needed solving. BDD doesn’t replace Exploratory and other forms of Testing.

BDD was also know as Acceptance Test Driven Development at one time.

Anti-Patterns for Behaviour Driven Development:

Behaviour-Driven Development Anti-Patterns

Tools

Concordion - a tool for creating living documentation. (I.E. Documents or examples that are written in text, but run automated test cases)
Cucumber - (versions have been ported to most programming languages/platforms)
Reqnroll is an open-source Cucumber-style BDD test automation framework for .NET. It has been created as a reboot of the SpecFlow
RobotFramework - keyword-driven test automation - can be used with examples driving the tests
Serenity BDD is an open-source library that aims to make the idea of living documentation a reality. </HighlightBox>

Specification by Example - Gojko Adzic - the original book on the subject - focuses entirely on people and collaboration
BDD in Action - Behavior-Driven Development for the whole software lifecycle - John Ferguson Smart
The BDD Books - Discovery - Explore behaviour using examples - Seb Rose and Gáspár Nagy
The BDD Books – Formulation - Document examples with Given/When/Then - Seb Rose and Gáspár Nagy
Behavior-Driven Development with Cucumber: Better Collaboration for Better Software - Richard Lawrence, Paul Rayner - Good for non-Technical and Technical readers
The Cucumber Book: Behaviour-Driven Development for Testers and Developers - Matt Wynne, Aslak Hellesoy and Steve Tooke
The Cucumber for Java Book: Behaviour-Driven Development for Testers and Developers - Seb Rose, Matt Wynne and Aslak Hellesoy </HighlightBox>

Bottlenecks

Tue, 07 Feb 2023 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

A bottleneck is a constraint that slows the delivery of value in our system. That is awfully abstract language, so let’s provide an example from everyday life.

In the morning, you’re driving to work on a highway. Traffic slows down for no apparent reason. You’re looking for the accident, but can’t find one. You emerge from the other side and traffic speeds up. You’ve just been through a bottleneck.

As the Theory of Constraints shows, nothing we do to either side of the bottleneck affects the throughput of the system. Let’s consider the morning commute again. If we speed up the rate at which cars arrive at the bottleneck, all we’ve done is increased the size of the queue in front of the bottleneck. If we increase the speed of the cars after they leave the bottleneck, we get only marginal improvements in the rate at which they get to work.

In the world of work, one way we find bottlenecks is by looking where there is work stacking up in front of a work station. For example, in many teams the developers are churning out features and they start stacking up in front of Quality Assurance. In this case the QA is the bottleneck. Either there aren’t enough people to do the work expected of them, or the way the work is being done is inefficient. Since most organizations don’t have an infinite supply of money to hire more people, then either people cross-skill to help with QA or they find more effective ways of working (hint: start testing earlier in the process with either Behaviour Driven Development and/or Ensemble Programming).

A Kanban board can be an effective tool in visualizing bottlenecks. Gentle reminder that, with all data, the data tells where to start looking, but it doesn’t tell you what is actually happening. To find out what is going on, talk to the people on the ground doing the work.

Scrum By Example: Team Gets Bottlenecked
Specialists Are Overrated
Agile Bonuses – The Damage They Do
How to Cross-Skill and Grow T-shaped Team Members - CrossSkilling team members is one of the best ways to eliminate bottlenecks.
GenAI, Systems Thinking, and Team Problems </LinkList>

Adopting flow analytics in software development projects - Readable academic paper that summarized the benefits of eliminating bottlenecks
How to Avoid Human Bottlenecks in Production
Kanban Bottlenecks
Kanban: Process Improvement and Bottlenecks Revisited | Software Process and Measurement
Strengthen the Weakest Link: Theory of Constraints
Theory of Constraints (TOC) 3 Bottle Oiled Wheels Demonstration </HighlightBox>

Trunk Based Development

Fri, 23 Apr 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Git, Mercurial and other source control tools provide robust and easy to use branching capabilities. For work with OpenSource software —where anyone could be a contributor and the environment is low trust— the use of branches is useful. For modern Agile teams attempting to continually improve (refactor) the code and use tools like Continuous Integration, Continuous Delivery etc, long-lived (> 1 day) branches just add overhead. If you've ever experienced merge hell, you know the problem. If you've delayed a refactoring because it would make the branch harder to merge, your code has suffered. The long-lived feature branching strategy became popular under the name "GitFlow", which even Atlassian (not known for being leading edge) says, "Gitflow has fallen in popularity in favor of trunk-based workflows, which are now considered best practices for modern continuous software development and DevOps practices."

Some organizations “solve” this problem by banning refactoring. (Not kidding, I’ve seen this and its effects).

Others move to a model called Trunk-Based Development, where all code is merged directly back to the Trunk every time a change is “committed”. In a world with Trunk-Based development, all work is done on the main branch or trunk. Team members (or, even better, Pairs) commit their work multiple times a day. This avoids merge hell and makes refactoring less painful.

Some teams in the Trunk Based model, use micro-branches, that live only for one day. Even day long branches increase risk.

Branch by Abstraction for dealing with the few complexities that crop up with working off of Trunk
Branching by an abstraction in the trunk instead of branching via Source Control
Continuous Integration and Feature Branching
Patterns for Managing Source Code Branches By Martin Fowler. This is the deepest single article on the subject
Long running branches — Why are we still doing this?
Perceived Barriers to Trunk Based Development
Scaling Trunk Based Development
Trunk Based Development a summary
Trunk Based Development as a Cornerstone for Continuous Delivery
Version Control and Branch Management from the book Software Engineering at Google
Why Google stores billions of lines of code in a single repository
Why your team doesn't need to use pull requests
TrunkBasedDevelopment.com - a whole website devoted to the ins and outs

EXAMPLE FROM REAL WORLD:

Google’s vs Facebook’s Trunk Based Development
Trunk Based Development for Microsoft Office </HighlightBox>

Trunk-Based Development And Branch By Abstraction - Paul Hammant </HighlightBox>

Business Analyst in Scrum

Mon, 03 May 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

In traditional approaches, the Business Analyst gathers the requirements months or years ahead of the team. Clearly, that doesn't work in an Agile world. Scrum doesn't define any traditional roles inside the team: BA, QA, DBA, Dev, UX - instead, everyone is a Developer or, better yet, a doer. This creates discomfort, but also opportunities.

"What is the role of a BA on a scrum team? My team and their BA struggle to know what falls on the PO's and what falls on the BA's responsibilities."

Part of the challenge is that the traditional approach of the Business Analyst going out to gather requirements disappears. Long-requirement documents are replaced with conversations with stakeholders before we start working on a problem. The core problem they want solved becomes the User Story. The details become the acceptance criteria.

This question, or a variation of it, is one that often comes up in training workshops and our Lean Coffee sessions. Some options I've seen work well:

BA is the Product Owner
BA works inside the Scrum Team, assisting the Product Owner to flesh out specific details. (This happens most often when there is one PO for multiple teams working on a single product, in which case the PO is focused on Product Strategy/Prioritization not PBIs/User Stories)
BA participates with QA and Programmers to define acceptance criteria using the BDD (Behaviour-Driven Development) collaborative approach. BDD leverages the detail-oriented skills of the BA to ensure we've covered all of the edge cases.
BA cross skills and helps with QA, this is a natural outgrowth of the previous step
Some cross skill into UX work and, rarely, others cross skill to programming

So we move away from having a distinct role named Business Analyst, towards a team member focusing on solving the customer problem, not gathering requirements.

Case Studies

Mon, 08 Feb 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

MULTI-COMPANY SURVEYS

Scrum Alliance Learning Consortium Report – 2015
Scrum Alliance Learning Consortium Report – 2016 </HighlightBox>

Causal Loop Diagram

Wed, 12 May 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import CausalLoopDiagram from '@/content/glossary/causal-loop-diagram/images/Causal-Loop-Diagram.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

A Causal Loop Diagram is a visual representation and reference that helps to understand cause and effect connections. It works best when people work together to create it, and the collaboration is used to tease out the common understanding of a problem. I like using them with teams to help think about moving beyond the Quick Fix mentality to deeper, more systemic solutions.

You can see examples of CLDs in action in these anti-patterns, where the Causal Loop Diagram makes more obvious the detrimental effect they can have:

Components

Variables - the things that are increasing or decreasing (i.e., stress, eating, etc.)
Arrows - illustrating a relationship between two variables: Stress and Eating
Plus/Minus signs - indicating whether one variable increases or decreases another): Stress increases Eating; Exercise decreases Weight.
B and R are often used to illustrate loops. B loops are in balance, and R loops are reinforcing. (Confused - don't worry, ignore this at first)

Use

Before making a big change, a CLD can be used to spot unintended consequences.
When we see a team, organization or system that is dysfunctional CLDs can help reason why.
Studying bottlenecks, why is this bottleneck recurrent?
CLDs can also be used to find leverage points.

<LinkList heading = "Agile Pain Relief Blog Entries"> We use the diagrams to visualize our antipatterns - Beyond the Surface: GenAI-Powered Critical Thinking for Deep Team Issues - Scrum Anti-Patterns: Agile Bonuses The Damage They Do - Scrum Anti-Patterns: The Hardening Sprint - Scrum Anti-Patterns: Large Product Backlog - Scrum Anti-Patterns: Micromanagement - Agile and Scrum Smells - AI-Generated Code Quality and the Challenges we all face </LinkList>

Coaching

Mon, 08 Feb 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Agile Coaching is an ill-defined concept. Self-described "Agile Coaches" appeared in the Agile world long before there was a definition.

ScrumAlliance definition: "An agile coach helps organizations, teams, and individuals adopt agile practices and methods while embedding agile values and mindsets. The goal of an agile coach is to foster more effective, transparent, and cohesive teams, and to enable better outcomes, solutions, and products/services for customers."

To complicate matters, the ICF states that the coach should be an agenda-less observer. But off course a coach has an agenda - they are promoting Agile growth and improvement to be used to become better/more effective.

ICAgile says: "Agile coaching is a craft intended to guide others in understanding, processing, and embracing constant change, so that the change is sustainable, lasting beyond the individuals. Agile coaches guide individuals and teams to get clear about the change they desire, identify places where current reality does not match desired reality and then take action to close the gap -- all in service of delivering business results that matter."

I suggest part of the challenge is that an Agile coach needs to take on many stances: Coach, Mentor, Facilitator, Guide and occasionally even teacher. The resources below focus on tools to help the coach on their journey.

Coaching Self Organizing Teams: review of Hard science for soft skills session </LinkList>

Powerful Questions

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition - Lyssa Adkins
Solution-focused coaching for agile teams: A guide to collaborative leadership - Veronika Jungwirth, Dr. Ralph Miarka </HighlightBox>

Code Reviews

Fri, 30 Sep 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Traditional approaches put a lot of emphasis on Code Inspection or Reviews to find defects. In human terms, that is like an editing process. The problem with code inspection is that, even under the best circumstances, it finds very few defects, and the ones that it does find are shallow. The challenge is that our brains are not designed to read hundreds of lines of code in a single sitting. When we do this activity, we tend to notice small improvement opportunities (e.g. a method or variable is poorly named) and might spot a way of simplifying a few lines of code. But we fail to ask bigger questions about the design, flow, etc. Static analysis tools better spot most things that a human code review finds.

To make matters worse, code reviews and their close friend, pull requests, add delays to a system. Delays increase our cycle time, without adding value.

W. Edwards Deming had a good quote for this:

Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.

Consider Pair Programming or, even better, Ensemble Programming instead.

The case against code reviews - Jo Crossick
Code review vs. Pair programming
Evolving Code Reviews Into Pair Programming
Pair Programming > Code Reviews - Theodore Nguyen-Cao
Software Code Reviews from a Deming Perspective - Build Quality. Inspection is for learning not quality (Source of my Demming quote)
Non-Blocking Continuous Code Reviews: A Case Study - Thinking Labs </HighlightBox>

Code Smells

Thu, 10 Oct 2024 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

A code smell is a hint that something might be wrong in your codebase. A smell isn't always a problem, rather it’s a hint that a further look is warranted. Code smells are a clue that says more time is needed to examine this area of the code.

They originated from one of the early Agile books, Refactoring by Martin Fowler (so important that it got a second edition). Many code smells are simple to describe: Mysterious Name, Duplicated Code, Long Function, Long Parameter List and Long Class.

The descriptions below are a mix of my own and some from The Code Smells Catalogue, which is an attempt to create a complete catalog of all code smells. I’ve listed only a subset here.

Bloaters

They make the code base harder to read, follow and modify by adding bulk.

Smell	Description
Data Clump	Data Clumps refer to a situation in which a few variables are passed around many times in the codebase instead of being packed into a separate object.
Long Method	One of the most apparent complications developers can encounter in the code is the length of a method. The more lines of code a function has, the more the developer has to strain himself mentally to comprehend what the particular block of code does thoroughly.
Long Parameter List	This is another code smell at the same abstraction level as Long Method which usually occurs when three, four, or more parameters are given as input for a single method. Basically, the longer the parameter list, the harder it is to understand.
Null Check	Null check is widespread everywhere because the programming languages allow it. It causes a multitude of undefined or null checks everywhere: in guard checks, in condition blocks, and verifications clauses. Instead, special objects could be created that implement the missing-event behavior, errors could be thrown and caught, and many duplications would be removed. Even an anecdote sometimes appears on discussion forums that the inventor of the null reference, Tony Hoare (also known as the creator of the QuickSort algorithm), apologizes for its invention and calls it a billion-dollar mistake.
Primitive Obsession	Whenever a variable that is just a simple string, or an int simulates being a more abstract concept, which could be an object, we encounter a Primitive Obsession code smell.

Object-Oriented or Functional Abusers

Misuse of OO or Functional principles.

Smell	Description
Conditional Complexity	Nested switch or if statements; a series of successive if statements. This preceding statement is itself an example.
Inappropriate Static	Static methods and class fields are the OO equivalent of Global Data. They allow global access to themselves, increasing coupling and reducing testability. There are clearly cases - Math.max() for example - where a static is useful. They're few and far between.
Refused Bequest	Whenever a subclass inherits from a parent but only uses a subset of the implemented parent methods, that is called Refused Bequest.
Side Effect	A method does more than its name promises, changing a variable/state that isn't part of its named purpose. Eg. a setAmount() that changes a date field.
Temporary Field	A variable on a class or object that is only initialized and used in particular circumstances, i.e. by one or two methods.

Change Preventers

Smell	Description
Divergent Change	If adding a simple feature makes the developer change many seemingly unrelated methods inside a class, that indicates the Divergent Change code smell.
Flag or Boolean Argument	Code smell occurs when a method requires a boolean or similar flag argument to control its behavior. The flag makes it difficult for the reader to follow the code without digging into the implementation. It also indicates that the method may have too many responsibilities.
Shotgun Surgery	Similar to Divergent Change but with a broader spectrum, the smell symptom of the Shotgun Surgery code is detected by the unnecessary requirement of changing multiple different classes to introduce a single modification. Things like that can happen with the failure to use the correct design pattern for the given system. This expansion of functionality can lead to an easy miss (and thus introduce a bug) if these small changes are all over the place and they are hard to find.

Dispensables

Smell	Description
Dead Code	Unreachable code
Duplicated Code	Possibly the worst smell
Speculative Generality	Developers are humans, and humans are bad guessers. Developers tend to create additional features in preparation for the future, guessing that they will be useful, but that time never came.

Couplers

Smell	Discussion
Fate over Action	Replaces Fowler's original Data Class - In the original definition a class with only Getters/Setters was considered a Data Class. A Data Class that allows others to change its contents is a source of many errors since we may discover the data changed over the life of the program without knowing how, when or why. <br /><br /> Use of Final/ReadOnly Data transfer objects (i.e. no setters), sidesteps these problems. <br /><br /> Fate over action focuses on the challenge where outside classes call setters on a class, leaving the receiver with no control of its fate.
Feature Envy	If a method inside a class manipulates more features (be it fields or methods) of another class more than from its own, then this method has a Feature Envy.
Message Chain	Suppose that class A requires data from class D, but to retrieve those data, it has to make unnecessary calls to class B sequentially and then C to get it. This function sequencing is called Message Chain code smell. Long sequences of methods calls indicate hidden dependencies by being intermediaries. A sequence of temporary variables could have also hidden the sequence of methods. The problem with this smell is that any change in the intermediate relationship causes the client to have to change.
Middle Man	The class that only performs delegation work to other classes is called a Middle Man. This is the opposite of the Message Chains. Encapsulation (hiding internal details) in the world of Object-Oriented Programming is a typical pattern. However, the problem arises when it goes too far - Fowler specified that it could be said that it's terrible when half of the methods are delegators.

There is also an excellent academic paper accompanying the Github repo, that attempts to survey and classify all code smells: "Code Smells: A Comprehensive Online Catalog and Taxonomy" by Marcel Jerzyk and Lech Madeyski.

Boolean Flags are so popular they may need additional reference sources to wipe out: Are Boolean Flags on Methods a Code Smell? Clean code: The curse of a boolean parameter

Colocation

Wed, 10 Mar 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Colocation is when team members are in the same physical location so in-person interaction and collaboration can take place. While the Scrum Guide does not specify that teams must be co-located, one of the principles of the Agile Manifesto states "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

Colocation improves the speed and quality of a team's communications. It allows team members to overhear conversations, giving them a chance to contribute when it would be helpful, or just be aware of what is happening. Colocated teams often have shared wall/white board space. They can use the space to maintain their Story Maps, Product Backlog, Sprint Backlog and other artifacts.

Co-location Transition, Tips and Concerns

Collective Code Ownership

Wed, 12 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Collective Code Ownership is the premise that the whole team owns the code. Anyone on the team can add new features, fix a bug, write a test case, or refactor. Teams that do this well reduce their bottlenecks, and improve Cross-Skilling (reducing their bus/lottery number).

Community of Practice

Thu, 18 May 2023 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

A Community of Practice (CoP) is a group that brings people with a common cause or purpose together on a regular basis. They can be formed around a role (e.g. ScrumMasters, Agile Testers, Usability) or an area of interest (e.g. Test Driven Development). The group meets on a regular basis to share activities, learnings and challenges.

Benefits:

Mutual support - As a member of a community, you know that you’re not alone in the challenges you face.
Shared knowledge across teams - By getting people to talk across different team boundaries, information about what has been learned moves organically.
Speeds professional development - Seeing your peers learning, exploring, and gaining recognition can be personally motivating. In addition, the community gives people the opportunity to stand on the shoulders of their peers. A colleague takes the time to share what they’ve learned in a problem space, and others don’t have to do the same digging again.
Gives people a moment to shine - As suggested by the SCARF model, a sense of personal status is an important motivator. Having a moment to share your learnings and shine in front of your peers can be very motivating. This can be especially important in the Agile world because it allows the person to have some visibility outside their team.
Breaks down silos and builds relationships across teams - Because CoPs work outside of the formal organizational structure and have open interest based membership, they help people who wouldn’t normally get to know each other build relationships.
Solve problems that can’t be solved inside a team - A CoP brings together a diverse group of people, sparking new ideas. Even when the community can’t solve the problem directly, it can help find other examples of the problem across the organization. When we can show more than one team is affected by a problem, it is easier to get management support in solving.
Alignment between people across different teams - Agile approaches promote self-organization. We also need standards to be created and maintained. These two ideas appear in contradiction. CoPs can help create standards with decision-making rooted in the community, thus honoring the Agile expectation of self-organization.

They seem new to many in the Agile Community, having been popularized by LeSS Communities and the infamous Spotify Model.

For a Community of Practice to work effectively, leadership must acknowledge the importance of team members spending time on improving their professional skills.

Building Successful Communities of Practice: Discover How Connecting People Makes Better Organisations: Webber, Emily: 9780957491939: Books - Amazon.ca </HighlightBox>

Continuous Delivery and Deployment

Wed, 05 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Continuous Delivery is the game of delivering features to Production whenever a change is made. It shortens the feedback and even the payment cycle, because you deliver the product more frequently. Because the steps are run multiple times a Sprint, teams need to automate all of the steps to deployment.

The application is built, and its automated test suite is run. In many organizations, it may be promoted through a staging environment where a wider suite of integration tests is performed.

In some organizations, a human (or the Product Owner 😉) decides with each build if enough additional value has been created to be worth deploying. This approach tends to be a sub-optimization.

Continuous Delivery builds on its sibling of Continuous Integration. With Continuous Integration, the team integrates their work more frequently.

Principles

Build quality in
Work in small batches
Computers perform repetitive tasks, people solve problems
Relentlessly pursue continuous improvement
Everyone is responsible

Along with the benefits of feedback, continuous delivery also reduces risk since each deployment is smaller. Therefore, if there is a problem, it can be rolled back and found more easily. Some of the other business benefits: Faster time to market; Able to test product ideas sooner and reduced cost of fixing defects.

What is Continuous Delivery? - by Jez Humble - he wrote the book on the subject.
Minimum CD - Summarizes the minimum conditions for Continuous Delivery.
Benefits of Continuous Testing
Continuous Delivery and the Perils of Feature Branching
Continuous Delivery Coding Patterns: Latent-to-Live Code & Forward Compatible Interim Versions
Continuous Delivery: The Value Proposition – Jez Humble
Continuous Deployment at Instagram
Continuous deployment for mission-critical applications – Eric Ries
Continuous deployment in 5 easy steps by Eric Ries
How Netflix Deploys Code
What are the technical practices of a Lean Startup?

EXAMPLE FROM REAL WORLD

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations – Nicole Forsgren, Jez Humble, Gene Kim
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation – Jez Humble, David Farley </HighlightBox>

Complexity and the Cynefin Framework

Mon, 08 Feb 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import CynefinChart from '@/content/glossary/complexity/images/cynefin-chart.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

We encounter complexity whenever we're asked to estimate how long it will take to fix a bug. Or when we're asked how long it will take to bring a novel product to market. We don't know what we can't know.

This is where Cynefin helps. Unfortunately, this theory has a complicated description. Cynefin is a poorly named mental model to help us see that different kinds of problems need different approaches. The word "cynefin" is the Welsh word for "habitat" and is pronounced: kuh-NEV-in. (It took me several years to learn to say it, so you're in good company if you're confused.)

Its creator, David Snowden, calls it a sensemaking tool, i.e. a tool to help you understand which domain your current problem lies in, and what actions to take based on that fact.

That's a fancy picture with a lot of words.

Clear Domain

(This was formerly called Simple/Obvious). In the world of software development, implementing an algorithm that has an existing recipe is an example. Outside of software, it is any activity that is well understood or that you can find a recipe for.

If it is clear what the outcome will be from the start, implementation is a matter of execution. If asked, you could have written down the steps involved in the work beforehand. With a high degree of predictability, estimation is practical and the approach of estimating in terms of hours/days will be more effective.

In the Clear domain, write down the plan and execute it, and things will probably go according to plan.

Complicated Domain

In the world of software implementing, an example is a new feature with at least some acceptance criteria, or building a new product in an area where the rough needs have already been understood. Outside of software, it is something that someone has done before, so you know the problem is solvable, but you don't necessarily know what the solution is.

From the starting point, you can see the rough end state. You couldn't write the steps it would take to get to the destination, because they weren't all known and the destination moved a few times along the way. As the destination and the individual work items aren't as well understood, the work is less predictable. Relative estimation, (e.g. Planning Poker) can be used as a tool to help people sense the volume of work and get a rough idea of which items are bigger or smaller. We often get requests to help teams with more accurate estimation, but in this domain that is simply impossible.

In the Complicated Domain, create a rough plan, start executing, and adapt. In Product Development this is the classical use of Scrum.

Complex Domain

Our original example of a software bug or creating a novel product are both in the complex domain. When we start, they're poorly understood. No one has solved this bug before. No one has built this type of product before. Outside of software, writing a book in an area that we don't know well is an example. We don't know if we can find enough information to describe the area well, or even if the area is well understood.

From the starting point, we don't see anything with clarity. Complexity can stem from the number of variables that affect our problem, the number of sources of information or, worse, the number of completely unknown things. In this environment, we have very little predictability. Estimation in this domain is a waste - more useful is to timebox an activity, saying, "We will do this for some number of hours or days and see how far we get or what we learned."

In a Complex Domain, run an experiment and see what it tells you. When working on a bug, it may then become Clear or Complicated. When doing Product Development work, the experiment will tell us what problem our audience wants solved. As the problem is narrowed, we can shift to normal Product Development work (e.g. the Complicated Domain). Effectively, this describes some of the ideas behind Lean Startup and Lean U/X.

Chaotic Domain

The system we're part of is off the rails. In the world of software development, this might be a key service that is offline. In the world outside of software, examples might include an oil pipeline that has burst and is leaking.

In a Chaotic Domain, take action and contain the problem. Chaos requires novel solutions and is typically transitory. Once the problem is contained, we want to move the problem to another domain (e.g. Complex or Complicated).

Confused Domain

(Formerly called Disordered.) We don't know where we are. Our job in this domain is to gather just enough information to sense which domain our problem is actually in, and then act from there.

Cynefin doesn't solve any problem for you, it is instead a "lens" to look at the world through. It helps you sense where you're at with a problem and then make better decisions.

Speed Trap: How the Obsession with Speed is Building a Fragile Organization - A fragile organization that goes faster will be knocked over in the slightest wind.
Simplicity </LinkList>

Estimation in Complexity:

Exercises to Understand Cynefin:

Continuous Integration [CI]

Mon, 08 Mar 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

In software development, Continuous Integration is the practice of merging all developers' working code to the main or head branch several times a day. This makes other practices from Automated Builds -> Continuous Delivery possible. Note: contrary to popular belief, Continuous Integration is the habit of frequent checkins and not the build automation. The automated builds are the supporting tools that make CI practical.

CI works by increasing the frequency of integration, so that most changes are small. Anything that works against that pattern (e.g. infrequent checkins, long-lived code branches, etc.) will harm the team and their code base.

Core Protocols

Thu, 22 Apr 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import Figure from '@/components/global/figure.astro'; import LinkList from '@/components/global/link-list.astro';

import CoreProtocols from '@/content/glossary/core-protocols/images/core-protocols.png'

The Core Protocols are a framework for improving team health and communication. They establish core commitments and then offer a set of practices/protocols. They were originally developed by Jim and Michele McCarthy, in 2001 in their book: "Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision" (Amazon sells this for a ridiculous price - I'm not linking to it). In 2018/2019, Richard Kasperowski updated them and gave them a home on the web.

Core Commitments

The Commitments are about team members helping to create an environment of Psychological Safety and focusing on team over individual. The Commitments are about:

Engagement
Lift others and improve their ideas
Focus on understanding others, not occupying the most space
Taking action towards the group goal
Seeking help when needed
Autonomy - at any moment, if we can't be engaged, then walk away
Contribute only when it will make the situation better Generally, the commitments are focused on creating a positive environment

<Figure src={CoreProtocols} alt="Core Protocols Organized by type - Copyright: Richard Kasperowski - 2019" caption="Core Protocols Organized by type - Copyright: <a href='https://kasperowski.com/'>Richard Kasperowski</a> - 2019" />

Protocols

These are a set of practices that improve team communication and performance. They're modelled on a principle similar to Design Patterns, and each protocol has a short description and set of rules.

Pass - I won't participate in this activity. If used too often, it may signal disengagement from the overall process.
Check-in - at the start of a meeting, a check-in is about sharing your current emotional state and your agreement to support using the other Core Protocols.
Check-out - "I'm Checking Out" - I can't currently participate and use the Protocols. The person may need to be somewhere else or can't currently engage using the rules.
Ask for Help - In too many teams, people don't ask, fearing it displays weakness.
Protocol Check - used when we think we're not abiding by the core commitment or misunderstanding another protocol
Intention Check - used to check your own or another's intention when we think behaviours might not result in a positive outcome
Decider - used to move the group to consensus.
Resolution - used when a minority doesn't support a decision
Perfection Game - when we want to improve an idea, we ask others what would make it better.
Personal Alignment - digging deeper into your intentions.
Investigate - ask questions to understand a phenomenon without passing judgment.

Practical Application

Discuss with your team and see if they can use the system to improve communication. <LinkList heading = "Related Blog Entries">

Introduction and History of the Core Protocols
The Core Protocols
Core Protocols - Effective Communication
Interview with the McCarthy's creators of the Core Protocols </HighlightBox> <HighlightBox heading="Related Books" variant="relatedBooks">
High-Performance Teams: The Foundations - Richard Kasperowski expands on the Protocols. The books is free from InfoQ.com </HighlightBox>

Cumulative Flow Diagram [CFD]

Fri, 30 Apr 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

A Cumulative Flow Diagram is a visual summary of the information contained on the Scrum Wall, Task Board, or Kanban Wall. A Cumulative Flow Diagram differs from a Burnup in that it tracks work through all of its states. It's useful because it can help spot bottlenecks and trends, but don’t confuse a Cumulative Flow Diagram or other measurement with the real world. A measurement is just a hint to go find out what is really happening.

Creating Cumulative Flow Diagrams
Cumulative Flow Diagram
Cumulative Flow Diagrams - summary from: Actionable Agile Metrics
Explaining Cumulative Flow Diagrams – CFD
How to Read the Cumulative Flow Diagram[Infographic]
The Cumulative Flow Diagram: High Performance Monitoring
Why we love metrics? Cumulative flow diagrams - a good story about what one team learned </HighlightBox>

Cross-Skilling

Tue, 04 May 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import CrossSkilledTeamOf5 from '@/content/glossary/cross-skilling/images/Cross-skilled-Team-of-5.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Cross-skilling is where a team member decides (without being pushed) to learn a new skill area. This learning will, of course, take time and in the short term slow the team down. In the long run, the team benefits from the shared knowledge with increased quality, fewer bottlenecks, etc. All of this of course will eventually lead to greater speed.

Teams that do not encourage cross-skilling and who have only person who perform a certain activity (e.g. Analysis, Database work, Testing) will suffer a variety of problems:

Bottlenecks - when there is more work for that skill area than the person can handle
Quality - there will be no one else to crosscheck that person's work
Stuck - if a team member goes on vacation or, worse, leaves the team maybe unable to finish some work items
... <LinkList heading = "Agile Pain Relief Blog Entries">

Cycle Time

Mon, 22 Nov 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import LinkList from '@/components/global/link-list.astro' import CycleTimeLeadTimeExampleScaled from '@/content/glossary/cycle-time/images/Cycle-Time-Lead-Time-example-scaled.jpg';

import HighlightBox from '@/components/global/highlight-box.astro';

Cycle Time is the time it takes from the moment a team starts work on an item, until the moment value is delivered to the customer. It matters because the customer doesn't see something as complete until they have it in their hands and can use it. Many teams seem to think their work is complete when it meets Definition of Done and the Product Owner accepts the item. If you live in a world where features are delivered continuously then this is true. Many teams, however, live in a world where work happens downstream of the Development Team. Cycle time captures all of that and therefore challenges us to optimize the whole delivery process.

Cycle Time (Martin Fowler)
Cycle Time and Lead Time
Experiment: Measure Lead And Cycle Time
How to Measure Cycle Time: With or without non-working hours?
Measure Cycle Time, Not Velocity </HighlightBox>

Cross-Functional Teams

Fri, 15 Sep 2023 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import DevOpsMindsetKanbanBoardTypicalScrumTeam1024x161 from '@/content/glossary/cross-functional-teams/images/DevOps-Mindset-Kanban-Board-Typical-Scrum-Team-1024x161.png'; import DevOpsMindsetKanbanBoardBlogVariation21024x170 from '@/content/glossary/cross-functional-teams/images/DevOps-Mindset-Kanban-Board-blog-variation-2-1024x170.jpg';

import HighlightBox from '@/components/global/highlight-box.astro';

In the Agile world a cross-functional team is one that has all the skills it requires to get the work finished, without relying on external help. Wow, that's a mouthful. Let's provide some examples. A team doing software development might have a mix of the following skills: Development, Requirements Analysis, Quality Assurance, User Experience etc. A team doing marketing work would have a different mix, maybe: Writer, Editor, Graphic Designer, etc. A key detail that often gets lost is that you don't necessarily need one person for every skill set required in your team. Instead, you need people who already have multiple skills or are willing to learn them (see cross-skilling). These people are often called T or M-shaped people because they have deep knowledge in 1-2 areas and can help out elsewhere.

Ideally our cross-functional team owns the work from the moment a feature or idea is consider until it is delivering value to the customer. (In the software world, this might even include monitoring their application in production). Most teams don't start with the ideal case, and instead evolve over time to a wider span. (If you understand Lean Principles, a Cross Functional Team owns a Value Stream Map from one end to the other).

Typical initial case:

Example of a team that owns their value stream from end to end:

Traditionally groups are often organized into departments by role or job title – e.g. the Development Department and Quality Assurance group. But cross-functional teams are not departments, and shouldn’t be treated as synonymous. We will explore why departments, often referred to as silos, are not as effective and why cross-functional teams are a better choice.

Less time spent waiting - Whenever a team has a dependency on an outside person or team, it spends time waiting for high priority work items to be worked on by others. In a cross-functional team, there is less work that has to be done outside and, even when there is, your team can proceed with lower priority work.
Reduced handoff size - In a traditional approach where teams are divided by skill set (e.g. Analysts, Developers and Quality Assurance) work items must be handed off from group to group. The typical outcome is the handoffs grow in size. Errors increase due to misunderstandings and poor communication. Whereas when the work happens within a cross-functional team, there may be still be handoffs but, when they happen, it is with smaller chunks of work. *Ideally teams discover Pair Programming or Ensemble Programming, at which stage handoffs disappear almost completely even within the team*
Better communication and co “Us vs Them” - Well maybe not completely eliminating it - nothing is perfect - but certainly far less than before. When the Quality Assurance is part of your team and not another group down the hall, there is less griping about their work and more effort on improvements.
Better quality - When Analysis, Development and Quality Assurance are done in collaboration, quality increases due to no handoffs, rapid feedback, work done in smaller chunks, much less time wasted logging defects, etc.
Flow - As communication and quality improve, the team will start to spot and resolve their own bottlenecks.
Faster time to market - As flow improves, individual features (or work items) get to market with less time from start to finish. (This is often measured as Cycle Time.)
Focus on customer - A team aligned to delivering the whole of feature (or work item) is better able to see the customer. In addition, once they have done work to create (or understand) their product vision, they have a common, challenging performance goal.
Self-organize - When we don't have to work across a larger group with formal boundaries, a cross-functional team can organize its own work without adult help.
Adaptability - With the mix of skills, cross-functional teams can adapt to changing product or market needs more rapidly and with less disruption.
Improved transparency - A team that is delivering complete features (or work items) every Sprint is more transparent, since there is no game of declaring work to 75% done and then blaming the next team downstream when problems crop up. With a cross-functional team, work is either Done or Not Done at the end of the Sprint. There is no 75%.

It is not easy to build cross-functional teams; there are more than a few challenges involved. Nonetheless, the advantages far outweigh the costs. In addition, getting from an initial cross-functional team to the ideal case pictured above may take a long time, but the benefit of small features delivered rapidly that consistently meet customer needs is well worth it.

Decision Making Tools

Wed, 03 Nov 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Agile Teams need to make small decisions frequently. Many teams experiment with majority rules and quickly discover that it's a way to ensure a few team members feel ignored. Usually it's the quiet people who get missed.

For Yes/No decisions both Fist of five and Decider protocol can work well. Dot voting is a tool for prioritizing among a group of items.

Why are Group Decision-making Techniques Important?
A Rebuttal of Groupthink </LinkList>

27 Decision-making Techniques and Activities for Deciding Together
Decision Making Systems Matter
Delegation Matrix for High Performance Teams
Four Quick Ways to Gain or Assess Team Consensus
Group decision-making.What the latest research says
How to flub (and not flub) group decision-making on technical teams
Learning with Fist of Five Voting
Manifold's Decision Making Process - elegant because it shows how to make decisions in differing contexts </HighlightBox>

Facilitator’s Guide to Participatory Decision-Making – Sam Kaner </HighlightBox>

Daily Scrum

Mon, 08 Feb 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

The Daily Scrum is the daily meeting where the Scrum Team get ready to collaborate for the day, and check if they’re still on track to complete their goal forecast by the end of the Sprint. It isn't about answering the three questions: What did you do? What will you do? What are your blockers? That is reductive and task-focused. A good Daily Scrum helps ensure the team is on track to meet their Sprint Goal and acts a form of mini-planning.

Definition of Ready

Wed, 02 Aug 2023 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import DefinitionOfReadyHarmfulHelpfulExamples1024x538 from '@/content/glossary/definition-of-ready/images/Definition-of-Ready-harmful-helpful-examples-1024x538.jpg'; import LeadTimeCycleTimeKanbanBoardExample from '@/content/glossary/definition-of-ready/images/Lead-time-Cycle-time-kanban-board-example.png';

import HighlightBox from '@/components/global/highlight-box.astro';

Definition of Ready is an agreement between the Product Owner and the team that describes what state Product Backlog Items (or User Stories) need to be in before the Sprint. Another way of describing “ready” is how prepared Stories are to be worked on.

A Definition of Ready helps a Scrum (or Kanban) team to ensure that their Product Backlog Items are well thought out, so nothing is considered for Sprint work if it has a high risk of getting stuck because some part of the work was ill-understood.

Here are some elements commonly found in a Definition of Ready:

Clear Understanding. Everyone agrees on what each Backlog Item represents.
Estimated and Small. The item has an estimate and it is, at most, a Small or 1, 2, 3 Story Points.
Acceptance Criteria. All acceptance criteria has been defined.
Dependencies. All dependencies have been discovered.
User Interface. A feature requires a mockup.

This list has strong parallels to the INVEST criteria and, as long as it remains a lightweight check, Definition of Ready can be a tool for good.

A team with a Definition of Ready isn’t optimizing for getting an idea from entering the Product Backlog to Deployed. Instead, they’re optimizing for Sprint Backlog to Deployed. The Definition of Ready acts a gate between the Product Backlog and the Sprint Backlog. Items can be held up at the gate for trivial reasons (e.g. incomplete Acceptance Criteria, missing user interface mockup, etc).

A rigid Definition of Ready encourages local optimization for the throughput of just the Scrum Team. This sounds like a more positive thing than it really is. The problem is that we should be optimizing for the whole system from the moment the customer places asks for their feature, until it is delivered. A rigid “Ready”, makes the Scrum Team look better by improving their cycle time, without necessarily improving things for the client. Imagine an example where a Definition of Ready holds up a feature for 6+ weeks while requirements are being gathered (perhaps the User Interface details, or final Acceptance criteria). Sure, once the work starts, it proceeds at a normal pace, but now the Scrum Team can say that they’ve reduced their cycle time, when all that really happened is the delay was pushed to early in the system. The team feels good but the customer isn't any happier. The customer's item still spent a long time sitting in a queue, and it doesn't matter what the queue was.

For teams that use a Definition of Ready, they should consider measuring Lead Time and not Cycle Time. By measuring Lead Time, any time spent waiting at the Ready gate is accounted for, making it harder to sub-optimize. This also leads to a general principle that says, when measuring, prefer measurements that observe the whole system.

My own preference is that, if your team has items that are frequently getting stuck in Sprint, consider a Definition of Ready but only cover the details that are currently causing problems. Hold on to the definition lightly - it shouldn't be rigid, and everything must 100% compliance check. Instead of making statements like "all acceptance criteria", consider "some or enough acceptance criteria have been found". Instead of a "requires a mockup" element, try "features that require large UI changes check to see if a mockup would help, preferring pencil sketches". Finally, as the team matures, check to see if the Definition of Ready can be made thinner by reducing the number of elements in it. Be careful that this doesn’t become a dumping ground for every little problem the team ever had.

Definition of Ready (by George Dinwiddie) - Definition of Ready (by Published Patterns) - Definition of Ready: A double edged sword
Definition of Ready — Dangerous or Necessary?
Definition of Ready is Evil
Definition of Ready: What It Is and Why It's Dangerous
Is “Definition of Ready” part of Scrum?
A Question of Handoffs & Queues </HighlightBox>

Definition of Done

Wed, 29 Nov 2023 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import UnDoneAndDone from '@/content/glossary/definition-of-done/images/Un-Done-and-Done.jpg'; import APRBlogIllustrationsNov2019AcceptanceCriteriaAV21024x607 from '@/content/glossary/definition-of-done/images/APR_Blog-Illustrations_Nov2019_AcceptanceCriteria_A_v2-1024x607.jpg'; import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Definition of Done is the official checklist that Scrum Teams maintain of the qualities they intend their work to achieve. It helps the team assess whether their work is truly completed and deliverable to the client as having added value. It also helps them in Sprint Planning by reminding them of the quality they have committed to achieving, ensuring they only commit to Product Backlog Items (PBIs) that they can get to truly “Done.”

The Definition of Done serves as a common understanding with the whole Scrum team (including the Product Owner) about the quality of the product. When a team has a rigorous Definition of Done, the Product Owner should be able to release a new version of the product at the end of every Sprint.

The 2020 Scrum Guide elevated Definition of Done to a formal "commitment" for the Increment, alongside Sprint Goal (for the Sprint Backlog) and Product Goal (for the Product Backlog). This framing reinforces that Done is not optional: it is the team's promise about what "complete" means.

How is Definition of Done different from Acceptance Criteria?

Definition of Done is the universal checklist that all product backlog items are checked against. Being universal also makes it more generic. Acceptance Criteria are the specific details that are unique to that individual Product Backlog Item. An example will make this easier to understand. With a software development team, Done might include:

Unit test written for new code
All Code Peer reviewed or Pair Programmed
Acceptance Tests automated
Usability Tests run
Security Review complete
…

For a marketing team creating a website, Done might include:

Page has one H1 tag and three to four H2 tags
Two pictures in the webp format and the pictures smaller than 50kb each
Pictures have alt text
All links on the page have been tested and link to the intended pages
…

How is Definition of Done different from Definition of Ready?

Definition of Ready describes the state a Product Backlog Item needs to be in before the team brings it into a Sprint. Definition of Done describes the qualities the work must have after the team completes it. Think of Ready as the entry gate and Done as the exit gate.

One important distinction: Definition of Done is a core part of the Scrum framework. Definition of Ready is not part of the framework and should be used with caution. A rigid Definition of Ready can become a bottleneck, holding up work while requirements are perfected. If your team uses one, hold it lightly and keep it thin. See the Definition of Ready entry for a deeper look at the trade-offs.

Key Characteristics of the Definition of Done

Clear and Specific – any team member can read the list and understand what they mean. Not every team member will be able to do all the work promised by Done.
Created by the whole Scrum Team – all teams including the Product Owner and the ScrumMaster are involved in creating Done. Hint: people won’t commit to something if they didn’t have a role in defining it.
Testable – the team should understand how to test or prove each item
Minimum Quality – Done sets the level of quality the team is promising to meet or exceed.

Steps to Defining "Done"

This is just one exercise you can use to come up with an initial definition of “Done”. It is structured to ensure that the voices of all team members are heard.

The Product Owner lays out their high-level needs. Remember, focus on qualities (e.g. no memory leaks) and not business needs.
Working in small groups, (e.g. 2-3) team members brainstorm the individual elements required to meet those needs, (e.g. Load Tests run) and other things they judge necessary, (e.g. Unit Testing).
Combine the exact matches and similar items. Find the outliers. Group work/Silent sort – best done with the most senior people going last and not first.
Eliminate suggestions that the group feels don’t make sense.
Team members decide on their own how frequently each element of “Done” can be met per: Story, Sprint or Release – as it stands today. There is a strong preference to get truly “Done” every Sprint. However at first some teams won’t.
Team members vote/agree on where items fit today, (e.g. Story/Sprint/Release).

At this stage we post the list on the Task/Story wall. Often the team adjust their columns on the wall to match the “Done” criteria.

If the team decided on “Undone” work (e.g. work delayed until Hardening Sprint), then they need to make that clear as well. They then need to clear a plan to ensure that they eliminate the Hardening Sprint over time.

Improving the Definition of Done Over Time

One area of misunderstanding is that some team members expect that Done changes every Sprint. If that happened, the product’s quality would be very inconsistent. Imagine if one Sprint the team released features with Automated Acceptance tests, and the next Sprint they don’t even have Unit Tests. Scrum Teams should have the same Definition of Done, Sprint over Sprint. This gives the Product Owner consistent expectations around quality. As a team becomes more skilled and automates some steps in Done, then they should make their Done stronger or more rigorous. While this takes time, the increase in rigour will reduce the number of defects in the long run.

Impediments or Problems in Achieving Done

When a team is new, they find it hard to achieve Done. As a result, the Product Owner can’t be sure if it is okay to ship the product. Many of these problems are from lack of skill or knowledge in something that affects Done. In our software team example, the team might have limited knowledge around Automating Acceptance Tests. Our marketing team might lack the graphics design skill to produce their own images. Cross-skilling and pairing (with someone outside the team) are going to be the approaches that help the team grow until they always produce a releasable product.

The other problem to achieving Done is pressure to deliver more features (or User Stories). As the pressure builds, the team may respond by compromising on Done. In the short term this appears to be fine, as they appear to get more work finished. In the long run, the increase in bugs inevitably offsets the value of the added work. Each shortcut accumulates as technical debt, making future work slower and more error-prone.

Trying to stuff more work into the pipeline always fails. Instead of more work, the organization needs to a better job deciding which Product Backlog Items will deliver the most value and prioritize those. The Team themselves need to start Sprint Planning with a clear understanding of their own Definition of Done. During Sprint Planning, they only take on work that they can bring to truly Done.

Undone Work

When a product is not truly releasable at the end of Sprint, the difference is often referred to as Undone work. Why is this a problem? It’s a problem because it reduced transparency. The Product Owner and clients think the team have completed work on those User Stories. Yet the work isn’t complete. Here are a few examples of how the work that looks finished, but doesn’t meet the Definition of Done, becomes a problem later:

A bug is found several Sprints after the code is written and now new code relies on the defective behaviour.
Missing a security audit, the application is susceptible to a SQL injection attack.
Missing a usability review, the new User stories are difficult for the client to use (e.g. colour blindness, …)
The Application is deployed and doesn’t work with the current firewall configuration.

Non-Software Examples:

Lacking alt text, pictures displayed on a page are undetectable to blind users.
Large pictures mean the page takes longer to load and clients abandon the site because they’re bored of waiting.

Scrum expects that, at a minimum, the product be “Potentially Releasable” at the end of Sprint. This reduces risk and allows the Product Owner and the client to have confidence that User Stories the team claim to have Done, are truly Done.

Limitations of Done

The team need to be honest about what is Done and what is not really done. The bigger challenge is for teams that work on a variety of Products. For example, a non-software team that is doing marketing work might have a number of different work products: a website; videos; artwork; Google ads; Facebook ads; … . In this case, the Done will become very fragmented and will be harder to use. But Done is perhaps even more important in these cases because it acts as a reminder for someone who less familiar with the work of all the things that need to be completed to deliver high quality.

Can Done be used as an auditable checklist for reporting?

Eewww. This sounds very traditional. I only include this because I’ve seen this with clients and we need to stamp it out. Definition of Done is for the Scrum Team to understand the quality of the product they’re creating. It’s not a reporting standard. From the teams I’ve heard from, using it as a reporting standard leads to micro management. Someone reads or hears a report related to Done and asks the team to stop doing some aspect of Done, so they can produce more User Stories. As shown above, this always leads to an increase in defects weeks or months after the initial decision was made.

Developers

Wed, 28 Jul 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

If you thought that ScrumMaster was a poorly named role in Scrum, check out Developers. In recent years, the ScrumGuide has been making changes to help people outside of software see that they can fit into the game of Scrum. Excellent. However, the 2020 change from "Development Team" to "Developers" just made the situation worse.

The Scrum Guide says, “Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.”

I wish it called them the “Doers” or the “Great People who get stuff done”. Perhaps we couldn’t put that in the ScrumGuide, but it gets the point across. The common misunderstanding is that, since they’re called Developers, they just write code, except nothing could be further from the truth. If you’re building software, the “Developers” are responsible for building from beginning to end. That includes UX, Testing, Test Automation, Creating Acceptance Criteria, … and even (gasp) writing the code. If your product is outside of software – for example an educational website – they’re responsible for the writing, editing, finding pictures, formatting as html, and even sourcing/creating supporting videos.

To achieve this, we assign Developers some responsibilities:

They plan the work.
They replan the daily work toward the Sprint Goal (they use the Daily Scrum to make this happen).
They focus on delivering quality, using their Definition of Done as a measuring stick.
They’re transparent with themselves and the Product Owner about the current state work.
They solve their own problems without waiting for outside help.
They put real effort into continuous improvement.
They collaborate towards achieving the Sprint Goal.

To learn more about the Doers, see: Scrum by Example: Stories for the Working ScrumMaster. It's focused on the ScrumMaster role, but the series also provides many examples of work in a team.

Specialists Are Overrated </LinkList>

Characteristics of a Great Scrum Team - this has an excellent summary of the developer role in addition to the other roles
The Role of the Developer in a Scrum Team </HighlightBox>

Dependencies

Mon, 08 Feb 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

Distributed Teams

Mon, 08 Feb 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

DISTRIBUTED TEAMS BOOKS

From Chaos to Successful Distributed Agile Teams – Johanna Rothman and Mark Kilby
Work Together Anywhere: A Handbook on Working Remotely—Successfully—for Individuals, Teams, and Managers – Lisette Sutherland, Kirsten Janene-Nelson [AMAZON]
Zapier – The Ultimate Guide to Remote Work (Free Download) – Wade Foster </HighlightBox>

DevOps

Wed, 12 May 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import DevOpsMindsetKanbanBoardSimple1024x230 from '@/content/glossary/devops/images/DevOps-Mindset-Kanban-Board-simple-1024x230.png';

import HighlightBox from '@/components/global/highlight-box.astro';

DevOps (also now DevSecOps) is the practice of Development working more closely with Operations. Over time, the Developers automate various aspects of their deployment. In doing so, they reduce the number of defects in the process (by eliminating manual steps) and speed the rate at which applications are deployed. DevSecOps takes these ideas and integrates security into the process. One view is that DevOps is simply a Scrum Team expanding their Definition of Done downstream until their application is deployed. That also hints that the work should be done inside the Development Team and not by a downstream group (there are no "DevOps Teams").

A Practical Guide to Testing in DevOps - Katrina Clokie </HighlightBox>

Diversity

Wed, 20 Sep 2023 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Diversity in Agile helps reduce the risk of problems created through cognitive and other biases, by ensuring the Scrum team has access to a wider range of ideas.

We all suffer unintentional biases sometimes. This isn't because we're bad people - it comes from our personal experiences and the environments we have lived in. As a result, we might make assumptions that don't fit reality. If we do that, we build poor products. For example:

Facial recognition software recognizes white men well and black women not so much
Google's photo recognition software tagged black people as gorillas and monkeys
Apple HealthKit in 2014 recorded blood pressure, but failed to take into account women's menstrual cycles

Clearly the above examples are unacceptable and offensive, even when unintended. A diverse group would have a wider range of experiences and references, so would be better at noticing different things – usually sooner (before they become public embarrassment), or avoiding them completely. The benefits of diversity don't stop at having different ideas. Once shared, the ideas can be recombined to create new solutions to problems. This is so powerful, the design firm IDEO has built it into the way they work: "great design is best accomplished through the creative friction of diverse teams and not the solitary pursuit of brilliant individuals".

Cross-functional Agile teams build in a degree of diversity automatically by mixing people across skill areas. However, that alone isn't enough if the team members all have similar education and backgrounds. What we often miss is cognitive diversity. This comes from many sources including personal background, interests and life experience. A parent of young kids will notice different things than a younger, single colleague will. Someone who grew up in a grittier Toronto neighbourhood will see things that a suburban dweller doesn't.

There are, of course, risks. Diverse groups might have problems with both inclusion and conflict.

Inclusion – Let’s imagine that you hire someone new because you recognized that your team lacked diversity. They join the team and, after the first week where everyone makes an effort, you see that this person isn't naturally included in the team's conversations. Even when they are included, the language has a shorthand that doesn't make sense to them.

People aren't necessarily being rude. When a new team member has a different communication style, sometimes it’s easier to ignore the disconnect than work through the differences. In addition, a team that has worked together for some time won't even notice that their conversation is sprinkled with things that don't make sense to an outsider. Consider revisiting the team’s Working Agreements to address inclusivity, revisit psychological safety, and perhaps run a survey to sense the current level of safety. You can also try changing activities in the events and meetings to give equal voice and, finally, conducting one-on-ones with people who might start to bridge the gap.

Conflict - People who frequently express different opinions can create conflict. This is much easier to solve if the preventative work is done upfront. We need to create an environment with an emphasis on Psychological Safety, and create working agreements around taking the time to understand other people's ideas before critiquing them. When the conflict comes from a difference in perspective or understanding, I ask the people with strong opinions to take the time to explain the other person's idea back to them. This works on two levels. First, it proves that you understood their idea well enough to explain. More importantly, when we have to explain someone else's idea/perspective, we take time to empathize with their position. Often in doing so, we change our own thinking.

When trying to increase diversity, hire or select, not for cultural fit, but for people who can bring new ideas or understanding to the team. Increasing diversity is clearly the right thing to do from a human perspective, and I hope we can see that it creates better Scrum teams as well if we're prepared to deal with the challenges.

Examples of how it helped:

Examples of where lack of diversity hurt:

Effective Teams

Mon, 16 Sep 2024 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Calling a group of individuals a "team" is only a label, unless they're organized and empowered with distinct characteristics to allow them to function effectively.

Too many teams struggle with Fake Agile and Bad Scrum. They know about velocity, tickets and pressure to deliver more story points faster, but they aren’t able to reach high-performance. This list is designed to get us out of that trap so we can start thinking – and functioning – as a real team, and reaping all the benefits that come from Effective Scrum:

Healthy teams, unhealthy teams: in your experience, what makes them so? </HighlightBox>

Dot Voting

Wed, 03 Nov 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import DotVoting1024x683 from '@/content/glossary/dot-voting/images/dot-voting-1024x683.jpg';

import HighlightBox from '@/components/global/highlight-box.astro';

Dot voting is a mechanism to help an Agile team select a single item from many or prioritize among a number of options. It's a remarkably simple tool. We give the players an equal number of votes or dots. They place their dots on the item or items that are most important to them. It differs from straight up majority voting in that people can split their votes across multiple items. To avoid vote splitting across similar items, the team should do a round of grouping before voting.

The above example was used by a group at an organizational retrospective to decide what items they should address.

Dot voting is the Agile community’s poster child for decision-making techniques that have some kind of weakness. Since dot voting is usually done with people walking up to a poster or wall to place their votes, everyone can see which items you voted for. Seeing other people’s votes will influence you and, of course, seeing a leader’s vote will influence everyone. This weakness can be overcome if all the votes are placed blindly. In the virtual world many tools like Mural, Miro and Stormboard build in a dot voting mechanism and make it blind to everyone including the facilitator.

The other challenge is that you can see that people voted for an item, but not why they voted against another, missing an opportunity to improve it.

Empathy Map

Wed, 02 Feb 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Empathy Maps are a tool to help us record what we understand about our audience. The maps prompt the team to answer questions about what the users do, say, hear, see, etc. In the course of building the map the team gains greater empathy for the users.

All of this work is predicated on the idea that the team has conducted enough interviews with a range of end users to have sufficient data to draw on.

The map is focused on the users and not the product because we don't want to get stuck with our preconceived notion of what the product should be.

Ensemble (formerly Mob) Programming

Wed, 05 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Ensemble Programming (formerly known as Mob Programming) is the logical extension of Pair Programming. The entire team work together to deliver a single Product Backlog Item (or User Story). They work using the same computer, at the same time. They do all of the steps of their development process together, from requirements -> code -> testing (and any other steps you want). Typically one team member acts as the "driver" - actually writing the code or the tests. While the rest of the team ask questions, make suggestions etc. The normal rule is that the person writing code, should only write things that the others suggest to them. People take turns, driving so that everyone gets time at the keyboard.

Because the entire team focused on one story at a time, then it is truly Limiting WIP. Furthermore, teams that do this tend to have higher throughput because of better quality. This also helps with knowledge sharing and cross-skilling.

Mob Programming Books:

Code with the Wisdom of the Crowd - Mark Pearl
Remote Mob Programming - Dr. Simon Harrer, Martin Huber, and Jochen Christ </HighlightBox>

Explainer Video MVP

Thu, 23 Jan 2025 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import YouTube from '@/components/global/youtube.astro';

Back at the beginning of time (ok, 2007), we didn't have ways to easily share files on the internet. At that point, if I promised file-sharing software that was easy to use, it would have sounded like science fiction, and you wouldn't have believed me. Instead of building science fiction and risking no interest, Dropbox first validated demand with a simple landing page description while simultaneously building prototypes. Once initial demand was confirmed, they created a simple video explaining how their product worked, targeting early adopters. In the process, Dropbox acquired 70,000 new customers (I might have been one of them).

Explainer Video Key Elements

Process: Create a short, simple video that tells the story of a real person solving a real problem with your product. This is not a sales pitch. You're telling a story.
When to use it: Use it when your solution requires education. It can gather feedback on your product idea before there is anything to show or after initial market evaluation. It's low-cost and so low-risk. It can be used in multiple situations: Business-to-Consumer, to attract people through advertising or word of mouth; Business-to-Business, in addition to ads, to get your sales team to use it. Inside a company or government, share with your internal audience.
Measurement: How much do they watch? Click-through rate or call to action? Conversion rate?

In a world full of AI slop, I would be tempted create Explainer Videos with simple hand-drawn images. Something that conveys the idea and makes it clear that real people are involved.

Pros and Cons of Explainer Videos

Pros: They're easy to make and low-cost. You can build them in-house, and before you have any product.

Cons: There are many videos on the internet; it's hard to stand out, and you need to spend advertising dollars to get people to watch them.

Explainer Videos are one type of Minimum Viable Product.

Dropbox's MVP Explainer Video Case Study
Dropbox MVP Explainer Video Lean Startup story </HighlightBox>

Estimation

Thu, 18 Feb 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

An estimate is a qualified guess to help people make a decision about doing work. In the Agile world, one approach to estimation has become prevalent: the combination of Planning Poker and Story Points.

Story Points are past time, according to Ron Jeffries and Chet Hendrickson, the people who created them. Hendrickson has said, "As one of the folks that sort of started all of this, let's say that it was the best we could think of in 1996, by 2001 we had discovered better ideas, and by now it should have been kicked to the curb long ago."

The benefit of Story Points was the speed at which the numbers could be generated, but among their many faults was that they fail to make clear the uncertainty, they're often used as a commitment and, worse, for comparison of teams.

Commonly used estimation techniques:

Story Points and Planning Poker
Bucketing, which is where a team sort a large number of Product Backlog Items into clusters using numbers that look like story points - Good for sorting through a large list of items.
T-Shirt Sizing, where the story point numbers are replaced by Small, Medium and Large. Anything classified as Medium or larger needs to be split before being worked on in a Sprint.
Simply count the number of product backlog items. If the Product Backlog contains a number of large items, notice on average how many small items they decompose to. Use that as a rough multiplier to go from large to small.
Abandon estimation and focus on Forecasting instead.

Blind Estimation for Planning Poker
Scrum By Example: Learning How to Estimate </LinkList>

CHALLENGES

Software Estimation withoutGuessing - George Dinwiddie </HighlightBox>

Facilitation

Mon, 08 Feb 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import KanerDiagramOfParticipationDivergentThinking1024x557 from '@/content/glossary/facilitation/images/Kaner-Diagram-of-Participation-Divergent-Thinking-1024x557.jpg'; import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Facilitation is the art of helping a group of people reach agreement or understanding, without direct involvement in the process itself. In the game of Scrum, facilitation is explicitly required in the events of Sprint Planning, Sprint Review, and Sprint Retrospective. In addition, we would expect facilitation to be part of Product Backlog Refinement and whenever the opportunity arises.

A good facilitator doesn't just make sure others are heard, they make sure that others are understood.

Facilitators need:

Empathy
Patience
To stay Neutral - you're there to make sure that your group reach their own conclusions
Active Listening Skills
Understanding of Group Dynamics (see the Groan Zone picture)
...and perhaps PhD 👩🏽‍🎓 in Behavioural Psychology

A good facilitator will always have an agenda or plan for an event. A great facilitator will allow the plan to float out the window and adlib if the group needs it.

Remote Teams

Tools List

Virtual Collaboration tools - a massive list of options </HighlightBox>

Facilitator’s Guide to Participatory Decision-Making – Sam Kaner
Collaboration Explained: Facilitation Skills for Software Project Leaders – Jean Tabaka
Where the Action Is: The Meetings That Make or Break Your Organization - J. Elsie Keith </HighlightBox>

Extreme Programming

Mon, 08 Feb 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Extreme Programming
What is ExtremeProgramming? </HighlightBox>

Extreme Programming Installed – Ron Jeffries, Ann Anderson, Chet Hendrickson [AMAZON]
Extreme Programming Explained: Embrace Change - Kent Beck, Cynthia Andres [AMAZON] </HighlightBox>

Failure Bow

Thu, 06 Nov 2025 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

In many organizations, Failure is a dirty word. Yet it is inevitable. When we try to hide a failure, our stress levels increase, and it becomes harder to recover from the mistakes we make. Enter Matt Smith, an improv performer and inventor of the Failure Bow. Improv results in a lot of failure, and so finding a way to get over it is essential. From personal experience, when I feel I'm failing in improv scene, it is increasingly hard to support my scene partners.

The Failure Bow is a simple technique, one I often use in my workshops. Here's how I do it:

Stand up and bow
Say "I failed at ...."
then "here's what I learned from it."

If a group has never seen this before, there will be some nervous laughter. But it’s a great teaching moment. I'm showing the group that it's okay to admit failure. In future, the group will be more willing to admit their own mistakes.

As the person who is failing, I also gain because it reduces my stress levels, I've acknowledged my mistake, and I can focus on recovering from it.

Used well, the Failure Bow also helps improve the team's feelings of Psychological Safety.

The Failure Bow: Matt Smith at TedX
The Failure Bow - Tobias Mayer is the person who introduced me to the concept.
The Failure Bow - Bob Galen also warns of potential pitfalls.
HBR - Go Ahead Take a Failure Bow </HighlightBox>

Failure Demand

Thu, 07 Jul 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

"Failure demand is demand caused by a failure to do something or do something right for the customer." - John Seddon 2009

All work a team does comes from some source of "demand". These can be new features requested by a customer or the Product Owner. They can also be defect reports, usability issues, and a whole host more. Some of these requests ("demand") are adding new value, and some of these are making up for past problems - the failure demand.

When we see service and product teams dealing with a high volume of requests, it can be very instructive to look, roughly, at how much of the work comes from new value requests and how much is the failure of the system/product to meet the customer's needs in the first place. With some operations teams, over 80% of their work effort is spent dealing with failure demand. In situations like this, attempting to improve other parts of the system without addressing the failure demand is a waste of time.

Examples: - When John Seddon coined the phrase, he was working with DEC trying to help them sell more computers over the phone. Ideally, the phone agents would be talking to customers about their computer needs and sell them more computers. In practice, when they talked to customers they discovered the customers wanted help with the existing problems: documentation, billing, missing parts for existing orders. This demand was a failure of the system to deliver what was needed. Hence the term "Failure Demand". - At a pub during high demand periods, the kitchen would often cook the wrong food, undercook it, or burn it. So if the demand was 100 meals, the mistakes the kitchen made meant they might have to cook 150 meals in total. This in turn led to longer delays, customer dissatisfaction and, of course, reduced profits. - An insurance company reshoring (from India to the UK) their call centre discovered 70% of the calls to the call centre came from contract specifications that were too rigid and left agents no room to respond to customer needs.

Seddon (the ideas originator) says to make your measurement a snapshot. Use it to create awareness of the problem, then put the effort into fixing the system, not monitoring.

Fake Agile - Anti-Pattern

Mon, 07 Feb 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Agile's success is also its Achilles heel. Everyone wants to do Agile, but not everyone wants to make any changes to be Agile. There is a lot of focus on performing ceremonies, yet organizations often don't take the time to understand the mindset. Like their close relative AntiPatterns, more ways to do Fake Agile exist than can be counted. Here are just a few:

No customer involvement
Agile means no testing
Focus on Output measurement (hello velocity) and not Outcomes (value to happy customers)
Low communication
No Engineering Practice
Slow rate of improvement
Saying 'yes' to all requests from stakeholders
...

Agile Theatre is Doing More Damage Than Waterfall Ever Did.
A bleak outlook for public sectortech
Detecting Fake Agile – US DOD
How the Efficiency Mindset Leads to Zombie Scrum - The Liberators have masses on Zombie Scrum
Imposition and Dark Agile
What is Fake Agile? How to identify it?
What is Fake Agile? Understanding the Dark Side of Agile and How to Avoid It </HighlightBox>

Failure Modes

Wed, 12 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Failure Modes Books:

Rolling Out Agile in a Large Enterprise - Gabrielle Benefield </HighlightBox>

Feature Factory - Anti-Pattern

Tue, 27 May 2025 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Weak (or absent) Product Owners lead to team members working in a Feature Factory. John Cutlefish coined this term in 2016 to describe a software developer who complained that they spent their day in a cubicle, just shipping features.

I see this happening for many reasons:

Rigid roadmaps, often published with dates more than a year in advance
Team members who don't understand the vision or the strategy
Limited discovery work with clients
Team members not involved in the discovery with clients
Non-stop urgency and fires
Organizations that obsess over velocity
Focus on output (number of widgets) instead of outcome (solving the customer problem)
Siloed teams and handoffs
Ignoring technical debt
Features never updated or removed

If we want to move away from the Feature Factory, we should focus on outcomes. Use either a Lean Startup approach or have a clear Product Vision and a Strategy (consider Impact Mapping and Story Mapping). Involve team members, not just in the regular backlog refinement, but also in the discovery work. Ask, did our solution help the customer? Measure the impact. Run experiments with customers (hint: Lean Startup or Lean UX) and be prepared to kill features that didn't solve their problem.

Moving away from being a Feature Factory to an Outcome Driven Organization makes the work more fun, and it also leads to a more profitable business.

12 Signs You're Working in a Feature Factory - John Cutler - the original article on the subject
Feature Factory - 3 Years Later - Cutler focused on how to escape the trap
14 Signs You're Working in a Feature Factory </HighlightBox>

Fake Door MVP

Thu, 23 Jan 2025 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import Figure from '@/components/global/figure.astro'; import FakeDoorMVP from '@/content/glossary/fake-door-mvp/images/fake-door-buffer-mvp.png';

Fake Door MVP lets you test interest in a product or feature before there is anything at all. Joel Gascoigne, the founder of Buffer, wanted to test if anyone would be interested in a tool that lets you post to Twitter more consistently. (This was 2010, Twitter was the place to be.) His initial test was a simple landing page describing the idea, followed by an email sign-up. Once initial interest was validated, he introduced a pricing page before the sign-up, which then led to a message saying, 'Sorry, we're not ready yet.' This allowed him to test both interest and willingness to pay.

Fake Door Key Elements

Process: Create a simple landing page with your offer. Have a clear and compelling Call to Action (CTA). In some cases, organizations use a fake brand to test interest, without revealing their real name.
When to use it: Validate Demand with minimal effort. Along with a landing page, it can even be used in an existing product to see if anyone is interested in a new feature.
Measurement: Do people click on the button? Do they answer the CTA? i.e. Do they sign up to be told when the product is available?

As AI slop takes over the internet, I would seriously use simple hand-drawn images to make it clear that there are real people and not just an AI.

Pros and Cons of Fake Door

Pros: They're easy to make and low-cost. You can build them in-house, and before you have any product. Time and money are saved by not building something that no one wants.

Cons: How will people find your landing page? Likely paid ads. Also, overuse or unethical implementation can damage brand credibility, so transparency and restraint are key.

Fake Door is one type of Minimum Viable Product.

Image attribution: Buffer Fake Door image from: https://buffer.com/resources/idea-to-paying-customers-in-7-weeks-how-we-did-it/

Feedback

Wed, 17 May 2023 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

The Situation-Behavior-Impact™ Feedback Tool </HighlightBox>

Forecasting

Thu, 18 Feb 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Forecasting in the Agile world asks the difficult questions: How much of our product backlog will ready by a certain date? or By which date a specific feature will be ready?

Many teams attempt to forecast by measuring their Product Backlog in Story Points and dividing by the average number of story points achieved per Sprint. This is rarely effective.

Red Yellow Green Status Reports and the lies they tell

Forecasting Tools

Focused Objective – Collection of Forecasting Tools a gold mine
Forecasting Using Data – Common Questions Answered [PDF warning!] </HighlightBox>

Forecasting using Data - a free eBook - Troy Magennis
When Will it be Done - Dan Vacanti </HighlightBox>

Impact Mapping

Thu, 22 Apr 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import ImpactMappingWSOBSExample3 from '@/content/glossary/impact-mapping/images/impact-mapping-WSOBS-example3.png'; import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Impact Mapping is a tool to help teams focus their work on the feature by identifying portfolio items or strategic changes that will have the greatest effect on achieving their goal. Impact Maps are intended to be drawn, and not just written in words.

Want to Get the Most Bang for Your Buck? Try Impact Mapping </LinkList>

Impact Mapping: Making a big impact with software products and projects – Gojko Adzic
Inspired: How to Create Tech Products Customers Love - Marty Cagan </HighlightBox>

Impediments

Fri, 10 Nov 2023 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

In the context of a Scrum team, anything that slows the team’s progress towards the Sprint Goal is an impediment. And since one of the primary responsibilities in the role as Scrum Master is removing impediments to the Scrum team’s progress, it’s important to have a clear understanding on this point.

All too often I hear Developers in Daily Scrum mention the same chunk of work 4-5 days running and say, “No Blockers.” Why is that? Experience tells me there is a heap of factors, but the biggest seems to be that we don’t have a common understanding of what an impediment is.

Understanding what is an impediment in Scrum

According to the Cambridge Dictionary, an impediment is “something that makes progress, movement, or achieving something difficult or impossible”[^1].

But in Scrum, it goes further. And until our teams recognize what impediments are, they can’t get resolved. For example, these are all Scrum impediments:

Low bandwidth connection while working from home
Email interruptions
Slack or MS teams scrolling messages at an alarming rate
Interruptions - People outside the team asking for help (either other teams or management)
Lack of information (e.g.. interacting with a poorly understood legacy system)
Missing technical knowledge or skills
Waiting for another team
Waiting for a third-party vendor
Team member out sick
Access or permissions problems that prevent team members from accessing a server or making database changes
Language or cultural barriers with an offshore team
Poorly understood Product Backlog Item/User Story
Low understanding how this Product Backlog Item fits into the overall product and delivers value to the customer
Slow computer
Frequent broken builds
Poor quality chair or desk, small computer monitor
Slow decision-making
Changing requirement mid-Sprint
Bottlenecks in the Team (e.g. worked piled in front of Business Analysts, Developers or QA)
Too many cat photos in the team's Slack stream 🙂
…

Anything that slows the team’s progress towards the Sprint Goal is an impediment.

Spot the Problem

There are a couple of tricks and tips that I’ve found to help make impediments more apparent. First, change the word to “slowdowns” – it’s a lot easier to admit to being slowed by something, than it is being impeded (which suggests stopped). Go deeper as the Certified ScrumMaster, and look at the Sprint Backlog or Kanban board to spot items that have spent several days in the same state (e.g. “In Progress”, “waiting for test” etc.). These items are likely impeded by something.

Is work piling up? Sometimes bottlenecks or missing skills create impediments. Too many teams don’t even notice that they have bottlenecks, but they’re great indicators of areas where cross-skilling will be a benefit and make the team more efficient.

How to remove impediments in Scrum

The Scrum Guide says the Scrum Master can act as an impediment remover by “causing the removal of impediments to the Scrum Team’s progress”. This sounds comically obvious and simple on the surface, and yet it gets misinterpreted. Too many teams think that it’s the Scrum Master’s job to directly remove the impediments. “Scrum Master, I’m out of coffee (or sticky notes), can you get me more?” This is clearly ridiculous. A good ScrumMaster helps the team learn to remove their own impediments. They aren’t a magician who waves a wand and does it all for you.

Even if the Scrum Master were to remove all impediments, the team would only learn that when they had a problem the Scrum Master would solve it for them. The Scrum Master would turn into a babysitter – an unwelcome prospect.

So what’s effective? This is where the ScrumMaster role can have a huge beneficial impact by promoting self-organization, and striking a balance between firefighting problems that crop up and preventing the impediments in the first place.

When there is a problem, I encourage Scrum Masters to ask their team member(s):

what they already tried toward solving the impediment
if they asked the rest of the team for help
whether they ever had similar problems before and what worked in resolving those

Tougher than it looks

If all of the above has been explored and the impediment to the Scrum team still remains, the problem is probably beyond the capacity of the team to solve on their own. However, before running around problem-solving, there is still more work for our Scrum Master to do, to be able to fix anything effectively. They should explore:

Is this the first time we’ve had an impediment like this?
If this is a repeated impediment, why has it reoccurred? (Hint: often because the last solution was a band-aid fix.)
Do we need to address this immediately or can the challenge become a learning opportunity for the team?
What else is going on here?

That last point is probably the most important, but hardest, one to deal with. Instead of using the popular but weaker techniques of 5 Whys or Root Cause Analysis[^2], dig into Systems Thinking to find the underlying issues. Use this understanding to address the real issues in the system, and not just the surface-level problems.

The Scrum Master role when impediments occur

The Scrum Master shouldn’t solve impediments on their own. It’s important that they give the team autonomy and let them self-organize. Encourage them to take ownership and find their own solution to many impediments.

When an impediment is one that the team can’t solve themselves, then the Scrum Master’s responsibility is to step in. Review team history for similar impediments. How were they resolved (or not)? What were the underlying causes? By identifying the real problem, and not just the surface issue, the impediment can be removed permanently, and not affect the team’s progress again in the future.

[^1]: Cambridge Dictionary [^2]: These approaches are weaker because they tend to find recent things and not the deeper problems.

<LinkList heading="Agile Pain Relief Blog Entries"> - Beyond the Surface: GenAI-Powered Critical Thinking for Deep Team Issues - Scrum Without Removing Impediments Isn't Scrum - Scrum by Example - Impediments are Holding Back the Team - Unpacking Interruptions: Why Your Team Struggles to Get Things Done - Scrum By Example - Interruptions Hurt the Team

Scrum by Example – How to Handle Production Support Issues in Scrum </LinkList>

Improvement Experiments

Mon, 10 May 2021 00:00:00 GMT

import CalloutBox from '@/components/global/callout-box.astro'; import Figure from '@/components/global/figure.astro'; import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro'; import AgendaShiftA3ExperimentTemplate from '@/content/glossary/improvement-experiments/images/AgendaShiftA3Experiment-Template.png';

Agile teams attempt to use Retrospectives as a tool for Team Improvement. Yet our improvements often lead nowhere. Instead of stating vague improvements like: "We should get better at..." consider creating experiments to test your improvements.

Each improvement is a small experiment designed to test a specific idea. The team predicts that a specific change will lead to the desired outcome. Success or failure, we still learn something about how we work. Like everything else in Scrum, experiments are iterative and adaptive. (Much like Evolution.) Each Sprint, we try something new, observe how it works and make adjustments in the next Sprint.

Well-Structured Experiments

A few key elements make experiments clearer and so more likely to succeed.

Measurable Outcome Look for a measurable outcome, instead of saying “We should get better at X." Define what "better" means. Perhaps the team wants to improve automated acceptance tests. The experiment might be stated as: by the end of the next Sprint, a number of user stories will have automated acceptance tests. (That assumes the team has a clear understanding of what a good acceptance test looks like.)
Part of the Sprint The other key element is to make the experiment part of the Sprint. I remind the team during Sprint Planning, and we add them to the Sprint Backlog. During the Daily Scrum, I want to hear the team talking about their experiments. Finally, in the Sprint Retrospective, we review how the experiments went and use the results to inform the next set of experiments.

Experiment Templates

Improvement Stories: These follow a format like "In order to [achieve a goal], as a [role], I want to [perform an action]. We will know we have improved when [measurable outcome]." This structure ensures the value, action, and measurement are clearly defined.
Experiment Templates (e.g., A3): These provide a more formal structure for defining the problem, proposed solution, expected outcomes, and how success will be measured.

Examples of Experiments

Limiting Work in Progress (WIP): The team might experiment with limiting the "Development in Progress" column to a specific number of items, with the goal of reducing average cycle time.
Reducing Testing Time: Experiments involving cross-skilling team members to run test cases independently or implementing regression test automation, with the aim of decreasing the time items spend in the testing phase.

Warning, many good experiments require more than one Sprint to demonstrate their value. For example both the WIP and Reducing Testing Time experiments will require 4-6 weeks before we start to see noticeable improvements. Setting expectations up front is important.

<CalloutBox heading="Experiments are Key to Effective Scrum"> The improvement experiment is at the core of our eBook: The Guide to Effective Agile Retrospectives - hint: plan your improvements into the Sprint, track them on the Sprint Backlog, and review them in the next Retrospective. </CalloutBox>

<LinkList heading="Agile Pain Relief Blog Entries"> - Scrum by Example – Same Old Song in Sprint Retrospective - Be Better with Better Data - Bringing your improvement experiments into your Sprint: The Humble Sprint Backlog - Two Key Things for Retrospective Facilitation - Improvement experiments can be applied at an organizational level: Agile Change or Adoption: Define Small Organizational Changes </LinkList>

Plan of Action - the simplest approach here
Improvement Stories - using an approach like User Stories to create actionable change
A3 Experiment Template - a full blown experimental model </HighlightBox>

Interruptions

Tue, 02 Mar 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import UnpackingInterruptions from '@/content/blog/unpacking-interruptions-why-your-team-struggles-to-get-things-done/images/unpacking-interruptions.jpg'; import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Team members get interrupted throughout their working day. Some of the interruptions are high value - e.g. a team member asking questions that helps the team stay in flow. Some are important, such as a production support issue, although we should understand their cost to see where to improve our system. In other cases, the interruptions are from outside the team and most of these interruptions should be blocked by the ScrumMaster or Product Owner, and redirected or saved for a better time.

Deep Work Is a Multiplier for Engineering Organizations
A Diary Study of Task Switching and Interruptions
The high cost of interruption visualized
Impact of task switching and work interruptions on software development processes
Interrupts: Just a Minute Never Is
Managing Sprint Interruptions by Tracking Buffer Use
Programmer Interrupted Key quote: A programmer is likely to get just one uninterrupted 2-hour session in a day
Programmer Interrupted: The Real Cost of Interruption and Context Switching
Worker, Interrupted: The Cost of Task Switching
What’s the cost of interrupting developers?
What is Focus Time and how does it impact productivity? </HighlightBox>

INVEST

Thu, 08 Jul 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Good User Stories can be measured against a simple set of criteria: Independent – Stories should not rely on each other. Dependencies between Stories limit the flexibility of both the Product Owner and Developers. The Product Owner should be able to ask for Stories in whatever order they value.

Negotiable – The Story is not a contract. It is an invitation to have a conversation around the actual need. It gives the Product Owner and team a chance to delay unnecessary decision-making until implementation begins. It allows the team to discover new options right up until they're done.

Valuable - Each Story needs to deliver some small sliver of value all on its own. In other words, the customer has to be able to see the value. This pushes us towards slicing our work into vertical chunks and not technological layers. In addition, this prevents writing "Infrastructure" User Stories. Scrum and XP take the view that Infrastructure should only be built to solve the current problem.

Estimable - If the team, through lack of experience, can't estimate a Story, they shouldn't fake it, and instead, they should run a short experiment to gain that experience. These experiments are called Spikes.

Small - Stories at the top (approximately the next 3 Sprints) should be small - so small that the team should be able to get 5-10 similar-sized Stories completed every Sprint.

Testable - It is clear how you will test this

Iterative and Incremental Development

Tue, 27 Jul 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Iterative and Incremental Development is fancy language for working in cycles and always releasing a version of the product at the end of a cycle. In Scrum that cycle is called a Sprint and the increment is expected to have releasable quality. This is done as designed Scrum Teams produce releasable quality products at the end of every Sprint. More advanced teams discover Continuous Delivery and Deployment, and the best teams discover DevOps.

Evolutionary Design - What Most Dev Teams Get Wrong
Iterative and Incremental </HighlightBox>

Kanban

Fri, 30 Apr 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import CSMSampleScrumTaskBoardV2895x1024 from '@/content/blog/the-humble-sprint-backlog/images/2017CSM-Sample-Scrum-Task-Board-v2-895x1024.jpg'; import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Kanban isn't just a board that you find in JIRA or Trello. It is a method to help improve the flow of work through a system. A kanban board is one way to visualize the work in your system, but use of a board alone will not improve things. Kanban, done as intended, requires discipline and the habit of continuous experimental improvement of the system. (Strangely, it has this in common with all Agile approaches.)

In a kanban approach, the team visualize their work and then improve the flow with attention to:

Limiting Work In Progress (aka WIP),
Unblocking work
Ensuring older items are addressed first
...

Kanban is process agnostic. You can use it with Agile or Scrum Teams, but also in traditional teams. The more you look into kanban, the more you will see that it has much in common with every other Agile approach.

Kanban Case Study

Large-Scale Kanban at Bosch Automotive Electronics

Games to Learn Kanban

Kanban Pizza Game template https://miro.com/miroverse/kanban-pizza-game/
Kanban Pizza Game </HighlightBox>

Real-World Kanban: Do Less, Accomplish More with Lean Thinking – Mattias Skarin - Kanban from the Inside: Understand the Kanban Method – Mike Burrows - Making Work Visible: Exposing Time Theft to Optimize Work & Flow - Dominica DeGrandis
Priming Kanban – Jesper Boeg - This mini-book offers an easy to follow 10 step guide to taking the initial plunge and start using Lean Principles to optimizing value and flow in your system. Each step consists of a section explaining “why”followed by examples of specific tools, practices and rules that have helped other teams better understand and optimize their system. </HighlightBox>

Lean Software Development

Thu, 29 Apr 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Applying Lean Tools and Techniques to Scrum
Grown-Up Lean - The Nature of Software
Little's Law - The ONE thing you can do to improve process performance - YouTube video </HighlightBox>

Lean Software Development: An Agile Toolkit – Mary Poppendieck, Tom Poppendieck
Implementing Lean Software Development: From Concept to Cash – Mary Poppendieck, Tom Poppendieck
Leading Lean Software Development: Results Are not the Point – Mary Poppendieck, Tom Poppendieck
The Lean Mindset: Ask the Right Questions – Mary Poppendieck
The Principles of Product Development Flow: Second Generation Lean Product Development – Donald G. Reinertsen
Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated – James P. Womack, Daniel T. Jones - the classic Introduction to Lean (as it pertains to manufacturing)
Critical Chain – Eliyahu M. Goldratt </HighlightBox>

Lean Startup

Wed, 28 Apr 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Lean Startup is a way for a group of people with a product idea to test it with the market and gain rapid feedback on whether the world wants what they're building. "Love the Problem, Not Your Solution" - Ash Maurya. In this approach, the team work to discover their biggest risk, and then run a small experiment to validate their choices. Lean Startup is the source of the badly misunderstood MVP and the mis-used Pivot.

Customer Interviews for LeanStartup

The Lean Startup - Eric Ries - The original book that introduced the idea
Running Lean
Ash Maurya - The book I recommend to most people as the most practical intro - Scaling Lean: Mastering the Key Metrics for Startup Growth – Ash Maurya - Testing Business Ideas: A Field Guide for Rapid Experimentation – David J. Bland - Experiments that fit into the Lean Startup model </HighlightBox>

Last Responsible Moment

Thu, 05 Feb 2026 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

The Last Responsible Moment sounds like a fancy name for procrastination, though it isn't. Instead of procrastination, it's about remaining flexible and deciding when we have more information.

A useful framing: think about how much more you'll know about a problem or decision in the future. Is the person sitting here now the same person six weeks from now? Of course, the answer is "future me" will know more. So why lock in a decision today when future-you will be better equipped to make it?

With the Last Responsible Moment, we delay decisions until the cost of not deciding exceeds the benefit of delaying. When we make a decision too early, we bake in the assumptions we were making at the time. When we delay too long, we lose the ability to make the decision altogether.

A practical approach when facing a decision:

When is the last time I could make this decision?
What would I need to know before I make this decision?

This idea appears throughout the Agile Universe, even when we don't name it. All Agile Engineering Practices are about avoiding early decisions. In Product Backlog Refinement, we encourage teams only to refine a few Sprints' worth of work. The list goes on.

The idea of the Last Responsible Moment came to the Agile community via Mary and Tom Poppendieck's Lean Software Development: An Agile Toolkit:

Delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative.

Scrum By Example – Waiting Too Long to Create Acceptance Criteria - When waiting too long causes problems
Story Splitting – a Play – Spike Sherman - INVEST's "Negotiable" principle in action
Story Slicing, How Small is Enough? - Small stories provide flexibility to adapt
Simplicity - Empirical processes over upfront decisions
Reinventing Existing Products – Big Bite vs Small Nibble Rewrites - Incremental vs big-bang decisions </LinkList>

The Last Responsible Moment - Coding Horror
Agile Architecture Myths #2: Architecture Decisions Should Be Made at the Last Responsible Moment - Rebecca Wirfs-Brock
The Last Responsible Moment - Jimmie Butler
The Last Responsible Moment in Strategic Decision Making - HackerNoon </HighlightBox>

Lean Software Development: An Agile Toolkit – Mary Poppendieck, Tom Poppendieck </HighlightBox>

Lean Startup Experiments

Wed, 23 Nov 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

A core concept of Lean Startup is that we need to validate aspects of your product or business idea that are assumptions or that represent risk. Looking at your Lean Canvas (your one-page plan outlining your Customer Segments, Problem you solve, and Unique Selling Proposition, etc.), are you certain that you have your customers well-understood? If you're less sure about whether they have problems you're not imagining, do customer interviews with open-ended questions. Do their answers match your hypothesis or lead you in a different direction? If the hypothesis is validated, fantastic, then it’s time to run experiments and validate your product idea. Example: include a landing page to validate your value proposition.

The list below gives you a start on some experiments to run. See also: Explainer Video, Fake Door MVP, and Wizard of Oz. <HighlightBox heading="Resource Links" variant="resourceLinks">

Testing Business Ideas: A Field Guide for Rapid Experimentation by David J. Bland </HighlightBox>

Agile/Lean UX

Mon, 26 Apr 2021 00:00:00 GMT

import LeanUXProcess from '@/content/glossary/lean-ux/images/LeanUXProcess.jpg' import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro'; import Figure from '@/components/global/figure.astro';

Agile or Lean UX (User eXperience) is about incorporating UX into the flow of work of a development team. Many try the approach of having the UX people work 1-2 Sprints ahead of the development team. This can work, however the pipeline model leads to some additional challenges with work being done on items that change before implementation, therefore wasting the UX person's time. The approach from Lean UX is to instead increase collaboration between UX and the rest of the development team. Over time, this collaboration increases the amount of UX work done in Sprint and reduces the amount done ahead of time.

Abbreviated Principles

Team Group:

Problem (or Outcome) focused, not Deliverable focused
Truly Cross-Functional i.e. includes UX

Culture Group:

Run Experiments to go from Doubt to Certainty
Shared Understanding is key
No Rock Stars or Ninjas

Process:

Continuous Discovery
GOOB - Get Out Of the Building - cute way of saying test with real customers
Making over Analysis

Shortest Summary of the Method

Declare Assumptions - find them in your problem statement and anywhere else you can.
Hypotheses - create testable hypotheses for the most important assumptions that need to be validated.
Outcomes - what outcomes would make each Hypothesis testable
Personas - lightweight proto personas over heavily researched. Favouring testing to discover if we understood our audience. Key parts: Name and sketch; Demographics/Personal Information; Pain Points; Solution.
Features (or user stories) are only created to support outcomes. Don't create features and then seek to justify them; instead focus on the features that support outcomes.

Vision to User Stories - What is the Best Flow? </LinkList>

Book review: “Lean UX”
Book review: Lean UX — Applying Lean Principles to Improve User Experience
How FreshBooks democratizes technical design by applying lean UX principles
Lean UX Explained
an interview with Jeff Gothelf - Lean UX – Getting Out Of The Deliverables Business - an introduction - Lean UX in the Enterprise: 5 hills to climb
Managing UX in Scrum Project - this isn't LeanUX - just another approach </HighlightBox>

Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability (3rd Edition) - Steve Krug
Lean UX: Designing Great Products with Agile Teams 2nd Edition - Jeff Gothelf, Josh Seiden
UX for Lean Startups: Faster, Smarter User Experience Research and Design - Laura Klein
The Elements of User Experience: User-Centered Design for the Web and Beyond (2nd Edition) - Jesse James Garrett </HighlightBox>

Liberating Structures

Thu, 02 Dec 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Liberating Structures are tools that create balance in self-organization, which is at the heart of all Agile approaches. Too often self-organized events and conversations can be either too formal (think: presentation) or open-ended (rambling conversations), which can lead to disengagement. Facilitators can use Liberating Structures to help the team understand the minimum boundaries needed to organize well, and then leave the implementation to the participants, which allows them more freedom to self-organize. In this way the practice resembles Scrum itself. Liberating Structures can be used to structure Sprint Planning, Retrospectives, and corral important open-ended discussions.

Scrum by Example – Team Friction Inspires Working Agreements </LinkList>

Building a new Team with Liberating Structures: Creating the foundation of trust and How must we organize…?
Design Thinking + Liberating Structures Facilitated Workshop Design Example
How Scrum Teams Can Benefit From The Principles Of Liberating Structures
Liberating Structures - The LS website with 30+ structures and case studies - Liberating Structures for Scrum: The Sprint Retrospective
Results of a Virtual Strategy Session for Scrum Masters Regarding Remote Work
A Retrospective with Liberating Structures at a rapidly growing startup
the Scrum framework is a liberating structure
The Value of Liberating Structures for Scrum Masters </HighlightBox>

Large Scale Scrum

Thu, 18 May 2023 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import WhyLeSS from '@/content/glossary/less-large-scale-scrum/images/why-LeSS.png'; import LeSSPrinciples from '@/content/glossary/less-large-scale-scrum/images/LeSS-principles.png';

import HighlightBox from '@/components/global/highlight-box.astro';

LeSS, aka Large Scale Scrum. The abbreviation leads to some good puns (do more with LeSS). There isn’t a one-size-fits-all solution to scaling. When the topic comes up, I recommend starting with LeSS because it was derived from running experiments, and it adds the minimum additional overhead to one team Scrum.

LeSS has been used to help groups of over 1000 people build products together, using LeSS Huge. To keep things manageable, we will focus on vanilla LeSS, which is intended for up to eight teams of eight people each.

A key LeSS lens is focusing the teams on the whole product as opposed to a single part. So instead of teams being focused on a single feature or area, they work across the product. It takes time to grow, but this flexibility means teams are always focused on building the highest value work vs. being pigeon-holed in a specific area.

A core concept and building block of LeSS is that we have multiple independent Scrum Teams. Each able to deliver value without expecting help from other teams.

As much as possible, LeSS attempts to be like one team Scrum:

Single Product Backlog for all teams and therefore one Product Owner
Single Definition of Team for all teams (ensuring even quality)
Single Product Increment at the end of the Sprint

All teams have the same Sprint start and end, meaning they can then do coordinated Planning, Review and Retrospective. This leads to a few changes from single team Scrum.

Sprint Planning becomes two parts. Part One, teams agree on which items each will work on that Sprint and they identify cross-team collaboration opportunities. Part Two, each team decides how they will do the items they have selected, leading them to create their own Sprint Backlog.
Common Sprint Review - since the teams are working from the same Product Backlog, creating a common Product Increment at the end of the Sprint, it makes sense that Sprint Review is held in common.
Retrospectives - each team holds their own team-level retrospective and then, separately, an overall retrospective is held with the Product Owner, ScrumMasters, Team representatives and other interested players.

LeSS also provides guidance on multi-team Product Backlog Refinement, however the details are more involved than we can cover in a glossary entry.

LeSS has a few other rules that are important to mention here:

Teams should be organized to focus on value for a customer, aka Feature Teams
Managers shift their focus from day-to-day team/product focus, to improving the system of work so that teams are able to deliver better value with fewer impediments. Managers should encourage experimentation to build a system that learns.

LeSS Principles

The principles exist in place of hard and fast rules to aid in guiding decisions.

Large-Scale Scrum is Scrum – just because there are some minor adaptations, it doesn’t change the core values
Transparency – be clear about what is done, use common definitions
More with Less – reduced defined processes, waste, overhead, roles, etc.
Whole-product focus – one Product Backlog, one Product Owner, and one Shippable Increment at the end of every Sprint
Customer-centric – focus on value from the customer perspective. Get feedback from real customers. Reduce Cycle Time because it gets value to the customer sooner. Help all team members see how their work delivers value to the customer.
Continuous improvement towards perfection – focus on delivering defect free products, that delight the customer. Every Sprint run experiments towards
Lean thinking – adopted from Toyota Lean Production System - seek to improve the flow of work, including eliminating waste. This includes the concept of Go See.
Systems thinking – see the whole system and work so that changes improve the whole system and aren’t just local or sub-optimizations. Do this by measuring the whole system (e.g. Cycle Time) and not the parts (Individual or Team Productivity).
Empirical process control – is fancy-pants language for Inspect and Adapt
Queuing theory – teaches us that reducing batch size and creating work in progress limits improve flow.

Legacy Code and Systems

Tue, 04 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Legacy code is often described as code checked into the system without a unit test. A popular definition from Michael Feathers, author of Working Effectively with Legacy Code.

The term “legacy code” is commonly used to refer to a codebase that has become increasingly difficult to maintain. There might be a number of reasons: complexity, hard to read, use of old apis or idioms. Maybe the original developers have left and their successors don’t understand the design choices that were made to get there.

The issue with legacy code is often made worse by a lack of reliable automated tests, so team members can’t easily tell if changes they make break the existing system.

Fixing Legacy code

Fixing legacy code does not come with a magic wand.

Churn + Complexity - Look for the biggest pain points first - look for the files that change the most frequently, that also have high code complexity
Time - Understand fixing this isn’t an overnight activity. Instead of taking a year off to fix all the problems, a more realistic approach - take at least 30% of the team’s time to work on remediation.
Fence and Add Tests - Identify testable boundaries, start writing automated tests that prove the behaviour of the system inside the boundary is stable.
Incremental Tidy Up - within the boundaries of passing tests, take small steps to improve.
Pair or Ensemble Programming - a big problem with legacy code is that no one understands it. Pairing and Ensemble will spread knowledge throughout the team and reduce the time it takes to understand.
Continuous Integration - Checkin Frequently and keep rerunning automated tests.
Static analysis tools - can help to a limited degree, hile these tools can help identify complex code, they don’t tell you what do with the code.
Microservices - another popular but limited tool. Splitting a large mess into smaller parts might seem beneficial, but remember that a mess divided is still a mess.

Finally have empathy for the people who wrote this code. It might even have been an younger version of yourself. The real magic is in putting the focus on improving the readability of the code and raising the bar on quality Sprint over Sprint.

Reinventing Existing Products – Big Bite vs Small Nibble Rewrites

Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software – David Scott Bernstein
The Mikado Method – Daniel Brolund, Ola Ellnestam
Working Effectively with Legacy Code – Michael Feathers </HighlightBox>

Metrics and Measurement

Wed, 28 Apr 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Metrics are the tools we use (and misuse) to help us understand how we're evolving. Used well, Metrics can give us feedback on our team's experiments and help us become aware of problems sooner. Used poorly, they become a stick to beat the team into submission. It's important to be careful when using them, because all metrics have cost, will introduce noise into the system, and might be gamed.

Agile Metrics: The Good, the Bad, and the Ugly
An Appropriate Use of Metrics
Beyond the Happy Bubble - using Metrics to help people see reality
Data driven coaching – Agile 2016 - Using Data to Tell a Story
Entangled – Solving the Hairy Problem of Team Dependencies
Forget dumb productivity measures and focus on software delivery performance with Accelerate's Four Key Metrics
How to do a Retrospective using Flow Metrics
Linear Thinking in a Nonlinear World
Making sense of organization impediments a presentation and the accompanying paper: Metrics for Understanding Flow
Measuring and evaluating Scrum in complex environments
Measuring Team Performance
Monte Python Simulation: Misunderstanding Monte Carlo
Talking about Sizing and Forecasting in Scrum
Team Metrics – Case Study
The Five Traps of Performance Measurement
The Happiness metric and a few others (we don't recommend the use of Happiness as metric; see the items in the subsection below for why)
The One Formula for Metrics Keep your Metrics simple at first
We Cannot Measure Productivity

Misuse of Metrics

Happiness Metric

I don't recommend the use of a happiness metric, focus on Morale and Team Cohesion instead.

Agile Teams: Don't use happiness metrics, measure Team Morale the level of rigour supporting this is astonishing.
Scrumming the Scrum
Measuring Happiness on the Team: What is Crisp?
How Measuring Happiness Helped Us Build a Better Team
How I Measure Scrum Team Morale </HighlightBox>

Actionable Agile Metrics for Predictability by Daniel S. Vacanti - covers in depth techniques around measuring cycle time and cycle time variance. If you're tempted to measure velocity as an indicator of performance, please read this book instead.
Escape Velocity - Better Metrics for Agile Teams - Doc Norton
Software Development Metrics Paperback – Dave Nicolette </HighlightBox>

Minimum Viable Product [MVP]

Fri, 30 Sep 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

MVP or Minimum Viable Product is often misunderstood, and confused with MCF - Minimum Crappy Feature. Where MCF is the minimum version of a product or feature that a customer could live with, Minimum Viable Product is intended to focus on the team learning from customer use of their feature/experiment.

Eric Ries (creator of the Lean Startup concept), defined it as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." So it's not about sales, it's about understanding what the customer needs.

Many groups ignore the key points of an MVP: - It is instrumented to gather data - e.g. what actions does the user take? - It is designed for learning and is not the final version of the feature, just one we can learn from. - The experiments don't need to be large or even involve writing code.

In our CSPO class we explore a number of approaches like Fake Door and Wizard of Oz, where the feature is incomplete or entirely absent but the team still learn.

Let's stop using MVP as an excuse to push ill-considered features out the door. (FWIW, the proper name of MCF - Minimum Crappy Feature is MMF - Minimum Marketable Feature).

Morale

Thu, 02 Dec 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Team health checks have been popular in the Agile Community for years. Getting people to pay attention to the joy in their teams is a boon. The challenge is the primary measure that people like to use is Happiness. Happiness is important, but it's too broad a measure for teams at work. When measuring happiness, we're measuring many things outside of work, for example: the state of someone's marriage, did they get enough sleep last night, etc.

We need something that more accurately measures the health of a team and their willingness to work together. Morale is a good choice because it is task and team oriented and is well-studied in the scientific literature. It is less subjective and less affected by mood.

There's no formal approach to measuring morale, but a common method is to ask teams to rate some qualitative questions, which helps generate discussion. A short, practical version is:

In my team, I feel fit and strong; I am proud of the work that I do for my team; I am enthusiastic about the work that I do for my team; I find the work that I do for my team of meaning and purpose.

Read the article "Agile Teams: Don’t use happiness metrics, measure Team Morale" by Christiaan Verwijs for more depth.

Caveat: if you attempt to reduce the four questions down to one or two, it's hardly better than a happiness questionnaire.

Agile Teams: Don’t use happiness metrics, measure Team Morale This blog post has a surprising degree of rigour and is the original source of Morale in the Agile Community. - How I Measure Scrum Team Morale
similar ideas, the questions may not have the proven rigour of the others - Agile Team Health & Morale Checks offers every team health check you could imagine. Some good, some I wouldn't recommend. </HighlightBox>

Motivation

Thu, 20 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Traditional approaches in the workplace assume that there is a strong linkage between motivation and financial reward. Theory is, if you pay people enough money, they will be engaged. Yet we know from watching everyone's favorite Dan Pink video that isn't the case. Don’t assume that you know what motivates - trust the research. Read psychologist Fredrick Herzberg's work. Specifically, how job satisfaction and job dissatisfaction are not opposites. The opposite of Satisfaction is No Satisfaction. The opposite of Dissatisfaction is No Dissatisfaction.

Below are resources that will point you in the right direction. My advice to improving motivation and enagement in team members goes roughly like this:

Look for demotivators in your environment and clear those away. Otherwise other efforts will have little effect. Hint: if you're stuck, use Systems Thinking as a lens. You're aiming for No Dissatisfaction, so you aren't pushing a rock uphill in an avalanche.
Look for opportunities to turn No Satisfaction into Satisfaction. We're talking about what research shows actually motivates: autonomy, mastery, purpose, recognition, etc.
Conduct one-on-ones on a regular basis with team members. Research will point you in the right general direction, but everyone is unique. Everyone wants to know they have a voice. Make a safe place for your team to be honest, then ask them what they need to feel motivated, and listen when they tell you.

Drive: The Surprising Truth About What Motivates Us - Daniel H. Pink
Why Motivating People Doesn't Work . . . and What Does: The New Science of Leading, Energizing, and Engaging - Susan Fowler </HighlightBox>

Niko-Niko

Mon, 31 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Niko-Niko calendars are used to track mood, energy, happiness, etc, but not everyone thinks that they're a good idea. The good: a team that tracks how team members are feeling can start to deal with some challenges that affect them sooner. The bad: if checking mood or energy reveals problems that don't get dealt with, it could breed cynicism; some people feel these questions are invasive; these measures may be measuring something outside of work.

Agile Teams: Don’t use happiness metrics, measure Team Morale
Niko-niko calendar </HighlightBox>

Multitasking

Mon, 08 Mar 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import MultitaskingKillsIndividualProductivity1024x544 from '@/content/glossary/multitasking/images/Multitasking-Kills-Individual-Productivity-1024x544.png'; import MultiTaskingProjectCostsSlide1 from '@/content/glossary/multitasking/images/Multi-tasking-Project-Costs-slide1.jpg'; import MultiTaskingProjectCostsSlide3 from '@/content/glossary/multitasking/images/Multi-tasking-Project-Costs-slide3.jpg';

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

Buried in most job ads is the phrase "Looking for a great multitasker". Too bad they don't exist. Contrary to what some books would have you believe, multitasking effectively is not an actual thing. As humans, we suffer from the problem of dual task interference. When we're already doing one thing, splitting our focus with an additional item causes us to make mistakes with both.

This topic is insanely deep and much larger than we can cover in a short glossary entry. This is only a short summary of the problems and how they affect us.

Effects of multi-tasking on an individual:

Increase in errors
Time spent task switching
Tasks or work gets lost
Degrades short-term memory (which is probably part of the source of errors)

<Figure src={MultitaskingKillsIndividualProductivity1024x544} alt="Multitasking Kills Individual Productivity" caption="Multitasking Kills Individual Productivity" /> Effects of multi-tasking when individuals are members of multiple teams:

Work items are often stuck waiting for a team who is currently switched to another project
Coordination overhead is increased

<Figure src={MultiTaskingProjectCostsSlide1} alt="illustration of the costs of multitasking costs with multi-project assignments - image by Agile Pain Relief Consulting" caption="illustration of the costs of multitasking costs with multi-project assignments - image by Agile Pain Relief Consulting" /> Teams working on multiple projects in parallel ensure that all projects get done later.

Key takeaways: Don't split people over multiple teams. Where humanly possible, get teams to focus on one major item at a time.

Academic sources

This just a sampling

Impact of task switching and work interruptions on software development processes
"Constant, constant, multi-tasking craziness": Managing multiple working spheres
Academic Publications on Multi-tasking
Mutltitasking Hurts Performance but Makes You Feel Better
No Task Left Behind? Examining the Nature of Fragmented Work
A Diary Study of Task Switching and Interruptions PDF of the paper

Learning Games:

The Name Game: A Multitasking Game for Agile Teams </HighlightBox>

NoEstimates

Fri, 30 May 2025 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

NoEstimates is a movement within the Agile community dedicated to eliminating the waste associated with estimation. At the core, the people behind this movement claim:

Estimates are a waste - clients don’t pay us for estimates, so they are considered overhead.
Estimation takes time that could be spent on more valuable work.
The further into the future we estimate, the more waste is created.
Estimates are harmful because they make precise promises about an uncertain future.
Estimates are often wildly wrong due to a long list of cognitive biases, including The Planning Fallacy and Optimism Bias.

The real problem with estimation isn’t that the estimate was wrong. From my experience, estimates don’t work because they ignore a key problem: the inherent variability in our work. Imagine two items that are both estimated to be a size ’5’ or medium. We would expect them to take the same amount of time or effort to be completed. The challenge is that numerous factors influence the time it takes to implement the work, including conversations with the client, code quality in the area where the changes are being made, and dependencies on other teams.

Instead, Team #NoEstimates would have teams:

Slice all product backlog items to approximately the same size (small T-Shirt size - a few days of work for a few people)
Count the number of small items the team achieves per Sprint
Make Sprint commitments based on the average number of items in the past few Sprints
Move away from forecasting based on arbitrary numbers, to Probabilistic Forecasting to provide insight into which items will likely be finished by a given date
Shift measurement focus from Velocity/Throughput to flow metrics: Cycle Time and Lead Time
Use Continuous Discovery to find the most important work items instead of large-scale prioritization
Shift away from once-a-year project funding towards smaller, more frequent commitments

Arguably, slicing all work to the same size is a form of Estimation. So the #NoEstimate isn’t eliminating all estimation; it’s about reducing waste so that teams can focus on delivering value. It is about basing the forecasts on real data (Cycle Time) and not guesswork (StoryPoints).

The #NoEstimates approach is most effective in organizations where the team is closely aligned with the customer.

Be careful of the #NoEstimates on social media, as you will attract attention from people who will tell you why it won’t work.

Measurement for Scrum – What are Appropriate Measures?
Red-Yellow-Green Status Reports and Other Models – How They Should and Shouldn't Be Used
Misuse of Velocity in Agile Projects
Agile Metrics
GenAI and the Feature Factory: Automating Away Collaboration </LinkList> <HighlightBox heading="Resource Links" variant="resourceLinks">
The Logic of No Estimates
The NoEstimates Movement
The Throw Down: Agile Estimation vs. #NoEstimates
#NoEstimates - Alternative to Estimate-Driven Software Development
#NoEstimates: 6 Software Experts Give Their View on the Movement </HighlightBox>

Onboarding

Thu, 07 Mar 2024 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Onboarding is a term to describe introducing a newly-hired person into an organization. In the case of Scrum and Agile teams, it's important to recognize the effects it can have on a team that is high-performing and effective. Fortunately, there are ways to onboard new people without losing scrum team magic.

Scrum By Example – New People on the Team </LinkList>

Adding a new team member
Brew the perfect onboarding storm
for remote teams - First Things to Do When Joining a New Scrum Team as Scrum Master
How to get started with a new team as a new Scrum Master?
Remote Onboarding: a Houseplant's Story </HighlightBox>

Organizational Structure

Wed, 13 Jul 2022 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import OrganizationalStructureUsedWithPermissionJeffAnderson from '@/content/glossary/organizational-structure/images/Organizational-Structure-used-with-permission-Jeff-Anderson.png';

import HighlightBox from '@/components/global/highlight-box.astro';

It's strange to start becoming Agile and assume that Organizational Structure won't change. As Agile steers an organization to focus on Product and improving effectiveness, the structure must change too.

We can't prescribe a specific structure, since each organization is unique. However, we can see general trends. Agile approaches push decision-making power closer to the people doing the work. Systems are decentralized and coordination is done as close to the work as possible. This leads to:

Teams often work across old departmental boundaries
Teams focus on delivering value to the customer
The system adapts as business needs change over time
A flatter organization, fewer layers of management

<Figure src={OrganizationalStructureUsedWithPermissionJeffAnderson} alt="Organizational Structure used with permission Jeff Anderson" caption="Organizational Structure used with permission Jeff Anderson" /> ](https://leanpub.com/agileorganizationdesign) From Organizing Toward Agility by Jeff Anderson, used with permission

There is a famous set of videos showing how Spotify organized nearly ten years ago, however many viewers misunderstand the lessons from those videos: Aligned Autonomy; Trust at Scale and Decoupling (see: The top 3 points you should have paid attention to in the Spotify Engineering Culture videos that aren’t Squads, Chapters, Tribes, Guilds). I won't link to the videos themselves since too many organizations have attempted to copy and paste the Spotify model onto their existing organization. Since your organization doesn't have the same history and culture, you can't copy their structure and expect the same results. The only effective approach is to evolve your own structure.

Warning: many articles in this area are written by the same companies that were providing advice on Org Structure before Agile showed up. Take their advice with a grain of salt. Also, if someone recommends using the Spotify model, run screaming from the room.

Don’t Reorganize: Run Your Firm As An Agile Network
Principles To Guide Your Agile Organizational Design
Organizational Structure
a book chapter with an emphasis on the Spotify Model - it shows a positive use of that model - Agile organization structures. Organization structures to work…
describes the use of Holocracy - Organizational Structure - Large Scale Scrum - What is an Agile Organization?
The Agile Organisation A case study on creating a more nimble organisation PDF Warning </HighlightBox>

Organizing Toward Agility - by Jeff Anderson - Organization Design: Simplifying complex systems
by Worren, Nicolay </HighlightBox>

Part-time Team Members

Fri, 03 Dec 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

People should be dedicated to one and only one team. The science of team work shows this over and over again. Yet, on occasion, we’re stuck when we have one person and their skills are unique enough that we can’t avoid having them work in multiple teams as part-time members.

But let's be clear from the beginning about some costs of having part-time team membership:

Multitasking - They will lose some fraction of their time to task-switching between groups.
Waiting - Both work items and other team members will get stuck waiting for the part-timer to be available to help out. This will show up in the work as an increase in Cycle Time.
Quality - When people are doing heavier multitasking, the work quality will suffer.
Loss of Context - The part-timer will miss some Daily Scrums and will need to be brought up to speed about things that have changed.
Priority - Which work is more important? One team will starve due to lack of support.
…

If you have an expert whose skills are essential, it might be tempting to just split them over, for example, three teams giving each team 33% of their time, but the costs are high. They may be worth paying, but the choice shouldn’t be made lightly.

If a team needs this skill for the long term, then we should look into Cross-Skilling. In this case, the expert would move from being an individual contributor to helping someone in the team learn the rudiments of the skill. Over the course of enough Sprints, our regular team member will move from having little knowledge, to being able to do the work without outside help. Our part-timer, meanwhile, will move from doing the work, to reviewing the quality of the work.

Can Team Members be on Multiple Teams?
Incorporating Part-time Team Members
Sharing Team Members in Scrum </HighlightBox>

<HighlightBox heading="Related Books" variant="relatedBooks"> Organizing Towards Agility - Jeff Anderson - Offers another model called the Traveller Pool. </HighlightBox>

Persona

Mon, 02 Jun 2025 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

A persona is a fictional character created to represent a group of users of a product. A persona is based on research of real users, usually discovered through structured interviews. The use of structured interviews helps reduce the cognitive biases of the researcher doing the work.

We use personas to help developers and stakeholders better understand and empathize with their end users. They remind the Scrum team that the end user is different from the people doing the work in respect to different tools, different skill level with technology and, often, different environments. For example, an NGO building a product in North America that their clients will use on the ground in Africa will have a completely different context than the end-users.

There is no single format for personas. I reinforce this point in Certified Scrum Product Owner workshops by using two different formats.

One Sample Format

Persona Label:
Photo:
Fictional name:
Occupation:
Demographics:
Goals and tasks:
Frustrations:
Environment:
Quote:

I like to include a photo or even a sketch to make them memorable. Others include behaviours, motivators, etc....

Common Mistakes

Relying on hearsay - i.e. feedback from stakeholders instead of doing real research
Relying on bug reports or feature requests alone - these only tell that there is a problem, they don't help us understand
Using GenAI to create the persona from User Interview Data
Making them too generic
Creating too many personas - we struggle to keep track of more than 3-4 at a time. If your audience is broader, focus on a few key points to start with and then refine some as needed.
Assuming they're unchanging
Not involving the team in creating the personas

Used well, personas build understanding and empathy between the customer and the team, and their basis in structured interviews can also reduce unconscious bias.

A Template for Writing Great Personas
Approaches to Creating Personas - excerpt from "The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web"
How Pragmatic Personas Help You Understand Your End-User
How to Breathe Life Into Personas
Five Approaches To Creating Lightweight Personas
Personas: Putting the Focus Back on the User
Persona “How To & Tools”
Personas: Why is it important to understand your users?
Tweaking the Persona
Why is it important to understand your users?
Customer Empathy Map - a great pre-cursor before creating personas </HighlightBox>

The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web - Steve Mulder </HighlightBox>

Pair Programming

Wed, 05 May 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Pair Programming is when two people write code together on one machine. This collaboration helps improve code quality, readability, and simplicity. Not only is it an on-the-fly code review, since it has two pairs of eyes looking it over, but it is also a form of design review, thereby beating regular code reviews on several fronts. Pairing also helps with Sprint progress by moving the focus to completing stories and limiting the WIP. There are too many other benefits to list in a short glossary entry.

Ironically, some of the earliest programming work (before it was called programming) was done in pairs: “Betty Snyder and I, from the beginning, were a pair. And I believe that the best programs and designs are done by pairs, because you can criticise each other, and find each others errors, and use the best ideas.” - Jean Bartik, one of the original programmers of the ENIAC computer. (source - https://martinfowler.com/articles/on-pair-programming.html)

Mythbusting - Collective Code Ownership - Pair Programming vs. Code Reviews – It’s a no Brainer </LinkList>

Pair Programming: A book on problem solving – YvesHanoulle, talboomerik, and Clare Sudbery </HighlightBox>

Personal README

Wed, 06 Mar 2024 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Github style READMEs can be turned to personal use. A Personal README, aka Personal Manual, is a document that describes how a person likes to communicate (Slack, email, text message, …), their timezone, the hours they like to work, etc. Most include enough information that a new teammate knows a little bit about their new colleague on a personal level as well.

Having looked at 10–15 examples to write this glossary, I’ve noticed the following attributes:

Preferred Communication channel - one person even said, “I prefer Slack but if I don’t respond in 24 hrs use email.”
Collaboration - several people talk about how to collaborate. “If it requires more than one round of emails let’s do a zoom call.”
How and when to book a meeting on this person’s calendar.
Several had a “What makes me grumpy” section.
Their thoughts around giving and receiving feedback.
Leaders shared their management style.
Another author shared his personal work history and how it shaped him.

Are they needed? No. Are they fun? Yes. Do they give an avenue to sharing a bit more about yourself? Yes.

petro.blog/my-personal-readme/

shawinnes.com/personal-readme/

Working with Brendan Best: A Manual </HighlightBox>

Product Backlog

Tue, 23 Mar 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

The Product Backlog is an ordered list of all the work items or value the Product Owner would like to see the Team work on in the foreseeable future. These items are called Product Backlog Items (PBIs).

Drowning in an Oversized Product Backlog? Story Mapping Is Your Life Raft
Scrum Anti-Patterns: Large Product Backlog - hosted on ScrumAlliance.org </LinkList> <HighlightBox heading="Resource Links" variant="resourceLinks">

Prioritization

Mon, 03 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Business Value Game

Business Value Game (or Poker)

Buy a Feature

Buy-a-Feature Game
How Pandora used the “Buy A Feature Game” to make choices among too many options
I tried Pandora’s brilliant method for feature prioritization. Here’s what I learned. - This is a variation of the Buy a Feature Game
Innovation Team, Accuity - Buy A Feature Game (YouTube)
Setting up the "Buy A Feature" Innovation Game

Cost of Delay

Kano

Prune the Product Tree

I don't recommend using either MoSCoW or WSJF and so place them last.

MoSCoW

MoSCoW Prioritisation

WSJF

Problems with WSJF </HighlightBox>

Portfolio Management

Mon, 22 Mar 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Agile Portfolio Management is a tool for a group of teams that have too many major chunks of work in flight. Traditional Portfolio Management is centred around the idea that we fund projects and assign people (or fractions of these people) to work on the project. By contrast in an Agile world, we have a fixed number of stable teams, so we can only have one project or major chunk of work being worked on by any one team at a time. This is a form of Limiting Work In Progress per team.

To make this work, the organization needs to see that the funding model in an Agile world is tied to teams, and then the Portfolio Management is just about deciding which chunks of work to do next. It is the art of getting stakeholders to help make big-picture decisions about the Product Backlog with you.

Kanban Portfolio View
Portfolio Management
[Portfolio Management with Upstream and Downstream Teams] (https://agilepainrelief.com/blog/portfolio-management-with-upstream-and-downstream-teams/) </LinkList>

Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects – Johanna Rothman </HighlightBox>

Product Backlog Refinement

Tue, 23 Mar 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

Product Backlog Refinement (formerly known as "Product Backlog Grooming") is a session during which the Scrum Team (Developers, Product Owner, ScrumMaster) prepare the Product Backlog for the next few sprints. New Product Backlog Items (PBIs) are added for new needs to be considered. PBIs that are too large to be worked on in a single Sprint are broken down into smaller items. Estimates are made as to how much time each PBI will require to complete. The Product Owner makes prioritization decisions about PBIs, sharing with the Team their reasoning. PBIs that are no longer important are deleted, making room for new ones. The items that are candidates for the next Sprint Planning have their initial acceptance criteria written.

<LinkList heading = "Related Blog Entries"> - Scrum by Example – Product Backlog Refinement in Action - Scrum Anti-Patterns: Large Product Backlog (via ScrumAlliance.org) </LinkList>

Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers by Dave Gray, a book to add some play into your work
Innovation Games: Creating Breakthrough Products Through Collaborative Play by Luke Hohmann, includes games that can be used for Backlog Refinement </HighlightBox>

Product Owner Role

Fri, 30 Apr 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

"The Product Owner owns the product that the team is building." “The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.” [1]

These are probably the two most unhelpful statements ever. A much more accurate description is that the Product Owner (PO) works with the customer(s) to understand the problems they face. They use their understanding of the problems, combined with the business constraints (for example, are they building a web browser based application; perhaps educational material videos, supporting text, quizzes and games?), to help imagine a product.

The PO owns the Product Vision and Strategy. However, the best Product Owners involve their teams and customers in creating/discovering the product vision together. By co-creating the vision with the people who will be building it, the PO helps them more deeply understand what problem the customer needs solved. In addition, by getting the team members and the customer talking at the beginning, we build up empathy on both sides. The developers learn to see the problems the customer is seeing, and the customer sees that the developers are normal people and that their work is challenging.

In addition to creating the vision and strategy with the team, the PO works with the team to build the Product Backlog. Since they created the Product Backlog with the team, they also own keeping it in priority order, with an attempt to maximize the value for the money spent.

Since we know from experience that the features we build into Products often don’t match the customer's needs, great PO’s run experiments (hint: look to Lean Startup and Lean UX for ideas) to validate whether their planned features solve real customer problems well. Even though this will cost time and money, it saves the organization a great deal more by not building and maintaining features that will never be used. So, in fact, running experiments is about maximizing value by learning which things to build and which things no one wants.

Qualities of a great Product Owner:

Able to empathize with the customer and in tune with their needs
Understands business priorities
Decisive
Good communications skills
Knows that their relationship with their team is more collaborative than directive
Gives time to both the team and customer
Understands User Experience and its application in the customer's business
Focuses primarily on the Vision, Strategy and Prioritization
- They do need to pay some attention to the details (e.g. User Stories, etc), however, if they put most of their effort on the details, no one will take care of the Vision and Strategy. Whereas a good Product Owner can coach the team to take ownership of smaller product details.

Mistakes organizations make:

Not empowering a PO to make business decisions
Treating the PO as proxy for stakeholders or senior management – the PO isn’t an errand runner
Assuming that a good product is just the sum of stakeholder/customer requests
Assuming that the PO is a Business Analyst with a better job title

Working with Stakeholders

Inspired: How to Create Tech Products Customers Love – Marty Cagan
Agile Product Management with Scrum: Creating Products that Customers Love – Roman Pichler
Scrum Product Ownership – Balancing Value From the Inside Out – Robert Galen </HighlightBox>

[1] Scrum Guide - https://scrumguides.org/scrum-guide.html#product-owner

Production Support

Fri, 23 Apr 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

When a team has a product that is live in the field, they need a pattern to handle the support issues that come up, so that the critical defects get fixed rapidly and the team is still able to focus on delivering value.

Hint: creating a separate team to handle fixing defects is an anti-pattern - see: Special Teams

Project vs. Product

Fri, 21 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

Projects break Agile. The whole mindset behind starting and stopping a PROJECT results in the opposite of what we're attempting to achieve using Agile approaches for a PRODUCT. The two words might sound similar, and mistakenly be used interchangably, but they are very different approaches.

Key Difference

Project-based approaches are to get the money, start the project, and bring the resources (not even people) to the project. In contrast, Agile approaches focus on building teams. First build an effective team, and then bring the work to the team to build a product.

Project Mindset	Product Mindset
Fixed scope with variable resources and time	Fixed team (not resources) with variable scope (aka a Product Backlog)
Focus on completion and hand-off	Continuous evolution and value creation
Temporary teams and part-time team members	Stable teams with domain and technical knowledge
Fixed upfront budget	Continuous funding based on value
Limited stakeholder involvement	Ongoing stakeholder collaboration
Success is measured by time and budget adherence	Success is measured by problem-solving and usage
Difficult to maintain what you build	Maintenance is built into the process
Complicates forecasting	Forecasts based on historical data
Leads to multi-tasking and increased use of specialists	Eliminates multi-tasking
Deliver value at the end of the project	Deliver value as early and often as possible

<LinkList heading = "Agile Pain Relief Blog Entries">

- In organizations that are struggling to break free of the Project based approach, consider [Portfolio Management](/blog/portfolio-management/)
- [In Agile, Where Change is Valued, Why Is a Stable Team So Important?](/blog/in-agile-where-change-is-valued-why-is-a-stable-team-so-important/)
- [Specialists Are Overrated](/blog/specialists-are-overrated/)
- [Speed Trap: How the Obsession with Speed is Building a Fragile Organization](/blog/speed-trap-how-the-obsession-with-speed-is-build-a-fragile-organizations/) - Organizations that remain stuck in the Project approach are more Fragile.

</LinkList>

<HighlightBox heading="Resource Links" variant="resourceLinks"> - Project Focus Is An Impediment to Long-Lived Teams - Products Over Projects - Product vs. Project Teams - Skateboards vs. Cars Revisited </HighlightBox>

<HighlightBox heading="Related Books" variant="relatedBooks"> - Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework - Mik Kersten </HighlightBox>

Psychological Safety

Thu, 25 Mar 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Psychological safety is about being part of a team and knowing that you can share ideas and information without fear. Psychological safety isn’t the avoidance of conflict, rather it is knowing that we can share information inside a team instead of focusing on protecting ourselves.

"The belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes, and that the team is safe for interpersonal risk taking" - Amy Edmondson, 1999

It isn't just trust. We can trust each other and not be safe. Psychological safety requires that we know that if we take a chance or make a mistake, that we will be supported and not punished.

As safety increases, communication within the team becomes more open. This openness leads to better awareness of what is really happening in the work environment.

As communication improves, mistakes are reported and fixed more rapidly.

It is a virtuous circle.

What psychological safety isn't

Psychological safety isn't agreement for the sake of agreement. Rather, it's an environment where we know we can be honest about what we have seen and not be punished for it. Warning: safety isn't an excuse to highlight the mistakes we see in other people on our team. It is about being able to acknowledge our own mistakes and what we learned without repercussions.

Amy Edmonsen, who has written the book on the subject, uses the following survey to test a team’s level of safety:

If you make a mistake on this team, it is often held against you.
Members of this team are able to bring up problems and tough issues.
People on this team sometimes reject others for being different.
It is safe to take a risk on this team.
It is difficult to ask other members of this team for help.
No one on this team would deliberately act in a way that undermines my efforts.
Working with members of this team, my unique skills and talents are valued and utilized.

People answer on a scale of Strongly Agree -> Strongly Disagree. Once the survey has been run, the team can use the data to help themselves see how they might evolve.

Timothy Clark - 2020 - has extended the concept to four levels: included; safe environment to learn; safe to contribute; safe to challenge the status quo.

Engineering a Culture of Psychological Safety
The Epic Guide to Psychological Safety
Foster effective team behaviors (from "Understanding team effectiveness")
High-Performing Teams Need Psychological Safety. Here’s How to Create It.
I Feel Unsafe Here! How to Embrace Conflict
The 4 Stages of Psychological Safety
Of Course Psychological Safety…But How?
The (Psychological) Safety Dance
The Psychological Safety Game
Psychological Safety
Psychological Safety Canvas — a report on how one company uses the concept
Psychological Safety: High-Performing Teams
Psychological Safety Made Simple — An Intro Guide
Understand team effectiveness — why psychological safety matters and what to do about it
What Google Learned From Its Quest to Build the Perfect Team
Why Psychological Safety Improves The Effectiveness Of Your Team — what it is and what it isn’t, what the science says, and how high psychological safety probably results in more conflicts </HighlightBox>

The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth Hardcover by Amy C. Edmondson - Turn the Ship Around ! A True Story of Turning Followers Into Leaders Hardcover by L. David Marquet. (An example of where a leader created a safe environment and changed how a team worked) </HighlightBox>

Pull Requests

Thu, 10 Oct 2024 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import PullRequestAntiPattern from '@/content/glossary/pull-requests/images/Pull-Request-Anti-Pattern.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Pull Requests are a proposal to merge a set of changes from one branch to another. They emerged from the world of open source and are optimized for low-trust, low-communication environments.

If worker busyness were the measure of software productivity, then pull requests would be well suited to the task. But we know that's not how quality and productivity are formed.

**Weaknesses to Pull Requests include:**

Typically only spot surface level problems, missing structural level issues.
Lead to a false sense of security and reduced sense of accountability
Increases the effort per developer as they carefully wordsmith feedback
Changes often require 2-3 rounds of feedback and change, which increases the time to production
Can erode culture by discouraging live interactions and conversations
Inherently ineffective and inefficient due to emphasis on minimizing human interaction
Back and forth interruptions slow both the code author and the reviewer
Delay the improvement process to the end instead of building it in from the beginning
Represent Work in Progress, and we know that increases cycle time and reduces throughput in the system

**What to do instead:**

Pair programming: active review that builds quality into the product from the start
Ensemble programming: collaborative development with an effective work-in-progress of one, eliminates need for post-facto reviews and rework
If pull requests must be used, reduce the size of the average change; prioritize finishing other people's pull requests before doing your own work; prefer conversations over written feedback.

Scrum Anti-Patterns – How We Hold Back Our Scrum Teams </LinkList>

Broken by Pull Requests:

Trunk Based Development Continuous Integration

</HighlightBox>

Refactoring

Wed, 05 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Refactoring is the process of restructuring existing code without changing its external behaviour. Refactoring is done to improve the simplicity and readability of a piece of code. Most refactorings are simple (e.g. rename method, extract method, etc) and have been automated by modern development tools to guarantee safety/correctness. A refactoring is like renaming a section header in a document to better convey the core idea to the reader, or splitting a large, unwieldy paragraph into smaller parts.

Refactoring: Improving the Design of Existing Code – Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
Refactoring to Patterns – Joshua Kerievsky </HighlightBox>

Quality Assurance in Scrum

Mon, 12 Jul 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

In traditional approaches, the QA, Tester, or Quality Assurance tests the work of developers in a separate phase - sometimes months later. Clearly that doesn’t work in an Agile world where delivery happens after every Sprint.

Scrum doesn’t define any traditional roles (like BA, QA, DBA, Dev, UX) inside the team, instead, everyone is a Developer or, better yet, a doer. This lack of strict rules about roles creates stress and tension for people who are used to a traditional approach. They want to know: Who does the testing? When it is done? How to meet strict rules, especially if work is done in regulated industry?

Most teams have team members with deep testing experience. From a role perspective, a key change from traditional to Scrum is that now they spend part of their time mentoring colleagues to improve quality before a User Story or PBI even moves to testing. (Cross-skilling)
Teams discover that putting testing last in the process is an invitation to create a bottleneck in test. So, instead, they adopt practices like designing the test cases through QA, BA and Developer collaboration, before work starts on a story and during its development. (Life Cycle of a User Story)
More advanced teams deepen that collaboration by adopting Behaviour Driven Development and/or Ensemble Programming

Scrum by Example – The Story of an Incomplete Sprint </LinkList>

A day in the life of an agile tester
A Day in the Life of an Agile Tester - Two observations: It is very strange that this group holds Daily Scrum at end of day; This tester is fairly isolated, ideally there would be more collaboration.
A day in the life of a QA Engineer at Native Instruments
How Does QA Fit with Scrum? The typical misunderstandings of QA with Scrum
My Experience as a QA in Scrum
The Role of Testers in an Agile Environment
Software Testing in Scrum Is Not What You Think It Is </HighlightBox>

Resource Utilization Trap

Thu, 29 Jul 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import HowDoesUtilizationImpactLeadTimeOfWorkTroyMagennis1024x505 from '@/content/glossary/resource-utilization-trap/images/How_Does_Utilization_Impact_Lead-time_of_Work____Troy_Magennis-1024x505.jpg';

import HighlightBox from '@/components/global/highlight-box.astro';

In many organizations, the people who do the work are treated like economic resources (think: iron ore) and it’s felt that they have a price, and so must be utilized to maximize their value. Except these resources are actually human beings. Labelling it “human resources” is far more ironic than helpful.

Thinking of people as resources reduces them to common, replaceable parts. It also leads to the mindset that, to deliver the most value, they must always be busy. This is known as the Resource Utilization Trap. People aren’t machines or assembly lines, and if they always look busy, much of their work will be low value.

<Figure src={HowDoesUtilizationImpactLeadTimeOfWorkTroyMagennis1024x505} alt="How Does Utilization Impact Lead Time Of Work - Troy Magennis" caption="How Does Utilization Impact Lead Time Of Work - Troy Magennis" /> Image From https://observablehq.com/@troymagennis/how-does-utilization-impact-lead-time-of-work

With the emphasis on busyness, quality is sacrificed. The team look to ensure that they're seen ticking off tasks from their list. Whereas things that improve quality (e.g. pair programming, improving simplicity, refactoring, etc. See: Agile Engineering Practice), don't show up on task lists and so lose focus.
Bottlenecks ensue when tasks wait for a team member who is already busy (or utilized) on another task.
Both Cycle Time and Lead Time get worse. The bottlenecks ensure that most work items take longer to complete. When quality is harmed, there are more defects. As the number of defects goes up, the team spend more time solving bugs than building new things, and so the Cycle Time increases.
**Throughput or Velocity will also decrease.**
There is minimal, or no, improvement. Process Improvement and learning requires time for reflection, experimentation and learning. A focus on busyness, doesn't leave room for improvement.
Dealing with innovation and complexity requires slack. The slack is used by team members to adapt as the work evolves. Complex problems and innovation require dealing with a large amount of uncertainty. Without room to manoeuvre, teams generally stop innovating altogether.

Organizations that focus on utilization and busyness are not resilient. These groups struggle to adapt when faced with change. The problem is often further compounded by violating the core constraint of Scrum that says team members can be a member of only one team. (See Part-time Team Members for more, including suggestions on how to handle experts.)

"When you focus on keeping people busy, what you get is a bunch of busy people" - Henrik Kniberg

“Watch the work product, not the worker” – Donald Reinertsen

"Striving to ensure that no resource be idle is the biggest generator of waste". – Eli Goldratt

The Economic Impact of High System Utilization
The Famous 'Resource Utilization' Trap!!
"Full Resource Utilisation"
How Does Utilization Impact Lead-time of Work?
How Kicksaw Killed Utilization
The resource utilization trap Video explaining how it impacts our ability to deliver and what we can do about it.
Scrum Master tactics: Escaping the resource utilization trap </HighlightBox>

The Principles of Product Development Flow: Second Generation Lean Product Development
Donald Reinertsen </HighlightBox>

Roadmaps and Strategy

Thu, 22 Apr 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

In traditional approaches, a Roadmap is a list of dates and promises that are being made to the customer. Traditional Roadmaps don’t work because there is an implied linear flow and promise of what will be delivered in 18-36 months time. In an Agile world, a Roadmap is a set of options to open a conversation with the customer about what could be built.

Scaled Agile Framework

Thu, 06 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Scaled Agile Framework, aka SAFe, is probably the least Agile approach to getting many teams to work together. At the heart of all of Agile approaches has been boiling the system of work down to its essence, finding the simplest way that people could work together. Scrum, eXtreme Programming, and Kanban all embrace this. SAFe takes a different approach. It claims to embrace all of those methods as part of a grab bag. Instead, it takes them and makes key changes. Scrum's Product Owner loses their responsibility for the product - instead they're responsible for alignment. SAFe adds a great deal of superstructure around normal Scrum teams. There are so many more reasons I could add but, instead, there is a great quote that I'll share: "SAFe is where Agile goes to die".

Safety Check

Wed, 03 Aug 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

A team safety check is a way of understanding the team's readiness to be open and honest. It starts with a question like "Are you able to be open and honest and say everything that needs to be said in this retrospective?"

Display the scale:

5 – Happy to talk about anything
3 – Some things can be discussed, others are hard to say
2 – I will be quiet and let others do the talking
1 – I don't have safety and won't talk

Get people to put a number on a note and collect them anonymously. Share the summary with the team, for example, "We had three people at 5, one at 4 and two at 3". Don't show the individual cards to avoid the chance of anyone's handwriting being recognized. With distributed teams, make sure your whiteboarding tool preserves anonymity.

If the results are high 4s and 5s, acknowledge that and move on with your plan. If the results are medium 3s and 4s, perhaps one 2, comment on the safety level and point out that silence in any activity is okay. If the results are low with any 1 or multiple 2s, then we would want to turn the retrospective toward nourishing Psychological Safety since it is clearly low in the group.

Scaling and Large Teams

Thu, 06 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

When attempting to get many teams to work effectively together in an Agile world, we need some coordination model. This is typically referred to as Scaling. Be careful, many approaches do this by adding more layers, additional ceremonies, and handoffs. All of this takes the teams further away from delivering value to the customer.

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum – Craig Larman, Bas Vodde [AMAZON] - Large-Scale Scrum: More with Less – Craig Larman, Bas Vodde [AMAZON] - Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum – Craig Larman, Bas Vodde [AMAZON] </HighlightBox>

SCARF Model

Thu, 31 Mar 2022 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import SCARFArrows from '@/content/glossary/scarf-model/images/SCARF-arrows.jpg';

import HighlightBox from '@/components/global/highlight-box.astro';

The SCARF Model of human behaviour is useful to understand how people respond to the world through the lenses of Status, Certainty, Autonomy, Relatedness, and Fairness. In our case, we focus on how the model explains behaviour of people in the world of Agile work.

The model is based on three major findings:

Social threats and rewards are treated with the same intensity as physical threats and rewards. - Eisenberger, N. and Lieberman, M. (2009)
Our ability to solve problems and make decisions is diminished when we're in a threat state, and increases when in a reward state. - Fredrickson, B. (2001).
People are more easily placed into Threat than Reward, so in our work we need to minimize the things that create Threat. - Baumeister, R., Bratslavsky, e., & Vohs, K. (2001)

SCARF Model

Attribute	Definition	Example Threat	Example Reward
Status	How you see yourself and how others see you.	Traditional performance review. Being mentioned in the context of a problem.	Thanking someone or acknowledging their work. Any form of recognition.
Certainty	How confident you can be of the future.	Change – Agile or otherwise – takes away the certainty of the people involved.	Transparency of information around the change process. Help clarify goals.
Autonomy	How much control you have over your situation.	Micromanaged people.	Involved team members – not only in assigning work, but also designing their mission or vision.
Relatedness	How connected/safe you feel with others.	New team member, especially in remote work environment. Explains why strangers are seen as a threat.	Without enforcing socialization, give team members time and opportunity to socialize. Consider building in opportunities to exchange information about who they are.
Fairness	How reasonable you feel that decisions involving you have been.	Unclear rules around how salary, bonuses, disputes or anything else is treated.	Working Agreements that cover team decision making protocols, etc. Training/education on the importance of diversity and how it works. Making salary and bonus tables public.

SCARF Model of Engagement - The SCARF Model - Explained (Youtube) - Neuroscience, Leadership and David Rock's SCARF Model - Examples of Using the SCARF Model </HighlightBox>

Your Brain at Work
David Rock </HighlightBox>

Scrum Team

Tue, 23 Mar 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

The Scrum Team is all of the people needed to get the product built and into the customer’s hands:

ScrumMaster, who helps the team grow capacity to deliver value
Product Owner, who manages the vision for what they will be creating
Developers, who are the cross-functional group of people who will build the Product (e.g. in software development this group usually includes programmers, business analysts, quality assurance, user experience and more).

Leading Teams: Setting the Stage for Great Performances
The Five Dysfunctions of a Team: A Leadership Fable – Patrick M. Lencioni
The Wisdom Of Teams: Creating the High-Performance Organization – Jon Katzenbach </HighlightBox>

Scrum

Tue, 23 Mar 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Scrum is an approach to applying the Agile mindset. Scrum is a way of organizing a team of people to deliver incremental parts or features of a product over a short, fixed time period. Scrum grew up in the world of software development, but it can be used anywhere that individuals need to collaborate as a team to deliver something of value to a customer.

Agile and Scrum are not the same things.

What Are the Limits of the Scrum Framework? What Is Scrum? – In a Nutshell

Scrum vs Kanban

Wed, 07 Jul 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Scrum is a tool that organizes a team to deliver value to a customer. Along the way, the team is expected to improve the product and also the way they work together. Kanban is a tool to improve the flow of work through your existing process. As a famous ad from the '70s suggested, they work better together.

Scrum doesn't solve all problems: see Limits of Scrum. It's most effective when it's used to build a team that learns to deliver value. Scrum is a revolutionary change, often radically different from the past way of working, which can be good since breaking old habits can sometimes form better habits.

Since Kanban evolves from an existing process, it's a gentle change, simply helping the current process become more effective.

The best Scrum teams adopt Kanban practices because they make Scrum better. But doing either Scrum or Kanban well requires discipline. Without discipline, no process will be effective. I've heard it said that Bad Scrum beats Bad Kanban. Bad Scrum will be painful and people will be forced to act to improve. Bad Kanban may look enough like the existing system that people still accept it as normal.

Don’t Inflict Scrum or Kanban on Teams </LinkList>

Kanban vs Scrum: best Agile frameworks for the age of uncertainty
Scrumban – Blending Agile, Scrum and Kanban into a methodology that works for you
Scrum vs Kanban - Two Agile Teams Go Head-to-Head (Youtube)
Dive into Kanban (6) - Scrum vs Kanban
I don't agree with many of the authors assertions, however the article is good at provoking deeper thought - When Kanban is the Better Choice </HighlightBox>

ScrumMaster Anti-Patterns

Thu, 10 Nov 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

An Anti-Pattern is a recurring pattern that frequently shows up, where the behaviour creates new problems somewhere else in the system. Example: the common practice of MicroManagement allows the MicroManager to feel like they’re maintaining control, yet their control reduces self-organization, creates disengagement, slows decision-making etc. So even though the MicroManager feels like they’re in control, their behaviour is damaging the system they’re part of.

Even the ScrumMaster can join in the AntiPattern fun:

Doesn’t understand self-organization and so gives orders to the Team
Doesn’t coach the Product Owner and so the Team continues to work without a Product Vision or Strategy
ScrumMaster Role is combined with the Product Owner role - the roles have different focuses and skill sets. Few people are skilled in both Coaching a team and also bringing a Product to life
Scrum Parent - ScrumMaster solves all the team’s problems for them
Facilitator only - not realizing there is more to the role; the ScrumMaster facilitates meetings but puts no effort into coaching

MicroManagement is just one of the many general Agile Anti Patterns that we document.

ScrumMaster Role

Fri, 19 Dec 2025 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

The ScrumMaster is a servant-leader responsible for helping teams and organizations effectively implement Scrum. Despite the title, a ScrumMaster in charge of team members nor do they give orders. Instead, they coach the team, facilitate Scrum events, remove obstacles, and drive organizational change. The name refers to mastery of Scrum knowledge, which takes years to develop as the role touches many aspects of organizational life.

Framed simply, the ScrumMaster is responsible for making sure that Scrum functions effectively and, by extension, that includes the Developers and the Product Owner.

In more depth, ScrumMasters:

coach the whole team in the art of Scrum
coach the Product Owner
coach the team on relevant technical or engineering practices – this will differ by problem domain
watch the team to understand what is happening. Are team members collaborating? This involves watching both individual behaviour and team member interactions.
maintain the Sprint Backlog with the team
help the team understand the value of flow and coach them to achieve it
help the team stay focused on quality - this often happens through reminding the team of their Definition of Done and improving the same.
facilitate team events - including Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and Product Backlog Refinement. A great ScrumMaster is constantly finding new ways to improves these events and make them more engaging. Hint: this often involves changing event agendas so that team members don’t get bored.
maintain team Impediments Backlog. The ScrumMaster should help the team by keeping their current list of impediments` visible to the team and the team’s manager.
protect the team from outside interference and, when it happens, track the effects.
nurture the Team's independence
help the team remember important things they committed to and that they might be losing track of - example: many teams commit to Definition of Done or Improvements (from a Sprint Retrospective) but then, during the heat of Sprint, they forget to act on them.
explain Scrum to the Organization - Scrum is different from the way many organizations work, and the ScrumMaster is responsible for helping others to understand those differences.
change the Organization - Eventually the ScrumMaster is responsible for helping the organization evolve.

This list is only a start. The role has a great deal more depth and, unlike a traditional manager, you have no power to enforce your intentions. If you make the role work well, it will be through understanding people, empathy, understanding systems, some negotiation, and myriad of other skills. It is the hardest role I’ve attempted and, 20 years on, I’m still learning.

Mistakes that organizations make:

thinking the ScrumMaster is just a meeting organizer and facilitator
appointing a ScrumMaster instead of getting the team to make the decision about who would best help them
making the Team’s Manager their ScrumMaster

ScrumMaster vs Project Manager

Aspect	ScrumMaster	Project Manager
Authority	No formal authority; servant-leader	Directs team; has management authority
Focus	Team effectiveness & process	Scope, schedule, budget
Approach	Coaches team to self-organize	Assigns and tracks tasks
Metrics	Team moral, Cycle Time	Completion dates, resource utilization
Impediments	Removes organizational blockers	Manages risks and issues

Frequently Asked Questions

What does a ScrumMaster do all day?

A ScrumMaster coaches the team, facilitates Scrum events (Daily Scrum, Sprint Planning, Retrospectives), helps to remove impediments, helps the team track their own progress, protects the team from interruptions, and helps the organization understand and adopt Scrum practices.

Is a ScrumMaster the same as a Project Manager?

No. While both coordinate work, a ScrumMaster is a servant-leader who coaches the team to self-organize, whereas a Project Manager typically directs work and manages tasks. A ScrumMaster has no formal authority over team members.

Can a ScrumMaster manage multiple teams?

While possible, it's not ideal. A dedicated ScrumMaster for one team is most effective. For multiple teams see: ScrumMaster for Three Teams? What are the Alternatives? - which explores the tradeoffs

What skills does a ScrumMaster need?

Key skills include: coaching and mentoring, facilitation, understanding of Scrum and Agile principles, conflict resolution, systems thinking, empathy, communication, knowledge of Kanban, understanding flow and organizational change management.

Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin
Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns Ph.D, Linda Rising Ph.D.
The Scrum Field Guide: Practical Advice for Your First Year by Mitch Lacey
Scrum Mastery: From Good To Great Servant-Leadership by Geoff Watts
The Wisdom of Crowds by James Surowiecki </HighlightBox>

updated: Dec 19, 2025

Scrummerfall - Anti-Pattern

Tue, 27 Feb 2024 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import StaggeredIterationsForDeliveryImageCreditMartinHinshelwoodOfNakedAgility from '@/content/glossary/scrummerfall/images/staggered-iterations-for-delivery-image-credit-Martin-Hinshelwood-of-Naked-Agility.png'; import StaggeredSprintStartingPoint1024x613 from '@/content/glossary/scrummerfall/images/Staggered-Sprint-Starting-Point-1024x613.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Alias: Mini Waterfalls in Scrum

A Scrum team should work on only a couple of Product Backlog Items (or User Stories) at a time. Most of the work should be done in a collaborative, and not isolated, process. When starting out, many Scrum teams reinvent a waterfall style approach, affectionately called ScrummerFall or WaterAgile or WAgile, because that’s what they’re most familiar with and comfortable practicing. There are two versions of this:

One version is staggered Sprints, where the Business Analysts work one Sprint ahead of the developers and the Quality Assurance people work one behind, as illustrated here with this image by Martin Hinshelwood of Naked Agility:

The other version is where everyone pretends to work in the same Sprint but the business analysts are in the lead and QA is at the end.

Both versions lead to:

Lack of Flexibility - changes after the business analysts kick into gear will be harder to accommodate. Worse, usability issues discovered in QA are easier to ignore than fix.
Reduced Quality - the longer there is in delay between doing the work and finding a problem, the harder it is to fix.
Delayed Feedback - longer work cycles for each individual item means a longer time from the start of work until the customer gives feedback. Both these approaches are a train wreck in slow motion.

A better approach is to watch the work product and not the worker. Help the team focus on getting items to finished, not maximizing the number of stories through a pipeline.

A better way than staggered iterations for delivery </HighlightBox>

Self-Selecting Teams

Tue, 27 Jun 2023 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

The default assumption when creating a new team is that the management and team leads will do the selecting and organizing. (Wait, team leads... are they even part of Scrum?) When a team is formed this way and then members are told that they have autonomy and they can self-organize, there is a bit of a dichotomy.

A true team is built on the strength of the team members' relationships. When management creates a team, it starts with weaker relationships, and often initial competition and conflict. Collaborative relationships may build up successfully over time, or they may not.

When people are given the opportunity to form self-selecting teams, we gain a real benefit because relationship bonds are already in place, and the team environment causes them to strengthen further.

The Power of Autonomy and Reducing Resistance

Autonomy is at the centre of all the human motivational models we recommend: SCARF, ARC, AMP. Self -selection gives team members more of their autonomy back.

When team members choose their teams, they naturally align with roles and projects that complement their competencies and interests. This liberty doesn’t just create a dynamic work environment, but it also breeds motivation and engagement, driving innovation and productivity.

Self-selecting teams also reduce resistance to change. Team members can say, "I made a choice to be part of this team," so, when things get difficult, it gives them an incentive to make the team work.

Setting Boundaries for Effective Self-Selection

Self-organization requires constraints or boundaries to be effective. Self-selecting teams need:

Team Competence - The Scrum Team should be cross-functional (i.e. the team is able to deliver complete user stories or features, without asking another team for help).
Skills - For example, one front-end developer, one backend developer, one additional developer, one tester, and someone with requirements or UX knowledge. Clearly this will vary as it depends on the project needs. Note, not everyone makes this an explicit constraint.
Team Size - Define the maximum and minimum number of people on a team. See: Scrum Team Size
Stewardship - Individuals should make choices on what they believe is best for the organization/product.

Sidebar: If the product being built requires few people (3 or less), consider making it part of the work of a bigger team. The same happens if the product work will be short-lived. Form high-function teams and then keep them fed. Unless truly required, don't pay a team re-formation tax every few months.

Mechanics of Self-Selection Process

The self-selection process involves several steps:

Orientation - Before the event, explain how self-selection works and why it’s being adopted.
Process Visualization - Draw a simple picture visualizing the day’s activities.
Shared Constraints and Product Vision(s) - Share the predefined constraints, product visions, and the product owner for each team.
Team Selection - Individuals choose their teams based on product vision, skill demand, and who else they want to work with.
Team Assessment - After each selection round, review the teams for imbalances or constraint violations.
Iterative Rounds - Usually, after three rounds, teams settle down.

From start to finish these events can take from two to six hours to run. The determining factor is the number of people in the group.

Stalemates and Logjams

After three rounds of self-selection, most groups are satisfied with the results.

If problems remain, there a couple of options. Sometimes a good conversation around why things are stuck can help. Amber Field has an example: "Our Engineering Director started a conversation, discussing everyone’s motivations for being on the over-staffed team (people loved that it was a full-stack team, they wanted to work with the leads, they wanted to do front-end work, etc). After one of our engineers spoke about wanting to work on a front-end solution that we call the Monitoring Dashboard, one of our Agile Program Managers realized that if we moved the Monitoring Dashboard work to one of the open teams, 1–2 engineers would happily come with it. After several sidebars, the matter was decided. The stalemate was over, we had our teams filled, and the event ended 30 minutes ahead of schedule!"

In another example I know, leadership gave the group a choice: either they self-organize to solve, or leaders can step in and make a decision for them. While forced decisions are risky, it seems to have paid off in that case.

How Do People Choose

Some make their selections based on interest in the product vision, and others choose because they already know some of the people on the team. In fact, many people move in groups of twos and threes, which tells us that the benefit of the latter is that they already know they get along with some of their teammates, which helps speed the team formation process.

Potential Fears and Risks

The self-selecting process in teams isn’t without risks. A lack of a clear product vision can make it harder for teams to understand what they’re organizing towards. Similarly, if there’s a lack of trust or an environment of fear, it hampers effective self-organization. If either of these are at play, they will likely need to be addressed before running a self-selection exercise.

Convincing Management

To convince management about the merits of self-selection, it’s crucial to address business constraints and present potential scenarios, as Serena Caruso mentions in an interview. "Even in the 'worst case scenario,' where agreement isn't reached, the organization gains insights into team preferences and dynamics, shedding light on the complexity of team creation and the potential need for a top-down approach." These insights wouldn’t have been gleaned in a traditional approach.

A Practical Look Into Self-Selecting, Distributed Teams
Empowering self-organising teams with self-selection
How to Form Teams? A Story of Self-Designing Teams
How Self-Selection Lets People Excel (Sandy Mamoli and David Mole)
Self Selecting Teams (Sandy Mamoli and David Mole)
Self-Selecting Teams: Could It Work For You?
Self-Selecting teams – tales from WW2 Lancaster bomber crews
Teamification: Agile Team Self-Selection
Team Self Selection Pocket Guide (Sandy Mamoli and David Mole)
Team self-selection (without the anxiety)
Team Self Selection workshop
Self Forming Teams at Scale (MS) a Crazy Idea

Research

Creating Great Teams: How Self-Selection Lets People Excel by Sandy Mamoli and David Mole </HighlightBox>

Self-Organization

Tue, 04 May 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import SelfOrganizationManagerLedTeam from '@/content/glossary/self-organization/images/self-organization-manager-led-team.jpg'; import SelfOrganizationSelfOrgTeam from '@/content/glossary/self-organization/images/self-organization-self-org-team.jpg'; import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

A self-organizing team is one where team members make all relevant decisions on how to achieve their goals. Contrary to the beliefs some people hold, self-organization isn’t a free-for-all where chaos reigns and there is no responsibility. Instead, it very much relies on the engagement, self-discipline, and focus of the team members. Self-organizing teams don’t lack leadership or roles; rather, these attributes emerge and change over time within the team itself instead of being appointed by an outside force (the fancy label is “emergent structure”). The person who provides leadership in one moment may not be the best suited for the next, so in a truly self-organizing team, roles change, often rapidly.

Benefits of Self-Organization

Increased Motivation and Engagement – Motivational models that we commonly refer to (e.g. ARC, SCARF) make Autonomy a central pillar. Self-organization teams are one way to grant people that Autonomy at work. This Autonomy leads to increased motivation and engagement. It’s empowering in many positive ways to not have rigid structure imposed on you from external viewpoints.
Resilience and Adaptability – When circumstances change unexpectedly, self-organizing teams adapt far more quickly, in part because they’re not idly waiting for direction from others (e.g. an unknown requirement from a customer, major local disaster, global pandemic)
Complexity – Manager-led teams struggle to deal with problems that require more knowledge, depth or perspective than a single person can encompass. (See: Complexity) As complexity increases in the world of work, manager-led teams are having an increasingly difficult time.
Creativity – Being responsible for achieving a goal, and having access to many minds, means the self-organizing team often finds more innovative solutions to problems than what a centrally-led team could produce.
Collaboration – Shared responsibility and decision making mean that team members talk more often. Increased communication gives us better knowledge of what our peers are working on and how we can help.
Learning and Cross-Skilling – When we work closely with people of different skills and backgrounds, we learn through observation and direct instruction. By expanding our own knowledge and skills in this way, more options are available to the team as a whole, and impediments are reduced. Another positive by-product is increased comradery and communication. As we see the challenges that people in other roles face, we have more empathy for them when things get difficult.
Speed and Effectiveness – As the team learn to work well together, they will outperform a manager-led team. Even more importantly, a self-organizing team will do a better job of delivering high-quality solutions to customers’ actual problems, as opposed to cranking more widgets out the door faster.

Making Self-Organization Work

Self-organizing teams need both support and space from management to be able to function effectively. In particular, management need to make the team’s Goal clear, and they also need to set decision-making boundaries.

<Figure src={SelfOrganizationManagerLedTeam} alt="manager led team with central decision making" caption="manager led team with central decision making" /> Decentralizing decision making** and putting it into the hands of those who will implement the decisions is the whole point of self-organization. However, many companies claim to embrace self-org, only for someone to say, “Yes, but I still need to make this decision.” Change the default. Most decisions should be left to the team.

Without a Common Purpose and commitment, team members have no reason to break out of their silos.[1] In the game of Scrum, their Product Vision is the long-term part of the goal and product strategy is the medium-term goal. Best case scenario, the team members are involved in co-creating the Vision with the stakeholders, so they feel a sense of ownership in addition to having a deeper and clearer understanding.

No team will succeed without Psychological Safety. Okay, but what does that mean? Psychological safety is knowing that I if try something and it fails, it won’t be held against me. Teams with Psychological Safety are also able to learn more rapidly. (Actually, I suspect that teams without a culture of safety don’t learn much at all.)

Creating a Learning Environment is a key step to making the team work effectively. Scrum builds in learning everywhere if our team only takes the time to breathe and notice. Refinement and Sprint Review provide product-focused learning, Retrospective gives the team a chance to learn about improvement opportunities, and Daily Scrum helps create both types of learning.

Finally, leaders and experts should start asking open-ended questions. This sends the signal that they’re not presupposing solutions and aren’t imposing their ideas on the team.

Challenges to Becoming a Self-Organizing Scrum Team

Traditional Hierarchy – When anyone in the chain of command asserts their “right” to make a decision that was inside the team’s decision-making boundary, the team members learn that they’re only self-organizing up to certain point, and then must wait for the adults. This is demoralizing and demotivating.
Matrix Management – This is when we create teams that are self-organizing but the team members report to different managers. Classic example: a product development team staffed with Business Analysts, Software Developers and Quality Assurance. Each part of the team is reporting to a different manager and each manager has their own needs. Rarely do these managers’ needs align well with the Product Goal.
Old Habits – Some people have 20 – 30 years of work experience waiting for someone to tell them what to do. It will take time and coaching support for them to take back their autonomy.
Dominant Personality – People who have dominant and outgoing personalities may feel that it is appropriate for them to take leadership in a team. Most are not doing this maliciously or intentionally, it is just an expression of their nature. In these cases the ScrumMaster will need to coach privately and use facilitation techniques that give everyone equal voice. (Beware. There are some people who read Machiavelli and thought it was a text book. Those people don’t belong in a team.)

The best Scrum Masters don’t solve their team’s problems. Instead, they encourage self-organization and help team members see where the problems are, then get out of the way. Only when the team can’t resolve the problem themselves does the Scrum Master step in, usually to escalate or ask for outside help.

[1] "The essence of a team is common commitment. Without it, groups perform as individuals; with it, they become a powerful unit of collective performance." https://hbr.org/2005/07/the-discipline-of-teams

</HighlightBox>

Servant Leadership

Tue, 16 Aug 2022 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Servant leadership is the act of leading through service to others. Okay, so how does that differ from traditional leadership? Traditional leadership emphasizes accumulating power and then using that power to get things done.

The label was coined by Robert Greenleaf in an essay in 1970:

The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions…The leader-first and the servant-first are two extreme types. Between them there are shadings and blends that are part of the infinite variety of human nature. … A servant-leader focuses primarily on the growth and well-being of people and the communities to which they belong. While traditional leadership generally involves the accumulation and exercise of power by one at the “top of the pyramid,” servant leadership is different. The servant-leader shares power, puts the needs of others first and helps people develop and perform as highly as possible.

Servant leadership can be applied in any endeavour and with any approach to organizing teams. Since our focus is Scrum and Agile, I will assume the servant leader is helping a team become more effective in the Scrum framework.

Greenleaf’s quote packs in a lot. Practically, how does a servant leader do their job? What characteristics do they display?

Active listener
Humility
Supportive and empathetic
Acts without power (no micro-managing, don’t assign work items to people)
Helps the team understand the purpose of their work (hint: make sure the team has a shared vision)
Helps the team understand their process
Models the behaviours they expect from others
Helps the organization understand the needs of the team
Helps the Product Owner ensure both the team and stakeholders have a good understanding of their current thinking
Mentors team members
Grows team members' autonomy
Speaks last - when there are ideas to be shared, gives space for other team members to speak first

For what it's worth, recent changes to the Scrum Guide mean that it no longer directly references "servant leadership". Instead, it says “Scrum Masters are true leaders who serve the Scrum Team and the larger organization.” It then cites a dozen ways the ScrumMaster serves the Team, Product Owner and Organization. So it avoids saying servant leadership and nonetheless implies it.

<LinkList heading="Agile Pain Relief Blog Entries"> -Scrum Anti-Patterns: Micromanagement

How Escape Rooms Teach About Teams </LinkList>

Slack

Mon, 26 Jul 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import HealthySprintSmall from '@/content/glossary/slack/images/healthy-sprint-small.jpg'; import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

Slack, in the context of Agile/Scrum, is when the time isn't solely focused on delivering. (It's important not to confuse this with Slack, a popular electronic communication tool, or the general vocabulary word defined as "a spell of inactivity or laziness".)

Slack time can be used as a buffer to deal with unexpected problems, issues, etc (see: Production Support), and Slack time is also for learning. Problems ensue when the Slack time for learning is only used for urgent issues.

Show me the rate at which your team is Learning (and adapting), and I will predict where they will be in a year.

When there isn't enough Slack in the system:

Dependencies from other teams get dropped or missed
There is no room to take care of small problems, so they accumulate and become large
People burnout
Technical Debt piles up, making the new feature work hard

In the Agile world, some approaches, like Scaled Agile, conflate both kinds of slack by lumping unexpected problems and learning time into the same bucket. This means Learning Time gets the short end of the stick.

Systems with no Slack are fragile and will break down when challenges appear. Healthy teams budget 15-20% of their time in every Sprint for Slack. With a Canadian audience, Slack is like the tax we pay to have a working healthcare system. To managers, I point out that while it looks more expensive up-front, it is more costly later when you have to pay the price of a fragile system.

Speed Trap: How the Obsession with Speed is Building a Fragile Organization - A fragile organization that goes faster will be knocked over in the slightest wind.
Cross-Skilling requires Learning Time
Scrum by Example – How to Handle Production Support Issues in Scrum - One common approach to Production Support uses slack time. </LinkList>

The Fifth Discipline: The Art & Practice of The Learning Organization by Peter Senge
Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco </HighlightBox>

Security in Scrum

Mon, 26 Apr 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

How do we build Secure products in Scrum? In a world where the development team deliver value every Sprint, it is hard to see how to ensure products are secure and still delivered every Sprint.

People have tried different approaches over time, with varying degrees of success.

Avoid:

Fix security issues as defects after the implementation
Hardening Sprints (which is just a formal version of fixing security issues later)
Special Teams - where the special team take care of the security work. Like all special teams in a Agile world, this team will likely become the bottleneck to frequent releases.

Try:

Special Team members/experts become advisers or coaches to teams trying to improve the security of their feature work. This scales better than a special team, because we're spreading the knowledge over more people.
Automate - for classes of problems that come up repeatedly, use automated tools to spot the problems. This is not a panacea, it merely reduces the load so that the experts can focus on more important work.
Definition of Done - Add the security requirements to Done. Now development team members are expected to check the specific requirement every time they declare an item as Done. Works well with automation, and experts become advisers.
Acceptance Criteria - when team members meet to discuss other acceptance criteria (hint: BDD), they also review their Definition of Done, they're reminded of security requirements. Based on this conversation, they write the acceptance criteria for that feature.
Separate Product Backlog Items - if some security needs are large enough, they might become their own Product Backlog Item. Caveat: the risk here is that product can't be released until key security features are implemented, contravening the Agile principle of "__Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
Build into all Scrum events - ask questions that relate to security in Sprint Planning; Sprint Review; Sprint Retrospective and Daily Scrum.

Everything mentioned about security is also applicable to any highly-regulated environment where the team are required to meet a compliance goal.

Scrum Anti-Patterns: The Hardening Sprint
Scrum by Example – Stuck Waiting for Other Teams (Special Teams and their effect)
Scrum Development Team – Who’s In It? </LinkList>

Continuous Compliance - Continuous Delivery with Compliance - DevSecOps — How Security Can Be Assimilated Into Scrum - DevSecOps Manifesto and What is DevSecOps?
A Guide to Threat Modelling for Developers - Secure software design, little and often
Managing Security Work in Scrum: Tensions and Challenges [PDF Warning] - Product Security Risk Management in Agile Product Management [PDF Warning] - SECURE SCRUM – INTEGRATING SECURITY WITH AGILE and the paper it was derived from: Secure Scrum: Development of Secure Software with Scrum [PDF Warning] </HighlightBox>

Spotify Model

Tue, 24 Oct 2023 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

The "Spotify Model" is often misunderstood and misapplied in organizations. It consists of Squads, Tribes, Chapters, and Guilds. Squads are like Scrum teams, owning specific parts of a product. Tribes are groups of squads that collaborate in related areas. Chapters consist of people with the same skills in a tribe, and Guilds are larger communities of interest. However, merely adopting this structure without a cultural shift is ineffective.

Many organizations make mistakes when implementing this model. Don't copy and paste another company's Agile approach. Remember, no model is perfect for all time and all organizations. Being truly Agile means evolving and adapting to each unique need. Create a custom Agile model based on your culture and people. Focus on key principles underpinning Spotify's success, such as: delivering value, product experimentation, autonomy, alignment, cross-functional teams, engineering culture, psychological safety, continuous improvement, morale, and optimizing workflow. These principles are crucial for long-term success.

The Spotify Model of Scaling - Spotify Doesn’t Use It, Neither Should You

"Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds" by Henrik Kniberg & Anders Ivarsson - the original paper
Failed #SquadGoals
My critique of “the Spotify Model” by Jason Yip
Spotify Doesn't Use the Spotify Model
The ‘Spotify model’ is not a model. Here is why.
There is No Spotify Model
There Is No Spotify Model for Scaling Agile
The top 3 points you should have paid attention to in the Spotify Engineering Culture videos that aren’t Squads, Chapters, Tribes, Guilds
Tribes and Squads. How adaptive is that?
You want to adopt the “Spotify Model”? I don’t think it means what you think it means!’ </HighlightBox>

Special Teams

Tue, 20 Apr 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Sometimes organizations form Special Teams assigned to tackle technical bugs or other challenges. Frequently, these special teams make the very problem that they're meant to solve, worse.

Three quick reasons, among many: - other teams no longer feel responsible for dealing with the problem: defects; security; ... - queues build up in front of the special team, often making it difficult to release - special teams have an incentive to keep their problems around forever to justify their continued existance

Scrum by Example – Stuck Waiting for Other Teams </LinkList>

Bug Teams v. The Nature Of Defects </HighlightBox>

Agile Organization Design by Jeff Anderson </HighlightBox>

Sprint Backlog

Thu, 25 Mar 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import CSMSampleScrumTaskBoardV2895x1024 from '@/content/blog/the-humble-sprint-backlog/images/2017CSM-Sample-Scrum-Task-Board-v2-895x1024.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

The Sprint Backlog is a list of [Product Backlog Items (PBIs) the Team has committed to for the next Sprint. It is the Scrum Team’s plan for how to achieve the Sprint Goal. Since the Sprint Backlog is solely for the use of the Team to organize their own work, they are the only ones who create, change, and manage it — not a tool, and not an outsider. Since Teams are unique, there is no single correct practice that they all should follow. Teams choose and experiment with whatever helps them most to stay focused and self-organize, creating the Sprint Backlog with whatever methods work best for them, such as index cards, whiteboards, or, yes, even electronic tools.

The Sprint Backlog: A Truly Complete Guide with Examples </LinkList>

Elements of an Effective Scrum Task Board
A Highly Evolved Card Wall
Myth: The Sprint Backlog can’t change during the Sprint
Sprint Backlog
Pattern - Your Scrum Sprint Backlog Caveat: it recommends the use of burndown charts - I don't anymore
What is Sprint Backlog in Scrum Framework </HighlightBox>

Sprint Goal

Fri, 26 Mar 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Sprint Goal is a single product objective shared by the Scrum Team that describes the purpose of the Sprint and ensures that everyone moves in the same direction. A simply-stated goal makes it easier to prioritize Product Backlog Items, assess whether tests and feedback are relevant to the goal, and summarize the work currently being done when asked by stakeholders. Sprint Goals are hard and not well understood. As a result, many teams skip or avoid them, but this is a missed opportunity.

A Sprint Goal isn't imposed on the team by the Product Owner. Rather, the PO explains what business objective they're attempting to meet then the team work with the Product Owner to describe what is feasible. So the Sprint Goal is something that is created through negotiation. Since all team members are participating in setting the Sprint Goal, they have a greater sense of ownership and purpose during the Sprint.

The Sprint Goal provides focus during the Sprint, especially during Daily Scrum. Some teams even go so far as to add a question like "Do we still believe in our Sprint Goal?" as part of the Daily Scrum.

When Teams Struggle to Set

To set a good Sprint goal, it requires the PO to prioritize the product backlog in a manner that a coherent purpose exists at the top of product backlog. When I see POs struggling with this, it is often a hint that their overall business strategy is unclear. (Consider looking at Impact Mapping, Story Mapping and the strategic tools to help in this case.)

Some teams make their goal process-oriented (e.g. complete all the User Stories committed in a Sprint, or complete 7 user stories) to help them get to a basic level of effectiveness. This misses much of the purpose of the tool. A Sprint Goal should help the team better understand the business objective so that their work rises above the level of just finishing tasks.

For reluctant teams, one trick that can work is brinksmanship. "If you don't set a real product oriented Sprint Goal, I will set a bad one for you." After doing that a few times, team members will likely start to participate in goal setting without provocation.

Questions for Better Sprint Goals

Do we believe this goal is technical feasible?
Will this goal interest stakeholders in the Sprint Review?
Does the goal help the team better understand what they're trying to achieve with the Sprint?
If the Sprint isn't going well, will this help the team refocus on the target?

7 Sprint Goal Patterns for Building Great Teams, Part One
7 Sprint Goal Patterns for Building Great Teams, Part Two
Building a Practically Useful Theory of Goal Setting and Task Motivation
Creating Effective Sprint Goals
Do we need a sprint goal? (Controversial. The authors recommend not using a Sprint Goal except under very particular circumstances.)
Examples Of Real Sprint Goals
Getting to Done: Creating Good Sprint Goals
How to Write and Use a Sprint Goal (With 5 Templates)
Is your Sprint Goal centred on deliverables rather than value and benefits?
Scrum History – The evolution of the Sprint Goal
Sprint Goals – Are They Important
Sprint Goals – What Do They Really Need (With Examples)
A Template for Formulating Great Sprint Goals </HighlightBox>

New Developments in Goal Setting and Task Performance - by Edwin Locke and Gary Latham </HighlightBox>

Sprint

Tue, 23 Mar 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import LifeCycleOfTheSprintLabelled1024x805 from '@/content/glossary/sprint/images/life-cycle-of-the-sprint-labelled-1024x805.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

A Sprint is a fixed period, ranging from one week to one month in length, during which the Scrum Team works to meet specific customer needs. As one Sprint ends, the next Sprint begins. The purpose of defining the work period is that it enables the Team to focus on a limited and prioritized number of features, and it encourages the delivery of at least some completed work to the customer each Sprint.

The Story of a Sprint - video and transcript

Is There a Best Day to Start and Finish a Sprint? </LinkList>

Sprint Burndown

Mon, 08 Feb 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Burndown charts graph work remaining vs time. They were originally used for tracking work in Sprints and across releases. Sprint Burndowns that track hours of task work remaining are usually considered an anti-pattern now. Instead, try limiting Work in Progress. Tracking (if required at all) can be done at the level of completed tasks or, better, completed User Stories. Burndowns for release imply the Product Backlog has fixed contents and we're only releasing every few months. Look instead at a Cumulative Flow Diagram to help improve flow.

Sprint Length

Fri, 26 Mar 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

The ScrumGuide says that Sprints "are fixed length events of one month or less to create consistency" and "When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame."

That's useful but incomplete. What is too long? What is too short? Where do most teams start?

Choosing a Scrum Sprint Length – Shorter Beats Longer </LinkList>

Determining Sprint Length
What is the optimal sprint length in Scrum?
Why Longer Sprints Probably Won’t Help </HighlightBox>

Sprint Planning

Fri, 26 Mar 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Sprint Planning is an event at the beginning of a Sprint where the Team plans the items they can complete in the next Sprint. They also craft a Goal to act as a focus for their work. Sprint Planning consists of three parts: Setting the Sprint Goal; Forecasting which Work Items the Team will achieve towards the Goal; Deciding how to do the Work. Hint from painful personal experience - the leading cause of poor Sprint Planning is inadequate Product Backlog Refinement.

Most of the time, your team shouldn't be Estimating Product Backlog Items in Sprint Planning. That normally happens in Backlog Refinement.

20 Sprint Planning Anti-Patterns
Capacity-Driven Sprint Planning
an alternate approach from Mike Cohn - Developer-Ordered Work Plan Pattern
Don’t Estimate Stories In Sprint Planning
Gut feel is as important as the velocity and other numbers for effective commitment
Mastering The Sprint Planning Meeting
Sprint Planning Anti-Patterns Part III
Sprint Planning Checklist
Sprint Planning Pattern
Should a Team Assign Work During Sprint Planning? </HighlightBox>

Sprint Review

Fri, 26 Mar 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Sprint Review is an event at the end of the Sprint where the Scrum Team review the completed work with stakeholders. Stakeholders provide feedback on the completed work and ideas for product improvements. The Product Backlog will get updated during future refinement to reflect what everyone learned.

Sprint Review and Retrospective are often confused. The Review is focused on the Product, Product Improvement, and feedback from Stakeholders/Customers. The Retrospective is focused on improving the team, their process and approach to the work.

Resources:

Distributed Sprint Review:

Remote Agile: Sprint Review with Distributed Teams
Sprint Review and Miro
Sprint Review and Retrospective in Large Scale Scrum (40 page article)

Stable Teams

Fri, 26 Mar 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

A stable team is one in which team membership doesn’t change often and, instead, is consistent over time. When team membership changes every few months, teams (Scrum, Kanban, XP or otherwise) struggle to: create Psychological Safety, maintain Predictability, stay focused on Product Vision, and grow their capability to Deliver. Stable teams isn't a requirement of Scrum or Kanban, but its absence causes great harm.

Read: In Agile, Where Change is Valued, Why Is a Stable Team So Important?

Story Mapping

Sat, 25 Oct 2025 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import StoryMapping from '@/content/glossary/story-mapping/images/story-mapping.png'; import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

A Story Map is a way to help visualize the flow or story of a product. Across the top or horizontal axis of the map we place the major steps (often features) in the user's workflow. Underneath each step or feature are the individual stories that would build out the portion of the product.

Story Maps were invented because their creator Jeff Patton was frustrated with "flat" Product Backlogs that lost track of the Product Vision. People use Story Maps as a stepping stone from Vision to User Stories, they're also used to help sort out and recover from a messy Large Product Backlog.

Story Mapping Tools

User Story Mapping Discover the Whole Story, Build the Right Product – Jeff Patton </HighlightBox>

Swarming

Thu, 02 Dec 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

If Pair Programming is two people working together on a single problem at the same time (pre-Covid, Pairing meant sitting side by side with one computer), then Swarming takes Pairing to the next level, with three or more people working on a problem together.

Most teams discover Swarming as they approach the end of the Sprint with multiple Sprint Backlog Items in progress. If it's clear that not all items will get to 'Done', they start to swarm one or two items at a time to complete them.

More effective teams learn to swarm all items, so a team of six people might only have two items in progress at one time. Each item gets worked on by several people collaboratively until it gets to 'Done'. Beware, Swarming is often a gateway drug to Ensemble Programming.

Scrum by Example – Overtime on a Scrum Team is an Unhealthy Sign - Swarming would have helped, just a bit. Scrum by Example – The Story of an Incomplete Sprint - the classic example that should lead to a team discovering Swarming.

Systems Thinking

Fri, 30 Apr 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

Systems Thinking takes the view that any problem we're working on is part of a larger, interconnected system. Instead of making a quick fix, systems thinking encourages us to work with our team to discover the larger context that surrounds our current problem.

A good example of systems thinking in action is the game of pool. You sank a coloured ball. Was it the cue ball that worked? The cue? Or the player? The player. Yet, if our perspective were the coloured ball, we might think the cue ball sank us. Systems thinking challenges us to see problems from a broader perspective than just the pieces immediately visible around us.

Many problems you see in your current situation were caused by an outside force. For example, if you see poor performance in a team, you want to study the incentive system or leader behaviour. The team is often not the source of the problem. (There are another 100+ levers I look for.)

A simple version of systems thinking to start:

Always ask yourself, "And then what?"
Think in increments of time. What do the consequences look like in five days? Five months? Five years?
What contributed to this five days ago? Five months ago? Five years ago?
Draw out the possible courses of action you might take using columns to organize consequences.

Feedback Loops

Systems thinkers are always looking for where feedback loops play a role in the system. There are two kinds of loops: positive (reinforcing) and negative (balancing).

Positive feedback loops reinforce and amplify growth. An example is as the team's morale improves, so does their productivity, and as their productivity increases, so does their morale.

Negative feedback loops balance. An example is as the temperature in a house increases, the air conditioning starts, and the temperature is reduced.

Emergence

A system can exhibit properties that aren't present in the individual components. A team can become high-performing, but the performance isn't present in any of its parts.

In our CSM workshop, I coach ScrumMasters to use Systems Thinking to understand the problems their Scrum teams face.

<LinkList heading = "Agile Pain Relief Blog Entries"> - Beyond the Surface: GenAI-Powered Critical Thinking for Deep Team Issues - Scrum By Example Series - Scrum Anti-patterns </LinkList>

Dancing with Systems
Guidelines for Drawing Causal Loop Diagrams
Habits of a Systems Thinker
Leverage Points Places to Intervene in a System - also as a video:In a World of "Systems”
Peter Senge and the learning organization
Russ Ackoff (helped establish Systems Thinking) – a short video
An Overview of the Soft Systems Methodology
Systems Practice, Abridged
Systems Thinking
Tools for Systems Thinkers: The 6 Fundamental Concepts of Systems Thinking
Why Systems Thinking? - Along with a good description of why, they also have a free course. </HighlightBox>

SystemsOne: An Introduction to Systems Thinking - Draper Kauffman (only 48 pages long and free)
Making Work Systems Better - Luc Hoebeke (pdf)
Thinking in Systems: A Primer – Donella Meadows
The Systems Bible: The Beginner’s Guide to Systems Large and Small – John Gall
Beyond Connecting the Dots – (free book) </HighlightBox>

Sprint Retrospective

Fri, 26 Mar 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import TheGuideToEffectiveAgileRetrospectivesInfographicV111Scaled from '@/content/glossary/sprint-retrospective/images/The-Guide-to-Effective-Agile-Retrospectives-infographic-v1-1-1-scaled.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

The Sprint Retrospective is an event at the end of the [Sprint where the Scrum Team reflects on all that happened in that period, with the intention to improve how they work in the next Sprint.

Sprint Review and Retrospective are often confused. The Sprint Review is focused on the Product, Product Improvement, and feedback from Stakeholders/Customers. The Retrospective is focused on improving the team, their process and approach to the work.

The Guide to Effective Agile Retrospectives by Mark Levison - get the free eBook and email learning series here

Distributed Retrospectives

Can you adapt any activity for a remote retrospective?
How we do large scale retrospectives
Sprint Review and Retrospective in Large Scale Scrum (40 page article)

Retrospective Activities Catalogs

Retrospective Wiki
Catalog of Retrospective Activities
Retromat - Plans for Retrospectives - over 100 activities </HighlightBox>

What Did You Say?: The Art of Giving and Receiving Feedback – Charles N. Seashore, Edith Whitfield Seashore, Gerald M. Weinberg
The Retrospective Handbook – Patrick Kua
Agile Retrospectives: Making Good Teams Great – Esther Derby, Diana Larsen
FunRetrospectives__: activities and ideas for making agile retrospectives more engaging by Taina Caetano and Paulo Caroli
Fifty Quick Ideas To Improve Your Retrospectives by Ben Williams and Tom Roden
Retrospectives for everyone – Powerful metaphors for effective retrospectives - Madhavi Ledalla </HighlightBox>

Team Formation Models

Mon, 30 May 2022 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import UnstableTeamsTuckmanStages from '@/content/glossary/team-formation-models/images/Unstable-Teams-Tuckman-stages.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Team Formation Models are helpful in understanding what state a team is at, and then using that information to make an educated guess as to what will help them progress. There are a large number of models to be found, however many of them don't appear to offer any evidence to support their validity.

The Tuckman Model is the one I refer to most often:

Forming- starting point, coming together, unsure things will work, avoid conflict
Storming - getting to know each other, role conflict, stepping on each other's toes, disagreement how the team should work
Norming - starting to find a rhythm, give/receive feedback, roles clarified, approach to work is starting to be well-defined
Performing - the team members are in sync, it is like the team has developed a mind of its own. It's now able to get a lot more work done as a team than as individuals. There is a sense of camaraderie.
Adjourning - the team is broken up at the end and they mourn

Not all groups go through all stages. It is also possible to slide back from one stage to another (e.g. from Norming to Storming). This usually happens when there is a shock to the system, such as a change in team membership, radical change in goals, or change in how the team is handled by management.

At different stages, different tools will be important. Forming: need to find a common goal (i.e. Product Vision, Working Agreements), Storming: we need to support understanding each other (i.e. Facilitation, Active Listening), Norming: we need to find better ways of working together (i.e. Cross-Skilling, Engineering Practice Improvement), Performing: take a bow and then continue improvement work. Adjourning: we recommend long-running Stable Teams so there is nothing special to recommend around adjourning.

We use Tuckman's as it is the model that has the largest body of research, testing its validity.

Other models to consider, with at least some research to back them:

GRPI Model - Goals, Roles, Processes, Interpersonal Relationships - Rubin, Plovnick and Fry
T7 Model of Team Effectiveness - Lombardo and Eichinger
ADKAR - while primarily focused on individuals, this model is helpful in understanding teams as well.

Avoid these models as they are either not research backed or the research invalidates them:

Lencioni Model - not research backed
DiSC Model - was developed as Personality Testing Model, not a Team model. Even its original realm of personality testing has flaws, please don't use it

8 Models of Team Effectiveness Caution: some of the models they mention are not well validated
Behavioral Hypothesis of Team Behavior - Petri Heiramo - Final.pdf - This is a PDF from a workshop presentation
Phases in Building Agile Teams with Tuckman's Group Development
The Stages of Group Formation, and how they Aid Your Teams Success
Tuckman Model of Team Development: A Detailed Blueprint to Build Awesome Teams
Understand Teams by Using the GRPI Model
Understanding the Tuckman Model of Team Development
ADKAR Model: What Is It and How to Use It </HighlightBox>

Team Launch

Mon, 16 Sep 2024 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

The purpose of the team launch or liftoff is to help the team move from a group of unconnected people to have the start of a real team.

(Additional content to be added soon.)

TDD vs BDD

Tue, 27 Apr 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Test Driven Development [TDD] and Behaviour Driven Development [BDD] are often confused because the similarity of their names. TDD is the original technique - "engineering practice where the developer writes their Unit Test case before they write their code". It helps raise quality by ensuring the developer built what they intended to. However, it doesn't prove that the developer had the right intention when they wrote the code. BDD is an evolution of TDD. In this approach, the people doing the work - often a BA, Developer, and Tester - work together to define the acceptance criteria as examples that could be understood by a non-technical person. Further, the examples are often automated as acceptance tests on the boundary of the system.

Test Driven Development is Not a Quality Assurance Technique </LinkList>

<HighlightBox heading="Resource Links" variant="resourceLinks"> The internet is rife with sources that advocate one over the other. This feels disingenuous. My experience is that I usually need both tools along the delivery path for a product.

TDD vs BDD: A Developer’s Pocket Reference With Examples
TDD vs BDD - from Matt Wynne
What’s the difference between Unit Testing, TDD and BDD? </HighlightBox>

Technical Debt

Tue, 04 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

Technical Debt is a deeply misunderstood term. It was originally coined at the beginning of Agile time by Ward Cunningham - from 1992:

Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid.

In the Cunningham definition, Technical Debt is okay when it is paid back promptly. Since his original definition, it has been misused to mean any mess left behind when team members rush through their code base, often because they feel pressure to get more work done faster.

For the non-technical people, the simplest way to imagine the problem is to pretend your developers are in a large gym. Time how long it takes for them to run across the gym and back. (Repeat enough times that the number is stable). Now move a few chairs into the middle of the gym, at random. Ask them to run across the gym again. They're slower. Repeat. Eventually there are so many chairs they can no longer walk around them, instead they have to crawl to get across the room. The chairs are their technical debt and the additional time taken is the interest your team is paying for that debt.

Scrum by Example – Stop Digging New Holes
Technical Debt a Perspective for Managers
Scrum Anti-Patterns: The Hardening Sprint - Hint: they contribute to the problem
Technical User Stories or The Team Try to Pull a Fast One on the Product Owner
AI-Generated Code Quality and the Challenges we all face </LinkList>

TechnicalDebt is Not A User Story

As a Developer is not a Story -- Bill Wake
Technical Stories: We don't need 'em -- Ron Jeffries
Refactoring not in the Backlog- also Ron Jeffries
Technical User Stories" Ariel Valentin </HighlightBox>

<HighlightBox heading="Related Books" variant="relatedBooks"> - Your Code as a Crime Scene - Adam Thornhill - Working Effectively with Legacy Code - Michael Feathers - Managing Software Debt: Building for Inevitable Change - Chris Sterling - Beyond Legacy Code: Nine Practices to Extend the Life - David Bernstein </HighlightBox>

Tech Debt Stories

Tue, 04 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Technical Debt Stories is an attempt to solve the Technical Debt problem by creating fake User Stories. Since User Stories are about delivering real business value to the customer, I don't recommend inventing these. Further since the Product Owner prioritizes the Product Backlog in Scrum, it would seem nothing technical belongs there.

Many teams maintain their own list of technical debt and pull from it using their own criteria. Sometimes, the best reason, we're already working in an area of the code base that is debt-ridden. Work on debt from that area.

As a Developer is not a Story -- Bill Wake
Technical Stories: We don't need 'em -- Ron Jeffries
Refactoring not in the Backlog- also Ron Jeffries
Technical User Stories" Ariel Valentin </HighlightBox>

Test Driven Development [TDD]

Fri, 23 Apr 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

Test Driven Development (TDD) is the engineering practice where the developer writes their Unit Test case before they write their code. Like Unit Testing, it is not a replacement for Exploratory Testing nor will Testers be unemployed. Instead, it forces a Developer to declare their intentions before they start to write the code. By declaring their intentions in a testable form first, they’re forced to take time and reflect more carefully on what they’re trying to achieve. As a side effect, developers write code that is simpler and more readable. In addition, code that is written “Test First” tends to be better isolated from other classes and methods because the developer was challenged to minimize dependencies to make it easier to test.

It is a practice or discipline that is used inside other Agile processes (Scrum, XP, Kanban etc.), however it isn't a process itself. TDD is an excellent technique, however it has limits. It works by ensuring the developer built what they intended, and by reducing complexity. Reducing complexity reduces defects. However, TDD doesn't prove that the code does what the user expected, just what the developer expected.

Introduction to Test Driven Development
Failing to Falsify - is about the importance of writing failing tests
James Shore Let’s Play TDD – 200 webcasts of doing TDD on a real application
Keith Braithwaite – TDD as if you meant it
Looking at TDD: An Academic Survey
Micheal Feathers “The Deep Synergy Between Testability and Good Design”
Practice Problem: Guitar Shack
Styles of Naming tests (not https, will require a browser acknowledgement)
TDD Heuristics: 0, 1, N
TDD Heuristics: Given-When-Then or Arrange-Act-Assert
TDD Heuristics: One Assert Per Test
Tell Don’t Ask
Test Driving Unity a 3D game development tool with too much cohesion
Test-Driven Development as Pragmatic Deliberate Practice
The payback of pairing with TDD
The ROI of Test-Driven Development
TDD Guided by ZOMBIES
TDD × ROI: Is Test-Driven Development worth the money?
Thoughts on TDD (After almost 20 years)
We’re in this for the Money

Tutorials

Test Driven: TDD and Acceptance TDD for Java Developers_ – Lasse Koskela
Test Driven Development for Embedded C_ – James W. Grenning
Test Driven Development: By Example – Kent Beck
Test Driven Development - Free eBook by Grzegorz Gałęzowski - It's a work in progress
Modern C++ Programming with Test-Driven Development - Code Better, Sleep Better - by Jeff Langr
Test-Driven Development, Build Automation, Continuous Integration - Lorenzo Bettini </HighlightBox>

Team Size

Fri, 26 Mar 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

The Scrum Guide offers very limited guidance, suggesting 3-9 people per team (exclusive of ScrumMaster and Product Owner), without giving reasons or context for those numbers. The Scrum Guide provides no guidance in choosing team size and, based on the evidence, the range is too wide.

What is the Recommended Scrum Team Size? </LinkList>

Testing

Thu, 29 Sep 2022 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import AgileTestingManifesto722x1024 from '@/content/glossary/testing/images/Agile-Testing-Manifesto-722x1024.png'; import TestAutomationPyramid from '@/content/glossary/testing/images/Test-Automation-Pyramid.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Agile Testing is "collaborative testing practices that occur continuously, from inception to delivery and beyond, supporting frequent delivery of value for our customers. Testing activities focus on building quality into the product, using fast feedback loops to validate our understanding. The practices strengthen and support the idea of whole-team responsibility for quality." - Lisa Crispin and Janet Gregory in Agile Testing Condensed.

Role

No separate role - rather a need that a self organizing team needs to fulfill. Requires true collaboration.

Participate in backlog refinement and sprint planning to understand user stories, acceptance criteria.
Collaborate on creating acceptance criteria with other team members.
Continuous Testing - start testing before development starts on PBI/User Stories.
Help automate tests of Acceptance Criteria (i.e. Example Mapping).
Provide Product Owner feedback during Sprint itself and also in Sprint Review.
Help the Product Owner and whole Scrum Team understand where the product quality is, especially with respect to the Definition of Done.
Mentor and coach other team members to raise quality, especially through cross-skilling.
Ask questions about usability, accessibility and security. Highlight risks found in these areas.
Ask questions about the business domain.
Exploratory testing - in addition to automating acceptance tests, exploratory work takes perspectives that haven't already considered.
Testing isn't checking to see if the product works.
Work in the language of the customer.

Key Ingredients for Success

Whole Team Approach
Agile Testing Mindset
Automate Regression Tests
Automated Acceptance Tests as Living Documentation
Continuous Feedback
Collaborate with Customers
See the Big Picture

Example Mapping
Scrum by Example – The Story of an Incomplete Sprint </LinkList>

Design for Testability
Do You Need a Test Column?…. Let’s Talk - title should be: "Does Your Sprint Backlog Need a Test Column?"
Just Say No to More End-to-End Tests
QA to AQ: Patterns about transitioning from Quality Assurance to Agile Quality - This paper outlines core patterns for transitioning from a traditional QA practice to a more agile one, where quality is addressed earlier in the process and QA plays a more integral role.
Test Planning Cheat Sheet
Testing is a Team Problem

Layers of Test Automation

Test Automation

Mind mapping

Chaos Engineering

Principles of Chaos Engineering
Chaos Engineering Upgraded </HighlightBox>

Agile Testing Condensed by Janet Gregory and Lisa Crispin - Summarizes their first two books in a way that makes Agile Testing accessible to all team members.
Explore It! Reduce Risk and Increase Confidence with Exploratory Testing by Elisabeth Hendrickson - Provides depth on the oft-ignored subject of testing beyond the automation. </HighlightBox>

Theory of Constraints

Fri, 25 Nov 2022 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

The Theory of Constraints is a system improvement tool. It illustrates how in a system where we find a bottleneck, the bottleneck is the constraint that limits the performance of the entire system.

For example, on a software development team that has a number of software developers and only one tester, the work will quickly pile up in front of the tester. The speed at which the tester operates constrains the whole team's ability to deliver value. Non-software example: we have a team with several writers and only one editor. The pile of work that needs to be edited quickly grows. The editor (like the tester) has become the bottleneck to delivering value.

No amount of speeding up work at the other stages will affect the throughput of the team. So I would expect these teams to put in effort to reduce the pile of work in front of the bottleneck. In this case, that would likely involve cross-skilling. Could a writer do a first editing pass on another writer's work? Can a developer help with testing? Over time, an Agile team would expect that multiple team members will learn in areas where the team experiences bottlenecks, so they can handle this naturally and within the team itself.

The full theory of constraints has a number of steps to ensure the bottleneck is addressed. But to keep my examples simple, I just assumed the bottleneck was that the team had insufficient skill to help. Done well, the analysis would have been deeper and far reaching.

Theory of constraints comes to Agile from the world of manufacturing. It is the work of Eli Goldratt, explained in the business novel The Goal.

Applying The Theory of Constraints to Agile Software Development
The Dice Games
The Theory of Constraints
a deep dive that examines financials - The Theory of Constraints in Agile
Theory of Constraint’s Dice Game Simulator
What is the Theory of Constraints? </HighlightBox>

The Goal: A Process of Ongoing Improvement by Eliyahu M Goldratt and Jeff Cox
Rolling Rocks Downhill: The Agile+ToC Business Novel (Theory of Constraints Simplified) by Clarke Ching
Theory of Constraints by Eliyahu M. Goldratt </HighlightBox>

Unit Testing

Mon, 08 Mar 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Unit Testing is an approach to test small, isolated chunks of code that prove whether the method did what the developer intended when the test was written. This means testing only one specific aspect or path, through a single method, producing one result.[1] Since most methods have multiple paths through them, they need multiple tests.

Unit Testing doesn't guarantee no bugs, nor is it a replacement for other kinds of testing. Instead, a Unit Test is simply a tool to help a developer discover if they built what they intended to. If their intentions weren't correct, a Unit Test won't catch that, so they have only a limited effect on quality.

Unit Testing forces us to think through more of the edge cases when we're building out the unit tests. As a result, the number of bugs is reduced. Unit Testing also makes it safer to make changes, especially refactorings since the test cases help prove the refactoring doesn't affect the existing behaviour.

Running Unit Tests frequently (usually every 10 -15 minutes) will give quick feedback if changes have harmed the behaviour of some other part of the code.

Example class is handling a user ordering books from a book store. Input has been validated else where, so the test cases just need to cover the functionality.

When creating test cases, consider:

Happy Path - E.g. Order one book; Order two books; Order many books; Order multiple copies of the same book
Inflection Points - E.g. Order more than 5 books free shipping; Order more than 10 books, get one book free
Edge Cases or Boundary Conditions - E.g. O books ordered; 1000 books ordered
Exceptional Conditions - E.g. Payment failed

Attributes of Good Tests

Readability - The name must tell the reader at a glance what is being tested. Furthermore, when a test failure is logged, the name should make it easy to understand what's going on.
Organization - Arrange, Act, Assert: Arrange everything so the test is ready to run. Act - call the method or operation being tested. Assert - the expected result was received.
Fast Tests - If our tests take more than a few seconds to run, we will run them less often. Interactions with the Internet; LAN; Database; or filesystem slow our tests down. In the age of modern SSDs, a few filesystem tests are probably not bad, however if there are many, their runtime will dominate the time it takes for the tests to finish.
Narrow - Investigating failure is quick since each test case tests only one logical thing even if requires multiple asserts. Example: In testing a bank balance transfer from one account to another, testing that one account is decremented and the other incremented is one logical thing (a transaction), which may require two assert statements. Ideally in this case we would use extensible assertions like AssertJ.

assertThat(fellowshipOfTheRing).hasSize(9) .contains(frodo, sam) .doesNotContain(sauron);

Repeatable - Both Deterministic (same result every time they're run) and Clean (they don't leave messes behind on the filesystem or database)
Isolated - Tests should not rely on the order they're run in, nor should they rely on a previous test to leave the system (filesystem, database, ...) in a known state.

Test Smells

Like Code Smells, but for Unit Tests. It's possible to make it hard for the people to follow to read your Unit Tests.

Logic in tests
Tests with no assertions
Multiple lines to assert a single thing
Testing multiple concepts in a single test case

Not everything written in UnitTest tool (e.g. JUnit, NUnit, Jest or ...) is a Unit Test. These tools have a good test runner, IDE Integration, test reporting and support from CI tools. So other types of tests are often automated with these tools: API Tests; Integration Tests and even BDD style Acceptance Tests. To improve clarity and keep the unit tests clear, it is a good idea to organize them into separate groups or folders.

Choosing the right JavaScript testing tool
Code from Practical Unit Testing with JUnit and Mockito
Database UnitTesting Framework for SQL Server
Don’t Measure Unit Test Code Coverage
F.I.R.S.T. Unit Testing Principles
Improve Your Unit Testing 12 Ways
Improving On assertEquals with JUnit and Hamcrest
Infinitest
JUnit’s Built-in Hamcrest Core Matcher Support
Multiple Asserts Are OK
Real world mutation testing
Test Driven Databases
UnitTest (by Martin Fowler)
Unit Testing (from the book Software Engineering at Google)

Unit Testing Books:

Pragmatic Unit Testing in Java with JUnit, 3rd Edition - Jeff Langr, Andy Hunt, Dave Thomas
Pragmatic Unit Testing in C# with NUnit – Andy Hunt, Dave Thomas
Pragmatic Unit Testing in Java with JUnit – Andy Hunt, Dave Thomas
xUnit Test Patterns: Refactoring Test Code – Gerard Meszaros
The Art of Unit Testing: with Examples in .NET – Roy Osherove

[1] From @TimOttinger F.I.R.S.T. Unit Testing Principles

</HighlightBox>

When to Use Scrum

Fri, 21 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

Frequently in workshops, I get asked, “Where shouldn’t we use Scrum?” The short answer is there are lots of instances where the Scrum framework doesn’t fit. However, to give a more complete and effective answer to this question, first we need to have an idea of why and when Scrum does work and what the key conditions are for success. We can then show examples of where it isn’t a good fit.

What Are the Limits of the Scrum Framework?

User Story Splitting

Thu, 08 Jul 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

User Story Splitting is the art of splitting User Stories or Product Backlog Items (PBI) into smaller parts when an item is too big. My recommendation is that Stories be no larger than 1/5 to 1/10 of the team's capacity for the entire Sprint. There are many reasons to split including: better flow of work; easier to understand items; easier to estimate; etc. Whenever we split a PBI, we should ensure that the resulting item still has demonstrable value, so splits that look like team member tasks don't count. Most of the time we only split stories that are candidates for work in the next few Sprints. We don't split all items in the product backlog months ahead.

User Story

Thu, 09 Nov 2023 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import UserStorySlices from '@/content/glossary/user-story/images/User-Story-slices.png'; import UserStoryIndexCardBlank from '@/content/glossary/user-story/images/user-story-index-card-blank.jpg'; import APRBlogIllustrationsNov2019AcceptanceCriteriaBV21024x607 from '@/content/glossary/user-story/images/APR_Blog-Illustrations_Nov2019_AcceptanceCriteria_B_v2-1024x607.jpg'; import APRBlogIllustrationsNov2019AcceptanceCriteriaAV21024x607 from '@/content/glossary/user-story/images/APR_Blog-Illustrations_Nov2019_AcceptanceCriteria_A_v2-1024x607.jpg';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

In Scrum, a User Story is a tool used to provoke, and then summarize, a conversation between the Development Team and their Product Owner, for a better understanding of an item on the Product Backlog. The User Story provides context regarding who a Product Backlog Item is being developed for, and why it is of value.

Are User Stories Part of Scrum?

It’s important to note that a user story isn’t part of Scrum per se, but is a tool that grew up beside Scrum and is often used in tandem. User stories can be helpful but aren’t required as part of the practice of Scrum. When used by Scrum Teams, user stories are placed in the Product Backlog along with anything else that affects the Product.

User Stories Capture Product Feature Requirements in Story Form

User stories replace traditional written requirements. The often-used language of a “Use Case” is stilted and hard to read. A user story acts a reminder of the conversations that created it, to move the focus from What we’re building (what often happens with traditional requirements) to Why and Who. As humans, we’re very good at remembering stories and conversations, but we’re not good at remembering a list of facts. User stories leverage this principle by capturing the main points in the form of a natural conversation.

Thin Vertical Slice

A user story is said to be a “thin vertical slice” – a pithy statement that is hard to digest. “Thin” is just a funny way of saying they’re small. Small enough that a couple of team members could finish one in a few days of work. “Vertical Slice” – imagine software to be composed of layers, for example: User Interface, Business Logic, and Backend systems. So an item that goes through all the layers is a vertical slice. A horizontal slice would focus only on a single layer or components.

How to Format a User Story

Everyone who has seen a user story before can rhyme this format off:

“As a <User/Role>, I want <to do something> so that <value>”

This is so popular that many people think this is a User Story itself. (It’s not.) The original user stories (going back to 1996/7) had no predetermined format. The above format is just one of several that is popular today. Here are two more:

“As a <role> I want <business value> by <method/requirement>”

“In order to <achieve some value> as a <type of user> I want <some functionality>”

If whatever user story format you’re using isn’t helping the Scrum team have a good conversation around what the end user wants and why they want it, then abandon it and create a new format. The exact user story format isn’t important – the goal is simply to be clear on who wants what and why. Present it in the form of natural language, rather than technical jargon, to make it easier to understand and remember. It also makes it more human-oriented, which helps a ton with motivation.

Typical components of user stories, often referred to as the three C’s:

Conversations: discussion of the details. Results in creating the acceptance criteria.
Confirmations: Acceptance criteria that, in software, can be turned into automated acceptance tests.
Card: A physical token (with a story title/description) traditionally written on a small paper card or sticky note to aid in planning. Acts as a reminder to have conversations.

Need, But Not a Solution

User Stories explain the need behind a product or feature, but not the solution. Traditional requirements often didn’t state the need, and instead they worked through the fine-grained details of what to implement without showing the team why it mattered. It is difficult to do a good job building a feature when it’s not clear why it’s needed. Worse, it’s demotivating. We need to see that our work has meaning and purpose. A user story is intended to state the business need in addition to what the story will accomplish.

Are Stakeholders involved in User Stories?

Some Scrum teams invite interested stakeholders (e.g. Marketing or Sales Manager, a real live end user) to the Sprint Review when they’re working on features that are especially important to the stakeholders. In these cases, the User Story facilitates the conversation between the people who want the feature (the Stakeholders) and the people building it (Scrum Team), and the team and Product Owner get to hear firsthand about the underlying need or rationale behind the product request. Once the Developers understand the intention behind the feature, and what the end user wants to achieve, they can get to work and figure out best possible solutions for how to build it.

A User Story is Different From Definition of Done or Acceptance Criteria

"Where do the details go?" is a question I often hear in Product Owner workshops. The original user stories had the text of the story on the front and the detailed acceptance criteria on the back. Specific details about what a story allows and disallows become the acceptance criteria, that are effectively the children of the user story.

Confusion over what is a user story vs. definition of done vs. acceptance criteria is one of the most common problems in Scrum, and we cover it in detail here. But, in a nutshell, Definition of “Done” is the global quality checklist for all user stories. Acceptance criteria are the specific details needed to complete a user story. A user story is a placeholder for a conversation about meeting a User need.

Goals of a User Story

focus on the problem that needs solved, not the solution to the problem
start a conversation about what problem to solve, why it needs solving, and who needs it
demonstrate a need as concisely and simply as possible
be a small, vertical slice of functionality

INVEST

Demonstrating the INVEST Criteria

(Updated: November 2023)

</HighlightBox>

Vision

Mon, 08 Mar 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import KanerDiagramOfParticipationDivergentThinking1024x557 from '@/content/glossary/vision/images/Kaner-Diagram-of-Participation-Divergent-Thinking-1024x557.jpg';

import HighlightBox from '@/components/global/highlight-box.astro';

The Product Vision is a shared understanding of the overall goal and purpose for creating a product. Your vision describes the motivation behind creating the product, it is not the product itself.

The Product Vision provides purpose and direction for the team. Without a vision, a group of people have little reason to move beyond individual work silos and become a true collaborative team. In addition, without a vision the team will flounder their way through the product delivery process making best guesses instead of informed choices.

For this reason, one of the first things I ask all new teams that I meet is, “Please tell me what your Product Vision is.” To ensure that it’s really the team’s own understanding, I ask the Product Owner to leave the room first. Most teams can’t answer the question because they don’t understand the vision.

Product Vision is Shared Understanding

In too many cases, Product Vision is decided by a central group and then handed out to the team. You can’t magically take something created by one group and expect other people to understand it. The least effective model I have seen is when the Product Owner shares a PowerPoint of the vision with the victims. They will learn little and retain less. It is far more effective to invite the people who are building the product to be in the room and participating in co-creating the vision.

Vision vs Strategy vs Tactics

Vision is where you’re going, strategy is how you’re getting there. Vision is focused on the longer term (in 3–4 years, where do you want to be) while Product Strategy is focused on the medium term (what are our options in the next 6–8 months). When it comes to strategy in the Agile world, look for tools that are focused on allowing you to explore options, instead of a fixed roadmap of what will happen. Examples include: Impact Map, Story Map, Opportunity Solution Tree.

Vision Tools

If you ask most team members what they expect from a vision, they will suggest that it is a short, meaningless statement, written with nice sounding words. This type of vision has only limited value.

There are a number of effective tools and exercises, but please remember that much of their value comes from the fact that the vision is co-created. The people who will build the product were present in the room when the vision was defined and so they understand why it is valuable and what it represents. If they’re not present, then all of the tools below become fancy versions of a PowerPoint presentation containing a short, meaningless statement.

Product Box – You create a physical box that would market the product in the real world. In the virtual world, you give people a fixed surface area in a virtual space like Mural/Miro - this is exactly what we do in our Certified Scrum Product Owner workshop. This is a powerful tool because we’re challenged to draw and, since we don’t that very often, it sparks creativity (laughter, too).
Vision Board – A one-page board that gets you to answer the following key questions/prompts: State your overarching goal; Who will benefit from the product; Needs or Pains these people have; … - We also practice with this tool in the CSPO workshop.
Pixar Pitch – Trigger warning: this will ruin all Pixar movies for you - Storytelling is one of the most effective ways to communicating an idea. A former Pixar editor (Emma Coates) noticed that Pixar movies follow a similar pattern: Once Upon a Time There Was ___. Every Day, ___. One Day___. Because of That,___. Because of That, ___. Until Finally ___.
Remember the future – Imagine that it is 5 years in the future and your company has just released a milestone version of the product. Then imagine several months later, when your customers are overjoyed. Why are they delighted? The customers have been talking so much, there is a headline in the New York Times/Globe And Mail. What does it say? The exercise works because it is easier for our brains to look back on something, than it is to look forward.

Vision Creation Workshop

We offer Vision Creation Workshops in our private training, but you can also run one yourself.

Preparation: Before the workshop, do some customer research by interviewing 10–20 customers and finding out what pain they’re suffering from. Ask open-ended questions and keep interviewing until you can predict what the next person will say. From past experience, that often happens after 12–15 people.

Who should participate in the workshop: End Users, Stakeholders (not as a replacement for the end users), Development Team, Product Owner. If there are more than 7 people, consider splitting them into groups. Each group needs a mix of all the roles. If you split into groups, the PO won’t participate in any single group and will instead move from group to group, listening and occasionally asking clarifying questions.

Why include Development Team? When they’re not included, then we spend 2–4 sprints getting them to redo completely misunderstood work in the product. Although it might be expensive to involve the team in creating the vision (1/2 day of work x the number of team members), the cost of building the wrong product is much greater.

Length: Most of these activities can be done in 2–4 hours, with group size having the largest effect.

Mechanics:

All of these tools are trying to foster divergence to generate good ideas, then cross-pollinate and, finally, convergence select the winner(s).

Explain the tool they are using
PO outlines the core thinking for the product and shares information from customer interviews, often in the form of an Empathy Map
PO shares a couple of examples of a completed product vision from the tool in question
Groups split up to work on their tool (e.g. building a Product Box or writing a Pixar Pitch)
Groups present what they built and the PO provides feedback
Groups return to building their product using feedback from the PO and inspiration from other teams to update their Vision
…sometimes a third round of building is necessary
The PO then selects which vision is closest to their understanding of the customer needs.

I like approaches like this because it gets doers and end users to start talking, all team members feel they had a say in the vision, and it’s motivating. The PO maintains a sense of overall control but provides enough autonomy that the team feel like they have a sense of ownership.

Attributes of a Good Vision

Emergent, not a compiled list of features
Focused on the customer problem, not the solution (LeanStartup, “Love the Problem, not the Solution” (Ash Maurya, Running Lean)
Vision provides focus
Inspiring, shared, ethical (will create a product that helps people and doesn’t cause harm), concise, ambitious
Looks far enough into the future that it won’t be completed soon Typically 4–5 years out, although others suggest as far as 10 years out.
Meaningful target group - Saying “Windows Users” or “Android Smart Phone Users” is meaningless. For example, for a budgeting app, consider something like “Female between the ages of 30–45, uses an Android phone, with income between $50K - $150K/yr”

Future Perspective for Change: Why Backcasting Helps Get You Where You Want to Be - this tool can be used for setting a vision for organizational change, in addition to creating a vision for a product.

8 Tips for Creating a Compelling Product Vision
Agile Product Planning: Vision, Strategy, and Tactics
All-hands Team Memo March 2024
Celebration-5W - Agendashift Discovery exercise
Common Product Vision Board Mistakes
Design The Box
How to Build a Product Vision Box and Clarify Your Software Goals
How to Create a Future Focused Vision in 5 Steps
How to get your project started on the right foot
My Innovation Games Project Box experience
Product Canvas – beyond the Product Backlog
Product Vision Canvas
Product Vision FAQ
Product Vision FAQs - Roman Pichler
The Product Vision Board
Remember the Future - from Design Thinking Toolkit and (originally from the book Innovation Games) - good for creating vision for teams that are involved in doing organizational change work as well
Remembering theFuture
Remote creation of an Agile vision
Strategy and the Importance of Vision </HighlightBox>

Wizard of Oz MVP

Thu, 23 Jan 2025 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro';

In Wizard of Oz MVP, we present what appears to the end user as a fully functional product, but behind the scenes, it's just people doing the work. The most famous example of this is Zappos (then called the Shoesite). Like any good Lean startup, they needed to test their riskiest assumptions: Would anyone buy shoes online? You can't test the fit, feel, or quality of shoes online. Rather than spend millions and millions of dollars to build a fulfillment center, Zappos put up a website that sold shoes. Instead of maintaining an inventory warehouse or building a fulfillment system, the founder, Tony Hsieh, fulfilled orders manually by shopping at local stores.

Airbnb is another example: the founders visited the homes of early hosts, took professional photos, and uploaded and listed them on their website. When a guest booked a stay, the founders handled the details in the background.

In both of these examples, the founders are testing the riskiest assumptions: Is it safe to buy or rent over the internet?

Wizard of Oz Key Elements

Process: Build a realistic front end of the product, but leave out the back end. Iterate quickly, as we see how people use the product. Key: to the end user, it appears realistic.
When to use it: You can use Wizard of Oz with any type of audience. If you can get people to use your application, you learn from them. It is best suited to problems that can tolerate a delay for the manual process on the back end.
Measurement: Anything you would normally measure in a live product. At its core, does the user buy, rent, or take the key action?

Wizard of Oz is a genuinely useful place to use GenAI. You're building a lightweight front end whose only job is to learn. You don't worry about technical debt; this is an experiment.

Pros and Cons of the Wizard of Oz

Pros: Cheap, cheerful

Cons: Maintaining consistency is hard when doing repetitive tasks manually. It's not scalable; if you're overwhelmed with demand early on, you might need to shut the door temporarily and build the real application. Please remember you built throw-away code. Don't build on top of it.

Wizard of Oz is one type of Minimum Viable Product, and it is one of my favourite MVP techniques.

Wizard of Oz MVP Technique
The Wizard of Oz MVP in Lean Startup Experiments
Wizard of Oz Prototyping: what is it and why should I do it?
Mapping the Landscape of Gen-AI Product User Experience - Apple using Wizard of Oz to understand how users want to interact with AI agents to do tasks </HighlightBox>

Work Week

Wed, 28 Jul 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

Our modern work week of five days on and two days off is nothing more than an accident of history. Many organizations, and now even countries, are experimenting with what is most effective.

Scrum By Example – Overtime on a Scrum Team is an Unhealthy Sign </LinkList>

Work in Progress

Wed, 15 Dec 2021 00:00:00 GMT

import Figure from '@/components/global/figure.astro'; import WSOBSLimitWorkInProgress from '@/content/glossary/work-in-progress/images/WSOBS-limit-work-in-progress.png';

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

In Scrum, Work in Progress is the batch of User Stories or Product Backlog Items that have been started but not finished. These are also referred to as partially finished items.

Work that hasn’t been deployed, shipped, or otherwise delivered to a customer has no real value. Value is only realized when the work is available for use by the customer. The naive assumption is that the more work in progress there is, the more work will get to ‘Done’. Yet evidence is to the contrary. More work in progress results in less work done. (See The Impact of Agile Quantified for more).

The use of a Kanban board is a simple way to help limit Work in Progress (WIP) by having a column that visually displays the work that exists in that state, and setting a maximum limit of the quantity. The idea is that we shouldn’t start new work before the existing work gets to the Definition of Done.

Many teams discover WIP Limits when there is large batch of work stuck waiting for someone else to complete it. In software development teams, this queue typically forms in front of Quality Assurance or Documentation.

A large Work In Progress queue highlights a bottleneck where the throughput of the team is constrained by the speed at which that station can complete work. Once a column hits a WIP limit and fills up, then we’re forced to help get the most downstream work to truly ‘Done’. Over time, teams often reduce their WIP limit to improve flow, and each reduction challenges the team to cross-skill and collaborate more.

Measurements

To understand the effect of changing our WIP limit, we need to measure a few simple things. Start off just by observing bottlenecks. Each day, count the number of Product Backlog Items/User Stories in progress that are stuck waiting for someone to pick them up. That gives a sense of how big our bottlenecks are and where they’re located. Measure Throughput and Cycle Time. Throughput is just the number of PBIs/Stories the team complete in a Sprint. Cycle Time is how long it takes for an item to go from being started to being delivered to the customer.

Effects of Reducing WIP

As with any improvement, for a short while the measures will get worse until the team adapts. As we reduce the WIP limit, first we would expect the size of the bottlenecks to be reduced. Then as the bottlenecks get smaller, the throughput will increase, and the cycle time will be reduced. You will know that you’re succeeding with limiting WIP when your throughput increases, your cycle time decreases, and you can see an increase in collaboration among team members. Remember that these effects will take a few months to build up a measurable effect.

What is a Good WIP Limit for My Team?

A long-winded answer would say something about your team size, skill, strengths and then say it’s too complicated to give you a real answer. The practical approach? Observe the largest number of items your team had in progress in the past few Sprints, then reduce that number by one. This is your initial WIP limit. Display it on your Sprint Backlog. For the next few Sprints, observe how the team adapt to the reduced WIP limit. Possibly coach them to encourage collaboration, pair programming and cross-skilling. Once they’ve adapted, reduce the Work in Progress limit again by one. Eventually your team will hit their own practical limit. Most Scrum teams discover that they can limit the WIP to 2-3 items for the entire team (hint: this requires improving collaboration and learning pair-programming, perhaps also BDD). Some teams go even further to discover Ensemble Programming and set their WIP limit to one. A key point is that the WIP Limit should be set for the whole team, and not just per person. For teams that are used to having three items in progress per team member, this can require a large mindset change with a change in focus from individual work to collaboration and teamwork.

WIP Limit: Per Task or Per User Story?

Which is better? Many Scrum Teams create tasks for each User Story and then focus their efforts on delivering those tasks. My recommendation to those teams is to ensure all tasks are one day or less in size. The problem with a task focus is that it increases the emphasis on individual work and limits the focus on the real value of the User Story. A better approach is to define the tasks, not for tracking purposes, but to ensure that everyone has a clear understanding of what needs to be completed. The Sprint Backlog should focus on User Stories and ensuring that each Story solves a customer problem, meets the Acceptance Criteria, and the Definition of Done.

What to Do When a WIP Limit is Too High or Too Low

Too high? If you use the above suggested approach of reducing the limit by one at a time, this shouldn’t occur as it will naturally get lowered over a few months until it settles where the team is currently able. Since the team finds its own limit, that will avoid the problem.

Too low? The theoretical risk is that if the limit is too low, the team will ignore it. Yes, this is a risk. Again, we avoid it by discovering what the team is capable of over time. Instead of imposing a theoretical limit, we discover what the team is capable of today and adjust to suit.

What is the absolute lower bound? Is a WIP limit of one story in progress at one time for the entire team actually possible? Or practical? Yes. Scrum Teams that use Ensemble Programming typically only have one item in progress for the entire team.

When and where do you adjust? WIP Limits are an excellent topic for discussion in the Team’s retrospective.

Does the WIP Limit Change?

As a Scrum team cross-skills and improves collaboration, they should be able to reduce WIP limits. I’ve been asked things like “The limit has been stable for over a month; should we stay here forever?” Probably not. As the team becomes better able to handle the current WIP limit, it could be reduced again to see if that provokes further improvement.

I’ve also been asked “Does the Work in Progress Limit ever go up?”

If there is a fundamental change in the team - like a new team member, a big change in the type of work, etc. – then, for a time, the WIP limit might increase. However, once the situation has stabilized, we would expect the steady march back down to continue.

How and Why do Work in Progress Limits Work?

As the number of in-progress items are reduced, team members are challenged to move outside of the narrow confines of a particular type of work. For example, on a team where there are a number of items building up in front of Quality Assurance (QA), the WIP limit will show a developer that they shouldn’t just start coding the next story. Instead, when their team is at the limit for the number of items that can be worked on right now, the developer might talk to someone in QA to see how they can help. The help might involve:

Pairing with a tester
Automating a small task
Doing a first test on a piece of code they didn’t write

As this happens again and again over the course of a few weeks, our developer is also starting to cross-skill, learning a little about how to do QA and what QA needs to make the product easier to test.

So, the WIP limit itself isn’t magical. Instead, it helps team members get unstuck from the status quo, challenges them to learn, and improves collaboration.

Scrum by Example – The Story of an Incomplete Sprint </LinkList>

How to Set WIP Limits on Your Columns When You’re Just Getting Started
Limiting Work in Progress (WIP) in Kanban
Scrum With Kanban WIP Limits
Why you should limit work in progress and stop multitasking
WIP Limit Definition
WiP Limit Simulator * This deserves a special mention * </HighlightBox>

Working Agreements

Mon, 08 Mar 2021 00:00:00 GMT

import LinkList from '@/components/global/link-list.astro'; import HighlightBox from '@/components/global/highlight-box.astro';

A Working Agreement is a short set of guidelines created by the Team, for the Team, that establishes what the expectations of the Team are for one another. A well-written Agreement should help establish, as well as reinforce, a clear, shared understanding between all Team members about what they acknowledge is good behaviour and communication. It is usually referred to as a single “Working Agreement”, but in reality it’s comprised of many individual agreements for each topic or issue.

Scrum by Example – Team Friction Inspires Working Agreements </LinkList>

Remote Team Working Agreements:

Create a Remote Team Working Agreement (PDF)
The critical role of team agreements in remote and hybrid workplaces
How to Create a Team Agreement for Your Remote Team
Remote Team Agreements and Protocols (requires creating a free account) </HighlightBox>

Zero Bugs

Thu, 06 May 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

Zoom Fatigue

Tue, 20 Apr 2021 00:00:00 GMT

import HighlightBox from '@/components/global/highlight-box.astro'; import LinkList from '@/components/global/link-list.astro';

During the COVID-19 pandemic, we learned the hard way that being on Zoom, or any other video conferencing system, wears us down.

Zoom fatigue is physical and mental exhaustion experienced after spending a long time on video conference calls. This isn't a medical diagnosis (which is good because I'm not a doctor), it is a well documented problem. Zoom Fatigue can lead to: Eye Strain, Headaches, Irritability, Anxiety, ... the list goes on. (I'm getting tired just writing it.)

Reduce the Harm from Zoom Fatigue

A few things we've learned can reduce the harm:

Breaks between meetings help your brain reset - 5-10 mins
Breaks need to be away from the computer - step outside; meditate; stretch - no screens
Make meetings more intentional, effective, and shorter
Our brains are not designed to see ourselves all day. Turn off the self view in your video tool.

Scrum by Example – Team Friction Inspires Working Agreements
The Modern Guide to the Daily Scrum Meeting
Good Agendas Make Great Meetings </LinkList> <HighlightBox heading="Resource Links" variant="resourceLinks">