Agile Pain Relief | Blog

$50 Million Phoenix Fix – Avoiding Disaster With Scrum

Tue, 27 Sep 2016 00:00:00 GMT

Duct Tape - original image by Photodune

As most Canadians can tell you, the rollout of the Canadian Government’s Phoenix payroll modernization system has gone disastrously badly. At one stage, there were over 80,000 civil servants who had payment problems, with some even losing their houses over the mess. I’ve seen everything from the contractor (IBM) to a lack of training being blamed for the problems. I suspect there is more than enough blame to go around, and it will take years to discover what really happened.

Early and Incremental Delivery

They say hindsight is 20/20, but it’s also a useful tool to avoid history repeating itself. So how could we have done this using Scrum, and minimized, or even eliminated, the pain? Most organizations can’t afford to pay $50,000,000 to fix an “oops”.

A basic tenet of Scrum is that it requires the team to develop truly shippable software every sprint. Or, to use an analogy that doesn’t involve Scrum knowledge, eat an elephant. How do you eat an elephant? One bite at a time, of course.

If we used Scrum as our tool, instead of putting all our weight on a big bang, two-stage rollout, we could rollout to smaller departments at first. If we can’t get things up and running smoothly with fewer than 200 people, then we’re not ready for much bigger. In departments with more complicated needs, do smaller rollouts until the specific needs are well understood.

Strangely, if it had been done this way, most of us would never have heard about Phoenix.

Let’s hope the Canadian Federal Government learns about doing Scrum before it commissions its next large project.

What has your experience been with Early and Incremental Delivery?

Reference: https://www.cbc.ca/news/canada/ottawa/phoenix-pay-update-deadline-1.3751126

Image attribution: Photodune

A Rebuttal of Groupthink

Fri, 20 Jan 2012 00:00:00 GMT

In a New York Times article: “The Rise of the New Groupthink” this week Susan Cain claims that teams and collaborative work give rise to groupthink. Groupthink is not out of the question, as Christopher Chabris and Daniel Simons demonstrate in “The Invisible Gorilla” group think is a risk – cite the example of the Georgian War in 2008:

When Mikheil Saakashvili was elected president of Georgia in 2004. he was only thirty —six years old. He stocked the government with loyal ministers who were also in their thirties and lacked military experience but sympathized with their leader’s views about the importance of reclaiming the breakaway regions from Russian influence. Over the next four years they managed to convince themselves that it was a good idea to fight an army that outnumbered theirs by twenty five to one. It’s not hard to imagine how a group of like—minded government officials could take a set of opinions that none of them held with great confidence individually and aggregate them, by deliberating among themselves and reinforcing one another’s public statements, into a high-confidence conclusion.

While it is difficult to diagnose from a distance Saakashvili would have been wise to seek diversity of thought in his cabinet as we recommend on teams. Where that diversity is lacking its important to seek fresh ideas from outside sources to challenge our own thinking.

However Cain overplays some of the research that she uses to make her points. In particular she cites DeMarco and Lister’s Coding War study where the authors demonstrated that developers who had privacy were more productive. What is missing is the circumstances around it. DeMarco and Lister weren’t studying teams and so the results don’t speak to teams. Perhaps more relevant in this case are the studies found in “Making Software What Really Works, and Why We Believe It” – Andy Oram and Greg Wilson – which is equivocal saying that depending on the type of work some teams benefit from team rooms and others don’t.

Roger Brown and I have done on an InfoQ interview the subject: Creativity and Brain Science with Mark Levison and Roger Brown.

Finally Keith Sawyer (author of Group Genius) provides an excellent rebuttal: Does Solitude Enhance Creativity? A Critique of Susan Cain’s Attack on Collaboration which provides details in some of the other errors Cain made.

Photo via: https://photodune.net/

Agile Bonuses - The Damage They Do

Wed, 07 Dec 2022 00:00:00 GMT

A design pattern is a description of a solution to a recurring problem. It outlines the elements that are necessary to solve the challenge without prompting the reader to address the issue in a specific way. Unfortunately, we also regularly see recurring patterns of ineffective behaviour. These are called Anti-Patterns. The following explores the common anti-pattern of a performance bonus. Micromanagement.

A few months ago a friend asked me about setting up a bonus scheme at his work. From working with Scrum and Kanban teams, I know that bonuses are counter-productive anywhere team members are doing knowledge work and their work is interdependent. The same might apply in other areas too, but I know this to be true in the context of software development in particular, because of my experience and study.

What kind of bonuses are we talking about here? Not Christmas bonuses, profit sharing, employee stock ownership plans or stock options (although, if not used carefully, even those have risks). We will focus on only performance bonuses for this article, which is what my friend was discussing.

“A performance-based bonus is an extra compensation granted to an employee as a reward for reaching pre-established goals and benchmarks.”¹

In software development, individual performance bonuses are often geared to something like personal velocity if you’re a developer, or number of defects found if you’re a tester. For team bonus, maybe the target would be set as “greater than 75% of committed stories are completed in most Sprints”. We’ll use the developer example in our illustrations, but others would have similar effects.

After a short conversation with my friend, we managed to identify a number of ways that bonuses would be a bad idea and I offered to assemble research for him as ammunition to convince his boss. And what I found in the research was curious. It showed that researchers have a very narrow focus when studying bonuses. With a couple of exceptions, they assumed that the people designing the incentive had chosen a good target.

Of course, from our experience in the agile world, we know that most targets are either outright dangerous (e.g. velocity as a measure of throughput) or far enough from the truth that focusing on them may cause harm (e.g. defects as a proxy for quality). Researchers don’t tend to look very far forward when they assume that bonuses will have a positive effect and they end up measuring the wrong things. If they instead ignore any assumed target, and follow cause and effect to the unbiased end results, they would see that.

Other challenges with common research:

Many of the tasks being measured are too simple. For example, in online game play, the task is designed to measure collaboration and competition. Unfortunately, the limited complexity of game play doesn’t simulate product development work well.
Many studies are run over a short period of time - hours or days - so would not show the long-term effects of most bonus schemes.
Since the research is typically based on short time periods, it rarely examines the effects of bonuses on morale or intrinsic motivation. Adding more effective motivation tools to this article might double its length.

To see what goes wrong with bonuses, we’re going to draw on a few tools.

Goodhart’s Law - “When a measure becomes a target, it ceases to be a good measure”
Motivational Models - specifically ARC
Systems Thinking - many of the problems created by bonuses come from a lack of consideration to knock effects. I.E. If we do X, what other effects will that have downstream? What effects will it have in a few months?

And to visually illustrate cause and effect, we’ll use Causal Loop diagrams to show positive and negative links. Remember, “positive” and “negative” shouldn’t be read as good or bad, but simply as increasing or decreasing.

Individual Bonuses

Here’s a hint right out of the gate if you’re new to Agile: you never want to measure anything for one person.

Individual Bonus (-ve)-> Autonomy - Chasing a bonus lessens the opportunities we have to make decisions to better the team because meeting the bonus requirements becomes the higher priority. This reduces (i.e. negative link) a team member’s Autonomy (see ARC and SCARF models).

Autonomy (delayed ->) Engagement - When we have Autonomy —control over our own choices— we have a greater sense of Engagement. But the bonus has reduced Autonomy, causing an opposite effect. It turns out, Autonomy is a core driver for Engagement at work.

Individual Bonus -> Competition - An individual bonus also increases (i.e. positive link) Competition between team members. It automatically means you should put your own needs ahead of the team’s needs, to maximize your bonus payout. Since others are doing the same thing, your cooperative Scrum team starts to have competition between members.

Competition is a fun one because it sparks a lot of effects of its own…

Competition (-ve)-> Peer to Peer Help - You will still help others, but only after your own work is done and mostly on a quid-pro-quo basis. This isn’t healthy collaboration and reduces the amount of Peer to Peer Help that happens.

Competition (Delayed -ve)-> Quality - As Competition increases and communication declines, more errors creep in. There is reduced cooperation between individual developers and, much worse, reduced cooperation between developers and testers. Have you ever been in a bug triage meeting where one party claims they’ve found a bug and another person claims it works as designed? This happens enough even without incentives getting in the way, and bonuses just make this much worse. Reduced Quality is a delayed effect; it will take a lot longer to show up.

Competition (Delayed -ve)-> Relatedness - We have a need to care about, and feel cared for by, others. As the feeling of Competition increases even a little bit, that harms our ability to Relate to others.

Relatedness -> Peer to Peer Help - As we get to know our teammates better and learn to care about them, our willingness to provide support increases. Unfortunately, Competition harms Relatedness and, therefore, further undermines the Peer to Peer collaboration required for Agile to be effective.

Relatedness (Delayed)-> Engagement - When we feel we’re part of something bigger than ourselves, our Engagement goes up and then we become more productive. The competitive environment which harms Relatedness, also creates dis-engagement.²

Autonomy -> Peer to Peer Help - When we have freedom to make choices, it is easier to collaborate because you don’t feel as much pressure inside yourself to get your own work done first. Instead, you can help a peer and expect the help will be repaid.

Individual Bonus (-ve)-> Experimentation - Experimentation allows a team to learn and improve through learning what succeeds and what fails. As people focus on meeting their bonus, and avoiding failure, Experiments are reduced and so is team learning and improvement.

Individual Bonus -> # of Features – Yay, a net good; we got more Features! But at what cost? ;-)

# of Features (-ve) -> Done - As the number of Features being worked on at any one time increases, there will be pressure to call them ‘Done’ sooner, even though they’re likely not done. The best part is, with a good bonus, this pressure doesn’t need to come from outside - the individual can create it for themselves.

# of Features (-ve) -> Quality – The more Features being worked on at the same time, puts increased pressure on the people doing the testing. This will have two effects: items will wait in a queue longer making their defects harder to fix, and more defects will slip through unnoticed. Reduced Quality will be the result.

# of Features (-ve) -> Peer to Peer Help - As the number of Features being worked on at any one time increases, there are fewer people who have capacity to help their peers.

Peer to Peer Help -> Throughput at the Bottleneck - We know from the Theory of Constraints that all systems have bottlenecks that limit its throughput. Bottlenecks are inevitable in a normal Agile environment, but when a bottleneck happens, we would expect another team member to help out until it is no longer the constraint for Throughput. If a bonus makes Peer to Peer Help less likely, Throughput at the Bottleneck will not improve.

Throughput at the Bottleneck -> Number of Features - If we improve the bottleneck, the number of features delivered will increase. Unfortunately, the use of bonuses means that there’s no incentive to help clear the constraint, so the bottleneck is likely to persist.

Peer to Peer Help -> Quality - Collaboration increases Quality through Pair Programming, Code Reviews, and even just having someone to bounce ideas off of. All this requires team members who feel that they have enough slack in their own work that they can help you. Bonuses ratchet up the pressure to meet a target and therefore reduce the amount of time anyone feels they have to provide help to others.

Done -> Quality - Scrum includes a Definition of Done as a quality leveler. Scrum challenges the team to ensure that level of quality is met whenever a Product Backlog Item is complete. As a team grows in skill, it normally strengthens its ‘Done’ criteria, therefore improving Quality. Unfortunately, in the land of bonuses and focusing on the # of Features, team members will feel pressure to skip parts of Done, as they feel it slows them down. Hint: over the long haul you never speed up by reducing quality standards.

Quality (Delayed) -> # of Features - When a team makes the effort to do quality work, through the Agile Engineering Practices, they increase the code quality. It is easier and faster to add new features in a code base where team members tidy up small messes and automate many of their acceptance tests. Unfortunately, in an environment where # of Features is consider a measure of success, corners get cut and quality degrades slowly.

Bonuses anti pattern CLD

Reviewing these results, we can see that bonuses might result in an increased number of features, but to stop analysis there is short-sighted and foolish. An increase in features doesn’t automatically lead to greater customer happiness. We should be focusing on Outcomes (features with good quality, that solved the customer problem) over Output (# of Features delivered). We may have got more of the target, but if the target was poorly chosen in the first place, the focus on it didn’t give us more of what we wanted.

Individual Bonuses can work in situations where we want competition. On a sports team, for example, a bonus for home runs might be helpful. Even here we have to be careful, because home runs alone don’t win baseball games. Bonuses may also help if there is a certain class of work that no one wants to do, for example update and maintain the build system. Again, this isn’t without consequences because, having provided a bonus for a mildly unpleasant task, all of sudden people will want bonuses for any task that is out of the ordinary.

In the context of Scrum and Agile teams we know competition is actively harmful and we want people to volunteer for the unpleasant tasks, so staying away from bonuses continues to be a good idea.

Team Bonuses

When we move bonuses to the Team level from the individual level, we reduce the competition within the team (Yay?), but now create competition between teams. The causal loop diagram won’t change very much. The effect of competition on things like cross-skilling will be reduced, but new elements will appear that affect cross-team dependencies and improvements.³

Thank You or Spot Bonuses

These are impromptu bonuses awarded to thank a team member for a particular success, such as delighting a challenging client or solving a really deep problem. These at least avoid the damage of encouraging changed behaviour to achieve the bonus, and they can have a positive impact on the team. But they still come with their own challenges.

How to decide the recipient(s)? There is a risk that the award will acknowledge an obvious team member but overlook the contribution of someone else who provided invaluable ideas and advice but not hands-on work.
Don’t reward overtime - this always backfires. Not everyone is able to do overtime (e.g. single parent or a team member going to school part time) so it creates unfair advantage. Overtime also leads to a variety of negative effects in the long run, both for the individual and the organization, so rewarding it sustains the harm.⁴

Fairness

Our causal loop diagram was already way too crowded, but fairness is another challenge. For many people, fairness is an important factor in motivation. (In the language of the SCARF Model⁵ this is a threat and reward). If members of the team feel that a bonus is unfairly awarded to one person for doing something (perhaps maintaining the build system) and the contributions of others are missed, they will feel unfairly treated. This will become a demotivator. I can’t readily imagine a case where the use of bonuses was a fairness motivator.

Conclusion

Bonuses are a bit like telling someone, “We value you enough to pay you X, however we will only pay you the last 10% of X if you jump through the following hoops.” Or, to use a different analogy, like large quantities of sugar where they taste great when we eat it, but the long-term effects are harmful. Bonuses attempt to improve performance by supplementing a person’s internal motivation with the allure of a sweet reward.

Instead of fighting against people’s internal motivation, find a way to align a team member’s own motivations with the needs of the team. When our team is working in an Agile way, this happens organically as part of the way we structure work.

The worst thing about bonuses is they seem so compelling in the short term but, when we add up all the delayed effects, it becomes clear just how insanely expensive bonuses are. So don’t waste money on a bonus scheme. They don’t improve performance. They destroy intrinsic motivation. Pay your people well and then give them the tools to find their own sense of motivation, and the performance results will follow.

Not yet convinced? You will be after you read this research that wasn’t conducted with an assumed target.

Research That Doesn’t Suck

Why Motivating People Doesn’t Work and What Does – Susan Fowler Intrinsic motivation—motivation that comes from inside us— is more sustainable than extrinsic or external motivation. The famous carrot or stick.

Self-Determination Theory in Work Organizations: The State of a Science – Deci, Olafsen, Ryan When our work environment has bonuses, the bonuses reduce the effect of the intrinsic motivation.

The first important finding in the meta-analysis by Cerasoli et al. (2014) showed that intrinsic motivation had a moderate to strong relation to performance across all studies and all types of performance, whether or not incentives were also being used. Accordingly, this indicates that intrinsic motivation is extremely important for the workplace. Furthermore, in line with the undermining effect of rewards on intrinsic motivation, Cerasoli et al. found that intrinsic motivation had a weaker effect on performance when incentives were directly salient, and a stronger relation to performance when the incentives were not directly salient.

The same paper shows that rewards help when the work is simple, but when the work is more complex (e.g. knowledge work) they don’t help at all and just interfere with intrinsic motivation.

In more nuanced analyses, Cerasoli et al. (2014) found that intrinsic motivation was a stronger predictor of performance quality, whereas extrinsic incentives were a stronger predictor of performance quantity. In a similar vein, Weibel et al. (2010) in their meta-analysis found that extrinsic incentives led to better performance on simple tasks but to poorer performance on more complex tasks. In short, PFP appears to be effective for motivating performance as quantity of simple, algorithmic tasks, but not performance as quality of complex heuristic tasks. Furthermore, PFP seems to interfere with the relation of intrinsic motivation to high-quality performance.

Do incentive systems spur work motivations of inventors in high-tech firms – Lazaric and Raybaut

Performance bonuses inspire competitiveness and resource guarding instead of teamwork and collaboration. The exact opposite of how we know Scrum — and productivity — thrives.

In a study of what happened to patent applications at Thales, a change in the bonus system: ”… harms relatedness and autonomy, reduces the creative output and knowledge diversity in an organization. In addition, changes to an existing bonus system may harm the culture it created: “new incentive system can conflict with intrinsic work motivation, notably because of the corporate imprinting. Instead of spurring work motivation, it may produce crowding out effects with a decline in motivations of some groups.”

Image attribution: Agile Pain Relief Consulting (Updated: March 2025)

Footnotes

Agile Change or Adoption Always Starts with Why

Wed, 30 Mar 2016 00:00:00 GMT

Your organization has decided to become more “Agile.” Why? As we learned in a previous blog post, “Because Our Competitors Are” is not a valid – or sensible – reason.

Before embarking on a change, adoption, or improvement program, you need to know the rationale behind that decision. So… why Agile?

Group of people - licensed from Photodune

A traditional approach to answering this question might see the executive team going off-site for two to three days and holding a workshop where they decide why they should be Agile, then design an adoption strategy, and then summarize the whole thing in a few sentences to be sent out in a memo.

Typically, large-scale change initiatives have a lot more ceremony, more meetings, and more setup than this. However, there are several key failings, including that they involve only a select few executives in the envisioning and decision-making process, and they attempt to plan for the long haul.

There are dozens of examples in our industry of failed change efforts that have cost billions of dollars and proved that this approach doesn’t work. At Nokia, Stephen Elop issued the famous ‘burning platform’ memo in 2011, and yet two years later the company was sold to Microsoft. In 2013 Avon had to write off $125 million[1] of work that built an enterprise software implementation which drove representatives away. This was change that failed to help the very people it was intended for.

These and other failures involve some combination of the following:

Why - The “Why” isn’t understood by most of the victims of change.
Strategy - The “Strategy” created by the executive group doesn’t make sense to all of the people doing the work.
Ownership - People at the edges of the system (who do most of the work) feel no ownership of the change.
Connection - The strategy doesn’t appear connected to the problems that the people at the edges of the system are experiencing.
Improvement -The strategy appears to improve the lot of the executives, but not of the doers.
Culture – The change doesn’t fit the organization culture.
Leadership – Top level is asking for change but doesn’t appear to be involved in making it happen.

To be effective, Agile organizational change needs to… well, involve the Organization! Not just the executives who have made the decree, often without fully understanding what the goals of the change are. This shouldn’t be a quick decision made at a two-day corporate retreat. It needs to be an ongoing effort to figure out the “why” collaboratively and share it effectively, being mindful of some essential ingredients.

We address those ingredients in the next blog post: Agile Change or Adoption – the Steps to Go from “Why” to “How”

[1] Avon’s Failed SAP Implementation A Perfect Example Of The Enterprise IT Revolution – Ben Kepes: https://www.forbes.com/sites/benkepes/2013/12/17/avons-failed-sap-implementation-a-perfect-example-of-enterprise-it-revolution

Image attribution: https://photodune.net/

Agile Change or Adoption: Create a Vision

Wed, 25 May 2016 00:00:00 GMT

Be Always Changing - create vision - image by Agile Pain Relief Consulting

(Continued from Agile Change or Adoption Always Starts with Why: Part 1, Part 2, Part 3)

Most organizational change effort starts with a vision. But problems arise if the vision was created by a few executives who went off-site, as that can result in a vision that doesn’t address the problems felt by the doers at the team level, and it isn’t articulated in a way that makes sense to them.

Instead of inviting just the senior executive team, we need a workshop that involves senior management, middle management, and a fair representation of the doers (e.g. developers, testers, support staff).

Then we need to define our vision collaboratively. Any of the familiar Agile approaches for creating vision (e.g. Innovation Games: Product Box or Prune the Product Tree, or Roman Pichler’s Vision Board) are effective choices. The goal is to create an initial vision with buy-in from all, and that can be easily explained/understood by even those who weren’t present.

But after you create the vision, you have to communicate clearly about it, otherwise the change you hope to generate is at risk.

Traditionally a town hall style event is used to announce a change. The CEO gives a speech, followed by several other executives, and then questions are invited from the floor. But few real questions follow, since attendees haven’t had time to digest or discuss the implications of the change. This isn’t collaborative and doesn’t even qualify as dialogue. It is purely a control and communications mechanism.

Catchball from Hoshin Kanri management (Japanese name for Toyota’s Strategic planning technique) is one collaborative approach to be considered as an alternative. Catchball is a fact-based strategic discussion process that gets Senior Management to sit down with Team Members. Senior Management show their vision, then they metaphorically “throw the ball” – i.e. pass the information back to the Team for their response. Team Members “catch the ball” and break down the vision into smaller digestible parts. They throw the figurative ball back to Senior Management, who review the approach to see if it will meet their needs. The ball is bounced back and forth until both groups are satisfied.¹

The key point here is that the vision wasn’t just explained – much like creating an effective user story, the vision was treated as an invitation to a conversation. Also like effective User Story conversations, they’re best tested by creating specific concrete examples that reveal whether all parties are describing the same thing.

Case Study

At the WorldsSmallestOnlineBookStore, Steve, our intrepid former ScrumMaster and now Agile Coach, organizes a Vision Workshop. The goal is to decide as a group what they’re trying to achieve with the significant organizational change they’ve taken on.

Steve has invited 20 people to the event and asks them to self-organize into three to four teams. Each must have at least one executive, one middle manager, and two doers. Beyond that, he lets people choose which group they want to work with.

His framing question: “In two years and one day we’re part of a better organization, how did we improve? Did we:

become more resilient?
improve quality?
create faster time to market?
have better employee retention?

Each team is challenged to create a “Product Box” that illustrates the organizational changes they would like to see. - One team creates a box that shows a customer abandoning a purchase, and then a bigger picture of many happier customers. An arrow indicates the change from unhappy to happy. - Another team shows quality changing from a rubber stamp, to being built into every brick in a structure. - The last team shows a box with images on two sides. On the first side there is a solid brick wall with moss grown all over it. Many of the bricks are old and chipped. At the bottom of the box is a tiny clean section of the wall where the bricks have been repaired. It says “Agile”. On the other side of the box the team shows a wall largely cleaned of moss and with many repaired bricks. They explain that the moss was the past practices that were holding all the teams back. Once cleaned, the teams - both product development and operational - were able to repair many of the bricks.

After an hour of work, each team shares their vision with the others and explains what each element represents. They return to their tables and update their own vision based on what they discovered from their peers.

Finally, they come back together at the end to select a box that best represents their overall vision. (This is done by consensus and occasionally a consensus can’t be reached). In our case, they decide that a combination of the first two boxes best represents their vision. The team that created the last box hasn’t done bad work, they just didn’t sell their peers on selecting it and the idea it represented. Sometimes you can have a great idea but others can’t see it and buy into it.

Next, we’ll explore how to turn Vision into Strategy.

Image attribution: Agile Pain Relief Consulting (Updated: March 2025)

Footnotes

Use the Catchball Process to Reduce Ambiguity – Tim McMahon ↩

Agile Change or Adoption: Define Small Organizational Changes

Thu, 15 Dec 2016 00:00:00 GMT

Be Always Changing - execute changes - image by Agile Pain Relief Consulting

(Continued from Agile Change or Adoption Always Starts with Why : 1 , 2 , 3 , 4 , 5 )

Seeing an organizational change map with seven to eight proposed major changes can feel daunting and discouraging. It’s even worse when we realize that list will keep growing as new organizational problems are discovered.

By taking on only one or two changes at a time, and creating and acknowledging the visible improvements that result, we avoid becoming so overwhelmed that we throw in the towel before significant change can be affected.

Our goal in the first few Sprints is primarily to create a habit of change, even more than the changes themselves. We want the idea of regular small changes to become the norm. The Organizational Improvement Team needs small wins. They need to create a sense of momentum and to prove to everyone that meaningful change is happening, so trust and support can grow.

In the previous post’s Case Study, the strategic items – “0 Net New Bugs at the End of Every Sprint” and “Find a More Effective Performance Review Process” are too big to be achieved in one or two Sprints, so they’re broken down into smaller visible steps. When breaking these down into smaller parts, it’s important to incorporate the element of Product Backlog/Organizational Queue Refinement and include some of the doers (e.g. QA, BA, Developers, etc.) who will be affected by the change. We need their input to ensure that the changes deliver value to them and are on point with what we’re trying to improve.

Scrum Development Teams often use User Stories to help them articulate the need and the value of a new piece of functionality, so let’s apply the same principles to this Organizational Improvement that we’re trying to accomplish.

Robin Dymond uses Improvement Stories at the team level so that teams have a tool to inject improvement into every Sprint. We will use the same approach at the organizational level. Like User Stories, Improvement Stories have: Why, What, Who and Acceptance Criteria.

Start with why – why would the organization benefit from a change? Time savings? Quality improvements? Repeatability? Reduction on conflict or stress? Happier team members? By stating the “why” first, we don’t presuppose the solution. Instead, we focus on the problem.

Improvement Story Templates

There are two different templates you can try for creating Improvement Stories.

“Template B - Start with Why” emphasizes the importance of why more than the standard template.

Sample Improvement Story Template - by Robin Dymond

Template A is likely more familiar to most people who are using User Stories.

Sample Improvement Story Template - by Robin Dymond

User Stories invite conversation, focus on the needs of the end user, have a clearly stated value, are small enough to be manageable, and can be implemented individually. They help us to break big challenges down into smaller, more manageable ones, and execute small changes

Will small changes solve all of the organization’s goals quickly?

No.

Will they foster positive momentum, an environment of trust, and habits that welcome improvements?

Yes.

Case Study

For the next few Sprints, the WorldsSmallestOnlineBookStore Organization Improvement Team selects two areas to improve: “0 Net New Bugs to Escape a Sprint” and “Find a more effective Performance Review Strategy”. They hand the first directly to the development teams and ask them to create a plan to implement, and the second is taken on directly by the Improvement Team itself.

“0 Net New Bugs to Escape a Sprint” – the Development Teams meet and come up with the following list of things to try:

Start testing partially-completed Stories
All testing involves collaboration between the team members who built the story and the tester
Eliminate pressure on the Development Team to push more features out faster
Try using the Specification By Example/BDD approach as a tool to foster greater understanding between QA, BA and Development.

For “Eliminate pressure on the Development Team to push more features out faster”, the Development Teams communicate with the Organization Improvement Team to make the need clear.

Meanwhile, the Org Improvement Team starts breaking down the Annual Performance Review:

Eliminate Stack Ranking
Test informal feedback process through bi-weekly one-on-ones
Look into Performance Review alternatives
Find options for Executive Coaching on Effective Leadership Mindset

Both groups agree to run these initial experiments for a period of six weeks (or three Sprints). They will recheck the results at the end of those cycles.

“Be Always Changing” image attribution: Agile Pain Relief Consulting Template images © Robin Dymond

Agile Change or Adoption: Sense Your Current Culture

Mon, 25 Apr 2016 00:00:00 GMT

Be Always Changing - sense culture - image by Agile Pain Relief Consulting

(Continued from Agile Change or Adoption Always Starts with Why: Part 1, Part 2)

Sense Your Current Culture

To understand the culture you’re attempting to change in your organization, you need to measure (or sense) the current state and then map that state to a model.

The model we will use is the Schneider Culture Model.¹ ²

Collaboration – a culture of working together
Control – a culture of predictability and staying in control
Competence – we’re the best at what we do
Cultivation – a culture of learning and growth focused on a vision

These attributes are mapped on two axes: Horizontal – People vs. Company oriented; Vertical - Reality vs. Possibility oriented.

Schneider Culture Model by Michael Sahota - used with permission

(Image by Michael Sahota, used with permission)

Each organization will have a primary and secondary culture. Agile and Scrum are primarily collaborative, with a secondary focus on cultivation.³

To sense where your organization fits in, you can either use a questionnaire (sample via Survey Monkey) or run a culture discovery workshop in conjunction with the questionnaire. My own experience, and that of Michael Sahota in “An Agile Adoption and Transformation Survival Guide”, suggests that using a workshop is more effective at creating a consensus around the results of the survey.

Case Study

For the past six months, WorldsSmallestOnlineBookStore has had trouble with customers leaving us or abandoning their shopping carts mid-purchase. We’ve figured out the technical sources of our problems, but nothing has been resolved. The executive team have been discussing them for months, and there is even some grumbling that Agile was “supposed to fix” the quality problem.

Of course, one of the bigger challenges that the teams perceive is that, while Scrum is being used at the team level, nothing is happening at the organizational level to support the changes that are needed. This doesn’t leave them with much faith overall.

In the above Case Study, a day-long workshop was held where attendees (a mix of Executives, Middle Management and Team Members) placed aspects of the current organizational structure, behaviours, practices and slogans on the Schneider model. The notes they added included:

Collaboration:

We share knowledge with other teams
The team ships, not the individual
We welcome new ideas
Our Scrum Teams are stable

Control:

We need Red, Yellow, Green Reports to retain control
Hierarchy matters – talk to your manager before going outside their span of control
Annual Performance Reviews are important
We use Stack Ranking and Rank and Yank to eliminate underperformers
Ship features now

Cultivation:

We use a skills matrix to identify strengths and weaknesses in the team. We use this information to help individuals learn.
We hold lunch and learns
We’ve created a community of practice to share new ideas. Example: https://www.infoq.com/articles/levison-TDD-adoption-strategy

Competence:

Nothing in this section as they don’t currently put emphasis on Competence.

From this picture we can see that Scrum has truly taken hold at the team level, creating a culture of collaboration and cultivation. However the organizational structure remains stuck with a focus on control. If nothing changes, the control focus of the organization could destroy the collaborative culture the teams have built. We will discuss how to create a vision for change collaboratively with people from all levels of the organization, not just the executives, in the next post.

Other Frameworks to consider: - Competing Values Framework (pdf) - Laloux Cultural Model – Red (Centralized Structure), Orange (Achievement Oriented), Green (People) and Teal (Shared Power).

Image attribution: Agile Pain Relief Consulting and Michael Sahota (Updated: March 2025)

Footnotes

From Reengineering Alternative: A Plan to Make Your Current Culture Work - (1994), William Schneider https://www.amazon.com/The-Reengineering-Alternative-William-Schneider/dp/0071359818/&tag=notesfromatoo-20 ↩
See: Michael Sahota’s excellent summary - Agile Culture https://www.methodsandtools.com/archive/agileculture.php ↩
Research from Michael Spayd https://collectiveedgecoaching.com/2010/07/agile__culture/ ↩

Agile Change or Adoption: the Steps to Go from “Why” to “How”

Mon, 11 Apr 2016 00:00:00 GMT

Be Always Changing - image by Agile Pain Relief Consulting

(Continued from Agile Change or Adoption Always Starts with Why)

If you’re going to become an Agile Organization, and you understand that it has to be a collaborative discussion and effort rather than an executive decree, here are the key ingredients to move forward with that decision effectively:

Sense Your Current Culture

Be mindful of the current state of both the business and culture before starting, so it can structure the change to fit in organically.
Create a Vision for Change

Create a vision for change collaboratively with people from all levels of the organization, not just the executives. Invite collaboration rather than proclamation. Visualize both the change (e.g. Product Box and the work involved in the change (e.g. a Kanban board)
Go from Vision to Strategy

See the Leaders changing before the Doers. Work in small steps, in the same vein as Scrum User Stories, making many small changes with each being an incremental improvement on the ones preceding it.
Define Small Organizational Changes

Experiment. Probe and adapt, using each change as an examination of the existing system and, when you get information back, update the plan.
Recheck the Strategy and the Vision

Be always changing – the pace of change continues to increase in the world, so we need to grow a culture where frequent small changes are the norm. Apply these steps as two concurrent feedback loops, rather than a linear list. One short-term (weeks), and the other mid-term (executed every 4-6 months).

In the next post in this series we’ll explore the above ingredients, and apply case studies for context and real world practical application.

Image attribution: Agile Pain Relief Consulting

Agile Change or Adoption: Turn Vision into Strategy

Wed, 22 Jun 2016 00:00:00 GMT

Be Always Changing - vision to strategy - image by Agile Pain Relief Consulting

(Continued from Agile Change or Adoption Always Starts with Why : 1 , 2 , 3 , 4 )

We’re already familiar with how Story Maps are an excellent way to help development teams visualize the work involved in building a large product. They act as stepping-stones between the initial vision and the resulting deliverable user stories. But Story Maps can serve a similar purpose in Organizational Change, too! If the Story Map (or Organizational Change Map) is created as a collaborative activity between the Executives and the people who will implement the changes, the activity becomes a form of Catchball, as discussed in the previous post . The Story Map then becomes the Strategy.

But collaboration is the key. Both Vision and Strategy should be created with input from the whole organization. Often they’re created in a Catchball / Story Map process mentioned above, but there is an alternative approach, such as an X-Matrix.

Some prefer to use the X-Matrix as a Strategy Deployment Tool – basically another way of visualizing the relationship between an objective, a strategy, and the tactics used to implement the strategy. Caveat: most of the examples you will find on the subject are around manufacturing and are heavily focused on metrics. Given the limitations of measurement in the world of software development (i.e. knowledge work), I don’t find that an X-Matrix adds much more than a good Story Map.

X Matrix cc license Karl Scotland

If you choose the Story Map method, break down a few items at a time into manageable changes. Changes at this level should be small enough that it’s clear which team(s) needs to be involved in making the change.

Case Study

At the WorldsSmallestOnlineBookStore, there are over one hundred people involved in making the quality changes that were implied by the vision! This is too large for even the most effective facilitator to handle in a single event. So Steve, the appointed ScrumMaster and Agile Coach, decides to run “Vision to Strategy” sessions in five groups. Each session includes at least one executive and a couple of other people who were participants in creating the original vision.The five groups discover the following problems:

Stack Ranking , affectionately known as Rank and Yank. Since its introduction two years ago, has turned the workplace into a competition to get a bonus and avoid being fired. Team(s) involved: Organizational Improvement Team
Full Regression Test Cycle is Too Long (four people take three weeks to run it). This means that even after a release is complete there is an extra three weeks before the software can be deployed. Team(s) involved: All Development Teams
Hard to Make Changes because the Code Base is Brittle. Team(s) involved: All Development Teams
Pressure to Deliver over Quality. Team(s) involved: Organizational Improvement Team
Lack of Belief in Management’s Commitment. Team(s) involved: Organizational Improvement Team
Every Sprint, new work results in net new bugs – i.e. “Bugs that escape the sprint”. Team(s) involved: All Development Teams
Meaningless Performance Review Goals. They happen too late to provide relevant feedback and improvement opportunities. They create goals but the goals become out of date so quickly that, if the goals are pursued, they might focus people in the wrong places. Team(s) involved: Organization Improvement Team will work with HR

They reframe them as more positive goals:

Worlds Smallest Online Bookstore Vision for Improvement - image by Agile Pain Relief Consulting with elements from Freepik

Next step: Define Small Organizational Changes

Image attributions: Agile Pain Relief, Karl Scotland, Agile Pain Relief with elements from freepik.com

Agile Games for Making Retrospectives Interesting

Tue, 28 Oct 2008 00:00:00 GMT

3D men holding hands in a circle. - image by PhotoDune

I wrote about this last week on InfoQ but I thought it worthwhile to call out the games I think are the most useful and interesting. In the news item I used a quote from Mike Sutton, that neatly sums up the value of games to my mind: “There is nothing as effective to accelerate learning as a physical immersive game. The simpler the better, better still with near to no props. As low tech as possible. You get to see the penny actually drop with some folks too - and that is a great moment”.

Games

Have a team that isn’t focusing enough on process improvement? Try Boris Gloger’s ball point game:

“The objective of the Ball Point game is to get as many balls through the team as possible within two minutes. Each ball must be touched at least once by every team member and must end with the same person with whom it began. After two minutes the team is allowed an additional minute to discuss the process and how it could be improved. The game is played a total of five times…”

Want to illustrate the value of early delivery? Try We’re having a Party!:

Once everybody is comfortable with all of the steps, start the timer and have participants build 3 cards each by completing each step to completion before moving on to the next step; this is known as batch & queue. Stop production about half way through and ask everybody what would happen if we decided to change the color of the paper. How much wasted effort would there be? How does this map to software? Let production continue and note the time when the first card is delivered to the customer and again when all cards are complete …

Need to demonstrate the value of working on problems in small batches and without specialisation? Try the Penny Queueing Exercise:

This simple simulation exercise helps people to understand the efficiency that can come from moving away from a waterfall or large batch process. The exercise can be done with 20 pennies, 5 people and a clock with a second hand.

More problems in specialisation? Try building paper airplanes with specialists:

In teams of 4 or more, have participants create as many paper airplanes as possible. When thrown from behind a table at one end of the room, airplanes must cross the room and touch the opposite wall. The facilitator, playing the role of the customer, can reject any planes that do not meet their quality standards. Track the number of planes created/approved, time to get the first plane approved, time to absorb a new team member, time to incorporate a new requirement (first yellow plane)

The Tasty CupCakes wiki has a number of other interesting games that can be used to help introduce new ideas or illuminate existing problems.

Image via: https://photodune.net/

Agile Gurus or Thought Leaders?

Thu, 12 May 2011 00:00:00 GMT

Thinking - image licensed from Photodune

In the past few months I’ve seen the following question several times: “Who’re the Agile/Scrum Guru’s or Thought Leaders?” The urge to ask the question is good but misplaced. I assume it comes from people who’re new to Agile and want to know where to get good ideas. Inevitably people reply with long lists of people.

There is just one problem, the whole concept of thought leaders is alien to Agile thinking. We promote the value of cross functional teams and always assume that even the least experienced person has a contribution to make even if it’s asking a question.

I learn from people in spite of their names. I’ve learned things from Ron, Alistair and other well known people, but I’ve also learned from lesser known people. When you start paying attention to names your narrow your thinking. Radical suggestion tell us which non-guru you’ve learned something from in the last week? (in my case Charles, Heather and Steve). Read widely and ask if the ideas fit with your understanding of Scrum and Agile. When you encounter a new idea go back to the Agile Manifesto and its accompanying Principles. Ask yourself will this new idea help you deliver high quality software and delight your customer sooner.

Frankly I focus most of my reading and thinking about outside the Agile community now. My personal energy is focused on understanding people through the lens of Psychology, Cognitive Psychology and Neuroscience.

Let’s stop gazing at our navels.

If you must have a guru look up Brian Marick (see: Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism) he will be happy to have a few followers :-)

This even more true than when it was written nearly 15 yrs ago. Many of our alleged thought leaders have turned out to have clay feet. Assume everyone your work with has something to teach you.

Image via: https://photodune.net/

Agile in a Tweet

Fri, 07 Dec 2012 00:00:00 GMT

children raising their hand in the classroom - from iStockPhoto

John Miller recently challenged some of us to summarize Agile for the K-12 crowd. I wound up writing a tweet I could share with my nine year old:

“Focus on the customer. Build amazing quality stuff. Release frequently. Always improving. Two heads are better than one.”

MJ and George both take issue with “Always Improving”. MJ prefers “continuous adaption” because improvement implies there is an agreed upon definition of up. George feels that it doesn’t imply continuous learning.

What would you write for the K-12 crowd? Have fun with it.

Image licensed via iStockPhoto.

Agile Metrics

Fri, 02 Jul 2010 00:00:00 GMT

eps10 business graph with arrow - image licensed from Photodune

I’m frequently getting requests for good Agile Metrics and I’m never quite sure how to respond. Courtesy of some time waiting at LGA, I’ve been giving this some more thought. For many organizations metrics are irrelevant, don’t bother collecting them as they will just waste your time (and money).

If you must collect metrics, here is what I would consider.

Running Tested Purchased Features – Ron Jeffries is famous the metric Running Tested Features (RTF). I suggest that you consider taking it one step further until you’ve sold the feature to the customer you don’t know if they value it or not. For most product organizations this is a bit of stretch to measure in which case stick with Ron’s advice.

Questions to ask:

What would you like to change?
If you had the information the metric provided what action would you take? Can you take that action now without the proof of the metric?
Your key measure (i.e. RTF), should measure your widest span of control – Sold Features > Deployed > Automated Acceptance Tests > …
Measure Cycle Time - i.e. how long it takes to get something done and not people.
Other measures can be used: i.e. test coverage from Unit Tests, but be careful they might measure what you think they mean.
Measures can be gamed/fooled (intentionally or otherwise): For example test coverage measures whether or not a line of code has been visited. It doesn’t measure if there its meaningfully tested. If you must use a measure like this pay attention to the trend and not the absolute number. In this case a large jump might indicate someone having written a not very useful test of the outside api of your application.
Metrics have best before dates. Eventually you will stop getting real value from them. At that stage throw them away.
Ask can I get this information by walking around, observing and asking questions.

Alright, you made it this far you deserve some options:

Martin Fowler says: CannotMeasureProductivity. Dave Nicolette presented on this at Agile 2009 (this article links to heaps of others). I wrote this for InfoQ last year: What is a Good Agile Metric?. InfoQ also has: Metrics in an Agile World.

The following tools will help you measure, but please remember they often have many bad measures (comments?) turned with the good ones. Think carefully when choosing your rulesets:

Sonar – has a bunch of interesting measures: Cyclomatic Complexity, Duplicated code, … . While there are other plugins, its of most use in the Java world.
JDepend – helps you spot good vs. bad dependencies.
PMD, FindBugs, JLint – see a comparison of all three (pdf). Some of these tools check some pointless things: method name too short or too long? missing Javadoc comments? Please configure these with the help of a grown adult. But they can also be configured to spot methods (> 30-40 lines) and classes (>300-400 lines) that are too long.
NDepend like JDepend and heaps more measures. Again please be careful configure only with an adults help :-) Caveat Emptor I’ve been given a free copy of NDepend (that I’ve never had a chance to use).

When paying attention to measures of the code, what matters is the trend and not the absolute numbers. Finally just because a tool can measure it doesn’t mean its worth measuring, conversely some of the best measures don’t have tools to measure them. In this case note that none of the above tools measure cycle time.

Updated to make clear the point that you shouldn’t measure people and the limitations of tools.

Image via: https://photodune.net/

Agile Retrospectives: How to Run Effective Sprint Retros

Tue, 14 Jul 2020 00:00:00 GMT

Agile and Scrum Retrospectives

The goal of this post is to give teams a basic, solid introduction on how to have not-sucky Sprint Retrospectives. I cover here the common misunderstandings about retrospectives and share the fundamentals of how to have an effective Sprint Retrospective. If you’re later interested in going in-depth on this topic, my Guide to Effective Agile Retrospectives also includes examples and descriptions of recommended activities to help improve this Scrum Event that Team Members and ScrumMasters often struggle with.

Retrospectives are explicitly part of Scrum – “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.” and implicitly part of the whole Agile movement – witness Agile Manifesto Principle #12: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Scrum values openness and courage. It’s all about looking honestly at past performance and making changes where needed. The Scrum pillars of transparency, inspect, and adapt are applied to pull those values, tenets, and goals together. To achieve this, continuous improvement and short feedback loops are at the core of any Agile process. Without a structured improvement process, it can be difficult for teams to improve, and without improvement, they will stagnate. For frameworks like Scrum and XP, and relatives like Lean, we use retrospectives as the core part of this process.

Common Misunderstandings

When I run Certified ScrumMaster workshops, I notice people often arrive with three common misconceptions:

A retrospective is the same as a Post-Mortem – No, they’re more like distant cousins
Retrospectives are Product-focused – No, that’s what a Sprint Review does
Retrospectives all have the same Agenda: What went well/poorly and improvements to make –Boring! Most people would rather poke out an eye than attend another boring event. Teams should craft agendas that work well for them.

It’s Not a Post-Mortem

The traditional approach with project work is to wait until the work is over before seeking systemic improvement. They often use a Post-Mortem: a meeting after a project, to help learn from what happened.

Retrospectives differ from Post-Mortems in some key ways:

Post-Mortems occur after the project is done (or even dead), when it’s too late to improve that project. Retrospectives encourage change to happen throughout to improve the final result.
Post-Mortems are long feedback loops, once per project, which might mean every 6-18 months. Retrospectives are short feedback loops, happening often enough to be relevant and valuable during the project.
Post-Mortems often generate attractive-looking reports that are placed on a shelf and ignored (also called write-only documentation). Retrospectives create no dust, only honest communication and action.
Post-Mortems sometimes turn into blame and shame events. Retrospectives offer opportunities to say “how can we” rather than “you should have.”

It’s Not a Sprint Review

Most people aren’t used to the idea of separating product improvement from process improvement, so it’s no wonder they don’t understand how a Sprint Review differs from a Retrospective.

The Sprint Review gives the Development Team, Product Owner, ScrumMaster, and any interested stakeholders/customers a chance to examine the product and make decisions about improving the product. By contrast, the Retrospective is about team and process improvement. When a team focuses too much time and energy on product discussion, it loses an opportunity for improvement.

	Sprint Review	Sprint Retrospective
Focus	The product	The process and team
Key question	”Did we build the right thing? With the quality we promised?"	"How can we work better together?”
Who attends	Scrum Team + stakeholders/customers	Scrum Team only
Outcome	Updated Product Backlog, stakeholder feedback	1–2 concrete improvement actions
When	End of Sprint, before the Retrospective	End of Sprint, after the Review

It Doesn’t Have to Be the Same Agenda Every Time

I’ve personally attended and (gulp) facilitated too many retrospectives that followed a simple format: what went well, what went poorly, and what do we want to improve. People always wanted to rush through these events. I kept wondering why. There was some engagement, but it was the same few people every time.

When we use the same limited palette of activities and fail to follow up on improvements, the energy for retrospectives dies. Even worse than habitually repeating the same structure each time, is having no structure at all – some retrospectives are nothing more than team members gathering in a room, speaking over each other and rehashing the same old problems Sprint after Sprint. Perhaps it’s not surprising that these teams stagnate. I walk through a real-world example of this problem in Same Old Song in Sprint Retrospective.

If you want your retrospectives to be engaging and reveal current problems, you must vary their style and content. Here are some formats to get you started:

Circle of Influence – the team sorts observations into three rings: things we can control, things we can influence, and things outside our control. This helps teams stop wasting energy on complaints and focus where their effort will actually make a difference.
Story Oscars – team members nominate and vote on “awards” for the Sprint: best collaboration, most frustrating story, biggest surprise, etc. Lighthearted and revealing, this format surfaces patterns the team might not notice in a more serious discussion.
4Ls (Liked, Learned, Lacked, Longed For) – a balanced format that encourages reflection on positives and growth, not just problems. Particularly useful when a team tends to focus only on what went wrong.
Timeline – the team plots key events from the Sprint on a shared timeline, then looks for patterns, clusters, and cause-and-effect relationships. Especially powerful when combined with real data from the Sprint.

For many more options, Retromat offers over 100 activities. I’ve also outlined the structure and intent of retrospectives below, and you can subscribe to receive the much more detailed Guide to Effective Agile Retrospectives, which includes recommended activities and samples of each.

With an improved understanding of retrospectives and that handy Guide for activities, there is no excuse, and I should never again hear that a team member attended the same boring retrospective, Sprint after Sprint.

What is an Effective Retrospective?

A retrospective is a structured moment for the team to stop, breathe, and reflect on the past cycle. The team meets to discuss what went well, what went less-than-great, and some things that could be better if the team has the energy to improve. In the world of Scrum, the retrospective is usually the last activity in a Sprint.

What Good Does It Do

Reminder of positive things that have happened recently in the team
Focused improvement goals for the system
Encouraged collaboration in the Sprint by collaborating in the Retrospective
Heightened sense of ownership of their work and process
Increased work satisfaction
Improved quality and, eventually, capacity/productivity
Better awareness of the needs of individuals and the team as a whole

Elements of an Effective Retrospective

Well-run retrospectives provide an opportunity for small improvements and clear agreement on actions to be taken afterward. Here are some things to focus on to help improve the effectiveness and reduce the “Ugh…” factor of your retrospective.

Don’t Blame the Player, Fix the Game

Take a systemic perspective.

We don’t need to blame people. Instead, engineer a system so simple that errors go away (Resilience Engineering).

11 Laws from the Fifth Discipline¹ (early book on systems thinking):

Today’s problems come from yesterday’s “solutions”.
The harder you push, the harder the system pushes back.
Behaviour grows better before it grows worse.
The easy way out usually leads back in.
The cure can be worse than the disease.
Faster is slower.
Cause and effect are not closely related in time and space.
Small changes can produce big results… but the areas of highest leverage are often the least obvious.
You can have your cake and eat it too² — but not all at once.
Dividing an elephant in half does not produce two small elephants.
There is no blame.

If you look around you will find that Systems Thinking is taking root in realms as diverse as patient safety and aircraft accident investigation.

Retrospective Prime Directive (Norman Kerth): “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Kerth’s Prime Directive is often misunderstood. He is not saying everyone is blameless no matter what happens in the retrospective. If we walk into a retrospective thinking about a certain team member and the big mistake they made, we won’t be looking at the circumstances surrounding the event. Instead, we will be focusing on the person. Many errors occur not because of a person’s behaviour, but because the system guided them towards the outcome. Example: mid-Sprint, a serious defect was found. A team member rushed to fix and deploy. Their work fixed the problem but created a new, larger problem.

A team focused on blame will focus on the individual’s behaviour (e.g., the team member failed to check the Definition of “Done,” they failed to run the unit tests before check-in, etc.), In this environment, the team member is likely to feel attacked than acknowledged for resolving the initial problem. They’re unlikely to learn anything from the criticism and, most importantly, miss the opportunity to dig deeper into the systemic issue.

Remind participants at the start of every retrospective that it is never about blame and shame. It’s about understanding what happened in the course of the last Sprint. The focus should be on events, not on people.

Simple Ground Rules

Clear meeting ground rules should be part of your Team Working Agreements.

Ideally, ground rules will be behavioural (e.g. “state views and ask genuine questions”) vs abstract (e.g. “be respectful”).³

These should be created, maintained and owned by the team.⁴ The ones below are possible examples:

Come with an open mind from all team members with a focus on solutions, not on problems.
The facilitator must be capable of staying out of the conversation while maintaining its flow. Occasionally, bring in someone to facilitate who is not involved with the team or its work, to see and benefit from different approaches.
Vegas rules – what’s said in the room stays in the room.
Laptops and phones away.
Use a Parking Lot for long discussions.
Don’t interrupt (some teams using a talking stick to help with this)
State views and asks genuine questions.⁵
Share all relevant information.
Use specific examples and agree on what important words mean.
Explain your reasoning and intent.
Focus on interests, not positions.
Test assumptions and inferences.
Jointly design the next steps.
Discuss undiscussable issues

Need a prompt to help create effective ground rules? Try “Think of the best or most effective meeting that you have been to recently. Tell the stories of those meetings, identify the common patterns. Those patterns are your potential ground rules.”⁶

Well-Structured

Many retrospectives use the model originally outlined in “Agile Retrospectives – Making Good Teams Great” – Esther Derby and Diana Larsen.

Sprint Retrospective Structure

Figure 1 - Creative Commons - Chris Smith https://leadingagileteams.com

That picture is evocative but it doesn’t tell you much about what happens at each phase, so let’s learn more about each one.

Set the Stage (also called Check-in and Opening) invites people to be in the room and it switches gears from the Sprint Review. Done well, it frames the purpose for the Sprint Retrospective and also reminds the team of the Retrospective Prime Directive and their agreed-upon Ground Rules. Choose an activity that helps to sense the mood or energy of the team.

For more details and suggested activities for each of these stages, subscribe to receive your free copy of The Guide to Effective Agile Retrospectives eBook.

Gather Data is when we look back to find information on what happened in the Sprint. In this phase, simply learn and list what happened and don’t immediately judge or search for things to improve.

Some of this work happens in the retrospective, but a lot of it happens before. Both the ScrumMaster and the Development Team could take data and bring it into the retrospective for this purpose. For example:

The Team calendar: helps to remember who was present and who was away
Number of Stories Completed
Sprint Burndown (hint: avoid burndowns in task hours as they cause team members to focus on completing tasks and not delivering features)
Sometimes better than the Sprint Burndown is to take a snapshot of the team’s Scrum Wall every few days. At best, a burndown shows that you had a problem. Snapshots of the team wall will show you which Product Backlog Items or User Stories got stuck and where the issue was.
Did the team have any Production Support issues to deal with? When did they happen? Were there interruptions from other sources (i.e. VP or CEO)? When? Capture this information on a Kanban wall.
Average Cycle Time and if there were any extreme outliers
Items still In Progress at Sprint End
Meetings that team members attended outside of the Scrum Events
Number of new defects introduced in the system
Number of User Stories that were thought complete but failed to meet Definition of “Done”
… Any other sources of information that could help with the team’s awareness of their circumstances – with one caveat – please, at all costs, avoid information that is focused or directed at one individual.

(For a massively long list of measures, see: Measurement for Scrum). Start small and build as your team learns to digest and understand the data found.

It’s important to gather this data before the retrospective because we don’t have accurate or complete memories of what happened in the past Sprint. In a CSM workshop, I ask a simple question, “Without looking at your tools, can you tell me what you completed a week and a day ago?” Most people can’t. Yet when we walk into a retrospective, we magically expect people to have better memories of a 2 to 4-week Sprint. Since that is unrealistic, the team and ScrumMaster need to gather the objective data that is available to them and provide it to the Team before the retrospective, either in a handout or email. Team members then can take time, either before or during the retrospective itself, to review the data gathered.

For the data gathering that happens during the retrospective itself, we need activities that get information out of the heads of team members without judgement or comment. Silent listing activities⁷ can be especially important when some team members are quieter than others (often referred to as introverts). Quieter people benefit because their voices aren’t drowned out by the louder team members — all ideas get equal space.

Generate Insights. The data from the previous round is used to inspire the insights this round. The linkage doesn’t need to be direct. The goal of gathering data first is to ensure the team is working from the widest set of ideas to improve from.

Decide What to Do. For many people, this is the only part of the retrospective that seems natural because we want to jump in and solve problems. The effort until now has been focused on having a deep understanding of the issues. Now we decide which action(s) the team thinks will be most effective for making small changes.

Once you decide what you have the energy to tackle, make your actions small and concrete: specific enough that the team will know whether they succeeded, and short enough to check back in the next retrospective.

One step many teams skip: reviewing previous retrospective actions at the start of the next retrospective. Without this review loop, improvements quietly die. Spend five minutes at the beginning of each retrospective checking which actions the team completed, which stalled, and why. This builds accountability without blame, and shows the team that their retrospective time produces real results. Better yet, add improvement actions to the Sprint Backlog so they get the same visibility as any other work.

If you want to take your actions up a level and turn them into experiments, we cover this in more depth in this free download:

Send me The Guide to Effective Agile Retrospectives

Closing is an opportunity for the team to reflect on the retrospective itself. Maybe there are things to change before running the next retrospective. It also provides an opportunity to celebrate – what did we learn about ourselves that will make us better in the future?

The structure we have described above (Set the Stage, etc.) isn’t a required format. You may use any model to organize your retrospectives, however, most sources, including blog posts, books, and online tools assume that you’re using it.

Who Attends a Team-Level Retrospective

It should involve the whole Team – personally, I like to see (or hear) the Product Owner and the ScrumMaster as well. Some people will tell you the Product Owner’s presence isn’t necessary. That’s fine, but if they’re not there, they can’t help make things better.

Remote and Hybrid Retrospectives

Most of the structure above still applies when team members are not in the same room, but a few things need extra attention.

Equal voice matters more, not less. In a co-located retrospective, a quiet person can at least scribble on a sticky note and post it on the wall. In a remote setting, the loud voices dominate even more easily. Use collaborative tools (Miro, FigJam, or even a shared document) where everyone writes simultaneously before any discussion begins. This mirrors the silent listing approach described above, and it works even better online because contributions are naturally anonymous until the author chooses to speak up.

Timebox more aggressively. Video calls drain energy faster than in-person meetings. For a two-week Sprint, consider capping the retrospective at 75 minutes rather than two hours, and build in a short break halfway through. Shorter, tighter timeboxes for each phase (Set the Stage, Gather Data, etc.) keep the energy up.

Hybrid is the hardest case. When some people are in a room and others are remote, the remote participants become second-class citizens almost by default. The simplest fix: everyone joins from their own laptop, even those in the office. If that’s not practical, assign a “remote advocate” in the room whose job is to watch the chat, call on remote voices, and make sure the camera shows the whole board.

Don’t skip the check-in. A quick round of “one word for how your Sprint went” takes two minutes and does more to build psychological safety on a video call than any icebreaker game. When people hear every voice early, they’re more likely to speak up later.

Summary

Retrospectives are to help the team celebrate all the things that are going well, to provide feedback to the team, and to create a plan to improve in the next Sprint. They should be happening at the end of every iteration or Sprint. Scrum Guide suggests a three-hour retrospective for a month-long Sprint. I find, based on my client experience, allowing one hour for every week of a Sprint is more effective. Therefore, a two-week Sprint would have a two-hour Retrospective.

For more on facilitation, see Two Key Things for Sprint Retrospective Facilitation. For a more in-depth look at retrospective items including suggested activities, subscribe to receive our extended guide.

Send me The Guide to Effective Agile Retrospectives

Related Blog Entries

Image attribution: Agile Pain Relief Consulting (Updated: March 2025) Significant Revisions: July 2020 First published May 2010

Footnotes

The Fifth Discipline: The Art & Practice of The Learning Organization by Peter Senge ↩
https://en.wikipedia.org/wiki/You_can%27t_have_your_cake_and_eat_it ↩
“8 Ground Rules for Great Meetings” by Roger Schwarz ↩
Curiously Roger Schwarz also recommends the opposite: ↩
These are originally from “8 Ground Rules for Great Meetings” by Roger Schwarz ↩
Original idea from Peter Stevens ↩
Activities where team members contribute their information silently and at the same time (e.g. writing on post-it notes and sticking them up when everyone is done). ↩

Agile Tools for Job Search - An Evolving Post

Mon, 22 Apr 2024 00:00:00 GMT

In recent months I have seen hundreds of people on LinkedIn and other places, who have been laid off. I see many people encouraged by well-intentioned, helpful outplacement services to tweak their resumes to get ingested by a ranking tool. If you’re lucky this might result in an interview and in some rare cases a job. If this worked for you and a job that brings you joy, then stop reading this entry isn’t targeted at you.

Applying for a job the traditional way has rarely worked well. It’s getting worse now for a few reasons: more competition (yes); but much worse Applicant Tracking Systems are forcing everyone to turn their resumes into clones. The problem is much like Google search, everyone’s webpage has very similar content because we’ve all learned what ranks well.

I’ve talked to more than a few people who’ve succeeded in their job search. Some things that have stood out: they had a vision; they had an iterative and incremental process and they remembered their sense of self-worth doesn’t come from a job. Many also discovered their next job through their network and not the application process.

When I’m advising an organization, I tell them that your Product or Team needs a good vision to be successful. By the same token, as an individual, you need a good vision about what you want from your next job. Without a clear vision, we have a hard time evaluating whether the next opportunity in front of us is a good opportunity for us.

Being unemployed, or having that threat looming, is an emotional time so having a clear vision of what you want will help you avoid making impulsive decisions. “I want to find a job as a ScrumMaster.” Okay, great, but do you have a clear picture of what it is about that role that you want? If not, how will you know whether you’ve found a good fit?

Getting hired into a position that is a poor fit is a bad idea, but I do appreciate that, for some people, cash may be tight enough that choice is affected. Having a clear vision, even when circumstances temporarily limit options, is still invaluable. Maybe even more so.

I’ve read a heap of books that helped me on the journey of defining my vision, and these are the best three that I recommend:

Hero on a Mission: A Path to a Meaningful Life by Donald Miller
Be Your Future Self Now: The Science of Intentional Transformation by Dr. Benjamin Hardy. This book should be about 1/3 of the length that it is, and it’s not a long book.
The 12 Week Year: Get More Done in 12 Weeks than Others Do in 12 by Brian P. Moran, Michael Lennington

Taking the time to establish a clear vision is just as important in life as it is in product development. Otherwise, you’re plugging away, without knowing if you’re putting time and effort into the things that actually matter to you.

I have a Life Vision and 3 Year Vision (akin to the 12 Week Year approach). Very generally speaking, my long-term Life Vision is to help 100,000 people create teams that are fun to work in and get great work done. Also to have the freedom to travel and contribute financially to social and charitable causes that are important to me. My mid-term 3 Year Vision is to create new products that successfully support ScrumMasters and Product Owners, as well as a dynamic and engaged online community.

I share those in very general terms with you, but my actual visions are much more detailed. They include the emotions I will feel when I reach those goals, and the steps to do so. This level of detail is important because you need to know what you want, and how you want to feel when you get it, otherwise even if you achieve it, odds are that you won’t be happy and enjoy it.

Approach it in a Scrum way, visualize your strategy (hint Story Map); determine what the next most important steps are; break the work down into small manageable chunks; and prioritize. Perhaps most important don’t be afraid to make mistakes.

Do frequent planning, refinement, review, and retrospective. Assuming you know Scrum. all those things are familiar. For example, every quarter I schedule time to take 1–2 days to review my efforts in the last quarter, and find 2–3 areas I would like to improve and then plan the next quarter. Every week on Sunday evening I review the past week’s accomplishments, recheck the quarterly plan, and then I plan the next week. (Yes, this is a Sprint Review, Sprint Retrospective and Sprint Planning all rolled into a single event, don’t do this with your actual team.)

Of course, you can’t control outcome, any more than you can control whether customers buy and use a product. But what you can control is the effort you put into it. So when I measure my success in a week, I ask myself whether I achieved what I set out to achieve. If you’re a job seeker, you might ask yourself if you made X meaningful posts on LinkedIn, or built one new relationship with someone who could help you. Only you can determine how and what to measure because only you know what you’re aiming for. Just remember: small, incremental steps.

Caveat: Clearly, I’m not an expert in job searching - I’ve only ever had three jobs and for the past 15 years I’ve run my own business. My skill is in helping people understand new ideas or old things from a new viewpoint.

I’m aware many of the people looking for work would value getting CSM or CSPO. Use the code UNEMPLOYED-2026 for our CSM or CSPO training.

Unfortunately, our registration tool doesn’t allow to me share a link with the discount baked in. (We asked and they don’t think the feature is a priority. Fair enough, I ask product owners in our workshops to give a clear no, I can’t complain when I get one).

To register and receive the special offer pricing, please: – Go to the course registration page for the preferred dates: Certified ScrumMaster training or Certified Scrum Product Owner training – Select “Regular” ticket (this is important as it won’t work/be valid otherwise) – Apply this code during checkout to receive the special discounted rate: UNEMPLOYED-2026

Caveats:

If you’ve not worked in technology before, neither certification will be enough on its own to help you get into the technology world.
Many organizations are looking for people with a blend of skills, i.e. a ScrumMaster who can also work as a team member. Being multi-skilled is a win.
If you’re employed, please pay the regular price so I can subsidize those who need help.

Other sources

Book: Never Search Alone: The Job Seeker’s Playbook and its accompanying support website – the author advises creating a Job Search Council. Very much in line with my thinking.
Accountability group for former attendees - If you’ve attended a workshop with me ever, I’m setting up a mutual accountability group inside our 3 Percent Better Community.
My approach bears some similarities to Personal Agility and Personal Agility: Unlocking Purpose, Alignment, and Transformation
Bernie Maloney has a video series on networking, resumes and interviews
Mark Kilby - Are You Job Hunting or Job Fishing
Johanna Rothman - has written a book, Manage Your Job Search, and has additional blog material
Elisabeth Hendrickson - Your Next Manager
Alberto Blanco - Career Transition Retro for Agile Coaches

Interviewing.io had a paper on recruiting and it also gave advice on the job search: “We strongly encourage anyone looking for work in this market, especially if you come from a non-traditional background, to stop spending energy on applying online, full stop. Instead, reach out to hiring managers. The numbers will be on your side there, as relatively few candidates are targeting hiring managers directly.”

Beware, there are people charging job seekers money for help. Bernie Maloney warns of hiring bandits - _gross (_the bandits, not Bernie 🙂)

If you’re a vendor and email me regarding this post, I will just mark your email as spam. (I already get 2–3 emails a day looking to promote things on our site.)

This is a moving target. As I find more things that have helped others, I will update the blog post.

Agile Voices Finally

Sat, 15 Sep 2012 00:00:00 GMT

Nearly 6 months ago I saw another Top 20 list of Agile people. I was troubled. As a result I started an anti top 100 list: from Looking for 100 Agile Voices we should hear more from.

In the past few years a number of Agile people I respect have published top 100 or even top 200 lists. While I, like many others, appreciate the attention they’ve brought, the whole idea seems very anti-agile. Agile promotes a democratic meritocracy. These lists do the opposite, they create “heroes” - people whose ideas are more important others. Instead, I think we should be widely read in the Agile community, often reaching outside our immediate realm. To that end I’m asking for your help creating a list of voices we should hear more from. My goal is find ~100, the limit is more from my time and energy than the lack of more people we could find.

I naively assumed that once this went “live” I would be flooded with names. The first few came in rapidly, and they’ve trickled in on and off ever since. Well, the list has now reached 70 people; I’ve long since had my minimum viable product, but summer and family time intervened.

As a reminder – my simple rules for inclusion are:

Nominees have to have a track record of doing something Agile for at least a year
Not be in the Top 100 of any previous list
The list isn’t sorted - no one is more important than anyone else
I’m most interested in people who write about their experiences, either good or bad
Please don’t suggest yourself

There is no order to this scrollable list.

I know that the table formatting is a bit of an issue – I will fix this when I have a chance.

Agile Voices

I know several people don’t have blogs or Twitter IDs listed, so I can’t find them; I’m hoping this post will encourage them to come out of the woodwork.

As I find new names and new blogs I will update the list periodically. Thanks to the many people who helped make this happen.

Image attribution: Agile Pain Relief

Agile and Scrum Smells

Tue, 17 Jun 2008 00:00:00 GMT

Sniffing dog- image licensed from Photodune

In 2003 Mike Cohn started this project with a paper entitled: Toward a Catalog of Scrum Smells (pdf - in the spirit of Code Smells) and last year Rowan Bunning did a presentation Sharing More than Deodorant for Scrum Smells (pdf). Rowan encouraged me to create a wiki with all of these smells. So I’ve spent some time in the past few days fleshing out this Catalog. These are a series of simple patterns that describe a problem and then offer some potential solutions.

As it stands today the Catalog contains nearly 20 smells:

Persistent Signatures
ScrumMaster Assigns Work
The Daily Scrum is For the ScrumMaster
Specialized Job Roles
Testers will not integrate with Team
Reluctance to estimate Backlog Items
Is It Really Done inspired by Henrik Kniberg
Nothing Ever Changes Around Here inspired by Henrik Kniberg
No One Wants to Attend Retrospectives, by Mark Levison
Executive Pressure inspired by Henrik Kniberg
Missing Sprint Commitment inspired by Henrik Kniberg
Technical Debt inspired by Henrik Kniberg
Not Acting Like a Team inspired by Henrik Kniberg
No Engineering Practices, by Mark Levison
Gorilla in the Room inspired by Mark Wainwright
We’re late - just add a another Team Member
Part time team members

But to improve this we need you help:

Proofreading
Most smells need a better discussion
Most smells are missing case studies
More smells

Sample Smell:

Nothing Ever Gets Better Around Here

1. Smells

Retrospective doesn’t happen
No actionable items generated from Retrospective
Actions aren’t taken
Non-team members attend the meeting
No one wants to talk
The same issues come up time after time

2. Discussion

If we’re not continuously improving we’re not really Agile. So what happened?

3. Causes

Action Items if they exist, don’t have owners.
Action Items get forgotten as soon as the Retrospective is over

4. Consequences

Team fails to improve

5. Prevention

6. Example Remedies

After discussing issues - ask team members to suggest concrete actions (see Agile Retrospectives: Making Good Teams Great for some great ideas).
Ensure that action items are small and achievable.
Ask a for one volunteer to own each action item.
Action items can’t be assigned to people not present at the meeting.
Discuss action items as part of the daily standup - at least a few times during the iteration.
Post action items in a highly visible location

7. Case Studies

Credit: this is based on material from “10 ways to screw up with Scrum and XP” by Henrik Kniberg, and personal experience.

Image via: https://photodune.net/

AI Chatbots for Agile Coaches: Why They Fail

Thu, 08 Jan 2026 00:00:00 GMT

AI used everywhere is a wave that is sweeping the internet, and now it is coming for Agile Coaches. There have been a number of Coaches using (or promising to use) AI Chatbots “trained” in their writing to act as a proxy for themselves.

As with everything in the world of GenAI, it is more complicated and more dangerous than it looks at first.

First, we need to clear up a misconception: unless you’re doing a serious amount of heavy lifting, you’re not training the model. Outside of the major labs, no one is training a model from scratch.

So, what can you do to build an AI chatbot using your materials?

Technique	Costs	What is it?
Fine Tuning	Large	A base model is trained on a dataset to better at that specific task
Reinforcement Learning from Human Feedback (RLHF)	Large	Human rates answers to thousands of questions
Retrieval Augmented Generation (RAG)	Cheap	The LLM decides when the query is run, which documents (or parts) are relevant to answering the question

Fine Tuning, RLHF and RAG

It sounds geeky. Why does this all matter?

If you spent the time and money to do a combination of Fine Tuning and RLHF, in most cases, we would get a more reliable system. However, even that system would have its content fixed when the training was complete.

So most Chatbots we see are based on RAG, and in the right context, that’s ok. The problem is that RAG is good at finding documents that closely match the query. If the writing comes close to matching the question, the AI will pull that document.

Problems with RAG Chatbots and Agile Coaching

The core problem is that the questions that people ask about Scrum, Kanban and Agile don’t map well to the writing in our libraries. As part of my work on “Effective Scrum”, I compiled a database of thousands of questions people have asked online. (My friends have called me the human LLM; unlike the tool vendors, I didn’t just send a bot out to scrape the internet. I spent days reading Reddit, Quora and StackOverflow.)

Here is a sampling of the questions I found:

Do we need to update time estimates when we estimate based on story points?
Numbering Sprints across products – should they reset or continue ad infinitum?
How to handle disagreements about story-point estimates in Scrum?
Whose responsibility is it to add stories to JIRA?
…

In a RAG system built against my own content, some of these questions are answered well, and others well the system made up an answer. That is the core of the problem right there. The person asking the chatbot a question likely doesn’t have the expertise to evaluate the answer.

Evaluating Chatbots in the Context of Agile Coaching

In Why AI Doesn’t Replace Your ScrumMaster I shared my list of criteria for evaluating the use of AI tools in general. Two of the questions are particularly relevant here:

Purpose: Do we understand the activity or task we’re attempting to improve with the AI tool? I don’t think most people deploying a chatbot have a deep understanding of how it will be used
Risk Tolerance: Can we afford the errors the tool will make? Do we know the subject area well enough to sufficiently review and identify errors in the generated work? This is the big risk. A general user asks a question of the AI Chatbot about Story Points or JIRA. They get indifferent or outright bad advice. They don’t have the expertise to know that the advice was bad, so they implement it.

Other Risks to be aware of with AI Chatbots

Not all models are good at sticking to your content. If it doesn’t find the answer in your content, many models will draw on their training data to answer the question. I can promise you that the average training data, from the internet, doesn’t have good advice for Agile teams.

AI vendors have reducee hallucinations (i.e. making stuff up) recently, but randomness and, therefore, hallucinations are inherent to the technology. More subtly, sometimes the chatbot just gets confused and forgetful. For example, I’m planning a hiking vacation in the Canary Islands, and the AI tool I’m using keeps assuming that I will park a rental car for 6 days at the ferry terminal in Los Cristianos while I’m on the island of La Gomera.

Shelves of books relevant to Agile Coaching. Maybe even the Tie Fighter is relevant

Agile teams and coaching on especially hard subjects for AI tools are especially hard because the subject area is so vast. In my office, I have two shelves of books related to Agile and according to DevonThink, another 20GB on my laptop. The more I learn about this subject, the more I realize most answers to questions should be “it depends” and “tell me more”.

Critical Thinking is key with these tools, and yet, as Microsoft demonstrated with a 2025 paper[^1], the better the tool sounds, the more likely people are to believe the output.

But I still want to build an AI Chatbot

Alaska’s court system is developing an AI chatbot to assist with all the forms involved in probate (i.e. dealing with property after someone dies). From all accounts, they’re doing the hard work to make it happen. Yet an activity estimated to take 3 months has already taken 15 months and is being scaled back[^2]. I would expect that dealing with probate is easier than dealing with the complexity of Agile teams.

Even Air Canada’s chatbot, which is just a glorified FAQ, has epic-fail moments that result in a lawsuit[^3]. It told a grieving family member that they needed to pay full fare, when in fact Air Canada has bereavement fares.

There are many effective ways to use GenAI in Agile teams, but a chatbot on a professional website to give advice is not one of them. Can you afford for your clients to subtly wrong advice? Agile is focused on people and relationships, let’s keep it that way. To understand the fundamental limitations that make chatbots unreliable, see GenAI vs Human Intelligence: A Reality Check. If you want to practice the human skills that no chatbot can replicate, our Certified ScrumMaster workshops are a good place to start.

[^1:] The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers

[^2:] Alaska’s court system built an AI chatbot. It didn’t go smoothly.

[^3:] Air Canada found liable for chatbot’s bad advice on plane tickets

Related Blog Entries

Instead of an AI Chatbot try: Systems Thinking with GenAI: Solve Deep Team Problems

AI Code Generation and the Tennis Kata

Tue, 02 Sep 2025 00:00:00 GMT

example of GenAI used to generate test cases

For an upcoming CSD workshop, I decided to expand the Tennis Refactoring Kata¹ to include scoring for sets. I thought it would be interesting to see how well GenAI could generating the code for the tests. (This was run through IntelliJ Junie which relies on Claude 3.7 Sonnet).

I gave Junie the following prompt:

We have mock data for tennis games: playerOneWin and playerTwoWin - in the file: typescript-jest/tests/MockGames.ts. Each one returns the results of single game. Use the mock data to construct a series of test using Jest to test winning a set:

A set is won by the first player to win at least six games, with a margin of at least two games. For example, a player could win a set 6-0, 6-1, 6-2, 6-3, or 6-4.

If the score reaches 5-5, a player must win the next two games to win the set 7-5.
If the score reaches 6-6, a tiebreak game is played to determine the winner of the set.

The only code should be written to the file: typescript-jest/tests/TennisSet.spect.ts

It did a credible job of generating the test cases themselves. They’re simple, clear, and they test what I expected. There’s not enough test cases, but that wasn’t surprising, it covered only the winning and tiebreak cases. It also wrote the implementation code. That isn’t what I wanted, but I’ve yet to find a way to avoid that.

Test code for games like this is very repetitive. Since the similar setup is needed for each Set, Junie created a function to handle creating all of the sample TennisSets. This where it went off the rails. Junie wrote a function buildSetSequence() to generate a set’s worth of games.

function buildSetSequence(targetP1: number, targetP2: number): TennisGame[] {
  // Builds a sequence that ends exactly at target score with player1 the winner (targetP1 > targetP2)
  // and ensures the set is not prematurely won before the last game.  const seq: TennisGame[] = [];
  if (targetP1 === 6 && targetP2 >= 0 && targetP2 <= 4) {
    // Make it b-b, then to 5-b, then last to 6-b
    for (let i = 0; i < targetP2; i++) { seq.push(P1, P2); }
    for (let i = 0; i < 5 - targetP2; i++) { seq.push(P1); }
    seq.push(P1);
    return seq;
  }
  if (targetP2 === 6 && targetP1 >= 0 && targetP1 <= 4) {
    for (let i = 0; i < targetP1; i++) { seq.push(P2, P1); }
    for (let i = 0; i < 5 - targetP1; i++) { seq.push(P2); }
    seq.push(P2);
    return seq;
  }
  if (targetP1 === 7 && targetP2 === 5) {
    for (let i = 0; i < 5; i++) { seq.push(P1, P2); } // 5-5
    seq.push(P1, P1); // 7-5
    return seq;
  }
  if (targetP2 === 7 && targetP1 === 5) {
    for (let i = 0; i < 5; i++) { seq.push(P2, P1); } // 5-5
    seq.push(P2, P2); // 7-5
    return seq;
  }
  if (targetP1 === 7 && targetP2 === 6) {
    for (let i = 0; i < 6; i++) { seq.push(P1, P2); } // 6-6
    seq.push(P1); // 7-6
    return seq;
  }
  if (targetP2 === 7 && targetP1 === 6) {
    for (let i = 0; i < 6; i++) { seq.push(P2, P1); } // 6-6
    seq.push(P2); // 7-6
    return seq;
  }
  throw new Error(`Unsupported target score ${targetP1}-${targetP2}`);
}

It’s silly the number of ways this code is strange:

Exceptional conditions in test setup code - that’s wrong.
P1 and P2 are constants in created, that copy the provided constants playerOneWin and playerTwoWin.
Special cases handling for each of the possible outcomes.
Nearly 40 lines for setup code.
…it doesn’t even handle the cases like 1-0, 0-5 etc. Instead, it just throws an error.

(An aside to prove 6-5 isn’t a final score, it couldn’t use its own set generator and hand-rolled the code for that specific case.)

I don’t claim mine is perfect but it is smaller and more readable:

function buildSetSequence(targetP1: number, targetP2: number): TennisGame[] {
  // Builds a sequence that ends exactly at target score with player1 the winner (targetP1 > targetP2)
  // and ensures the set is not prematurely won before the last game.
  const gamesPlayed: TennisGame[] = new Array<TennisGame>();
  const mostGames = Math.max(targetP1, targetP2);
  for (let gameCounter = 0; gameCounter < mostGames; gameCounter++) {
      if (gameCounter < targetP1) {
          gamesPlayed.push(playerOneWin);
      }
      if (gameCounter < targetP2) {
          gamesPlayed.push(playerTwoWin);
      }
  }
  return gamesPlayed;
}

At least I didn’t rewrite Junie’s comments. FWIW, I also tried the same prompt with qwen/qwen3-coder-30b² on my local machine and I got test cases that were more idiomatically correct, but it made fatal tennis mistakes (e.g. playerOne gets 6 games, before playerTwo has any so the game is over at 6-0 even thought the test case promises 6-2).

It was very useful to outline the basics of the test cases, and it did provide an outline of the structure the problem requires. However, it continues to show that the current crop of GenAI tools can’t generate code that I would want to rely on. For a deeper analysis of why these quality problems are structural, see GenAI Code Quality: The Fundamental Flaws and How Bluffing Makes It Worse. For the broader cost picture of relying on AI-generated code, see The Real Cost of AI-Generated Code: It’s Not All It’s Cracked Up To Be.

Image attribution: Agile Pain Relief Consulting (September 2025)

Footnotes

AI-Generated Code Quality and the Challenges we all face

Wed, 04 Feb 2026 00:00:00 GMT

Last summer, I wrote about the growing problems with AI-generated code in The Real Cost of AI-Generated Code - It’s Not All It’s Cracked Up To Be. I wrapped it up hopefully: “I’m not saying that GenAI can’t help; I think we will get there.” This week? I dug into 5 papers—academic and vendor—examining AI code quality and its impact on software development. More to come on GenAI’s effects on security, product ownership, and developer identity.

None of them budge the core conclusion here.

Bottom line: It’s going to get worse before it gets better.

Key Findings from 5 Studies

AI-assisted PRs have 1.7x more issues than human-authored PRs
Technical debt increases 30-41% after AI tool adoption
Cognitive complexity increases 39% in agent-assisted repos
Initial velocity gains disappear in the first few months
Change failure rate up 30%, incidents per PR up 23.5%

Building the wrong thing faster with AI is not a superpower

There is no way to measure the value of the code we write. All of these papers focus on the number of lines of code and pull requests. This is the only thing they can measure. However, this misses the question: “Did this code deliver the value that was expected?” We’ve all done work where 5000 lines of code were written, but the feature was hardly ever used. On another occasion, 20 lines of code made a huge difference.

Even before GenAI, in most organizations, there was too much code being written. Not enough effort goes into ensuring the feature was worth building in the first place. In addition, these papers only cover security issues in passing; this is another ticking time bomb.

Where did I misplace my instructions?

Engineering in the Age of AI 2026 Benchmark Report¹

Most of the contents are survey results from 50 engineering leaders - I’m ignoring the opinion-based survey data and focusing only on the hard numbers.

Cortex measured Pull Requests (PRs) and reported percentage differences from Q3-2024 to Q3-2025. The assumption is that AI is responsible for most of the differences: Cycle time up 9%, PRs per author up 20%, incidents per PR up 23.5%, and change failure rate up 30%.

Since they don’t share the data, all we can tell is that with GenAI assistance, people are taking longer to write more PRs — with more incidents and higher failure rates. We can’t tell anything else. How big are the PRs? Do they do what they’re supposed to? Readability? Maintainability? Security?

Given the lack of detail on the data, it’s hard to trust anything beyond the fact that an increase in GenAI usage has led to an increase in the number of PRs, incidents and failure rate.

State of AI vs. Human Code Generation Report²

By contrast, the Code Rabbit paper is clear about the data (stated up front) and its limitations. They examined 470 pull requests: 320 co-authored with AI, 150 likely human-authored. (Caveat — they have an automated review process.)

Headline takeaway: AI-co-authored PRs have 1.7x more issues than human-authored PRs. At the 90th percentile, 2x as many. Correctness 1.75x, Maintainability 1.64x, Security 1.57x, … . The only thing noticeably better: spelling.

We’re using AI to build products that don’t do what they’re supposed to do, are harder to maintain, and have more security issues.

There’s a lot of detail in the Code Rabbit paper; it is worth taking the time to get more detail in each area. Caveat: Even the Code Rabbit paper would be better if they provided a link to the data and statistical analysis.

AI IDEs or Autonomous Agents? Measuring the Impact of Coding Agents on Software Development³

This paper is focused on the impact of Agentic AI (i.e. Claude Code) on software

Coding agents differ from traditional coding assistants in that they work autonomously on larger, multi-file tasks. They break complex requests into steps, execute plans independently, and submit pull requests for review—rather than just offering real-time suggestions while you code.

This paper looks at the agent’s impact on the entire repository, not just how much work an individual contributor creates. In addition, the data comes from open-source code rather than vendor applications.

If your project was started from scratch with the use of Agents, you get a temporary speed up, up until about month 6. More commits (36%) and more lines of code (76%). Remember, more lines of code isn’t a win. If your project was started from scratch by humans, you don’t even get that speed up.

Worse, any repo where an agent does its own independent work over a few months suffers an increase in static analysis warnings (18%) and Cognitive Complexity (39%). Duplication also increased, mirroring what we saw in the GitClear paper last year. (The Real Cost of AI-Generated Code - It’s Not All It’s Cracked Up To Be) For a hands-on demonstration of these quality issues, see our AI Code Generation and the Tennis Kata experiment. For a deeper look at why these problems are structural, see GenAI Code Quality: The Fundamental Flaws and How Bluffing Makes It Worse.

Cognitive Complexity is a measure developed by SonarQube to replace Cyclomatic Complexity⁴. Its job is to measure how much effort it will take for a person to understand a piece of code. It matters because we will spend more time understanding than writing it. An increase in Cognitive Complexity means less understanding and more time spent doing code reviews. Another way of looking at it, an increase in Cognitive Complexity is an increase in the technical debt.

Complexity Debt Trap⁵

AI Agent Use and Complexity - A Reinforcing Loop

“First, the adoption of Cursor leads to significant, large, but transient velocity increases: Projects experience 3-5x increases in lines added in the first adoption month, but gains dissipate after two months. Concurrently, we observe persistent technical debt accumulation: Static analysis warnings increase by 30% and code complexity increases by 41% post-adoption accord-ing to the Borusyak et al. DiD estimator. Panel GMM models reveal that accumulated technical debt subsequently reduces future velocity, creating a self-reinforcing cycle. Notably, Cursor adoption still leads to significant increases in code complexity, even when models control for project velocity dynamics.”

How I Built a Production App with Claude Code⁶

Josh Anderson tells the story of how he built a production app with Claude Code. From Lots of features, faster -> more technical debt.

The key takeaway:

At 100,000 lines, I was no longer using AI to code. I was managing an AI that was pretending to code while I did the actual work. Every prompt was a gamble. Would Claude follow the architecture? Would it remember our authentication pattern? Would it keep the same component structure we’ve used for 100 other features? Roll the dice.

My Own Experience

In the past 6 months, I have been using Claude Code to work on a series of projects. One big one, a new app for YourFinancialLaunchpad.com, an Obsidian plugin and many small tools that run on my Mac. For most of it, I’ve been working in Typescript. UI components in Svelte or Astro (for the APR website).

My experience mirrors the findings of the papers and Josh. I have been able to write more code in less time. I also see the maintainability problems. Sometimes the ClaudeCode built me a full OAuth2 flow with refresh tokens when I just needed to hook into an existing system. I often see code that just shouldn’t exist: On one occasion, I was offered a regex solution for parsing and finding a daily journal entry. The problem is that the regex was fragile and unique to my journaling. There are standard approaches, and the AI didn’t look for or ask about the possibility. We shouldn’t even be looking for a filename; instead, ask the system for the journal entries themselves.

For the throwaway projects on my Mac, this is fine. For the real application I’m writing, a lot of effort is needed to ensure I have the correct acceptance criteria before I let the AI write the code.

What to Take Away from All This?

Think of these tools like a megaphone. They don’t change what you’re saying—they just make it louder.

Key Takeaways

Run experiments first - Build prototypes and validate assumptions with live end users. Look into Lean Startup and Lean UX for experimentation techniques.
Keep features small - If you get 1000 lines of code in one go, it wasn’t a small feature, and you can’t possibly review or test it well. Don’t tell me you got another Agent to review the code, that’s a help and it won’t protect you from a critical issue.
Clarify User Stories and Acceptance Criteria - Look at Example Mapping - Your Secret Weapon for Effective Acceptance Criteria. Acceptance criteria should be the result of human collaboration. Humans create, GenAI acts as a critic.
Use BDD or TDD - Test cases first, code after. Assume the GenAI tool will generate more code than the tests need.
Enforce readability and style standards - Strict naming conventions pay off in the long run. Hint: better Claude.md files.
Strengthen security audits - AI tools don’t prioritize security; you must build it in from the start.

Even with all these precautions, the tools will still have limitations.

Many of these skills: Lean Startup, Product Experimentation, User Stories and even Acceptance Criteria are covered in our Certified Scrum Product Owner workshops.

Deliver Value, not Code

Remember, writing code was never the goal, nor is it the bottleneck. We don’t need more code, faster. We need products that solve real problems and are easy to use and maintain. Security needs to be designed in at the start, not bolted on later.

Footnotes

Scrum Anti-Patterns: The Hardening Sprint

Wed, 12 Jun 2019 00:00:00 GMT

Hardening Sprints are one of the most common kinds of Scrum Anti-Patterns: ways of addressing recurring problems that seem like effective solutions at the time but in fact hamper productivity or create more problems later on. Here we introduce why they are used, why they are not an effective design pattern, and how you can create more effective solutions.

Scrum Anti-Patterns

In software development work, a design pattern is a description of a solution to a recurring problem. It outlines the elements that are necessary to solve the problem, including context and the consequences of certain actions, without prompting the reader to solve the problem a specific way, leaving them with the agency to write code as they see fit. Patterns, when applied well and not overused, provide a guide to solving repetitive problems rapidly. A good pattern provides enough background information to help the reader appreciate where it is applicable, without declaring that is the best solution in all instances.

Scrum, Agile, and Kanban, in this sense, are sets of behavioural design patterns. In the Scrum Community, we have Scrum PLOP (Pattern Language of Programs) that documents known patterns of effective behaviour.

Unfortunately, we also regularly see recurring patterns of ineffective behaviour. These are called Anti-Patterns.

“An anti-pattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn’t one.” ~ Andrew Koenig¹

To explore the topic more deeply, please see this growing collection of articles.

Anti-Patterns in Agile Banner Illustration

](/blog/category/anti-patterns/)

Scrum as an approach is already designed to deal with the unpredictable, without having to force exceptions. Whenever a team creates an exception, such as a special Sprint to solve a challenge, it creates an Anti-Pattern, which often results in additional problems.

The following is an exploration of one of the most common Anti-Patterns: the “Hardening Sprint.”

Anti-Pattern² Name: Hardening Sprint

Aliases: Stabilization, Hangover, Release Sprint, or IP Iteration (Innovation and Planning Iteration in SAFe)

Scale: Team and across multiple teams

Related Anti-Patterns: Sprint 0, Separate Test Team; Component Teams; Technical Debt can be paid off later; Sprint Burndown Charts, Velocity is Important, ….

Potential Solutions:

Better Definition of “Done”
Improve Engineering Practices
Slowdown

Why a Hardening Sprint might seem like a good idea

Teams new to Scrum often focus on getting as many User Stories finished as they can every Sprint. If they have good discipline, they write Unit Tests for their code. Once complete, they ship the feature off to their overburdened testers. In Sprint Review, the feature is accepted by the Product Owner. If defects are found, they’re added to the Product Backlog in a lower priority slot.

While this sounds fine on the surface, trouble may be brewing. If they finish User Stories to the Definition of “Done” but that definition still leaves some things to be dealt with later, eventually it’s going to catch up to them.

After five or six Sprints at this pace, they may elect to pause and have a “special” Sprint, or Hardening Sprint. They use this Sprint to do all of the work that they postponed during the working Sprints. The delayed work often includes tasks such as running a regression test suite, doing performance tests, and fixing defects. Often more defects are found than can be fixed. Once the Hardening Sprint is complete, the Product is released to Production.

While this is common practice, it’s not in the spirit of Scrum. Scrum is intended to help teams learn the rigour and discipline to ship working software at the end of every Sprint. Clearly, having a Hardening Sprint as part of this process allows the Team to avoid dealing with that challenge, therefore becoming an anti-pattern.

Teams who have spent a long time working in a waterfall fashion often elect for Hardening Sprints. This isn’t surprising since Hardening Sprints seem like a logical replacement for the testing and deployment phases they’ve been used to. But that’s only because Teams new to Scrum haven’t yet felt the pain that is caused by these special Sprints, so they’re more likely to fall into the trap of thinking they’re the solution to the difficult question of how to deliver working software at the end of every Sprint.

Consequences of using Hardening Sprints

The Hardening Sprint - Causal Loop Diagram

Hardening Sprints are essentially the Scrum developers’ version of “we’ll fix it in post.” They tend to decrease the readability of the code base because people have a habit³ of delaying any tidy-up work until then. The messier the code is to read, the harder and more time-intensive it is to add new features or test existing ones. Many people call this Technical Debt.⁴ It doesn’t take long before the team needs to add more time into the Hardening Sprint to get the work fully tested.

Hardening Sprints have negative downstream consequences too. By delaying the release of a working product to the customer, we delay when they will pay us. Conventional or Waterfall approaches to product development delay tasks like testing and writing documentation to the end of the development process. When we delay work until a Hardening Sprint, we’re dragging a waterfall approach into an Agile environment.

The use of Hardening Sprints leads to:

A larger volume of untested code – Many forms of testing (regression, performance, usability, etc.) are postponed until the Hardening Sprint.
Defects difficult to resolve – The longer we delay in fixing them, the harder they are to fix, both because the person who wrote them forgot their intention and code base will have evolved so we may be relying on the defective behaviour elsewhere.
An increase in defects that are either not discovered or discovered later – The more time that passes between writing code and testing it, the harder the defects are to find. In many cases, because of the ever-growing complexity, the defects are never found.
Delay for the customer – In real Scrum, the customer can use the Product Increment (aka Working Software) at the end of every Sprint. With Hardening Sprints, they get access only after the Hardening Sprint. If Hardening Sprints happen every 5-6 Sprints, that means at least 3 months without new software and real engagement.
An increase in the complexity of the regression tests **eventually** requiring an increase in the time spent doing Hardening Sprints – As the code base grows, so do the number of test cases. Eventually, one Sprint isn’t enough to run them all (let alone fix the defects) so we schedule another Hardening Sprint.
More difficult to tidy messes after they’re found because the code base is more fragile – Lacking good unit tests and automated acceptance tests, making changes becomes harder because we don’t know if we can trust that our change is good. Often we avoid making changes (e.g. refactoring) because the changes are “too risky.”
Regression Test cases run by hand (or manually) being error-prone⁵ – We’re relying on people noticing mistakes in software that they have seen many times before. Even the most careful tester will miss things due to this form of repetition blindness, called the Observer-Expectancy Effect.⁶ Relying on people to do repetitive task work is error-prone and boring for the people.

If you wish to have maintainable software, then you must eliminate the Hardening Sprint. Large-Scale Scrum hints at the problem by calling anything not truly done in the Sprint as “Undone Work.”⁷

Typical Causes

A belief that teams need to work faster from the start
Focus on increasing velocity, without first focusing on quality
A “traditional phased” approach to Scrum
A weak or non-existent definition of “Done”
Lack of rigorous engineering practices
A belief that multi-Team efforts require extra integration time before they’re ready to release
SAFe ⁸ recommendation (called an IP Iteration)

Solutions

Improve Definition of Done
- Large-Scale Scrum calls the difference between Potentially Shippable and Definition of Done “Undone Work.”⁹
Improve Engineering Practices

Both of the above should result in the Team discovering Agile Test Engineering Practices such as Behaviour Driven Development (aka BDD) Specification By Example/BDD/ATDD, etc. (see: Example Mapping)

Slow down. Don’t focus on speed – instead, focus on quality. (Which should result in the team focus of learning. This should, in turn, discover Agile Test Engineering Practices.)
- Consider the Pattern: Good Housekeeping or Daily Clean Code
Deliver working software at the end of every Sprint. (Which should refocus on Definition of “Done” and Agile Test Engineering Practices_._)
- Consider Pattern: Teams that Finish Early Improve Faster

Realistically, there is only one solution to the challenge that Hardening Sprints represent: reduce the number of time-demanding things that get pushed forward to be a future problem. Most of the work that is delayed to a Hardening Sprint is comprised of pieces of work that are done manually. For example, many software teams have a suite of regressions tests that require a person to execute a series of steps in the software and check the results. That takes hours of labour, so to have the resources and capacity to run these tests every Sprint, we need to reduce the overall manual load.

To reduce the number of manual tasks, a team could:

Take one or two test cases every Sprint and find ways to automate them. It is sometimes easier to automate in the area the team is already doing feature work. Caveat: the default approach to test automation – automate the GUI ¹⁰ and watch the results – is often not effective in the long run. However, effective test automation is beyond the scope of this blog entry.
Slow down. Since automated testing will require new skills, the team needs to slow down and take time to learn. Too often, it is assumed that team members will learn by osmosis.
Prioritize fixing defects. Delaying the fix just increases the complexity of the eventual fix and the code base. If instead, the Product Owner puts defects at the top of the Product Backlog when they’re found, they’re also sending the team a clear message: focus on quality. Related to defects are those messes (incorrectly called “Technical Debt”¹¹) in the code base that are below the level that the Product Owner can see. If they’re small (e.g. 15-30 minutes work) they should just be fixed right away. If they’re larger, they warrant a discussion with the team on how that section of the code can be improved as part of their ongoing work.

Teams that follow this approach well should not only eliminate their Hardening Sprint, but they should also be able to join the groups that do true Continuous Deployment/Delivery.

If done correctly, Teams will eventually wander into the realm of DevOps simply by getting more truly done every Sprint.

One client started to get so good at this that their team began to do documentation work in Sprint. They were noticing that some parts of their product were hard to explain, so they took that as a hint and reworked the software to be easier to use, rather than delay and just push the problem to the future. By not postponing the problem, they delivered a higher quality product.

In Certified ScrumMaster training, when discussing the Definition of “Done”, I usually reveal my true feelings and call Hardening Sprints what they should be called: an abomination. Or a slightly gentler version: Hangover Sprints.

Do you want to coach your team towards better solutions?

Fundamentally changing the way a Team works as it transitions to practicing Scrum is one of the more challenging issues of developing high-performance teams. If you would like to learn how to handle issues that organizations face like this one in their Scrum evolution, consider attending one of our workshops, where you’ll receive hands-on learning of the challenges – and solutions – and tips on how to integrate them into your Scrum.

Related Blog Entries

Systems Thinking with GenAI: Solve Deep Team Problems

Image attribution: Agile Pain Relief Consulting (Updated: March 2025)

Footnotes

An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. ~ Wikipedia ↩
https://www.martinfowler.com/bliki/AntiPattern.html ↩
In the worst cases they may even be ignorant of the need to tidy up. ↩
It isn’t Technical Debt as originally defined by Ward Cunningham. See: https://www.ronjeffries.com/articles/019-01ff/tech-debt/ - Cunningham’s Technical Debt was intended to be a design tradeoff intentionally done now, allowing the team to finish work faster, with the intention of returning later to fix the debt. Most use of the term today should be called Technical Mess or Spaghetti. ↩
This isn’t explicitly part of the Negatively Reinforcing Feedback Loop image since Hardening Sprints and Manual Regression Testing are two sides of the same coin. Teams use Manual Regression test suites that grow ever longer, which delay that testing until the Hardening Sprint, and so begins another cycle. ↩
Observer Expectancy Effect ↩
Definition of Done from Large Scale Scrum. ↩
IP Iteration or Innovation and Planning Iteration as described: https://www.scaledagileframework.com/innovation-and-planning-iteration/ and as illustrated in the big SAFe Picture https://www.scaledagileframework.com/ - in this picture they’re illustrated after every 4 normal Sprints. ↩
Undone Work - Large Scale Scrum ↩
Just say no to more end to end tests ↩
Ron Jeffries on Technical Debt ↩

Basic Explanation of the Different Parts of Agile Planning

Tue, 08 Mar 2011 00:00:00 GMT

An image of two architects' hands doing work - image licensed from Photodune

Agile Planning has many distinct phases and when you’re first learning it’s hard to keep track. This table is an attempt to simplify some of that. Note that release planning is split into two parts to make them distinct in practice. They’re normally just part of the same meeting, run on successive days.

For the sake of simplicity, I’m ignoring anything beyond release planning (e.g. strategic, roadmap, …), but you should definitely have some.

Layers of Agile Planning

Activity	Purpose	Attendees	When	What Happens
Initial Product Backlog Refinement	- Establish a common Vision - Create initial Product Backlog - Prioritize - Estimate	Whole team + Stakeholders (where possible)	At the Team Launch or before starting work on a new release	- Vision - The Product Owner presents their business case/problem, preliminary sketches, and any other information that would help the team understand the business needs. The PO and Development Team collaborate to express this as a Vision. - Initial Product Backlog - The team works in small groups writing User Stories to meet the Product Owner’s needs. - Prioritize – PO prioritizes the Product Backlog with input from Stakeholders and team. - Estimate - Using Planning Poker, the team estimates the size of the User Stories in story points.
Ongoing Backlog Refinement	- Refill the Product Backlog - Ensure team members have a common understanding of Backlog Items	Product Owner working with other team members + Stakeholders (where possible)	Not a meeting, just something that happens on an ongoing basis	As the team completes existing User Stories, the Product Owner works to restock the Backlog with new Stories. Often these Stories come from breaking down Epics. The intention is to maintain a list of Stories sufficient for the next 3-4 cycles of work (~30-40 Stories), anything beyond should be left at larger chunk sizes. Estimate new/changed Stories both to understand their size and also to ensure team members have a common understanding about what the work represents.
Write Acceptance Criteria (Part of Refinement)	Clarify the details behind a Story	The people who will do the work (e.g. BA, Dev, QA, …) in concert with the Product Owner	Not a meeting, just something that happens on an ongoing basis	The Product Owner writes a series of statements that make it clear to the team what is and isn’t included in a Story. These are typically very short and could fit on the back of an index card.
Sprint Planning	Commit to Stories for the next Sprint	Whole Team	At the start of the Sprint	The team uses their velocity in Story Points to determine how much work they can commit to. They break the Stories down into tasks. Estimation in hours is done only to ensure that the team is on the same page and hasn’t over-committed. Many teams eliminate Estimation in hours as they mature.
Daily Scrum	Prepare for collaborating for the day, plan for what will happen today	Whole team	Daily, preferably as early in the day as possible	The team check what work they completed yesterday, recheck what they can complete today, and share anything that is slowing their work down.

Be Better with Better Data

Mon, 22 Nov 2021 00:00:00 GMT

Data and metrics are not synonymous. Let’s tackle that misunderstanding right out of the gate.

Data is a number or set of numbers. “Three days.” There. That’s data. Is it useful to you? Of course not, because you have no context to go with it.

Metrics is the context and measurement of where, and under what conditions from which, that data is the result. Metrics tells you whether three days is how long it took one person (data) to unload a cubic yard (data) of rocks in a rainstorm, or whether it’s how long it took a team of five developers (data) to plan, create, test, and release a product that does X.

We talk about using better data but, really, we should say be better with well-chosen metrics. The problem is that just doesn’t roll off the tongue the same way.

In Scrum, most people instantly think of velocity as the key metric – how much work a team does in a Sprint, usually in the form of number of story points completed. But that’s a weak and easily gamed measure.

“Tell me how you measure me and I will tell you how I behave.” – Eliyahu Goldratt¹

How could a team game (i.e. manipulate) this number? The ways are many, but here are just a few:

They could inflate their numbers during estimation, even without intending to mislead. Someone might say, “Let’s make it 13 or 20, just to be on safe side.” They didn’t purposely inflate the estimate, but that was the outcome.
Feeling pressure to deliver more Story Points by the end of the Sprint, they might skimp on testing thinking, “Oh, that’s good enough and, in the worst case, we can always fix the bug later.”
They might argue in Sprint Review that an item is partially complete so they deserve partial credit.
…

All of these and more are outcomes of Goldratt’s quote. We told the team they were measured with Story Points and they behaved accordingly.

Forewarned is forearmed, and metrics have a good side as well. so they still have a place in Scrum.

Metrics are a tool to help a team know where to focus its energy for improvement next.

Notice that we’ve shifted the focus from measuring productivity to where to focus for improvement. Measurement shouldn’t be individual vs. individual or team vs. team. Rather, it should be team vs. itself in regard to “Where can the team improve next” or “Where has the team improved?”

But when we encourage you to improve, we can hear you cry back, “How do we measure that? Much of it can’t be measured and, when it can, the effects will only appear months after the actions are taken.” Fair point. Good metrics help you spot trends and find problems. Unfortunately, the data might not tell you if the specific change you made had the effect you wanted.

The key problem is that all measures we can find are trailing, and some measure their effect long after the action was taken. An example might help. Suppose our heroic team decides to better their engineering practice with “trunk based development”, their hypothesis is that doing all work on the main branch with daily checkins will reduce the frequency of merge problems and make refactoring easier. In turn, this will reduce code complexity and decrease the number of defects. So our mythical team adopts this improvement, and finds a good measure for code complexity and defects. Yay, team. The problem is that, with a sizeable existing codebase, it will take months for the benefits to prove themselves in a measurable way. In that time our team will likely have tried several other things to make improvements (a wise idea). How do we tell which improvement lead to the change in the measure?

Or if you prefer a non-programming example, think of data like a blood pressure test. High numbers suggest that improvements could be made. So you immediately cut down on salt and coffee. Maybe you take some medication. A few weeks later you book some vacation time and go hiking. Months down the road, you feel much better. What was the “fix”? Diet? Medication? Reduced stress? Exercise? All of the above? None of the above? A combination of some but not others?

In the end, does it really matter? You’re healthier and happier. The measurement data was important because it showed where to look for trouble brewing, but don’t get hung up on using it as the thing that tells you if you were successful.

So the measures we offer here are tools to help your team to understand where it is in pain, but they won’t tell you whether or not you got better.

Start with Throughput

In The Guide to Effective Agile Retrospectives eBook, we mention many sources of data that you could collect for the team. We suggest replacing velocity with a simpler measure like throughput – the number of Product Backlog Items completed in a Sprint. (Note: “completed” means Product Owner accepted and the item met the Definition of Done.) Throughput is elegant because most attempts to game it improve the product we’re building. For example, in an attempt to increase perceived throughput without doing more work, the team split their features or user stories into smaller chunks. When features are split into smaller chunks, there are typically fewer defects since they’re better understood and the product owner gains greater flexibility.

To improve your use of metrics, find a few simple sources of data you could bring to your next retrospective. From the eBook, some highlights:

The Team calendar – helps to remember who was present and who was away
Did the team have any Production Support issues to deal with? When did they happen? Were there interruptions from other sources outside the team (e.g. VP or CEO)? When? Capture and display this information on a Kanban wall.
Items still In Progress at Sprint End
Number of User Stories that were thought complete but failed to meet the Definition of “Done”

Consider Morale

We all want to create a workplace that we enjoy. We spend the vast majority of our awake adult lives there, so it sucks if it’s something we dread. No matter how good, or bad, it’s normal to have many ideas about how we’d change things if we were the boss for a day. The question is then, how do we measure that?

There’s rising popularity for using the Happiness Index – whether you’re happy at work – but there are many problems with this as a measure. Morale, on the other hand, is robust, less susceptible to mood, and vastly better studied by both Occupational and Military Psychologists:

‘(Team) Morale is the enthusiasm and persistence with which a member of a team engages in the prescribed activities of that group’ (Manning, 1991).

In the Retrospectives book, we shared some summary notes about Christiaan Verwijs’s advice on how to measure morale for a team in a way that more useful than the Happiness Metric. He also a created a free survey tool to help measure morale anonymously across a team: https://teammetrics.theliberators.com

Example Data - Morale

Example of data collected to measure team morale presenting results using red-yellow-green colour coding

In a retrospective, we could ask questions like:

Why is our morale at this level?
How does it compare to our historical morale?
Can we see if changes in morale correlate with any other measures?
Has there been a noticeable downward trend? If so, what has prompted that change?
Is there one experiment that might help in improving morale?

Address Impediments and Interruptions

We already know that the ScrumMaster doesn’t solve most impediments on their own and that it’s a team effort. That leaves the bigger issue of creating awareness of the impediments and their sources. There aren’t any miracle cures in this area, but it really helps to gather both quantitative and qualitative data.

Qualitative first – listen in Daily Scrum and make note of problems that your team members encounter. Both the things they describe as impediments, and even the ones that aren’t explicitly named (for example, if a team member says, “I spent half hour waiting for a build to complete or another person to do something for me”). Watch for interruptions from outside the team. Also note incidents of lack of knowledge, which can slow one or more team member as they search for an answer. All of these point to different sources of slowdowns or blockages for your team. A great ScrumMaster will record these and bring the data to a retrospective.

Quantitative – count the number of these impediments, interruptions, or blockages that occur each day. This is also information to bring to the retrospective.

The qualitative data can be used immediately; the quantitative will take a few Sprints until we have enough data that we can show people the correlations. There’s an example in the Retrospective book that shows where, in the Sprints where there are more outside interruptions, the team deliver less value. Take the time to assemble this correlative data, because it can be very powerful at helping to start bigger organizational changes.

Graph measuring number of defects found in a product over time, measured in weeks.

Remember, metrics are a tool to help a team know where to focus its energy for improvement. There is no magic, but the closest thing to it can usually be found with teams that make an ongoing effort to consistently make small, positive changes. Something as manageable as a 3% improvement rate will add up to noticeable benefit quicker than you might think. Data, both quantitative and qualitative, can be a source of ideas for those improvements. Or, if the desired improvements are outside of the team’s control, the same data can be used to spark conversation around deeper changes.

Want to have a better understanding of the why and how of more things in Scrum, and not just the book-level what? Practising Scrum without proper understanding can bring poor results and, ultimately, frustration and resistance. In our Certified ScrumMaster workshops, attendees learn in a fun and non-judgmental environment how to make Scrum work effectively in the real world, not just in principle. Join us to learn and to gain practical, hands-on experience.

Image attributions: https://medium.com/the-liberators/agile-teams-dont-use-happiness-metrics-measure-team-morale-3050b339d8af and Agile Pain Relief Consulting (Updated: March 2025)

Footnotes

https://en.wikiquote.org/wiki/Eliyahu_M._Goldratt - from The Haystack Syndrome – caveat this book is generally considered hard reading even for experts in the field. ↩

“Because Our Competitors Are” is No Reason to Become an Agile Organization

Wed, 17 Feb 2016 00:00:00 GMT

Companies are starting to fall into a trap, and it goes something like this, “Our partners/competitors/… are Agile, so we need to be Agile.” Becoming Agile without a valid reason will harm your organization. I can’t state that any simpler.

In the ‘80s and ‘90s, rival manufacturers often visited Toyota plants, and Toyota was delighted to welcome them, because Toyota understood that even if their competition copied company practices, practices change. What competitors weren’t copying was the culture that created the practices in the first place, and that’s where the real value was. Thus we had Cargo Cult Lean at many North American manufacturers, and it didn’t produce the results that companies were hoping for.

We’re seeing that again with Agile. It’s not enough to become Agile and to copy Agile practices simply because your competitors are. Unless you develop a culture that creates its own practices, this will lead only to Cargo Cult Agile, and not a true Agile Organization.

What competitors weren’t copying was the culture that created the practices in the first place, and that’s where the real value was.

So what are some valid reasons to become Agile? One of the primary ones is to be able to readily adapt to a changing environment. Other reasons include: Resilience; Predictability; Risk Reduction; Morale and Retention; Early ROI; Predictability; Customer Satisfaction and Simplicity.

Consider how Blockbuster adapted to online video, or how the taxi industry is responding to Uber/Lyft. Control-focused organizations struggle to adapt rapidly enough to survive, compared to their competitors who embrace change. Traditional/hierarchical organizations work well when problems are clear and solutions are repeatable but, unfortunately, those that thrive in those conditions are fragile when the situation changes and they can’t adapt.

The structure of traditional organizations is one which evolved in a world where the pace of innovation and change was much slower. Changes could be spotted years out, and a response could be crafted and the organization would do well.

That world no longer exists. Whole industries die in only few years if their response to change isn’t rapid and flexible. Which is where Cynefin can come in to the conversation.

Cynefin

Cynefin is a way of understanding the problem domains in which we find ourselves, and identifying which tools would be appropriate in response.

At first blush it can look a little daunting, but bear with me and you’ll see that it doesn’t have to be. It’s merely a matter of “cause and effect”, and how simple or complicated that plays out within the context of your organization.

The Cynefin Framework breaks down into 5 different domains to describe different types of relationships between cause and effect – from straight-forward, to complicated, to non-existent.

The first of these is, well, Obvious.

Obvious (formerly called Simple) is just as the name suggests. These contexts are clear to all involved. If X, then Y. At any stage in a process, it is clear what the next steps are. Examples are aspects of banking (interest calculations), insurance (calculation of premiums), etc., Organizations in this realm gain value from a degree of structure to ensure that people follow the rules. Standard practices apply here.

A simpler example? Let’s talk about growing things. Develop your green thumb. In an Obvious system, we have a sponge. If you apply water to it, it will swell and grow. Cause and Effect in its simplest form. Sponge + Water = Bigger Sponge.

That’s Obvious. The next domain is a little less so.

Complicated is where the relationship between cause and effect is harder to see. It requires analysis and, often, expertise to find and understand the relationship(s). Once understood, “best practices” can be developed in this domain.

To return to the growing analogy, this is the system where we’re growing one plant in a pot, which is considerably more complicated than growing a sponge, but there is still logical cause and effect involved. Seed + Soil + Water + Sun + Food = Plant. In this world, there are rules of thumb (green or otherwise) and best practices.

It’s important to note that one of the risks of a Complicated Domain is that we listen only to the experts. It’s vital that we also factor in our own observations and environment.

The next domain is more Complex and, in these contexts, cause and effect relationships are only understood in hindsight. Given the unpredictability of this domain, we’re better off probing, sensing and responding instead of trying to control or plan. Instead of looking for complex solutions, seek simple rules or heuristics to help work well in this environment.

Trying to help grow our kids is an example of the Complex Domain. We ask them to do something (probe), they respond (sense) in an unexpected way. It’s only in retrospect that we can see why they responded that way. Next time, we adapt (our response), changing the phrasing/tone based on our new understanding of them.

Complex domains require many diverse viewpoints to help solve. Although challenging, they’re still much easier to navigate than Chaotic.

In Chaotic Domains, there is no relationship between cause and effect. Emergency/disasters are examples of the Chaotic domain. In these cases, the goal is simply to try and bring them back from Chaos to the world of the merely Complex. We don’t often see this domain in the business world, so we’re not exploring it here.

And the fifth and final domain is Disorder, which exists when it hasn’t yet been determined what the cause and effect relationship is. It’s in this state that people are most apt to make decisions based on their own comfort zone.

These days, businesses are usually working in Complex Domains, which means that traditional, old-school approaches aren’t realistic.

We can’t afford to have the DNA of Simple organizations persist, if organizations want to thrive in this new, rapidly-evolving world. So we need to create organizations that can adapt – and even thrive - in a Complex world, and help Simple and Complicated structure businesses evolve to that goal. We can do that by creating Agile Organizations that understand the Cynefin Framework, and how different responses are appropriate for different complexities of situations.

Cynefin Framework - image by Agile Pain Relief Consulting

Agile Organizations:

Can sense their playing field
Can adapt
Have resilience built in
Focus on quality
Delight the customer
Get earlier ROI
Target delivery, not risk reduction
Build simpler systems and products
Create the unimagined
Ensure alignment toward a common goal

Become an Agile Organization because it helps your organization to thrive in a Complex world – not because your competition is doing it. Choose this path knowing that there is a great deal of change involved, but understanding that the change will help create more value in the long run.

References:

-https://www.anecdote.com/2009/04/a-simple-explanation-cynefin-framework/

Image by Agile Pain Relief Consulting. Image elements designed by Freepik.

Bell Curves and Measuring Badly

Mon, 21 Mar 2016 00:00:00 GMT

False Assumptions and Cognitive Biases

To keep life manageable, and so we don’t run out of steam before we leave the house in the morning, we develop a series of mental shortcuts, aka habits. Habits aren’t only things like brushing our teeth and locking the front door, but also include our route to work and whether we take the elevator or stairs. Without these mental shortcuts, we would be exhausted by the number of decisions we would need to make before we reach our desks. Unfortunately, these same mental shortcuts also cause us to miss key questions, misjudge, and misunderstand risk.

Gambler’s Fallacy – we tend to put weight on past events, thinking they’re likely to affect future events, even when they’re independent. Example: flip a coin 9 times. If each result is heads, we tend to assume that it’s very likely the next one will be tails. Yet it’s still 50%.

Observational Selection – right after we buy a new car, we notice that there are more cars of the same model on the road. Yet the number of cars on the road hasn’t changed - what has changed is what we notice.

In the business world we tend to assume that a bell curve or normal distribution applies anytime a number is quoted to us (numbers are often quoted as an average). For example, if I asked you to show me a model of the wealth of 10,000 randomly selected people it would probably end up being a graph like this:

2 standard deviations – 95% confidence interval
3 standard deviations – 99.7% confidence interval

Yet there is a very good chance that your sample included a few people with a net worth of over $50 million and even one of $500 million. In which case, our bell curve isn’t a good model for what we actually found. Even better, if I ask you to ensure that your graph includes the wealth of Bill Gates, now the graph likely looks more like this:

reality curve - image by Agile Pain Relief Consulting

Because we tend to assume that normal distribution applies to most numbers we see, we fail to correctly estimate the likelihood of extreme events.

Nassim Taleb (“Antifragile: Things That Gain from Disorder”) calls these extreme events “Black Swan events”. Events that normal distributions underpredict by a multiple of thousands. For example, assume that stock price movements on the S&P 500 index fit a normal distribution, and that events that fall 5th standard deviations from the mean have a 1 in 3.5 million chance of happening. Yet in 1987, the S&P index had 3 such days, and over 50 since it was first created. The S&P 500 was founded nearly 60 years or 22,000 days ago (this includes weekends and holidays), so if a bell curve applied, we would expect 0 or 1 extreme events thus far.

original image by AGorohov: Photodune

We think we know stock market, and we think we can model risk in the stock market. Yet we can’t. So don’t assume that we understand, and can model, business risk either.

Our attempt to use numbers as our primary way to measure and manage risk misrepresents the real risks because our models give us false assurance. Our models do a good job predicting the normal, everyday events, so we believe them. However, we significantly underrepresent drastic events, making them seem almost impossible even though they’re not.

Numbers are useful, but give us only a small piece of the picture.

See also: Linear Thinking in a Nonlinear World by Bart de Langhe, Stefano Puntoni, Richard Larrick

Graph images by Agile Pain Relief. Calliper image attribution: AGorohov via Photodune

Beyond Scrum Blog Series

Tue, 17 Jan 2017 00:00:00 GMT

We’ve had requests for a single page that lists all the ongoing Beyond Scrum blog posts in one handy spot, and we’re happy to oblige! The below list will be updated as new posts are added.

Beyond Scrum: Scrum Alone Is Not Enough

Scrum Alone is Not Enough

Simplicity

Scrum Development Team – Who’s In It?

What is the Recommended Scrum Team Size?

Specialists Are Overrated

How to Cross-Skill and Grow T-shaped Team Members

“Because Our Competitors Are” is No Reason to Become an Agile Organization

What Are the Limits of the Scrum Framework?

Don’t Inflict Scrum or Kanban on Teams

Taking Organizational Improvement with Scrum Seriously

Taking Organizational Improvement Seriously – Case Study

Agile Change or Adoption Always Starts With “Why”

Agile Change or Adoption: the Steps to Go from “Why” to “How”

Agile Change or Adoption: Sense Your Current Culture

Agile Change or Adoption: Create a Vision

Agile Change or Adoption: Turn Vision into Strategy

Agile Change or Adoption: Define Small Organizational Changes

How to Be an Effective Manager in Scrum

The Role of Agile Managers: Why Job Titles Are Dangerous

Kanban Portfolio View

Portfolio Management

Red-Yellow-Green Status Reports and Other Models – How They Should and Shouldn’t Be Used

Bell Curves and Measuring Badly

Measurement for Scrum - What are Appropriate Measures?

(Original background vector elements designed by Freepik.com. Adaptation by Agile Pain Relief Consulting.)

Blind Estimation for Planning Poker

Mon, 07 Jan 2013 00:00:00 GMT

Blind Planning Poler - image licensed from Photodune

When helping people learn Planning Poker I always ask what will happen if one person plays/says their estimate before anyone else. Many people usually spot the problem and they call it “influence.” And they’re right. Sometimes a wise person says, “but I won’t be influenced”. The science of “anchoring” is well known but until recently I couldn’t think of a personal example that illustrates the problem. Happily a recent trip to San Francisco solved that problem.

I was shopping for a new pair of pants. My expected price was $75 for a decent pair of khakis. My first stop was Hugo Boss which sold very casual khakis for $150. I thought, “No way! Far too much money.” In the next few stores I saw several more pairs of pants at $100-120. But fifteen minutes after I first saw the $150 pants, I bought a pair for $100 in Bloomingdales (10% discount because I’m a Canadian). I was happy to get such a bargain. After an insanely long walk back to my hotel I realized what had just happened. Seeing the $150 pants reset my price point and now I thought that was the high end and that $100 was “reasonable”. Luckily I didn’t buy two pairs, which was my original intent.

Anchoring is subtle and it can be pernicious. One comment that really stuck with me in this area came from Dan Airely- even with everything he knows about these kinds of biases and errors he still makes these mistakes.

That is why Planning Poker estimates are done blind, no pre-conversations about the estimate.

Image licensed from Photodune

Characteristics of Effective Scrum Teams

Mon, 16 Dec 2024 00:00:00 GMT

Grouping individuals together doesn’t make them a team. It takes more than just a label to turn a collection of people into an Effective Team.

In 1993, Jon Katzenbach and Douglas Smith published, The Wisdom of Teams[1], which highlighted the difference between Working Groups and Real Teams. In this article, we summarize Katzenbach and Smith’s work and then offer a modern example of what is required for Effective Scrum Teams.

graph comparing working group to real team to hig-performing team

Katzenbach and Douglas described teams as needing open interaction, fact-based problem-solving, open communication, and a way to improve. This is a simplified list from their book of how a real team is distinguishable from a working group:

Characteristics of High-Performing Teams

Small number of people
Complementary skills
Common purpose
Have a specific and challenging performance goal
Mutual accountability
Common approach

When Katzenbach and Smith published their work, Scrum didn’t yet exist. So their description is a good start, but too abstract for Scrum Teams. I’ve created a more focused list of Characteristics of Effective Scrum Teams, and it would also apply to those using other Agile approaches (e.g. Kanban, XP, etc).

Characteristics of Effective Scrum Teams

Psychological Safety: This is being part of a team and knowing 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.
Collaboration: Collaboration over coordination or cooperation. Coordination is synchronizing the independent work among a group people. The work isn’t necessarily working towards a common goal. Cooperation is to act or work together for a shared purpose, however, many tasks will still be completed independently. Collaboration is working together in a joint effort towards a common goal.
Self Managing: Teams are empowered to manage their own work and make decisions independently.
Clear goals: Specific and well-understood objectives that align with the overall product vision.
Cross-functionality: Ensuring that team members have the necessary skills to complete tasks end-to-end, reducing (or eliminating) dependencies on other teams.
Continuous improvement: Regular reflection on processes and practices to identify areas for improvement and make adjustments as needed.
Short Sprint Cycles & Adaptability: Short sprint cycles focus on specific goals, adapt product work based on client feedback, and improve the team itself.
Customer Focus: Prioritized work based on value delivery to customers and stakeholders.
Quality over Quantity: Emphasis on delivering high-quality work rather than rushing through tasks for quick completion. Relentless focus on the Definition of Done.
Respect for Craftsmanship: Team members who are encouraged to take pride in their work, strive for excellence, and continuously learn and grow.
Embraced Change and Transparency: Being Agile means adapting to new requirements as they arise, even late in the game. It also means be open about what we’re doing and what we see.
Willing to Ask for Help: For example, to clarify end user needs, or when you’ve spent more than an hour on the same problem, etc.
Sustainable Pace: We balance Productivity with maintaining a Sustainable Pace. We work at a pace we can sustain for the long term. This is especially true as GenAI takes over our work places.
Experimentation: Great teams take on the mindset of experimentation. All improvements, whether product, quality, technical or productivity started with an experiment.
Diversity of Thought: A team with different perspectives finds its own blindspots sooner, is more creative and can solve more complex problems.

Think about the best team you have ever worked on. Which of these characteristics did it have? If you’re lucky, most of them. The above list was created to help teams identify where they can improve.

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.

Related Blog Entries

[1] Thanks to Mishkin Berteig, who introduced that book to me in ~2006

Building effective teams is a core focus of our Certified ScrumMaster workshops, where attendees learn to foster these characteristics through hands-on exercises and coaching.

Image attribution: Agile Pain Relief Consulting (Updated: March 2025) Updated: Jan 2026

Choosing a Scrum Sprint Length – Shorter Beats Longer

Tue, 05 Nov 2019 00:00:00 GMT

How long should a Scrum Sprint be? A Scrum Sprint is a short period of time when the Scrum Team works, but there is no hard rule as to how long that should be – in this post, we cover the pros and cons of shorter and longer Sprints and how you can discover what works best for you.

Let’s start with the purpose of a Sprint: a fixed period of time for the Team to focus and develop a product with quality high enough that they could release it to the customer. A “good” Sprint Length, then, has to be long enough to produce results, but short enough to limit risk.

The Scrum Guide says that:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done,” useable, and potentially releasable Product Increment is created.

Scrum Sprints are limited to one calendar month. When a Sprint’s horizon is too long, the goal of what is being built may change, complexity will rise, and risk is higher – all of which contribute to increased costs and unpredictability. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. As well, they limit risk to one calendar month of cost.

The Scrum Guide leaves it up to the Team to decide what Sprint length works best for them. When you’re first starting out in Scrum, it’s reasonable to experiment to find out what that ideal length is, but there is one caveat: shorter Sprints (1-2 weeks) help reveal problems and impediments faster. Sometimes this is uncomfortable, which results in Teams favouring longer Sprints to avoid dealing with these problems. That isn’t a Scrum-like approach; Scrum is intended to bring the problems we have to the fore so they can be addressed.

A key consideration when deciding Sprint length is risk tolerance. Longer Sprints are riskier for predictability and cost.

Before getting into the pros and cons of different Sprint lengths, something that you should consider is Sprint Cancellation. The Product Owner may elect to cancel a Sprint when the original Sprint Goal becomes irrelevant. Sprint Cancellation should be rare – in fact, most teams should never experience this. However, if you find good cause to cancel a Sprint more than once, you should be considering what circumstances make this happen and fixing the underlying problem.

Why Shorter Sprints are More Effective

To understand why you ideally want to lean toward a shorter Sprint, let’s look at some pros and cons of different Sprint lengths. I’ve also included some tips to help you decide what might work best for your Team. Remember: this isn’t a substitute for getting the Team to make their own decision based on their understanding of Scrum.

How to choose a Scrum Sprint Length - image by Agile Pain Relief Consulting

Longer Sprints (3-4 weeks)

Important: If your Sprint is longer than one calendar month, you’re not doing Scrum anymore.

Pros

It’s easier to start practicing Scrum with longer Sprints because Teams often assume it will be easier to deliver a valuable chunk of work and get it to “Done” in one month rather than two weeks.

Cons

It is difficult to plan well for a three to four-week Sprint during Sprint Planning. This tends to lead to more “shadow work” ¹ being done.
Related to shadow work – new features and needs tend to crop up more often mid-Sprint.
The Product Owner will have a harder time not asking for change; e.g. new features or stories mid-Sprint.
Fewer Sprint Retrospectives lead to fewer explicit opportunities to improve as a Team.
Fewer Sprint Reviews give the Product Owner fewer opportunities to improve the product.
Greater risk of Sprint Cancellation due to changes in the market or customer expectations.
Greater risk of something going wrong that makes it impractical to deliver the original goal.
Makes it easier to do “Mini-Waterfalls” within Scrum, i.e. Analysis -> Development -> Manual Test, with a certain number of days planned for each. This leads to the dark side and Scrum Theatre. Mini-Waterfalls also usually lead to the use of Hardening or Stabilization Sprints.
Team and Organizational problems tend to be discovered and addressed more slowly.

How to choose a Scrum Sprint Length – Shorter Beats Longer - image by Agile Pain Relief Consulting

Shorter Sprints (1-2 weeks)

Pros

Since the Team has more, but shorter, retrospectives, they have more opportunities to make smaller changes. This also provides more opportunities to improve as a Team because…
More frequent Sprint Reviews give the Product Owner more feedback and more frequent opportunities to update their thinking with respect to the Product Backlog. This should largely eliminate the need for the Product Owner to ever ask for a change (e.g. new Story) during an in-progress Sprint.
Impediments and slowdowns are highlighted more quickly since the Team is expected to get feature(s) to Done by the end of every Sprint. This forces the Team to come to terms with things that are slowing them down.
Shorter cycles make planning easier, which increases focus and reduces the amount of “shadow work.”
Forces Teams to do a better job of slicing stories or features into smaller chunks. This increases visibility and understanding of progress within a Sprint.

Cons

It’s harder to get to a finished product at the end of a one or two-week cycle. Caveat: this is true at first, however, most Teams are able to get the hang of it after three to four Sprints.
Working in one-week Sprints can be more stressful at first.
People say that Sprint meetings are too much overhead for a one-week Sprint. However, Sprint meetings should scale linearly with the length of a Sprint. So, a one-week Sprint will have two hours of Sprint Planning; a two-week Sprint will have four hours, and so on.

Today, most Teams new to Scrum pick two-week Sprints.² Some go as short as a week.

Note: On the rare occasion that I’ve seen Sprints shorter than one week, it seemed to reveal a much deeper dysfunction. In most cases, it’s unlikely to be the best choice.

Important Tips

Once a Sprint has started, don’t change its duration (i.e. don’t extend) - The end of Sprint is not a deadline, but an opportunity to pause, reflect, learn and improve. - If there are problems either in delivering the committed items or delivering the intended quality, you’re better off pausing and learning from the problems than changing the Sprint duration.
Consistency – Humans benefit from having some consistency, structure and predictability in their world. So, once the Sprint length is set, it’s usually best to stick with it. The Scrum Guide even notes: “Sprints have consistent durations throughout a development effort.”
Experiment – As your team and organization evolve, what used to work might change. Run experiments – example: https://medium.com/akeneo-labs/experimenting-one-week-sprint-93dd04b42191 Note: I don’t recommend growing a single team to 15 people.
2-day Sprints? In an extreme case, Mishkin Berteig coached one team to use 2-day Sprints using the short Sprint to reveal greater dysfunction in the organization.
To do well with shorter Sprints, Scrum Development Teams need to work on some skills: - Story Splitting – so that they divide the work into small manageable chunks - Agile Engineering Practices – to ensure that increment delivered is of high quality - Learning to put Quality Assurance at the beginning and not the end of their development process. Usually this requires learning Behavior-Driven Development, also known as Example Driven Development.

Choose the Scrum Sprint Length

We’ve reviewed the purpose of a Sprint, and some pros and cons of Long versus Short. So now how do you decide what length of time to use? Consider everything by asking questions of the Team to prompt discussion. Some examples:

How long are you comfortable with potentially creating the “wrong” thing? (i.e. what is your risk threshold?)
How often do you want to get feedback from the PO/customer?

Can you think of more good prompt questions? Please share in the comments.

Whatever Sprint Length you set, honour it as the Team’s choice. Then review, experiment, and adapt until you find the “sweet spot” that works best for your Development Team.

Additional References

“The Sprint Length” by Sjoerd Nijland

“What is the optimal sprint length in Scrum?” by Matthias Orgler

If that all seemed like too much…

The many different factors to consider can be a little overwhelming for people new to Scrum. That’s okay, nobody has ever practiced Scrum perfectly. In our Certified ScrumMaster (CSM) workshops, you will learn through hands-on training on how to grapple with all that information and make uncomplicated decisions to help support your Scrum Team and organization.

Mark runs CSM workshops in Ottawa and across Canada throughout the year. To find out when he’ll be near you, check out our ScrumMaster page.

Image attribution: Agile Pain Relief Consulting (Updated: March 2025) Original: 2013, Updated Nov 2019

Footnotes

“Shadow Work” is any work that wasn’t intended to be done during the Sprint that is picked up and done without being surfaced to the team and placed on the board ↩
https://info.scrumalliance.org/State-of-Scrum-2017-18.html ↩

Coaching Self Organizing Teams

Thu, 07 Aug 2008 00:00:00 GMT

In the best session I’ve attended at Agile 2008 Joseph Pelrine talked about some of the ideas and science around self organization teams. The talk has an excellent subtitle “Hard science for soft skills”. I’ve already covered some of the presentation and exercises on InfoQ so I won’t repeat that here. Instead I will focus on the additional material we covered.

Conflict

Based on the work of his partner Ben Fuchs. In an attempt to suss out our differing definitions of conflict we were asked:

So when you think of conflict in your environment, what do you think of?

Do you see it as threatening?

Is it struggle between right and wrong, good and evil?

Or is it the struggle for intimacy?

Is it a natural consequence of differences and opportunity to deepen relationships?

Is it evidence that our social and power structures are distorted and not in harmony?

Does it prove that our group is healthy enough to engage with differences

Perhaps it is a synchronous and meaningful signal that something in the wider system needs attention?

How does the experience of conflict feel to you? Is it painful, frightening, or perhaps a little exciting?

Within our small group there was a surprising range of difference where some thought a little conflict was necessary and good to grow, while others thought all conflict was bad. Joseph used the analogy of a soccer coach and team to illustrate how a little conflict can help push the entire team to a higher level. A soccer team has 24 team members only 11 of whom will play in any given game. The result competition and conflict pushes people to both greater individual and team performance.

When conflict happens its important to recognize that there three levels of conflict:

Pre conventional – primitive feels of fight or flight that evolved to handle life threatening events.
Conventional – personal identity and sense of self – likely evoked when “personal values and beliefs, self-esteem or rank” are at issue.
Post conventional – threats beyond the individual to the group that the person is involved in.

Mihály Csíkszentmihályi’s Flow Model (Revised)

Challenge_vs_skill by Oliverbeatson via Wikimedia Commons

Skills vs. Challenges – we were challenged to think about various tasks and see where the map into the diagram. Do we spend our time in Boredom, Flow, Control, …? For instance if we’re programming in a new language and using to solve a non trivial problem then we will find ourselves either in Anxiety or Arousal. If we’re doing complex tasks that we no longer find challenging then we’re in Boredom or Relaxation. As we think about teams and team members we can consider where do they fit on the circle for specific tasks. If we see people in Anxiety or Arousal then we should consider what can we do to help move them towards Flow and Control – so that the project will be in a safer place. Conversely if they’re Bored or Relaxed then we need to consider how to challenge them to help move their performance around the circle.

Power bases

Reward power - you give someone reward power if you believe that someone will do something good for you.
Coercive power - you give someone, if you believe that someone can do you harm
Legitimate power - explicit (work), implicit (children) contract - mix of reward and coercive
Expert Power - on the basis of your belief in someone’s expertise.
Referent power - based on their personal integrity example: Ghandi, Mandella, Dalai Lama, …

Which power bases can you raise?

Expert power - learn, professional development Referent power - be open, honest, deliver on your promises.

Tidbits

If you make the interpretation then you have to accept to the conclusions. If you have people who are having troubling accepting the conclusion then you have to get them to do the interpretation.

You have to listen for weak signals - not all problems that teams have are obvious.

Baseball bat – apparently from Ron J.

First time person does something - explain the effect of the behaviour on the team
Second time - explain the effect on themselves.
Third time - implement it on them aka the baseball bat/rolled up newspaper.

Now turn the model on its head - why should the person change? If the behaviour violates the team norms under some circumstances the team will adapt. Either the team will adapt or the person will. In many cases instead of intervening step back and let the team sort the issue out: maybe the team will regroup around this person to protect.

J’s law of groups - groups larger than seven tend to sub-divide when you add the eighth person. In part this happens because the number of communication channels grow too large for the group to handle. For more on how group size affects teams in practice, see What is the Recommended Scrum Team Size?.

In addition when the group organisation changes (adding/removing members) all the relationships need to be renegotiated. So if change of team membership must happen its better to get it all out the way at once. For the same reasons groups must reform as per the Tuckman. This is one of the key reasons stable teams matter so much in Agile.

When team friction does arise, Working Agreements are a practical tool for channelling conflict into productive team norms.

Image attribution: Oliverbeatson via Wikimedia Commons

Collaboration, Over Work in Isolation

Tue, 22 Aug 2023 00:00:00 GMT

woman and man sitting in front of monitor doing code review, Photo by Desola Lanre-Ologun on unsplash

When I’m working with new Scrum Teams and say that Scrum encourages collaboration among team members, everyone nods and smiles. When I ask them to describe their actual collaboration, I hear about collaboration in Sprint Planning, Review and Retrospective. If I’m lucky, someone mentions solving impediments found in Daily Scrum through collaboration.

Wow. Jaw drops. Jaw hits the floor and shatters. That is a seriously low bar for collaboration. This suggests that only 10% of a Scrum team’s work is collaborative.

Let’s define our terms:

Coordination - synchronizing the independent work among a group people. The work isn’t necessarily working towards a common goal.
Cooperation - to act or work together for a shared purpose. However, many tasks will still be completed independently.
Collaboration - working together in a joint effort towards a common goal.

In the world that many Scrum people imagine, team members grab User Stories, Tasks, or (worse) Tickets at the start of the Sprint. They then retreat to their desks and only emerge to talk during Daily Scrum. When they finish their part of the task, they mark it as “Done”, and hand it off to the next person, then grab a new task. So their “Done” isn’t truly done and deliverable, it’s just done for them, before someone else tags in and takes it another stretch forward.

The Sprint Planning and Daily Scrum portion are being used for coordination. Sometimes this rises to the level of cooperation, but typically each task is performed solo. This certainly isn’t collaboration because team members aren’t working together toward a common goal.

The above paints a disappointingly common scenario where they call themselves a Scrum team but, in reality, people are working primarily in isolation.

Why is working in isolation so bad?

Handoffs result in a loss of information and force (re)learning about the current and historical status of the item. The more handoffs there are, the greater the loss of information. The more handoffs, the slower the progress of items from start through to delivery to customer (aka cycle time). This happens because each handoff adds the opportunity for a ‘waiting for’ delay.
Work in isolation (and with additional handoffs) reduces quality since the work is completed without ensuring the person’s work meets the needs of the User Story. Or worse, the expectations of the other people who will work on this item.
Work in isolation harms our sense of team because of lack of time spent interacting with each other.
Working only on individual Tasks or User Stories harms the overall Product Vision, because team members aren’t staying focused on the overall product, just the piece in front of them right that moment.
Work done in isolation leads to only marginal improvements in productivity and customer satisfaction, because real performance improvements come from acting as a team through diversity of thought, spotting each other’s mistakes, reduction in errors, helping your partner stay focused, etc.
Work in isolation increases our coordination costs through lost productivity during handoffs and, even more so, the reduced amount of information transmitted, which increases the likelihood of defects and the need for rework.

I have never seen a truly high-performing team (and I’ve seen many teams) when the work was done largely in isolation rather than with collaboration.

Why is collaboration beneficial?

Shares knowledge and aids the cross-skilling process through hands-on work, rather than just theoretical study.
Generally diverse groups make better decisions than a single individual because of the broader range of experience and knowledge to draw from.
Easier to adapt to changing circumstance (e.g. if a Dev and Business Analyst or Dev and Tester are working together and there is a change in the acceptance criteria, they can more easily write new example and test case together)
Increases motivation. Humans have evolved to be social, and working together on a problem deepens relationships and communication.
Increased creativity through diversity of thought.
Reduction in mis-communication thanks to more face to face discussion, and opportunity to clear up misunderstandings quickly before they compound.
Constant feedback, which catches errors early.
Rebalances workloads and reduces bottlenecks.
Items finished to truly “Done” sooner, thanks to fewer handoffs and delays.
Reduces Work In Progress. When two people are working on one thing, they’re more likely to get it to “done”, and there aren’t two separate things in progress at the same time.

How can you tell the difference between coordination, cooperation and collaboration?

Coordination

Daily Scrum is about reporting to the ScrumMaster and not understanding what your peers are working on.
You exchange messages in Slack, GitHub Issues, or over email. Real time conversation is low.
All work is completed by individuals who then pass it to the next person. For example, a User Story starts with a Business Analyst, who hands it off to a Developer, who hands it off again to a Tester.

Cooperation

You know what your peers are working on.
You help each other out when there are specific issues you think you can assist with.
Most work is completed by individuals as above, however there is more communication around the handoffs, reducing the errors.

Collaboration

Scrum has evolved beyond the dreaded three questions: What did you yesterday? What will you do today? What are your blockers?
Instead, it is a collaborative event where people discuss who will pick up a User Story on a given day. They also might touch on the pairing rotation (see Pair Programming).
Most work is completed by 2–3 people working in flow. For example, the Business Analyst and Developer sit down to work the first pass at a User Story. After a day of work, they involve a Tester.
Work in Progress is limited to 2–3 User Stories at one time and handoffs have been mostly eliminated.

Hint: a large volume of noise on Slack or any other chat mechanism isn’t a sign of collaboration. It is either coordination or, at best, cooperation. When collaboration is happening, people move out of Slack to actual conversation.

Why does work happen in isolation?

It probably starts with history. Most people have spent a large chunk of their career working this way, and they don’t realize that a different approach is possible. I’ve spent time in work places where people were compared to others on the speed at which they completed work items. When the performance system puts a high premium on individual effort and productivity, then you get people working in isolation.

Many team members see their Sprint Backlog/Kanban board with columns like Develop, Test, and Deployment as a demarcation of roles. This is reinforced by the ticket-focused culture that often comes with JIRA and many other electronic work tracking tools. (Hint: these aren’t Agile tools.) Many JIRA implementations limit User Stories (or Product Backlog Items) so that only a single person can be assigned to a task. So, by default, people assume that this is the correct model for work.

Lack of trust also contributes to work in isolation. If we don’t trust each other, it is easier and safer to work alone on items than to risk working with our colleagues. Anyone who ever did a group project in school where some of the group didn’t contribute, may have trust issues to overcome.

Other contributing factors:

Lacking a common goal (aka Product Vision)
Unclear priorities. Too many teams I meet tell me their Product Backlog isn’t a well-ordered, clear list. Instead, it looks more like the overgrown, building lot down the street, where there was once a good building, however the owner moved out a while ago and it’s starting to fall down.
Remote work has improved the lives of many people by reducing their commute, reducing costs, and giving them more time with family. However, collaboration went from the ease of walking down the hall or mentioning something at the water cooler, to online communication that requires more explicit effort and is more prone to misunderstanding.

How to encourage real collaboration

As with many questions in Scrum, start with asking the team. What do they need to do to move from coordination to collaboration?

There are many approaches that lead to increased collaboration; I will touch on three specifically. But more important than any individual technique is the goal to create a team culture that defaults to asking the question: How could I do this piece of work with the help of at least one other person? This will result in collaboration becoming a healthy habit.

All of these approaches are documented in our Agile Engineering Practices section of our glossary.

Pair Programming - Two people work together in a single development environment to do a chunk of work.
Ensemble Programming (formerly called Mob Programming) - The whole team work together to build a feature and get it to truly done.
Behaviour Driven Development (BDD) - Many people think that BDD is a technical practice that automates acceptance tests. That is a side effect. The primary benefit to BDD is communication and collaboration. Getting 3–4 diverse people (often Analysis, Development, and Test) to sit down and agree on detailed acceptance criteria with examples, is a deep form of collaboration. When done, all the people who are at the table have a deep understanding of the feature.

Specific actions that help improve collaboration:

Create Psychological Safety - In environments where people feel unsafe about experimenting or trying things, it is difficult to collaborate. Before trying the rest of the items on this list, if there isn’t psychological safety, work on establishing it.
Have a Common Goal (aka Product Vision) - Without team members having a deep and shared understanding of the goal they’re attempting to achieve, they will not form a true team and collaboration won’t happen. If we believe that working independently will get the job done, by default human nature, we’ll usually choose to work alone.
Set Goals Collaboratively - Set (or create) all goals within the team: Vision, Product Goal, Strategy, Sprint Goals, and especially User Stories collaboratively. This puts the emphasis on collaboration as a default model.
Limit Work In Progress - This should naturally invite people to collaborate. Once the limit is hit, team members should be asking themselves where they can help others out.
Run a Cross-skilling Exercise - As the team inventories their skills and see where they can learn from one another, they will collaborate to share the knowledge.
Retrospectives - Appreciative Inquiry (AI) – This takes the approach of finding what is best within the system. Instead of focusing on finding fault and fixing problems, Appreciative Inquiry wants to find the good and amplify it. From the Retromat you might ask questions like: “When was our collaboration at its best?” and “When did we do the best work with our Product Owner?” Having found the good, AI is often followed by an exercise to imagine a future positive state (“Remember the Future” is the classic example).
Model Behaviour - Don’t wait for collaboration to start happening on its own. Model the behaviour you would like from other people. Invite people to pair program with you. When you see other examples of collaboration, ask them what worked and then comment on it out loud.
Make Collaboration Intentional - Consider incorporating collaboration into the team’s Working Agreements.
Improve Communication - Collaboration can’t happen without a clear understanding of what is happening in the team. Make it explicit what should be communicated through email, Slack, etc. One team I’ve worked with recently has a rule that anything that requires more than one email exchange immediately goes to a short Zoom meeting. Another team has set office hours, where each person sets aside two slots a week where they open a Zoom session and anyone can come by to chat.
Create Space for Experimentation - When the team runs experiments, acknowledge it. Celebrate both the successes and failures. Put emphasis on the learning, more than the outcome.
Map Workflow - Rather than expect collaboration to happen magically, get the team to map the flow of work. Then invite them to find ways to reduce handoffs. Invite them to find opportunities to run experiments.
Make it Visible - Having mapped the workflow, make it easily visible using a Sprint Backlog or Kanban board.
Reduce Communication Bottlenecks - James Shore has an exercise where team members, including Customer/Product Owner, spend time learning what information they need from each other, and then working out how to reduce the time it takes to get/provide the information. This is a more involved exercise than others, and it provides a model to improve both communication and collaboration between parties with limited understanding of each other.

When does collaboration not work?

There are rare cases where collaboration isn’t possible:

People on the team have skills far enough apart that don’t share a common language. To my surprise, I have had one client overcome this barrier. They had designers/artists on the same team as metal workers. The distance in their skill areas was far enough apart that they didn’t really have a common language. Yet, over the course of months, they created a common language.
Legal boundaries exist that block people in one area from working closely with another.
No overlapping time when people on the same team are located far enough apart that they don’t have any business hours where they can work together.

It saddens me to hear of the low levels of collaboration most teams have. It’s time to break down the virtual zoom barriers (or climb over the cubicle walls if you’re back at the office). We need to help our teams understand what real collaboration is and then coach them to get there. Cooperation alone will not build the high performance teams we all aim for.

Collaboration is easier when teams are stable and members have had time to build trust. Growing T-shaped team members helps break down the role silos that keep people working in isolation, and clear group decision-making techniques give teams a reason to come together rather than defaulting to individual work.

Helping teams move from coordination to genuine collaboration is a central theme in our Certified ScrumMaster training. For ScrumMasters already working with teams and looking to deepen their coaching skills, our Advanced Certified ScrumMaster program focuses on sustained improvement over time.

Photo by Desola Lanre-Ologun on Unsplash

Scrum By Example - Waiting Too Long to Create Acceptance Criteria

Sun, 13 Jan 2013 00:00:00 GMT

Done image licensed from Photodune

The recent Backlog Refinement session helped split the upcoming User Stories.

The team was able to get from a very large Story: “As a first time book buyer I want to read a trustworthy review before I buy a book” to:

As a first time book buyer I would like to read a review so I can see if a book is worth reading.
As a first time book buyer I would like to see a star rating associated with a review so I can quickly assess if the book is even worth thinking about.
As a first time book buyer I would like to see reviews by staff members marked separately so that I know whom to trust.
As a first time book buyer I would like to see reviews by friends highlighted so that I know whom to trust.
As a staff member I would like to write a book review so that I can help customers choose great books.
As a staff member I would like to rate a book I’ve reviewed so I can give customers a quick guide.

We’re in better shape than we have been with previous Sprint Planning meetings but the team lacks concrete acceptance criteria.

Analysis

During the first half of a Planning meeting the team is trying to determine its goal for the Sprint. Specifically, it’s trying to answer the question, “What stories can we commit to?” To have a realistic commitment the team needs small Stories and a clear understanding of what they will look like when they’re done.

Story

Brad reads the first Story aloud, “As a first time book buyer I would like to read a review so I can see if a book is worth reading.” He sees an entire new web page, separate styling and a whole lot of infrastructure to support it. Doug, on the other hand, sees a small addition to each book page. He says that no new style sheets need to be developed. After a few more minutes of debate Product Owner Paula intervenes by saying that reviews will just live on the main page for now. In addition, each review must be under a thousand words and in plain text only.

Debate continues around each successive Story until two hours have passed; and the team is still unsure what they can commit to. ScrumMaster Steve has been doing his best to bring team members back to focus, but it’s been a struggle.

Analysis

The team is struggling because they don’t have clear acceptance criteria. As a result, they don’t agree on the size and can’t agree on what to commit to. They’re spending the Planning meeting focusing on the question of, “What are we trying to do?” as opposed to, “What should we be doing?”

Acceptance Criteria:

The goals of Acceptance Criteria are:

To clarify what the team should build (in code and automated tests) before they start work.
To ensure everyone has a common understanding of the problem.
To help the team members know when the Story is complete.
To help verify the Story via automated tests.

Creating good acceptance criteria is a collaborative effort. Usually, they’re created by the Product Owner working with several other team members. When created in isolation they fail to meet the first two values.

In addition when we create them a few days before the Sprint Planning meeting, team members have time to consider just what they mean, how they fit the product and what is missing.

Let’s wind the clock back for the team to three days before our Sprint Planning meeting.

Story

Paula asks Ian, Brad and Tonia to come spend half an hour with her. Their goal is to hammer out the acceptance criteria for each Story that might be committed for the next Sprint.

At the end of their white-boarding session they’ve got very rough sketches for the first three Stories that clearly limit their scope. In addition there are also textual criteria:

As a first time book buyer I would like to see a star rating associated with a review so I can quickly assess if the book is even worth thinking about.
- Rating from 0 to 5
- No ½ stars
- It appears at the top of the review
As a first time book buyer I would like to see reviews by staff members marked separately so that I know whom to trust.
- The word “Staff” appears in bold before the reviewer’s name.
- All reviews posted from computers inside the Smallestonlinebookstore offices will be considered as staff reviews. (This avoids having to tag users as having different roles for now).

A few days later during the Sprint Planning meeting, the team spends far less time debating and manages to get to commit to their Stories within the first hour vs. their traditional two or more hours.

When do you write your Acceptance Criteria?

Scrum by Example is a narrative-style blog series designed to help people new to Scrum, especially new ScrumMasters. If you are new to the series, we recommend you check out the introduction to learn more about the series and discover other helpful articles.

Images via: https://photodune.net/

Creativity for Agile Teams

Thu, 23 Nov 2017 00:00:00 GMT

Crayons image licensed from Photodune

There are many ways to redefine a work environment to support greater creativity that have been discovered through experience, experimentation, and accident. At the same time, modern neuroscience suggests guidelines for deliberately designing conditions to enhance creativity, using our best understanding of how our brains work, learn, integrate, and create.

How do we support, enable, and enhance the creative abilities of Agile teams?

Creativity can manifest in a variety of ways, including the creation of something new, refinement of something that already exists, and problem-solving. While creativity is traditionally thought of as a solo activity, many human endeavours also leverage the creative power of groups. Agile emphasizes group creativity to produce better products in shorter time frames.

I gave a presentation on this subject at the GOAT17 Conference, offering a summary of the literature and our experiences, which describes and demonstrates how creativity can be enhanced by providing a safe, nurturing environment. Doing so often has the added benefits of enhancing group interactions, more appropriately pacing activities that utilize different sensory modes, and increasing collective trust in the power of subconscious integration.

The following are my downloadable materials from my presentation. The PDF itself is a general, but limited, resource so I strongly recommend that it be used in tandem with the much more valuable handout.

Creativity For Agile Teams – Mark Levison and Roger Brown

Creativity for Agile Teams handout

We hope that this material helps provide the foundation and encouragement for your own team. Please share in the comments or on the Agile Pain Relief Consulting Facebook page some of the fun ways that your team fosters creativity and agility!

(Crayons image licensed from Photodune)

Scrum by Example – Feeling Pain from Your Daily Scrum?

Tue, 24 Jul 2018 00:00:00 GMT

Banner image of distracted team members not effectively communicating with each other

Dramatis Personae

Steve: A scrumMaster and the hero of our story

Michael – another ScrumMaster for a different team

Doug, Fred and James – a members of Steve’s team James

Paula: The Product Owner of Steve’s team

Steve and the team are starting to reduce the rate of production support interruptions. The team is starting to collaborate more, but Steve notices that team members are still sometimes surprised by what others are doing. Wasn’t that what their Daily Scrum (also known as Daily Scrum Meeting or Daily Standup) was supposed to inform them on? Steve goes back and checks his trusty Scrum Sources:

Daily Scrum should happen first thing in the morning.
Team members answer three questions: What did you do yesterday? What will you do today? What are your obstacles?
The ScrumMaster runs the meeting.
Daily Scrum is held with all participants standing.
Daily Scrum should last no more than 15 minutes.

It is easy to lose sight of what Daily Scrum is for

As far as Steve can tell, the team is doing all these things. Unsure of what to do, he calls his friend Michael, a ScrumMaster for another team, and asks him to come and watch the team’s Daily Scrum.

At 9:15 am, Steve walks around to everyone’s desk and reminds them it is time for Daily Scrum. At the start, he assembles everyone in front of the team’s Sprint Backlog, then reiterates the three Daily Scrum questions and directs each team member to answer them. Often, the answers include ticket/bug tracker numbers. After many of these answers, the team breaks into discussion on how to solve the problem(s) identified. When that happens, some team members play with their phones and don’t pay attention. Steve, as ScrumMaster, tries to rein discussion in and re-engage everyone with the meeting. He notices Doug stroll in 10 minutes after Daily Scrum has started and doesn’t acknowledge this as a problem. As well, James is working from home, so has phoned in to Daily Scrum, but other team members aren’t paying much attention to the speaker phone. Steve shares with Michael later that neither issue is new, but have been persistent problems for at least the last week.

Michael attends Steve’s Daily Scrum, observing quietly in the background. He comes back and attends each Daily Scrum for several days to get a true sense of what is going on. Beyond what Steve has told him about the above issues, he also notices:

James often couldn’t hear what was going on;
Several team members checked in only long enough to give their reports, then returned to their phones;
Fred would often give so much technical detail in his report that most of the team nodded off after the first minute, especially Product Owner Paula, who couldn’t understand anything Fred was saying;
The whole thing would often last over 20 minutes daily, due to the lengthy discussion and problem-solving that surrounded each update; and,
Most team members couldn’t tell if the team was on track to meet the Sprint Goal.

Michael asks the team what they think the purpose of Daily Scrum is, but there isn’t a clear consensus: some think it is for reporting to management (through the ScrumMaster), others think it is to help Steve resolve their impediments.

Dysfunction in the Daily Scrum

Michael sits down with Steve and talks about the things he noticed:

In directing the team, Steve was missing the chance to engender self-organization and ,instead, was implicitly giving team members permission to disengage. Also, the team members don’t all understand the true purpose of Daily Scrum:
- To self-organize and coordinate work among team members
- To check their progress toward the Sprint goal
- Discover what, if anything, is impeding their ability to meet the Sprint goal
The team doesn’t understand that Daily Scrum is intended for their own benefit as team members, not as a management reporting tool.
Stuck on the phone, James was never an effective participant, since the team made no effort to ensure his voice was heard, nor did they ensure he could hear them.
Discussion around each update isn’t supposed to be part of Daily Scrum.
Fred needs to understand most of his audience will get lost if he goes into too much technical detail.

Image of four team members effectively communicating with each other as part of their daily scrum

The Purpose of Daily Scrum:

❖ to coordinate among team members ❖ to check progress towards the Sprint goal ❖ to discover obstacles that the team faces

Daily Scrum = Active Listening

Daily Scrum is all about active-focused listening – taking the time to understand what team members are saying, as opposed to focusing on what it is you will say in your own update. Active listening is hard to do well and doesn’t come naturally to most of us, but is an essential part of succeeding with Scrum. The good news is, with some help and practice, anyone can become great at active listening.

Michael suggests to Steve that he focus his efforts on promoting active listening within the team. To do this, he suggests Steve:

Explain and emphasize to the team members the purpose of Daily Scrum.
Step back from trying to direct Daily Scrum and let the meeting run itself – act as a facilitator instead of a manager.
Remind team members that discussion should wait until after Daily Scrum, allowing those who are not interested in a specific issue to return to their work.
Improve the Daily Scrum questions by changing from what team members “did”/“will do” to “what did you complete?”/“what will you complete?”

Mark’s Note: I prefer the word “complete” because it puts the emphasis on completing small pieces of work daily. Clearly, some days you will complete one thing and start another. It helps avoid the problem of a team member saying “I worked on XXX” three days running. In addition, this “complete” isn’t a stay-late commitment but a best-efforts commitment.

Help team members empty their minds by suggesting that they write down notes before Daily Scrum, readying their minds to listen instead of worrying about what they’re going to say when their turn comes. These notes can be short – even just a couple of words reminding themselves of what needs to be said.
Encourage team members to limit note-taking to the names of who they want/need to talk to after Daily Scrum. It is impossible to be actively listening if you’re writing notes.
Warm up with any activity that forces the team members to focus. It can be as simple as passing a football from person to person (in random order), to more complex “Improv” activities. The key is to find a variety of activities that require focus and engagement from the team.
Engage remote team members and ensure they’re kept front and center. This can be as simple as moving the phone to the centre of the team or as complex as creating a puppet of the absentees to remind the group of their presence in the discussion.
Communicate that Lateness on a regular basis is disrespectful to the team and sends the message that one individual’s needs are more important than those of the whole. A ScrumMaster should investigate when a team member is habitually late, as there may be an unrevealed valid reason, and either find a way to move the Daily Scrum to accommodate those needs or help the individual understand the importance of arriving on time.
Practice privately just before Daily Scrum with team members who need help. E.g. Fred might need help to find the right level of appropriate detail; another team member may need support to raise their voice.

Summary

Steve takes Michael’s advice to heart and implements his suggestions. After only a week, he finds a noticeable improvement. Team members have a much more effective Daily Scrum, which now lasts around 15 minutes, and are much more knowledgeable and aware of what others are working on. A few weeks later, collaboration starts to noticeably improve.

By keeping these principles front-of-mind and guiding their team toward them, ScrumMasters everywhere will be well on their way to facilitating successful Daily Scrums.

Daily Stand-up Variations

Fri, 21 Jan 2011 00:00:00 GMT

business people - image licensed from Photodune

For a comprehensive look at what makes Daily Scrum work (and what doesn’t), see The Modern Guide to the Daily Scrum Meeting. This post focuses on one specific variation: adding habit-building questions.

When trying to instill a new habit with a team I often find it useful to add a new question (or two) to the daily standup. Perhaps the team needs to pay more attention to Code Smells or Unit Testing. In those cases I ask team members to mention one thing they discovered (or better improved) related to that idea during standup everyday. My goal is to make spotting these issues a daily habit, even when they can’t be fixed right mentioning them raises awareness. Non-coders please reinterpret questions 4 and 5 in your own context.

As a reminder here are the updated questions:

What did you complete yesterday?
What do you commit to today?
What are your impediments/obstacles?
What Code Smell/Missing Unit Test/… did you spot yesterday?
What improvement did you make to the code yesterday?

Even with the extra 2 questions teams should easily finish their stand-ups in fifteen minutes or less. I recommend that discussion be left until after the stand-up so people who’re not interested can sit down.

An additional trick I saw someone at my client us: pass the questions round on a piece of paper. You don’t need to read them but just holding the piece of paper is good reminder and helps people remain focused.

Image via: https://photodune.net/

Scrum by Example – How to Deal with Bad User Stories as a ScrumMaster

Wed, 16 Jan 2019 00:00:00 GMT

It is common in the early stages of Scrum implementation for there to be misunderstandings about what User Stories are for and what makes them useful. A ScrumMaster’s task is to be able to help the Team and Product Owner when they are faced with ineffective User Stories as they go into Sprint Planning.

Dramatis Personae

Steve: A scrumMaster and the hero of our story

Paula: The Product Owner of Steve’s team

A Bad User Story Helps No One

Scrum By Example – How to Deal with Bad User Stories as a ScrumMaster

Steve is preparing for tomorrow’s Sprint Planning session. He asks Paula to show him the Product Backlog and she sends him a spreadsheet. Besides how difficult it is to read anything in this format, he’s shocked by how poorly the User Stories are formulated:

As a user, I want to search Smallestonlinebookstore.com to find some books
As a user, I want to buy the book that I’m currently looking at
As a user, I want to search using the author’s first and last name fields along with the title field
And so on…

Reading through, he also realizes that the Development Team hasn’t seen these stories or discussed them with the Product Owner yet.

Steve panics; the team can’t possibly have a Sprint Planning meeting tomorrow if they have never seen the User Stories at the top of the Product Backlog.

A Good User Story Is All About Users’ WHY

There are three central problems with the kind of User Stories you see above:

1. No Clear Why

A User Story is essentially the outcome of a conversation the team has with themselves and the Product Owner, in which the Product Owner explains the context for a desired product feature and what kind of value it is meant to give the user. This should be followed by a discussion about how to best deliver that value.

A User Story clearly identifies what feature is wanted and why it would be of value.

Paula’s User Stories identify a user and the desired features, but lack any explanation of how these features benefit the user – the essential reason WHY the feature is necessary in the first place.

This is critical because a good “why statement” is important not only for effective prioritization of the Product Backlog, but it also helps the team consider different approaches beyond the original intention.

As an example, take the first User Story: “As a user, I want to search Smallestonlinebookstore.com to find some books.” Conventionally, a User Story like this should have a “so that” clause at the end, explaining why. So, as a step towards making this a good User Story, we can begin with adding to it:

As a user, I want to search Smallestonlinebookstore.com to find some books so that I can save time by quickly locating what I am looking for.

In this instance, the Product Owner and the Team have determined that the speed at which a user could find a specific book is important, explaining why the search feature is needed and what benefit it provides. This User Story still isn’t complete, but this could be a good place to start a conversation between the Product Owner and the Team about the feature.

2. Too Broad and Generic to be Useful

The above User Stories are all much too broad to be implemented effectively. This is evidenced by a total lack of descriptors of either the feature or the user. Who exactly is the user in any of the stories? Are they all the same user? Are they all different? In the case of “As a user, I want to buy the book that I’m currently looking at,” how might they want to buy that book? Perhaps a one-click buy and delivery system? Do they want it as a paperback, trade paperback, hardcover, e-book? We don’t know.

User Stories that can be interpreted in all kinds of different ways are not useful. If you attempt to proceed with working on a Story likes this, it would be unsurprising if miscommunication were to happen, resulting in neither the Product Owner nor the customer having their expectations met by your product.

In order for a User Story to be useful, it must be specific and focused.

To be specific and focused, a good User Story needs to have a few characteristics:

It must have a clearly defined user or persona (e.g. frequent book buyer; guest).
It should be specific to the user’s context and the benefit they desire.
It should be clear what the user wants to achieve.
To ensure it can be completed within the Sprint, a single Story should be restricted to what can be completed in 2-3 days by the Team.

To improve further on the “save time by quickly locating…” User Story in Problem 1 and make it specific and focused, additional details need to be added:

As a frequent book buyer, I want to search Smallestonlinebookstore.com to find a book using the author’s full name so that I can save time by quickly locating more titles by the author I just finished reading. (3 Story Points)

Now the User Story tells us something about the nature of the specific user, what kind of outcome they want from the feature, and details about why speed is a desirable benefit for them. It also now has a points estimate associated with it, indicating how much work this story will be for the Team.

3. No Conversation with the Team

Perhaps the most serious problem with Paula’s User Stories is that they have all been written by her, the Product Owner, in isolation. How can the Development Team effectively plan the next Sprint if they haven’t yet seen, let alone discussed, the most important User Stories with the Product Owner?

A User Story expresses the clear, shared understanding between the Product Owner and Development Team of what they will be building and why.

Remember: A real User Story is one that comes from a conversation between the Team who will do the work and the Product Owner who is responsible for the vision for the product based on customers’ desired outcomes. Since the Team has never seen these items before Sprint Planning, they categorically can’t be real User Stories. It also means that if there were any Story Point estimates attached to these Stories as to how much can be accomplished in one Sprint, they aren’t going to be meaningful because only the Team can estimate the amount of work needed to complete a feature.

The Right Way to Create User Stories

Before a specific feature is ever built, there should be a discussion between Product Owner and the Team about what the user expects the feature to do and why it’s wanted. The understanding generated by this discussion is then written down as a User Story. Ideally, the conversation should focus on what problem the user wants the feature to solve. This process is the core of Product Backlog Refinement.

What To Do When You’re Faced with Bad User Stories

So what options does Steve have as he sees unclear and unspecific User Stories that the Development Team have never seen, let alone discussed, on the Product Backlog for tomorrow’s Sprint Planning session?

He could work the rest of the day with Paula to rewrite and split the stories, although this still won’t engage the team and get accurate estimates on each User Story. This also sets a bad precedent of having to work overtime.
He could cancel the Sprint Planning session and delay the start of the Sprint on the basis that the backlog is not ready to be used in planning. While this isn’t the worst course of action, especially given that Paula is new to Scrum and is trying to do the right thing, cancelling Spring Planning at such an early stage in Scrum implementation tends to send an extremely strong negative signal to everyone, especially senior management.
He could turn tomorrow’s Sprint Planning meeting into a Product Refinement session, allowing Paula and the team to collaboratively rewrite and estimate the Stories. Once that is done, they could then proceed with a Sprint Planning meeting.

Steve suspects that the last option – backlog refinement followed by Sprint planning - is the best course of action, but he wisely chooses to first do what is almost always the best thing a ScrumMaster can do when faced with a difficult decision: ask the Team.

Steve sits down with Paula and the Team to discuss the challenges that he sees.

He focuses not on the mistakes made, but instead on the Product Backlog and what makes a good User Story;
He explains the current state of things to both Paula and the Team. Given that the meeting is the next day, he asks the team what options they see, describing all the options he thinks they have, and then finally,
He asks the Team to decide what the best course of action is.

These actions demonstrate that Steve is focused on helping grow the autonomous decision-making capacity of the Team, while facilitating better communication between them and the Product Owner. Even if they make what Steve believes to be a less-than-optimal choice, they will get the critical opportunity to learn from any mistakes they make and grow from them. At the end of the day, this is what being a great ScrumMaster is all about.

The Team agrees that the next day should be devoted to doing Product Backlog Refinement, with the formal Sprint Planning following shortly afterward. Armed with an accurate and effective backlog, the Team proceeds with their Sprint.

Are You Ready To Transition To Scrum?

What other options did you consider for Steve? What do you think he could have done differently? Being a great ScrumMaster requires more than just knowing what a User Story is. To develop the communication techniques and diplomacy that will help you deal with the real-life challenges of Scrum like this one, consider joining one of our Certified ScrumMaster workshops, where you will get the chance to both learn and get hands-on experience helping Teams and Product Owners write effective User Stories.

Image attribution: Agile Pain Relief Consulting

Definition of Done vs. User Stories vs. Acceptance Criteria

Tue, 10 Dec 2019 00:00:00 GMT

Definition of Done vs. User Stories vs. Acceptance Criteria

One of the more frequently asked questions in my Scrum workshops is around the difference between Definition of “Done” and Acceptance Criteria, and how they relate to User Stories.

While Acceptance Criteria is a commonly understood concept in software development, Definition of “Done” is unique to Scrum. People get confused between these two things but they’re distinctly different, and it’s important to know how to tell them apart so they can be used effectively. This post will help you better understand each, as well as User Stories, and their unique roles and relationships with each other in the context of Scrum.

Since both Definition of “Done” and Acceptance Criteria apply to User Stories, let’s make sure that we understand User Stories first.

User Stories

A User Story is a tool to move the focus from What we’re building (what often happens with traditional requirements) to Why and Who. It’s intended to start a conversation between the people who will implement the Story and the Product Owner, with the goal of ensuring the Team solves the underlying business problem instead of just delivering a requirement.

User Story slices

The goals of a User Story are:

to focus on the business problem that needs to be solved, not the solution to that problem.
to start a conversation about why a problem needs solving, who needs it, and what problem to solve.
to demonstrate a need in as concise and simple a form as possible.
to be a small, vertical slice of functionality – if we were making a cake, this is something that goes through all the layers – as opposed to delivering only the icing. In technical terms: through the entire system, not a description of the component layers or technical need (as illustrated by the picture). Traditional approaches often describe work to be done in technical layers (e.g. Business Logic or Database). This leads to waste in the form of Over Production. User Stories avoid this waste by challenging teams to build only the pieces in each layer required at that moment.

A User Story is an invitation to a conversation.

Since User Stories are not official Scrum tools, there is no required format, but a common structure is “As a <role> I want <to do> so that <value>”.

The three components of User Stories, often referred to as the three C’s, are:

• Conversations: Conversations that discuss the Story details and result in creating the acceptance criteria.

• Confirmations: Acceptance criteria that, in software, can be turned into automated acceptance tests. These automated tests enable the simple and light approach implemented by the other two C’s.

• Card: A token (with a Story title/description, traditionally written on a small paper card or sticky note), used for planning and acts as a reminder to have conversations.

Here is an example of User Stories for an imaginary Point-of-Sale system. The user is denoted as a Buyer.

As a buyer, I want to pay by tapping my debit card so that I spend less time in the checkout process.

As a buyer, I want to be able to enter my pin code when transactions are over $100 so that I know that I’m secure if my card is stolen.

As a merchant, I want debit cards to be checked to ensure that they’re valid so I don’t lose money by accepting invalid cards.

Each User Story (sometimes called a Product Backlog Item or PBI) and its associated Acceptance Criteria (we’ll cover them last) are then checked against the Definition of “Done” to ensure correctness and completeness.

Definition of “Done”

The Scrum Guide, in a way that is maddeningly vague, says that:

When a Product Backlog item or an Increment is described as ‘Done’, everyone must understand what ‘Done’ means.

I promise you, that sentence and the paragraphs that follow are the most poorly understood aspects of the Scrum Guide. Some Team members will assume “Done” means it works on their machine. Others will believe it means they throw their work over the wall to Quality Assurance or Test. Still others will assume that “Done” is limited to checking in working code. Since the Scrum Guide is so vague, Teams need to establish their own shared understanding of what they will call “Done,” and put it in writing so it’s clear.

That’s why the Definition of “Done” exists: to ensure that the members of the Development Team and the Product Owner (PO) agree about the quality and completeness of the work they’re producing. Used effectively, the PO will know that, if the Team can show that they have met the list of conditions of “Done,” then the PO can safely deliver the product to the client.

This is intended to be applicable to all items in the Product Backlog, not just an individual User Story.

Here is an example of a simplified Definition of “Done” from the World’s Smallest Online Bookstore that we use as a model in our Scrum by Example series:

Here’s the content as a list instead of a table:

Whenever changes are made to existing code, a Unit Test is written to cover that method
Usability Review Completed
Tested on iPad, iPhone and Android Phone
Performance Tests run
Code Peer Reviewed (if not written using Pair Programming)
End-User Documentation has been updated

The Definition of “Done” is different from Acceptance Criteria because “Done” doesn’t change from one User Story to the next, while the Acceptance Criteria is written specifically and uniquely for each individual feature or User Story. It also differs in that it has a formal Scrum definition, whereas Scrum doesn’t require either User Stories or Acceptance Criteria to be used.

To summarize, the goals of “Done” are:

to build a common understanding within the Team about quality and completeness.
for that understanding of “Done” to include the Product Owner.
to be a checklist that User Stories are checked against.
to ensure the increment shipped at the end of the Sprint has high quality and that the quality is well understood by all involved.

Definition of Done vs. User Stories vs. Acceptance Criteria

Acceptance Criteria

While a User Story is deliberately vague to allow the Team freedom to decide the precise details of how something will be built, Acceptance Criteria are the precise details. They are unique to each User Story. (For more details on how and when the Acceptance Criteria are discovered see: the Lifecycle of a User Story and Acceptance criteria)

The goals of Acceptance Criteria are:

to clarify what the Team should build before they start work.
to ensure everyone has a common understanding of the problem.
to help Team members know when they should cease work on a Story. This is distinct from “Done” because they may have met the acceptance criteria but not checked everything against “Done.”
to help verify the Story via automated tests.

An example of Acceptance Criteria:

This User Story:

As a buyer, I want to pay by tapping my debit card so that I spend less time in the checkout process.

results in the following Acceptance Criteria:

Tap limit is $100 Tap not allowed under $10 Linked account is checked to ensure the balance is sufficient

The trouble with Acceptance Criteria written in a plain English format, as above, is that they’re full of ambiguity. So, a popular approach to describing Acceptance Criteria is “Specification By Example”, also known as Behaviour Driven Development (BDD) or Acceptance Test-Driven Development (ATDD).

User Story: Tap Credit Card Acceptance Criteria:

Here’s the HTML table converted to markdown format:

Sale Amount	Bank Balance	Expected Result	Expected Message
$0.00	$99.00	Fail	No purchase
$9.99	$99.00	Fail	Below minimum threshold for tap
$10.00	$99.00	Pass
$90.01	$90.00	Fail	Purchase over the amount of money in the account
$100.00	$100.00	Pass
$100.01	$200.00	Fail	**ç

Conclusion

Definition of “Done” is the global requirement 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.

Your Guide to Demystifying Scrum

People using Agile and Scrum sometimes throw around terms and phrases and assume everyone listening understands what they mean. This is not only problematic – a kind of gatekeeping against people new to the field and/or not from a software background - but it does little to help people find new solutions for their challenges.

Agile Pain Relief is committed to helping new Scrum professionals who want to learn the language of Scrum and become confident knowing what’s what, so you can focus on helping teams become the most effective they can be. If you share this view, we invite you to join us for our Certified ScrumMaster courses across Canada.

Image attribution: Agile Pain Relief Consulting

4 December 2019: Updated for 2019 from 2017

Do You Suspect You Have a Less than Productive Person on Your Team?

Wed, 07 Jan 2009 00:00:00 GMT

typewriter - image licensed from Photodune

In the past couple of days on the Scrum Development mailing list an interesting thread has developed around what to do with a poor-performing team member.

Too my mind there have been a number of key takeaways:

Be very careful about the language you use: Strong language implies prejudice and assumptions.
Reset use a Beginner’s Mind.
Does the team perceive this to be a problem?
Possible causes of this perception.
Measuring Individuals doesn’t work (nor does measuring teams, but that’s a different topic).

If it is a real problem how to handle it.

Your Perception

Strong language like “Rotten Apple” “Ruins the team""drag on productivity” etc. imply that you’re already convinced the person is the problem. Unfortunately, this can just be prejudice. Linda Rising, author of “Fearless Change: Patterns for Introducing New Ideas”, notes that people will categorize or stereotype other people in a very short period of time.

“In many cases, a supervisor “determines” the ability of a worker in about three weeks, labelling them as either “can do” or “can’t do” workers. Once a prejudice has been formed, the supervisor views all the actions of that worker through this filter. If two workers make the same mistake, in the case of the “Can’t do” worker, the supervisor will think, “There he/she goes again, making the same mistakes,” while in the case of the “Can do” worker the supervisor will think, “Maybe he/she wasn’t feeling well.” Eventually, the supervisor can only recognize actions that affirm their prejudice.”

In such a case like this consider using Beginners Mind (courtesy of Jean Tabaka and David Hussman). Let go of the outcome, take a stepback, ask why not how, bring silence listen, and observe. The key is finding a way to let go of previous conceptions and reexamine the situation from scratch.How is this person working?

Team’s Perception

Remember the Star Wars quote (thanks to Paul Hudson):

Obi-Wan Kenobi: So what I told you was true, from a certain point of view.

Luke Skywalker: [incredulously] A certain point of view?

Obi-Wan Kenobi: Luke, you will find that many of the truths we cling to depend greatly on our own point of view

Does the team see the problem? Do they work with this person or avoid them?Are they making jokes about the situation? Behind the person’s back? Is thisperson included in lunch, coffee breaks, and water cooler conversation? Has the team raised the issue in retrospective? If the team doesn’t perceive a problem,then maybe they see the situation differently than you do.

Possible Causes

Assuming there is a productivity issue, examine what they’re doing and see what the possible might be:

Personal problems at home (new kid, divorce, family member is sick, …)
Maybe they underestimate tasks.
Maybe they’re very careful and leave no loose ends behind.
Perhaps they act as glue for the team, holding the team together by communicating ideas and solving little problems. All the stuff that goes unnoticed but really does matter.
Maybe they’re just slow by nature
Maybe this person knows much less about the problem domain, technology etc than anyone else does.
Maybe they’re bored, and this will come out in your one-on-one’s (see below).
Maybe they really are a slacker.

Measuring Productivity

We also hit the problem of measuring the individual’s performance by using the number of story points they completed during the iteration. This was a troublesome topic for any number of reasons:

Measures of people are entirely subjective
No meaningful way to measure productivity or even skills
Measures like this are too easily gamed
It doesn’t take into account anytime the person may have spent pairing, studying, removing impediments etc.

Possible Solutions to the problem (if it really exists):

Pair with the person yourself. It will give you a much better idea of how they work.
Have a one on one with this person (if you’re not already doing it, then make it a team wide habit first so that you’re not seen as singling the person out). Ask them how they perceive their own productivity. Maybe they do things, that you don’t see.
Put together a plan to solve issues that both of you can agree on.
If none of this works ask the person what they want. Maybe the person feels out of place on the team.
Consider letting someone go only after all avenues have been exhausted. Whenthis happens, I consider that I have failed.

So before we rush off to action:

Stop, let go of preconceptions
Re-examine the person’s role on the team
Listen/Watch - don’t measure
Only if there is a problem - then solve it.

The dynamics described here are deeply connected to team stability and composition. For context on why reshuffling team members creates exactly these kinds of perception problems, see Why Stable Teams Matter. And when productivity concerns do surface, Working Agreements give teams a structured way to address friction without singling individuals out.

For a great deal more on this and related topics you might like a book by Johanna Rothmann and Esther Derby: Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers).

Caveat Emptor - if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

Image via: https://photodune.net/

Does Scrum Work? Hell Yes!!! Why

Wed, 27 Jun 2007 00:00:00 GMT

Rugby match - image licensed from Photodune

This is the second post in a series (thanks Mishkin for hosting the opener_)_ – that discusses: Why does Scrum work? Why do any of the Agile Project Management methodology work? Final part here.

Teams

At the core of any successful development project is a team. The team can either work together as a group of individuals or as a high performance team. A high performance team is one that has a track record of both delivering high quality software and meets or exceeds their iteration commitments.

Nothing can guarantee the creation of high performance teams. The best you can do is put in place the conditions that will help them form.

Characteristics of High Performance teams

From “The Wisdom of Teams” by Katzenbach and Smith (Thanks to Mishkin Berteig for introducing me to this book):

Small number of people with complementary skills.
Committed to a common purpose
Have a specific and challenging performance goal.
Committed to a common approach which
- Requires all team members to contribute equally
- Demands open interaction
- Uses Fact based problem solving
- Uses results based evaluation
- Provides for modification and improvement over time
- Seeks fresh input and perspectives systematically from outside the team
Mutual Accountability.

In addition as high performance teams form they find a sense of commitment to one and other – often a sense that transcends the boundaries of work.

How does Scrum help?

Through Events Artifacts and People. Let’s examine how these elements contribute to building high performance teams.

Events

Planning

Basics: At the start of every iteration the team gets together to discuss the goals (also called Stories) with the product owner. The team breaks down the stories into tasks and estimates the size of each task.

Values supported:

We forge a specific performance goal for the team with the participation of the entire team.
Use fact based problem solving to break the stories down into appropriate tasks.
Gets team members to make a public commitment (“Influence: Science and Practice” by Cialdini - Chapter 3 Commitment and Consistency)

Daily Scrum

Basics: Once a day (preferably near the start of the day) the team gets together to answer three questions: What did you yesterday? What will you today? What obstacles are in our way? (With a Modern Daily Scrum many teams have abandoned those questions.)

Values supported:

Keeps individuals focused by providing a daily reminder of what’s valuable to the team. It becomes the heartbeat of the team.
Keeps everyone on the team in touch with what other team members are doing – which helps cross pollination and also demonstrate that all team members are participating equally.
Problems discovered are solved offline – promoting both fact based problem solving and a greater reliance on your teammates. According to Karl Weick (author of “Managing the Unexpected: Assuring High Performance in an Age of Complexity”), surfacing problems is one of the biggest issues that organizations and groups face.
Encourages team members to talk to each other a habit which usually extends beyond the daily scrum. Result: problems are solved more quickly and a better quality of architecture evolves.
By talking about what we intend to accomplish we’re making a form of public commitment which helps motivate us (“Influence: Science and Practice” by Cialdini - Chapter 3 Commitment and Consistency). Yes this effectively a form of social pressure.

Review and Retrospective

Basics: At the iteration end review meeting the Product Owner demonstrates the product (new features and old) in front of all the stakeholders (team members and interested outsiders). After the demo the team discusses what went well and what poorly during the iteration with the intention of improving the next one.

Values Supported:

The demo by the product owner is a form of Results based evaluation, they get to see the value they requested working.
Mutual Accountability: The public demo in front of the team emphasizes the fact we succeed or fail as a team not as individuals,
In discussing how to improve, we’re engaging in fact based problem solving and it reinforces the point, that the team owns and is responsible for the process.
Inspect and Adapt – the entire purpose of the retrospective

The final part is posted here.

Image via: https://photodune.net/

Does Your Grocery Store Limit Work in Progress?

Wed, 04 May 2011 00:00:00 GMT

Grocery store - image licensed from Photodune

Shopping in our local Grocery Store (Farm Boy) on a recent Saturday made me realize what a good job they do Limiting Work in Progress (WIP) and Self Organizing. Driving into the parking lot with my 4yr old, I was dreading the busyness of the store. When I got in, the place was packed, and trying to manoeuvre even a small cart with a 4yr old driving was quite the experience. I had expected the checkout experience to be easily 10 minutes long, an eternity even with the best behaved child.

When I entered the store there were only a few people on cash and the lines seemed to be building. By the time we were ready to checkout half an hour later, all 9 cashes were open and we waited less than two minutes.

What happened? A couple of conversations with cashiers have helped me piece together the key points:

They all recognize that Farm Boy doesn’t make money until you’ve paid – a Customer with unpaid groceries is Work In Progress. After all if you only have a few items and see a 10 minute line up you might just leave. Especially if the 1-8 items queue is also deep.
If there is a line up, cashiers just start opening lanes until the bottle neck is cleared
Many of the staff can work the cash, so you’re rarely stuck waiting for another cashier
Staff don’t wait to be told to open cashes they just do it
When demand ebbs, the cashiers start to close and return to other work

So effectively they’ve seemed to discovered the Theory of Constraints (TOC) and they Self-Organize to eliminate the bottleneck. Their system is informal, but even without sophisticated measurements you can still observe and eliminate bottlenecks. Compare this to another large Canadian grocery chain where I often line up for 10+ minutes, just waiting to get to the front of the line. Guess which store gets more of my business?

In the software world, QA, especially when all the tests are run manually, is often the constraint we find. So we need to take steps to eliminate the bottleneck:

Automate your Regression Tests, so that you have a minimal (if any) manual regression work to do
Train everyone on the team in the basic of QA
When work builds up in QA, cease writing new code until the existing code has been tested and the tests automated
Start write your application using Acceptance Test Driven Development

Eventually QA stops being the bottleneck, at which point we re-examine the system to see if the bottleneck has moved again. When that happens, take similar steps all over again to eliminate the next bottleneck.

What bottlenecks have you observed in your grocery store? Your development process?

Another Theory of Constraints post: “Theory of Constraints in Software Development”

Image via: https://photodune.net/

Don't Inflict Scrum or Kanban on Teams

Thu, 25 Jan 2018 00:00:00 GMT

(This article is part of the Beyond Scrum series)

We’ve all experienced the pain of having someone impose a change on us – it doesn’t work.

Forcing change conflicts with the essential human need for autonomy – No one likes being told what to do (if they didn’t ask to be). Whichever model for understanding human behaviour you use¹²³, all of them recognize autonomy — to work in the way we see fit — as a central feature of human psychology. So when an organization imposes an approach to work, whether it be Scrum, Kanban, or another Agile framework, it is unsurprising that the result often is team members feel discouraged and resist adopting the change.

As your organization evolves to become more effective (remember, Agile is not the goal in and of itself) and you want your teams to follow and take ownership of the changes happening, instead of telling them, “we’re switching the whole organization to Scrum, Kanban, or another flavour of Agile,” invite them to join you on the transformational journey.

Outstretched hand image designed by FreePik

Invite, Don’t Impose

Start with explaining the business need – what are the business goals and objectives you’re attempting to achieve and why. Frame it in terms of the required outcomes you are seeking.

As an example, you could start with, “The business needs working, integrated, tested product every two weeks that delights the customer. We don’t need the largest number of features, just ones that solve the customer problems.”

Explain there are two major approaches (and many supporting practices) that you believe would be suitable: Scrum and Kanban.

Scrum is focused on building high-performing teams who build great products.
Kanban improves the flow of work while building great products.
Any other approach that achieved the outcome “The business needs working, integrated, tested product every two weeks that delights the customer. ….”

In many cases, each approach can be used to complement and enhance the other. Help your teams understand that success with Scrum, Kanban, or other Agile comes in large part from their self-discipline, focus, courage, respect, and willingness to experiment continuously.

Choices Are Just Experiments

All choices that teams and organizations make are just a series of experiments. Each choice comes with a set of trade-offs. Instead of just picking one choice or another, explore both/all to gain a deeper understanding. Once you’ve made a choice, run an experiment to validate your learning. Whichever you select, keep on studying other, alternate approaches and borrow ideas from them.

You Can’t Impose Agile

Agile can’t be imposed on people and still be effective. Agile is a journey you invite your team to join you on, which includes being open to the possibility that your team may favour a framework that you had not previously considered. At the end of it though, your teams can confidently say that they participated in the decision and joined you on the journey. All our study so far has been in this vein.

a) Create the vision for the change b) Create a strategy for change c) Involve the team(s) doing the work of implementing your changes d) Focus on the outcome, i.e. the organizational benefit you seek to achieve, not on the individual practices e) Keep the team(s) involved in decisions around the change

Follow these easy steps and you won’t be inflicting anything onto teams, they’ll be embracing it.

(Hand image designed by Freepik)

Footnotes

Scrum by Example – Don't Let Sprint Review be a Missed Opportunity

Tue, 12 Oct 2021 00:00:00 GMT

Dramatis Personae

Steve: A scrumMaster and the hero of our story

Paula: The Product Owner of Steve’s team

When last we left our World’s Smallest Online Bookstore team, their Sprint was rocky. To have an effective Sprint Review story, let’s assume that they magically wound back the clock (shazam!) and implemented the changes. As a result, they had the more effective Sprint Planning that we discussed in the last blog post.

So let’s quickly recap that last episode. The team set “Have basic reader review system in place so book buyers can see a variety of opinions about a book” as their Sprint Goal. (They had a weak Goal initially but, after they magically went back in time and did things different, that was the improved result.)

They then selected the following Product Backlog Items:

Reader can add star ratings to a book
Reader can write a review of a book (plain text only)
Reader can add pictures to their reviews
When a review is written by someone who purchased the book through our store, the system highlights their review as a “verified buyer”
Registered site users can click a button to vote that a review is helpful
Reader can format the text of their review
Reviews feature the date they were written and the location of the author
They also planned to fix two bugs that affect how books are displayed to buyers.

The Sprint went surprisingly well. They finished the top five of seven items and fixed one bug. (By the standards of many teams this is remarkably good.) They are now ready to hold a Sprint Review.

Steve, being a well-organized ScrumMaster, has an agenda in place:

Remind the audience that the Sprint Review has a focus on the Product
Restate the Sprint Goal and review if it has been met
For each feature:
- Team members demonstrate the features they worked on
- Team checks features against the Definition of ‘Done’
- PO accepts or rejects an item¹
PO, Stakeholders, and Team members discuss the Product Backlog and the Product Map (often a Story Map or Impact Map)

Steve has invited all stakeholders to attend, which include the Team’s Director, and the Directors of Support and Marketing.

Illustration of Scrum team meeting with shareholders, with the Product Owner moderating discussion.

At the start of the Review, Steve reminds everyone of their Sprint Goal: “Have basic reader review system ….”.

Paula reports, “The team achieved the core of that goal, with a reader review system ready on staging server. All I have to do is press a button and the new version is live on the site.”

She then hands over the stage to team member Ian to start walking through the features that the team have built.

Director of Support Eric’s phone starts buzzing and he disappears into it, apologizing to the room. “Sorry, we have a problem with some users not being able to see their account order history.”

The first few features that Ian demonstrates garner almost no feedback except people saying vague things like “Good job” and “I like that”. There are no substantive questions or suggestions offered.

When Ian demonstrates the Product Backlog Item “Reviews from a verified buyer are highlighted and displayed above other reviews”, Paula asks a few questions about the behaviour of the feature. She also checks the Definition of Done and learns from the team it is Done except for testing the text-only book review in Safari on MacOS and iPad.

Placeholder example of an online review with a 1-5 star rating

Jan, the Director of Marketing, asks, “How are we handling fraudulent reviews? Our reviews have always been from staff. That has been a differentiator. If we take this feature live, we lose our ability to differentiate on that.”

Paula replies, “But we’ve verified that the buyer bought the book, so their review is legitimate.”

“There is a black market for reviews, and the book seller might pay the reviewer $10 for a good review and reimburse them the cost of the book,” explains Jan. “Although we verified that they bought the book, we haven’t verified that they read the book or that this is their honest opinion.”

After a lot more discussion it’s agreed that it’s okay to leave the verified buyer tag on the reviews since most are legitimate. However, they won’t be featured or placed higher on the page. They will just appear in the normal sort order.

Ian is almost afraid to bring up the next feature, “Registered site users can click a button to vote that a review is helpful”. He wonders what unexpected problem will be found next.

As he shows the feature, Jan interrupts. “We can’t have that at all. It’s another source of fraud. Sellers will often pay for many users to click the helpful review button on any review that has 4+ star rating. Their goal is to bury critical reviews.”

A placeholder example of an online review from a verified buyer of a product

At this point Paula can’t contain her frustration. “Why didn’t you tell us this before? Why wait until we wasted the team’s effort on implementing these features?”

Jan snaps back, “I tried to warn you about fraud weeks ago, but you didn’t listen.”

Realizing that the event has spiralled out beyond his ability to facilitate, ScrumMaster Steve asks for a ten-minute break. When everyone returns to the room, he suggests that they wind down the Sprint Review early, since they now have the list of features that were accepted and the ones that need more work.

As they leave, Ian mutters under his breath, “That was a ton of fun. Next time I’m asked to do the demo, the answer is NO!”

Analysis

What happened? Steve was exceptionally well-prepared. He had a thoughtful agenda and yet most features got no feedback. Of the people present, some (like Eric) were engaged only with their phone and they never participated in discussing upcoming product priorities.

Done well, a Sprint Review is a point of pride for the team. This one was a downer for their morale, even though some of the work that was completed made the product better.

Challenges:

The Sprint Review was a Show and Tell. The goal is to increase engagement with stakeholders and end-users, not decrease it. If you ask the team members who worked on each feature to demo it, it’s likely to result in an unnecessarily long, tedious monologue, or demonstration of every nook and cranny of the feature, putting attendees to sleep. Having Paula demo alone would be just as bad. She might script a better story and make it seem more fun, but “Telling” — aka talking at other people — decreases engagement.
The Definition of Done wasn’t checked before the Sprint Review. This is critical. It is the way the team and the Product Owner know that they’re on the same page with respect to quality. However, much of the “Done” is just going to put the audience to sleep, so going through the process during the Sprint Review isn’t practical.
The Director of Support was more engaged with his phone than in participating in the Review. We missed the opportunity for his feedback and we don’t know if his team’s needs are being well represented.
The surprise around the two features and how fraud mitigation wasn’t included indicates that the Marketing Director wasn’t involved enough in the Roadmap (hint: StoryMap) or Ongoing Backlog Refinement.
No end users were involved in the Sprint Review. Without their input, all of the feedback that was delivered was theoretical and from people who are involved day-to-day with the Product, so hardly objective.
Underdeveloped facilitation skills showed through. As Steve grows in the role of ScrumMaster over time, he might prepare in advance for conflict. Knowing that it will or might happen, he could have a short reset exercise ready to go that will cool tempers and improve relations so the Review can continue and the conflict can get resolved, rather than postponed. In the early stages of a ScrumMaster’s journey, it is a little unfair to expect them to know how to facilitate through conflict.

What could they do differently next time?

It starts long before the Sprint Review meeting. When the strategic work is done in Product Backlog Refinement, ScrumMaster Steve and Product Owner Paula need to make sure that key stakeholders, like Jan (Marketing) and Eric (Support), are involved. ScrumMaster and Product Owner should also commit to spending a couple of hours a month reviewing the strategy and looking for things that might turn into surprises. When there are items that represent more risk or challenge, Paula can invite the Stakeholders to the Backlog Refinement session so they can provide input and clarity. These two actions will go a long way toward reducing surprises in the Sprint Review.

Seeing a feature get reviewed by the PO and checked against the Definition of Done has never been a recipe to increase engagement. As an alternative, Paula could review features as fully completed, having already checked them against “Done” prior to the Sprint Review. This approach fits well in a world of Continuous Delivery, something many modern teams are already employ. As a good final check just before Sprint Review, Paula could recheck all features to make sure they work well together.

Get End Users in the room. Where humanly possible involve actual users of the product to get feedback, to learn more about their needs, and generate enthusiasm. There are clear limits as most users won’t have the time or energy to participate every Sprint.

Replace Show and Tell with Show and Play. Have someone who knows the product well show the high-level features. Have each developer pair with a stakeholder/end-user and invite them to play with the product. As much as possible they should focus only on the work completed in this Sprint. Show and Play helps the users and other stakeholders discover how the product actually works, it generates a much deeper level of feedback, and it helps team members learn more about the needs of real users.

A good Sprint Review gets features accepted and deployed. A great Sprint Review engages the attendees and creates productive discussion around product direction and business priorities.

Learn more about how to hold great Sprint Reviews

Consider attending one of our Certified ScrumMaster workshops, where we discuss the how and why of Scrum, not just the what. You’ll get hands-on practical experience, and learn about some of the challenges – and solutions – along with tips on how to help your Team learn and grow to realize their potential.

Image attribution: Agile Pain Relief Consulting (Updated: December 2023)

Footnotes

Hint: this shouldn’t be the first time the PO sees a feature ↩

Drowning in an Oversized Product Backlog? Story Mapping Is Your Life Raft

Fri, 24 Oct 2025 00:00:00 GMT

Can you guess how many Product Backlog Items (PBIs) are in your Product Backlog right now? I’ll wait while you go look.

“Over 1,000 items in the Product Backlog, for one team,” I heard recently. I was so stunned, I couldn’t respond for a moment. As the story wound on, I heard that their team is having trouble with motivation and engagement. They don’t understand how their day-to-day work ties into the bigger picture. That’s far from surprising. When the Backlog is that big, it’s depressing and feels disconnected from the reality of the work.

The Math Isn’t Mathing

Simple math will illustrate how illogical it is to have a large Product Backlog. The result is bad enough for 100 items in the queue (graveyard?), let alone 1,000.

Let’s create an imaginary team. In fact, to keep this simple, let’s fantasize and make it an impossibly ideal team — they can complete seven User Stories per Sprint, all User Stories are the same size, all Stories meet the Definition of Done, there are no defects in their work, and there is no rework.

These are, of course, best-case assumptions; reality is far worse.

So if our fantasy team has a Product Backlog of 100 items, it will take over 14 Sprints (or 28 weeks, assuming 2-week Sprints) to get through that queue, assuming nothing is added in the meantime. For most teams, that too is a fantasy because the queue grows faster than the team’s work, so our problem is getting worse, especially if the Product Owner doesn’t have the discipline and authority to say No.

That’s using the example of 100 PBI. Remember, this article started after a conversation with someone who had ten times that amount.

28 weeks multiplied by ten = yikes.

Time Isn’t the Only Issue

There are a number of problems that large Product Backlogs cause, as I’ve written about in this article on the Scrum Alliance site. Here are some of the highlights:

Work queue can’t be properly prioritized
Important things get lost
Less important items get worked on simply because they’re near the top
Morale lowers because there is never a sense of progress
Team members can’t see how an individual Product Backlog Item or User Story contributes to the long-term goals

Enter Story Mapping

Jeff Patton invented Story Mapping to help a client deal with just such a mess. Jeff and the team printed out the User Stories and started to sort them on the floor, looking for patterns within to try and organize and understand. Organizing the collection into a visual map allowed them to evaluate how the User Stories related to the Product Vision.

How to Use Story Mapping

I’ll use an example of an app I’m currently building to illustrate how to make a Story Map. We’re creating a family expense management app that handles receipts, credit card reconciliation, expense categorization, and more. In the process of building it, the Product Backlog started to be used as a wish list or a graveyard, not as a simple list of upcoming work.

So we created a Story Map, working through these steps:

Strip anything related to Technical Debt out the Product Backlog. A simple rule: the Product Owner should understand and prioritize everything in the Product Backlog. Since fixing technical debt is the role of the team and not the PO, it doesn’t belong in the Product Backlog. (See Technical User Stories or The Team Try to Pull a Fast One on the Product Owner
Start with the key User or Persona for the Product. In the case of our expense app, the persona is someone who wants to understand where the money is going so they can ensure their daily spending decisions line up with long-term goals (e.g. riding bikes and travel).
Take a slice of the Product Backlog - lets say maybe the top 100 items - and select those that are relevant for that persona.
User Steps or User Task¹ layer. Group related items, for example:
- Creating an Account and Profile
- Upload and Scan Receipts
- Receipts by email
- Manual Editing of Receipt Data
- Upload Credit Card Statements Reconcile Receipts against Credit Card Transactions

Example of early step in creating a story map

Activities/Themes layer. Review the Needs or User Tasks and look for relationships between them. In our example:
- New User
- Receipt Management
- Credit Card Reconciliation

Repeat for each Persona
Walk through the Story Map. Does it tell the story of how the product will be used? If not, we’ve identified a gap. The larger the existing product backlog, the more likely it is to contain gaps of this nature.

If you’re like the person I was talking with and you have over 1000 items in your Product Backlog, it may not be possible to finish this activity in a finite time. My back-of-the-napkin math says 60-100 hours of work to get a rough draft of the Story Map using a Product Backlog of that size. I’ve never seen a team map with more than ~200 items before they’ve done a good enough job to understand the shape of the overall strategy.

This will lead to the next set of shocking suggestions. A Product Backlog with over 1000 items is full of items that will never be built. Some of these items were added to address problems that have already been solved. Other items were added several years ago, and they are no longer relevant. Many were added by stakeholders who no longer work at the organization. Hanging on to these items makes it much more difficult for the Product Owner or the team to see the product that they could build, because their thinking will be anchored by past ideas that are no longer relevant.

Instead of trying to map every item, the backbone (Activities/UserSteps) of the Map serves as a placeholder for items that will be worked on in the future.

Keeping the Map and the Product Backlog Manageable

It is easy to get caught up in creating a Map with all the details worked out, over a year in advance. I’ve seen some Story Maps with over 200 individual User Stories underneath the User Steps and Activities. It looks impressive and well-organized. The problem is that most of it won’t be worked on before the landscape changes.

For the portion of the Map that will be worked on in the next ~3 Sprints, a detailed understanding of the User Stories is good. For areas of the Map that will be worked on over the next few months, go only as far as the User Steps. Beyond that, note only the Activities.

The common refrain is “What if I misplace that gem of an idea?” The answer is that in a backlog of anything larger than 100 items, you already misplaced that gem. The Agile point of view is that —if it really is a gem— we will find it again. Further, the version we wrote down a year ago would restrict us from finding a better solution when we revisit it. That said, many Product Owners take a copy of the mess and archive it somewhere (the freezer?). Fantastic, shoot me an email the day you actually find that in the freezer. I can wait.

Whether you delete or archive the old Product Backlog Items, don’t keep them in the Story Map. Doing so creates a false sense of security that these items will be built in the foreseeable future.

Managing Technical Debt

That first step in building the map caused some heart palpitations. There is a simple approach to managing technical debt. Instead of expecting the Product Owner to prioritize these decisions, the team maintains its own queue and prioritizes them. I recommend using a tax model. For example, “We agree that the average Sprint will pay a 15%-40% tax to pay down the messes in the system.”

In the best case, the team prioritize paying down debt in parts of the system that either:

Change often or
Have a Feature that is being worked on in that Sprint

How to decide how much tax to pay? That’s going to depend on the system’s health. Is the codebase healthy? Assume 15% of the team’s time to maintain that. A system that has been worked on for over 5 years and no effort has been made to pay down the debt? Closer to 40%. Even when leaders say, “Don’t waste your time paying down the technical debt, we can’t afford it!! ☠️️💰️💰️”, we still pay the tax. Instead of tidying the mess, we take the time to try to understand the mess before we make the change.²

Unfortunately, as it currently stands, GenAI is making this situation worse, increasing code duplication and other smells faster than they can be fixed.

“The Real Cost of AI-Generated Code: It’s Not All It’s Cracked Up To Be”

Replace Your Product Backlog with a Story Map

A good Story Map is a visual representation of where the Product is going. It helps tie day-to-day work to the Product’s Vision. It gives the Product Owner a clear picture of what will be built over the next few Sprints and months. The Product Owner also gains a tool to discuss with their stakeholders, allowing them to make better tradeoffs on which aspects of the product are prioritized. Using our recommended Portfolio Management approach, the Story Map is a great tool for these meetings to ensure everyone is on the same page. Even if your Product Backlog isn’t an oversized mess, Story Mapping is still an excellent tool.

Related Blog Entries

Learning Story Mapping Through Exercises
Scrum Anti-Patterns: Large Product Backlog (via ScrumAlliance.org)

Footnotes

Jeff Patton originally called these “User Tasks”. That can be confusing because many developers call much smaller chunks of work “Tasks”. I often use the term “User Step”. Jeff and I are united that Epics are evil. https://jpattonassociates.com/the-new-backlog/ ↩
When a codebase is a mess, it takes 124% longer to get a feature built. Worse, uncertainty goes up. As uncertainty increases, predictability decreases. See “Code Red: The Business Impact of Low Code Quality” https://codescene.com/hubfs/web_docs/Business-impact-of-code-quality.pdf ↩

Early Feedback Reduces Anger and Frustration

Mon, 22 Oct 2012 00:00:00 GMT

business man angry for computer crash - licensed from Photodune

Have you seen a developer react after they’ve spent three days writing a feature, only to have the tester say, “Um… no” in a Post Mortem (a meeting about a project after it has finished) that went badly wrong - with lots of finger pointing and anger?

Recently in a CSM Class an attendee helped me see the emotion of the situation. The more time that has passed, the more emotion and energy we will have invested in an activity. The more energy we’ve invested, the harder it is to see new perspectives and perhaps even let go entirely.

Specification By Example and Retrospectives help by reducing the length of the feedback cycle. In the case of Specification By Example we get the team members who will be involved in implementing the feature to sit down together before any code is written. It’s much easier to accept changes before we’ve done much work on the feature. Retrospectives are similar, because they reduce the length of the feedback cycle to a point where less emotion has built up before we begin work to improve the situation.

In my personal work experience, I’ve also found that the longer we go without receiving feedback the more likely it is that there will be a problem.

For a long time when facilitating my courses I’ve had an end-of-day “Retrospective”.¹ Attendees give me feedback at the end of Day One while the feedback is still actionable. Attendees write their feedback on post-it notes. I try to make this anonymous by turning my back or using my phone when they’re posted.

Where have you noticed early feedback helping with a problem?

Image via: Photodune.net

Footnotes

“Retrospective” is in quotes because this isn’t a real Retrospective, a real retrospective involves a facilitated discussion among all team members. ↩

Example Mapping: Your Secret Weapon for Effective Acceptance Criteria

Tue, 12 Nov 2024 00:00:00 GMT

Example mapping is a collaborative technique for a team to take a User Story (or PBI) and have a deeper conversation to clarify their understanding of it. The conversation generates the Acceptance Criteria. (Acceptance Criteria is the generic idea - Example Mapping is the approach I generally recommend.)

We need an example. Let’s pretend that we’re building an app to reconcile store receipts with month end credit card statements. We’re doing it because it was boring and time consuming to do it manually. The system has the job of categorizing our spending for future analysis.

The simplest part of the system is to make scanned receipts reconcile against an item on the credit card statement. “As a conscious spender I want to match a single receipt against the equivalent transaction on my credit card, so that I know my credit card bill is accurate.”

Let’s assume these are the rules we’ve put in place:

We match on date and amount. Not store, since store names vary wildly between credit statement and receipts.
We match on a date up to 3 days before/after, since stores sometimes take days to upload their transactions to the credit card company.
We ensure that refunds happened.

Work a single Backlog Item at a time, and limit to a short amount of time to keep people engaged. Work from the User Story -> Rule(s) -> Examples. When in doubt, write Questions.

Core Idea

Start with a User Story

Write the Rule(s) that express a single constraint or need
Write Examples that illustrate each rule, each example proving one (and only one) point
Create Questions when the team is unsure or there is debate

There isn’t any correct order. Sometimes when a team is stuck trying to define a rule, I ask them to give an example or two. Then we can derive the rule from the example.

Example Mapping sample

Suggestions

Discover something that doesn’t fit the original user story. Keep the original small and write a new Story.
Just write examples. Don’t write Gherkin or automated test specs here – they’re clunky and time-consuming. Consider doing that with a pairing partner offline. (e.g. Given/When/Then Specs)
After 25 minutes pause and ask, “Is this ready for development?”
The Examples help explore the edge cases.
Avoid jargon. As much as possible, write examples in the language of the end users.
Effectively, the team is replacing most/all of Backlog Refinement with these example sessions.
Try to have a minimum of three different perspectives: Business; Development and Test. More team members involved is generally better.
The original version of Example Mapping was done with coloured cards: Yellow for User Stories; Blue for Rules; Green for Examples; and Red for Questions. However, the magic is in the conversation and not the colour of the cards.
Remote teams can use tools such as Mural or Miro, and even MS Whiteboard supports coloured “index” cards. In a pinch, Google Sheets works as well.
If a team finds a lot of ambiguity or questions, then the User Story/PBI is ill-understood. Instead of bringing it to Sprint Planning, someone needs to work with the client/stakeholder to dig further into the real need.
If there are a lot of rules (more than 3-4), then perhaps the item is too big. Consider splitting it into smaller parts. The Rules/Examples often make good splitting criteria.

Benefits

Reduces Risk of feature creep - we identify that we shouldn’t add things that the examples don’t justify
Identifies Questions or ill-understood areas before work starts on an item
Most Assumptions are clarified before we start work on the item
Reduces Defects - clear examples make it easier to write test cases (especially automated tests)
Reduces Finger Pointing - when features are built in a more adhoc fashion there can be a lot of finger pointing when the tester finds a defect. Especially when found late in the game, blame is faster than fixing the underlying issue.
Splitting is easier - large product backlog items become clearly identified and split into smaller parts. Rules/Examples often make the best splitting criteria.

Original idea from Matt Wynne. (Bonus: I learned that Friends episodes can be named, “The one where…”)

Forcing People Back to the Office

Thu, 16 Feb 2023 00:00:00 GMT

A man sitting alone in an office - photo by cottonbro studio

In December the Treasury Board of Canada ordered that, starting in mid-January, all employees would be expected to return to the office for two to three days a week. Among the stated goals were: Innovation, Creativity, Fairness, and Consistency. This all ties in well with the Agile Manifesto which includes the principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Prior to the pandemic, I would have trotted out reason after reason, study after study, why this was always 100% the best choice. I would have gone on to show that Team Rooms are generally more productive. (Hint: if you have an office, giving them a Team Room is generally a much better choice). I know from experience that working face-to-face increases collaboration, creativity, and innovation, so I should be applauding the Treasury Board’s decree.

I’m not. And here’s why…

Does Remote Work… Work?

COVID-19 swept into our awareness in March 2020 and upended our lives. We were required to move to remote work. As a result, that question has been well studied:

Remote Work Productivity Study Finds Surprising Reality: 2-Year Analysis¹: “Working from home is just as productive as working in the office – possibly more so.”
Research: Knowledge Workers Are More Productive from Home²: “We are spending 12% less time drawn into large meetings and 9% more time interacting with customers and external partners.”
Remote work – a forced experiment during the Covid-19 era or a lasting value?³: “Under normal circumstances, remote work increases productivity and helps people to strike a better balance between their work and family life.”
Working From Home Under Covid-19 Lockdown: Transitions and Tensions⁴: “we found that almost nine in ten workers (88.4%) said that they had got more done or as much done as in the office pre-lockdown, and just over one in ten felt they were doing less.”

It wasn’t all roses. Challenges that are apparent:

Some people find working from home more stressful
Others had problems with internet bandwidth
Some suggest there is a loss of creativity

It is worth reading the reports referenced for a lot more detail. The key, however, is that it does suggest that people were as/more productive. In addition, they were happier. That will become important in a moment.

How 2-3 Days a Week in the Office is Working

The claim the government made is “Bringing in this common approach of two to three days in the workplace … will help with having in-person teamwork and collaboration. But also, the one factor it will really help is the fairness and equity issue”.⁵

Collaboration is good in the Agile world. So let’s see how this policy is helping.

To improve “teamwork, collaboration and creativity”⁶, we need people to be in the office at the same time, working in the same place. Preferably, we want people in team rooms. Except, as it’s been mandated by Treasury Board, there is no reason that the whole team will be in the office on the same day. From the people I’ve heard from, there is no coordination of who shows up on which day, so people go into the office but still don’t see their team. Instead, they join the same MS Teams/Zoom meeting they would have from home, except that they’re at the office.

But wait, it gets worse.

Suppose for a moment that you and a teammate make it to the office on the same day, then face-to-face conversations will surely happen, right? Not so fast. Many departments are moving to a hotdesk/reserve-a-desk approach. Some people even reserve desks with their team but, when they arrive, their reserved desk is occupied by a stranger. In many cases, I hear stories of not getting a desk on the same floor as the other person from their team who is in that day. So the theory is great, but the practice is, at best, a failure thus far.

Engagement at Work

Employee engagement is critical to an organization’s success. It’s the difference between a person who comes in to do a job, collect a pay cheque, and go home, and an engaged individual who is there to help solve a problem and make something better. An actively disengaged employee will sabotage their own work as well as the work of others. Gallup has documented a lack of engagement as one of the bigger problems in the modern work place.⁷

When we have engaged people on our team, magic happens:

Performance - engaged team members are more productive as individuals
Collaboration is easier - when people are disengaged, collaboration is reduced because people don’t feel that their work has a purpose
Retention - engaged people stay with their employer longer, which means tacit knowledge stays in the building
Better quality and customer satisfaction - as our engagement goes up, so does pride of ownership
Less Burnout - engagement is a protective factor in preventing burnout and maintaining mental health

The importance of engagement at work could occupy an entire blog post in itself.

How Does the Change to Remote Work Affect Engagement?

Anything that negatively affects motivation will harm engagement. I will cherry-pick elements from the ARC and SCARF motivational models that I share in the Advanced Certified ScrumMaster workshops.

Autonomy - As humans we have a strong need to control the way we do things. Consider the reaction you get when you tell another family member how to do some work in the kitchen. In this case, Treasury Board has taken away a lot of people’s autonomy. They no longer have the freedom to choose how often to go into the office.
Fairness - Allegedly this change was made to ensure fairness. Simplistically, everyone is treated the same way, but most individuals don’t feel that they’re being treated fairly. Most were productive while working remotely. They feel that their accomplishments during the pandemic are being ignored. For some people this reaction is so strong, they’re looking for employers who are embracing remote work.
Fairness - When a change is imposed from the top in an organization, it rarely works well. Fairness is violated in this case, because people don’t feel like they had a voice in the change. I don’t think that Treasury Board can make true collaborative decisions with 300,000 people. But I do think they could have created guidelines and given departments room inside those guidelines to experiment.

Outside the motivational models, there are many other ways that this harms people at work, including:

Child care - Many people changed their child care arrangements or [shock] had new kids during the height of the pandemic. Now they’re magically expected to find childcare arrangements that will accomodate two or three days a week. This in the city of Ottawa where there was already a shortfall of childcare options.
Stress - No one has told me that they enjoyed their pre-pandemic commute. Insisting that people start driving downtown again simply brings that stress back into their world with no benefit to offset it.

Other Challenges of Mandatory Office Attendance

It limits hiring options. Remote work made it possible for the government to hire people anywhere across Canada. The change means we’re back to the same pool we always had.
Remote team members are forced to be in an office with no colleagues. Imagine a team in Ottawa hires a person in Calgary. There is little point in forcing the person in Calgary to commute to an office when their team isn’t there.
It limits the hiring pool. LinkedIn⁸ announced over a year ago that remote jobs got 50% of all applicants. If the government is committed to hiring the best people, then this policy says “no” to many of them, even before a job ad goes up.

Not All Pixie Dust and Goodness

Remote work isn’t a magical solution to everything. There are some real challenges that need to be addressed. One of the things I’ve heard throughout the pandemic is that, while the work is getting done, people have less sense of their team and teammates. People clearly need time together to renew bonds. Pre-pandemic, many remote-only companies would get the whole company together in person once to twice a year. A recent survey published in The Conversations⁹ suggests that many people would like one day a week in the office.

Allowing each department to do its own thing was creating unfairness, however, Treasury Board has done something worse in that it left everyone feeling unfairly treated.

One size doesn’t fit all. CSE, CSIS and parts of the Department of Defence can only operate on a secured network, in a secured facility. Even during the height of the pandemic their work happened in the office. In addition, entire classes of work (Coast Guard, active military units, Emergency Operations Centre, …), need people to be physical present and will never be remote.

What Should Organizations and Leaders Do?

The argument about just returning to the way it was before is specious, that world no longer exists. We live in a world where remote work has been proven viable (with caveats). We can’t wind the clock back. I’ve updated my hard-set, previously-held beliefs, and it’s time that organizations do the same.

In theory, I should address this section to Mona Fortier and the Treasury Board Secretariat. In practice, I don’t think I have their ear. Decisions on how to make hybrid or full remote work, in the long run, should be made at the level of the people they affect - the people actually doing the work. The best choice would be to have leaders wading through the evidence carefully, summarizing it, and sharing it with their teams. Then either the teams are trusted to make their own choices or, if a degree of coordination is required, decisions should be made by creating a larger, temporary group with representation from each team. In the latter case, the group helps to decide the policy around things like how often people need to be back in the office, and they also help with the implementation (e.g. which teams go into the office on which days).

For teams that are remote full-time, then the team(s) need to decide how to recreate the missing social connections. They also need more explicit effort with activities to help spark connections for creativity and innovation.

On the off-chance that Treasury Board is interested in a conversation, the same formula applies. Summarize the research, share it with the departments, and trust people within each department to make decisions that are best for them. Every six to eight months, gather data on what is working at the departmental level and share it out across the whole government.

We shouldn’t force people to do what is familiar and comfortable just because it’s what was done before. Not only does it invalidate new discoveries (like that people still work hard when at home) but it misses all opportunity to benefit from change and evolution. That is most definitely not being Agile.

Update: I shared this article in our newsletter along with the question “What would you set as the required number of office days each week for your team members if you made the rules?” We received many interesting replies from people around the world.

Some respondents were behaving like true systems thinkers, by considering the environmental impact of commuting. Another agreed, explaining that if you live in a major city where the average commute is 2-3 hours a day, travel time is a big issue. They believe most people gladly work 8-10 hours days when they are home, but they are less likely to do that when they also have to fight with traffic and, when they do arrive at the office, they’re not at their best.

The stress of travel was a common experience. One reader reported that they ended up quitting their position because they were being forced back into the office. They found a new job that is 100% remote, with an office that people are free to use when they want to. With the removal of the commuting time, they said they hadn’t realized how stressful it had been and how much it affected them and made them exhausted before.

They weren’t the only one who quit under pressure to return to the office. Another reader left their municipal government position after 15 years because they were ordered back to the office. The key reason they were given was to bring people to the central city, spending money and adding to the vibe. They acknowledged that was an admirable goal, but it wasn’t their job, nor were they being compensated for the increased local purchases they were expected to make.

In regard to collaboration, having pairing sessions over zoom reportedly helped teams gel with each other and avoid the feeling of isolation. One reader leans toward one day at work max per week where employees attend as needed. In their senior role, they make an effort to meet team members for lunch, which reportedly works well for morale and social interactions. They wisely pointed out that there are many better ways to keep track of work than just attendance in the office.

Others talked about the importance of flexibility to balance work life and personal life, as long as commitment is maintained to contribute the hours they’re paid for.

The topic really resonated with many people. “Let the team decide what they need” was a common theme in the replies, demonstrating a strong understanding of Scrum and Agile philosophies. Another point made was that if a team managed to be effective during a pandemic, they will certainly still be effective when the pandemic is not there to drain their resources.

I liked seeing people take a wide viewpoint. There is no one answer appropriate for everyone, and there are plenty of pros and cons to be considered. Some readers commented that they found it good for their mental and professional health to get out of the house and interact with colleagues a day or two a week. This was interesting balanced against those who reported improved mental health from not having to deal with commuting.

One reader found the mandate to return to work pretty hypocritical. In addition to the carbon footprint effects of forcing employees to come onsite, they pointed out that the pandemic allowed companies the flexibility to create teams that were distributed geographically. The result is that now, when forced back to the office, they still need to conduct meetings online to include colleagues in other cities.

This distributed team awkwardness was mentioned by another reader who shared that they personally prefer either 100% in-person or 100% remote, and that half the team in the conference room and half dialed in feels clunky. Another suggested two days would be their preference since their sprint ceremonies and refinement can all happen in that time.

One long-time alumni shared that his company has gone fully work from home and it’s working well for them. They reportedly have no plans to force anyone back into the office, and plan to end their lease when it comes up for renewal. They’ve opened their hiring to anywhere in Canada, and have roughly doubled in size over COVID. They report that, from a team experience, it has been positive but the challenge does remain for organizational connectedness since it’s hard to get to know colleagues on other teams very well when you’re not in a shared location.

An excellent question that was brought up: What problem is an organization trying to solve by bringing people into the office? Some suggested that management decisions to force people might be the product of historical habit, or perhaps even leadership desires to try to control employees, rather than trust them to do their jobs.

I agree that paranoia is one reason many managers don’t like remote work. Consider the following observation in “Hybrid Work Is Just Work. Are We Doing It Wrong?”:

“85% of leaders say that the shift to hybrid work has made it challenging to have confidence that employees are being productive. And as some organizations use technology to track activity rather than impact, employees lack context on how and why they’re being tracked, which can undermine trust and lead to ‘productivity theater.’ This has led to productivity paranoia: where leaders fear that lost productivity is due to employees not working, even though hours worked, number of meetings, and other activity metrics have increased.”

Another interesting article: “Think Hybrid Work Doesn’t Work? The Data Disagrees”.

While hybrid work isn’t preferred by everyone, it’s undeniable that the freedom to choose the where has a direct and profound impact on the what and how for teams.

I’d love to hear your take on the issue, too. Please comment below.

Footnotes

Remote Work Productivity Study https://www.greatplacetowork.com/resources/blog/remote-work-productivity-study-finds-surprising-reality-2-year-study ↩
Research: Knowledge Workers Are More Productive from Home https://hbr.org/2020/08/research-knowledge-workers-are-more-productive-from-home ↩
Remote Work: Forced Experiment During Covid-19 Era or Lasting Value https://www.macroeconomics.lv/remote-work-forced-experiment-during-covid-19-era-or-lasting-value ↩
Working from Home under COVID-19 lockdown https://www.employment-studies.co.uk/resource/working-home-under-covid-19-lockdown ↩
Public Service Ordered Back to Office https://policyoptions.irpp.org/magazines/december-2022/public-service-ordered-back-to-office/ ↩
Does this feel like a game of buzzword bingo yet? ↩
Dismal Employee Engagement Is a Sign of Global Mismanagement https://www.gallup.com/workplace/231668/dismal-employee-engagement-sign-global-mismanagement.aspx ↩
Remote Jobs Attract Majority Applications https://www.linkedin.com/business/talent/blog/talent-acquisition/remote-jobs-attract-majority-applications-first-time ↩
Working One Day a Week In Person Might Be the Key to Happier, More Productive Employees https://theconversation.com/working-one-day-a-week-in-person-might-be-the-key-to-happier-more-productive-employees-195076 ↩

Future Perspective for Change: Why Backcasting Helps Get You Where You Want to Be

Wed, 22 Jun 2022 00:00:00 GMT

When a product team starts work on a product, it’s important that they understand the vision. This is, as they say, a bit of a no-brainer since otherwise they might build something that completely misses the mark. In a modern Agile world, we’re expecting a mix of Product Management, Developers, ScrumMaster, the Customer and perhaps key Stakeholders to spend time together in a collaborative effort to have, and maintain, a shared goal so many teams use exercises like the Product Box (originally from Innovation Games), Pixar Pitch, etc, to spark conversation between the people building the product and the people for whom the product is being built. Over the process of a few hours these activities get the Developers and Customers to a common understanding of what problem they’re attempting to solve.

Right. Great. So that, in an oversimplified nutshell, is how everyone can have a vision that they agree on to build a great product.

But what about building a great organization?

When I’m brought in to help people undertake Organizational Change, I always ask them, “Why are you undertaking this change?” Too often the answer is, “To be Agile”. The problem, of course, is Agility is not the goal, it’s the outcome of improving the system. Then I ask who was involved in creating this “why” and the answer is usually “Management”.

When change is started by Management alone, the Doers perceive the change to be imposed on them and not something they’re part of. Co-creating the Product Vision is critical for a Product to succeed, and the same applies to changing the system itself. We need the people who will be part of the change to participate in deciding the why of change.

Typically the why is because they want improvement of something, otherwise what’s the point? It can get trickier, though, when asked to identify what exactly that improvement should look like —what their vision for organizational change is. When we attempt to imagine the future, we tend to picture a slightly better version of the present. If I had asked you in the early to mid-2000s to imagine a future phone, it likely would have been some improved variant of a Blackberry with a physical keyboard. Few would have mentally pictured the iPhone features released in 2007, changing our expectations.

This happens because our brains are only able to extrapolate from the current state. So if we’re asked to look forward a few years into the future, we tend to project a version that is consistent with the current world but only about 20-30% better. If we want to create a new world, we must reverse that direction and, instead, imagine ourselves in the future state looking backward. This is referred to as “backcasting”, which is different from forecasting in that you start with the end in mind and “cast” backwards.

Variants of this technique have been used by Amazon,¹ Komatsu² and any number of groups imaging a world without the use of fossil fuels.³ In this case, we will use this approach when starting or sustaining an Organizational Improvement Process. By slightly tweaking the initial question, this is can also be used for Product Vison.

backcasting - c.The Natural Step

Picture from: Natural Step. Used with permission.

Process Outline

Goal	Discover what success looks like in a change process.
When to use	At the start of a project or any time you’re beginning a new initiative.
Time	1-2 hours depending on facilitator experience and the size of the audience.
Who is involved	The Organizational Improvement Team – must include some doers, a few key decision-makers, and a few key stakeholders (the people sponsoring the change)

Characteristics:

Long term scale, imagining a future at least five years out, sometimes longer
Participatory Process, not just the views or plans of one person
Identifies and helps prioritize preferred outcomes
Vision should motivate and lead to collective action

Facilitation Notes:

(Adapted from Innovation Games⁴ - Remember the Future)

The exercise starts off with the facilitator asking the attendees to imagine a moment several years into the future, when their world of work is much better now. The facilitator asks participants to “look back” and see what made the change a success.

Participants write down the changes on sticky notes or the virtual equivalent using as much detail as they can. Once everyone has had a chance to write, draw, and reflect (10 – 15 minutes), participants take some time to group common themes (another 10-15 minutes). Once the themes are found, they’re reviewed to see if they suggest a headline (e.g. “World’s most improved quality” or “Our clients are so happy with our work, they surprised us with a paid vacation for the whole team”). Some approaches have boxes or prompts that invite people to answer specific questions – e.g. a newspaper article has a headline, main story, a picture and related news:⁵

future perspective newspaper - blank

When the team have created enough examples, they select the best one(s) and that becomes their change vision. When choosing, look for one that gets people jazzed up about making change.

The change vision feeds into creating their change strategy – think Story Maps or Impact Maps, adapted from the Product world to the Change world.

The key is, as the facilitator, to frame things as looking from the future state backward, to help reframe the thinking, and then asks open-ended questions. So instead of asking, “What will make our company more flexible/agile/better/happier/faster/have better quality?” the ask is more along the lines of, “It’s been five years and one month. Our team members are happier, our customers appreciate our quality, and our executives like our flexibility. What changes got us here?”

Other prompts that the facilitator might use:

“Our improvement team is walking up on stage to receive the _____ award; the presenter says at no time in the history of this award has the committee seen an organization more deserving. Fill in the award name and describe the accomplishment.”
“You overhear a group of your colleagues talking about the organization. They say they didn’t believe change was possible but, here we are five years later and change happened, this is now a better place to work. As you listen to them speak, what are they saying? Why is it a better place to work?”

If the group is larger than 7-8 participants, break into subgroups and share results back after a round of play. In this case invite the groups to self-organize into subgroups of 4 or more people. Ask that they work with people they haven’t worked with before. We’re trying to reinforce that all aspects of an Agile work world can be self-organizing.

Consider a second round of play where groups take ideas that inspire them from other groups, and see if they want to change their own “remembered future”.

Since most teams are used to working with a Product focus, you will need to remind them at the start, and perhaps also after the first round of work, that the focus isn’t about the product but making the process better.

Example

We know we want to improve our quality and how our customers see our product. We might start with an opening question: “It’s been 5 years and a few months, our customers are phoning support, but not with problems.” What are they saying and why? Or “It’s been 5 years and a few months, we’re at an industry awards ceremony, the presenter is on stage saying ‘never before in the history of this association has ….”.

The team work with the prompt and say:

future perspective example cards

From this they might create a number of newspaper stories that shows the effect of their quality work from the customer perspective:

future perspective example newspaper headline

We’ve only shown one here, but a group will create many and then select the best idea(s) for their change vision.

Just by changing the opening question, this exercise can also work well for a Product Vision too.

Complementary tools

Liberating Structures 1-2-4-All might work well to help the group self-organize to synthesize their discoveries.

Blank newspaper headline template:

future perspective newspaper - blank

Also see our “Agile Change or Adoption Always Starts with Why” article.

Want to have a better understanding of the why and how of more things in Scrum, and not just the book-level what? Practising Scrum without proper understanding can bring poor results and, ultimately, frustration and resistance. In our Certified Scrum workshops, attendees learn in a fun and non-judgmental environment how to make Scrum work effectively in the real world, not just in principle. Join us to learn and to gain practical, hands-on experience.

Image attribution: Agile Pain Relief Consulting (Updated: March 2025)

Footnotes

GenAI and the Feature Factory: Automating Away Collaboration

Thu, 29 May 2025 00:00:00 GMT

In 2016, John Cutler coined the phrase “Feature Factory” to describe a situation where team members churn out features all day long without a connection to the client, the discovery process, or even knowing what the product vision is. Fast forward to 2025 where we see the rise in the popularity of GenAI, with misused GenAI making our Feature Factory worse.

Using AI to churn out features faster doesn't equal a better product.

In Why AI Doesn’t Replace Your ScrumMaster, we shared Guidelines for the use of AI in Scrum Teams and then tested the promises made by various tool vendors regarding the use of AI. In this article, we will examine the good, the bad, and the truly ugly uses of GenAI in the world of Product Owners. (Note: In many of these examples, I’m summarizing what is on a vendor’s website, so remember that, as with all summaries (human or LLM-generated), essential details might have been accidentally missed.)

Before using GenAI, check:

Increases collaboration?
Targets bottlenecks/value?
Acceptable risk?
Manageable complexity? sustainable?
Enabling Innovation?

Full Guidelines for GenAI Use

Speeding Product Backlog Refinement

It has been suggested that GenAI could save time in Backlog Refinement by generating User Stories. People aren’t using a special tool; they’re just asking Claude Sonnet or ChatGPT to create User Stories based on a prompt. One tool vendor even promises “Craft clear, concise, and actionable user stories that propel your project forward with the click of a button.”

My Take

But hang on, let’s consider the real value of User Stories. The goal isn’t to write product requirements with better language. Backlog Refinement is a tool to get everyone on the same page about what to build. User Stories are the outcome of that conversation between the Product Owner and the Team.

Let’s evaluate using our guidelines. Will generating User Stories from a prompt build a common understanding between the PO and the rest of the Team? Will it increase or decrease collaboration? … AI-generated User Stories would seem to harm both.

Further, all of these tools that promise to speed Product Backlog Refinement are helping to speed up an activity that typically only takes 2-3 hours in a two-week Sprint. So the AI is being used to speed up an activity that focuses on collaboration and understanding the Product we’re trying to build, all just so we can save a couple of hours in the entire Sprint? Generating User Stories speeds up the wrong thing, saving time that will harm the quality of the product and make it less likely to meet the customer’s needs. That seems completely of whack. (Harsh, but honest.)

Other tool vendors promise to speed up Story Map creation. This is another collaborative activity where saving a few minutes or hours at the start will ultimately cost us more in the long run.

How could GenAI help? Take a User Story the team has written, along with any additional context — persona description, summary of the vision and strategy, etc. Feed all of this to the tool and get it to ask the group clarifying questions. Most of the questions it generates will be useless, but a few will help reveal assumptions that haven’t been explored. I know because I’ve tried this myself.

AI Evidence-Based Estimation

This was copy and pasted from a tool vendor’s website:

AI brings a new level of objectivity to the estimation process by:

Analyzing historical data for similar user stories or tasks

Identifying patterns in estimation accuracy across different task types and team members

Recognizing and accounting for common estimation biases

Providing estimation ranges based on confidence levels derived from past performance. Machine learning models can process vast amounts of sprint data to predict effort and complexity with increasing accuracy over time. This data-driven approach helps teams transition from subjective assessments to evidence-based estimations grounded in actual performance history.

My Take

Using GenAI can help make the estimation process more accurate. But let’s consider why we estimate in the first place: we can make forecasts based on estimates; they help us decide how much work can fit in a Sprint; and the act of estimating helps people better understand what they’re trying to create.

Those are benefits of estimation, but what are the risks? Estimation processes are flawed because they create a false sense of precision, consume valuable time, ignore uncertainty, and often become a political tool rather than focusing on delivering value (see NoEstimates for more detail). Taking that view, if estimates are fundamentally flawed, then making them more accurate still leaves us with a flawed system.

Even if estimation is valuable, the vendors offering to remove people from the estimation process are missing some key points:

Estimation as a Tool for Collaboration - For teams that estimate, a key value of the exercise is building a common understanding of what they’re estimating. An AI doing the estimation won’t help create that understanding.
Variability - Inaccurate estimates don’t come from humans doing a poor job. The real problem is variability. When asked to build two similar-sounding features, the GenAI estimates should be the same. However, artifical intelligence wouldn’t consider variables like the quality of the code where the change is being made; the number of conversations required with the end users; or hidden dependencies.

AI doesn’t make Estimation better, because Estimation was never the real problem. If these vendors provide tools to help teams ask better questions, the team members themselves might provide better estimates without any automated assistance.

AI for Product Discovery

This is a summary of a real tool:

Product X is designed to streamline the product discovery process by leveraging artificial intelligence to analyze extensive customer feedback. It gathers customer interactions and comments from many sources, including communication channels, in-app feedback mechanisms, and CRM systems, consolidating them into a unified view. This centralization is key to understanding the broader customer narrative. The system employs AI to sift through this large volume of customer data, automatically identifying and categorizing key patterns and actionable insights. It can distinguish between various types of feedback, such as complaints, feature requests, emerging opportunities, or reasons for customer churn. The tool generates reports highlighting significant customer signals, segmenting them by factors like the source of feedback, customer demographics, potential revenue implications, and specific tags.

My Take

Discovery is a time-consuming task, so automating parts of the process could be helpful.
Discovery is about finding patterns in large quantities of data, so AI can be helpful for this.
Risk of errors? All discovery processes have errors, so an AI-aided process isn’t creating a new risk. However, it does underscore the importance of a Product Owner listening to interviews and reading customer tickets themselves so they can spot false positives and hallucinations.

AI-Powered Prioritization

One tool vendor promises to help Product Owners with the insanely challenging task of prioritization. In our CSPO workshops, we dedicate 60-90 minutes to exploring this subject, providing attendees with at least five models.

The tool processes data (user feedback, project history, market trends) to identify critical requirements, analyze relationships, and predict outcomes. AI tools work well at interpreting unstructured data.

Key Details:

Pattern recognition to categorize requirements
Predictive analytics for risk assessment
Automated scoring/ranking based on criteria
Continuous learning to adapt to new data
As conditions change, items can be reprioritized quickly and with limited effort
Early detection of conflicts or inconsistencies

The vendor also highlights key risks, including data quality issues (inaccurate or incomplete data) and overreliance on AI without human validation.

My Take

I’ve reviewed over 30 tool vendors that promise AI will magically make your team better. This example is one of the few where they address risks.

How well does this do with our guidelines?

Collaboration: It might hurt collaboration depending on how the product owner currently prioritizes.
Bottlenecks/value: Prioritization can be a time-consuming task.
Innovation: It enables more frequent prioritization experiments and would help to try different prioritization models.

AI-powered prioritization has potential, but only if it is used as an adjunct and not a replacement. Specifically, the product owner still needs to have a deep understanding of prioritization. In addition, take the time it promises to save and invest it in testing the recommendations.

So, how can Product Owners use LLMs effectively?

Along with the positive mentions above, GenAI/LLM tools are highly effective at generating a large volume of text quickly. They’re also excellent at processing a large amount of text. They’re excellent at distilling large amounts of data from customer interviews. They can help work through thousands of support requests to find recurring themes.

One Product Owner I know used Claude Sonnet to help write a prototype (i.e. throw-away code) for a product feature they wanted to test. Over several days, they went from a rough idea to a prototype that worked with the existing product. The prototype was used to start a conversation with executives and get buy-in for the feature. The same prototype also showed what worked well and what needed usability work. This usage checks many of the boxes in our guidelines because it increased collaboration with the execs and the developers, throw-away code was an acceptable risk and sustainable, and it was innovative in making the previously difficult work practical.

Conclusion

Using GenAI effectively isn’t just about copying and pasting prompts from the internet. Relying on someone else’s set of Product Owner prompts is likely to result in products that don’t solve the customer’s real problems. Instead of creating another Feature Factory, use GenAI to help you see things you might have eventually noticed, or maybe would have missed. Use it to run experiments that were previously impossible.

Related Blog Entries

GenAI vs Human Intelligence - a Reality Check

Thu, 21 Aug 2025 00:00:00 GMT

GenerativeAI is being pitched as a tool to replace software developers, human resource professionals, graphic designers, editors, radiologists, and many others. Leaders are mandating the use of AI without understanding what they’re asking. The language that is used to describe GenAI includes thinking, reasoning and learning, and we’ve been told many times that superintelligent AI is just around the corner. My late father used to say, “Marvin Minsky promised me AI would be coming in a generation.”¹ Minsky was trying to develop intelligence that could compete with human intelligence. I’m still waiting.

The hype and language used to describe GenAI makes it difficult to understand what it is good at and what it can’t do. All Scrum teams I encounter are doing creative work and solving real problems. In theory, LLM tools can do much of our current work, but can they truly replace human creativity and thinking in the workplace?

GenAI's only job: generating plausible sounding text

At its core, GenerativeAI takes the text you give it and rolls a giant set of dice to predict the next word in your sentence. It works fairly well because it has been trained on a large volume of text — effectively the entire internet and most of the world’s books. So let’s remember, there is no magic; these models are just prediction machines. When we see that GenAI is just a tool to generate a plausible response to our prompt, the following limitations can be understood.

Fundamental Limitations of GenAI:

Originality - Under the right circumstances, you can get many GenAI models to spit out chunks of existing creative works, including JK Rowling’s “Harry Potter and the Philosopher’s Stone”², but that’s just regurgitating human creativity and not being inherently creative on its own.
Learning and Memory - Contrary to popular belief, the models don’t really learn from you. They can only draw on the data that is included in the training. Each chat with a model is a fresh start. Its memory is like a rolling window - once we get to the end, it drops the earliest part of the conversation. (OpenAI and other vendors have worked around this by saving key details from past conversations and inserting them at the beginning of each new conversation.) Worse, even with models that have large context windows, they suffer from recency bias.
Thinking, Reasoning and Bias - Current GenAI models now have a reasoning mode, which makes them better at solving some problems. But it isn’t reasoning in the human sense; instead, it’s just pattern matching³. This can work well if the problem is close enough to what it was trained on, however it can go off the rails when the problem is a little bit outside its training. Additionally, models can amplify the biases found in their training data.
Mistakes and Self-Explanation - If a child makes a mistake and we ask them how it happened, their explanation is based on the actual series of thoughts and events. If a model makes a mistake and we ask it to explain the error, the explanation is entirely made up. The model doesn’t have any self-awareness and it doesn’t understand what a mistake is, let alone that it made one. When asked, it will come up with a plausible explanation, because its job is to generate plausible text in response to a prompt.⁴ Even more important, the child will learn from the mistake and update their understanding of how the world works. AI can’t learn, because it doesn’t change. Once a model’s training is finished, it stops learning. So each conversation with it has the same knowledge as the last.
Math - If we ask a child what 6x7 is, they will know the answer and understand how they got there. If we ask a model what 6x7 is, it will likely give the correct answer, but only because it was represented many times over in the training data. OpenAI and Anthropic have worked around this by providing the model’s access to a Python interpreter. They turn math problems into Python code. This works as long as the model recognizes that it is a math problem and translates correctly into Python code. (In the case of OpenAI ChatGPT5, the Python interpreter is hidden under the hood, so you can’t see what is going on.)

GenAI sometimes makes mistake

Output Quirks

Hallucinations and Falsehoods - Because it is just generating plausible text, GenAI models sometimes spit out a result that seems correct on the surface, but isn’t. Worse, because it has been trained on the entire internet, a model will parrot back something it found on the internet, even if it isn’t true. It has no sense of truth; the model just picks the next most likely word in the sentence.
Sycophantic - When asked to perform a task, models will often respond with a comment like “That’s a good question”⁵. When asked to critique my writing, I often get a compliment telling me that I’ve made a good point. Responses are what the tool predicts we want to hear; even if we think we’ve written a neutral, unbiased prompt, it often contains hints that a Large Language Model (LLM) interprets in its responses.⁴
False Confidence - Since models have read the entire internet, and much of the writing on the internet sounds confident, the models have learned to sound confident in their phrasing. This is dangerous given the hallucinations and faslehoods previously mentioned. Worse, the model has no way of assessing how confident it should be so it doesn’t self-regulate its tone.
Small changes in the prompt can lead to large changes in the response.
Excessive - A model will often do far more than it was asked to do. Depending on the context, this can be helpful or harmful. If I’m asking the model to summarize reviews of several different products, doing too much can be okay but it does literally waste energy⁶. Sometimes, it can be helpful when the additional depth reveals something unexpected. But doing too much can also be harmful. When I’m getting the model to write code, it will often create hundreds of lines of code that are completely wrong and must be deleted. If I were getting the model to do something on my computer, it might delete files or take other irreversible actions. Even if you ask for brevity, it can still ramble on.

The above limitations and quirks aren’t just idiosyncrasies, they can be potentially quite damaging. Further, these problems are inherent to the current approach of AI development. That’s why caution and responsible use is so important, especially when it comes to sensitive data and privacy.

Privacy

When I tell something to a model like OpenAI’s ChatGPT, we need to think about privacy. Much of the focus is on ensuring your prompt isn’t used to train the model in the future. (That’s important, and most vendors have a toggle to allow you to turn this off.) However, even when it’s not used for training, vendors keep a log of your interactions, and their staff may have access to that log. This is a double-edged sword; on the one hand, being able to see your chat history can be helpful, on the other hand, we don’t know how secure these logs are. We should also ask whether AI vendors will resell our usage to advertisers⁷.

There are two approaches that I can currently see that have complete privacy: Apple’s Siri Intelligence and running the LLM on your computer. Siri’s Intelligence relies on models that run on Apple servers. They don’t keep any records of your Siri interaction. They even invited security experts to prove their promise of privacy. The downside is that the Apple models are only okay for most tasks on their own, and if you ask Siri to use ChatGPT, we’re back to the earlier privacy problem. Recent generation Macs with enough memory can run local models, some of which are very useful, and well-equipped Windows machines can also do this. In all cases, local models have excellent privacy ;-).

Remember

There is no magic; these models are just prediction machines.

What can we use GenAI for?

These tools aren’t human; anthropomorphizing them makes us think they are. When we anthropomorphize, it is harder to see what they’re good for and what they can’t do.

I limit my use of LLMs to:

areas I know well enough to check the subtleties myself
areas where correctness doesn’t matter (e.g. getting a list of ideas or critiquing my writing)
answers grounded in search data, which I can access and double-check

I use LLMs every day. Where practical, I run them on my machine so I’m paying attention to the energy usage and I have privacy. They’re very useful at:

Brainstorming - good for generating a long list of ideas quickly
Critiquing writing or presentations
Transcribing meetings and finding the tasks that were agreed to
Summarizing longer pieces of text - often helps me see which academic papers are worth reading carefully. (I don’t assume the summary is right, it’s merely a way of finding a needle in a haystack.)
Summarizing large quantities of customer interview data or support comments - gives me an idea of where to dig further
Analyzing larger bodies of text to find patterns
Helping me write code to automate a task
Helping to write test cases

So with this understanding of the mechanics and limitations of LLMs, next time your manager tells you to use AI, you can ask them how many dice they want you to roll. :-)

One last challenge with any of these tools is that they don’t help us see when we’re asking the wrong question. For example, many teams focus on velocity as a meaningful metric. If we ask a LLM how to stabilize or improve our velocity, we will likely get advice that focuses on just that. Whereas an experienced human, and not AI, will consider all factors and, in this example, suggest that we’re putting the focus on the wrong place.

Ignore promises of Artificial General Intelligence (AGI) and Super Intelligence (better than AGI)⁸, there is no evidence to suggest that current approaches will get there. The hype hides the real utility of these tools. LLMs aren’t going to replace human creativity, thinking, and reasoning. They’re simply useful tools for speeding up some particular tasks (like meeting transcriptions and summaries) and for widening the range of ideas we’re considering. Understanding these limitations is essential for any Scrum team deciding how to use AI responsibly, something we explore in our Certified ScrumMaster workshops.

Related Blog Entries

Image attribution: Agile Pain Relief Consulting (August 2025)

Footnotes

GenAI Code Quality – The Fundamental Flaws and How Bluffing Makes It Worse

Thu, 12 Feb 2026 00:00:00 GMT

AI-generated code has 1.7x more issues, the GenAI code quality gap is turning into a chasm. That’s not a random number, that’s from a CodeRabbit research report¹. You’ve probably already seen the problem yourself. AI-generated, quick to write, harder to read and maintain. Why? Researchers from the GENIUS project² put it plainly: training focuses on pass/fail — does the code compile, does it pass the tests? There’s no reward for writing code that’s easy to maintain.

Previously, I demonstrated that LLMs are increasing defect density in their generated code and are a source of increased production defects, security vulnerabilities, and other issues.

Defect Density: The number of defects per unit of code, usually per 1,000 lines of code. Why is this important? Because LLM-generated code has more defects than human-written code. The CodeRabbit report takes further and shows 30–41% more tech debt, and 39% more cognitive complexity.¹

Cognitive Complexity: is a measure created by SonarQube that assesses how difficult it is to understand a piece of code.

Some teams think TDD is the fix. They’re solving the wrong problem. Others suggest we can code review our way out of this. That’s not going to work either.

These problems are structural. To understand them, you need to look at how the models are trained and that plumbing hasn’t changed since 2023. Model refinements since 2024/2025 haven’t changed the fundamentals of these models, which are built. If we want to avoid the pitfalls inherent in these models, we need to understand how they are trained and the types of mistakes they make.

The Four Core Flaws of GenAI Code

Training

Pass/fail is all that matters. Training and evaluation systems reward code that compiles and passes functional tests, which creates a “test-taking” mode that penalizes acknowledging uncertainty. There is no reward for nuance models that learn to “bluff” with plausible but overconfident best guesses because 0-1 grading schemes incentivize guessing over admitting a lack of knowledge.³
Benchmarks don’t generalize. A model that scores well on HumanEval or SWE-Bench doesn’t necessarily write good code in your codebase. Worse, some of those benchmarks have contaminated the training data, so even the scores are suspect.³
Trained on the average of the Internet. These models learned from the internet’s code — the same code we used to joke about never copying from StackOverflow. Now we do it at scale and call it productivity.⁴ ⁵
No understanding of design. The model has no coherent grasp of architecture, design patterns, or programming paradigms. It doesn’t know OO from functional — it just predicts the next token.⁶
Silent failures. Newer models aren’t always an improvement. Jamie Twiss reports in IEEE Spectrum⁷ a pattern with recent models that were more likely to silently fail when asked to fix a simple Python error, producing code that looks correct but quietly removes safety checks or fakes output to avoid crashing.

Maintainability

Duplication and Extensive edits everywhere. This occurs because the model doesn’t know where to make changes. That churn destabilizes otherwise-stable code, and bug fixing turns into whack-a-mole.⁶
Your conventions don’t matter. The models don’t follow the patterns in your codebase, making the output harder to understand.⁶ ⁸
Correct but brittle. The reward functions used to fine-tune the models optimize for “does it work,” not for principles such as DRY or CUPID. You get code that passes today and breaks the moment something changes.⁶

OX Security likens this to an “army of junior developers”, fast and functional, but lacking architectural judgment.⁹ They also found the models are excellent at generating test coverage without writing meaningful tests.

Security and Predictability

Security vulnerabilities built in. The models have learned from the average code on the internet. Security flaws and all. So it’s no surprise, they’re excellent at replicating them. Good security is designed in from the start, not bolted on after the fact.¹⁰
Popular choice over good. Given the choice, models default to whatever’s most popular: Python over Rust, React over Svelte, the big library over the specialized one. Popularity isn’t a design decision, but the model treats it like one.¹¹

In addition, Veracode’s 2025 GenAI Code Security Report¹² demonstrates that models can’t simply be trained on better security principles, because security requires understanding context. Is this piece of data under system control or was it entered by an end user? Is this piece of code on an internal system or exposed to the internet?

Your Code base

Blind to your domain. The model doesn’t know your business, your users, or the problem you’re solving. It generates code without context for why that code needs to exist.¹³ ⁸
Scattered sources, incomplete picture. Your code lives in one place, your user stories/PBIs in another, your documentation somewhere else. Even if the model has access to all of it, the connections between a specific user story and the code that implements it are hard to see. So the model never sees the full picture.⁸ ¹³
Context windows have a middle problem. Even large context windows don’t solve this. Models tend to lose focus on the middle, paying attention to the start and end while forgetting the parts that matter.¹³ ⁸ Strangely, the model suffers from similar cognitive biases as we humans³, see: Primacy¹⁴ and Recency Effects¹⁵.

Some of this we try to retrofit by adding more rules or context via Claude.md or Claude/Agent skills. I.E. Explicitly telling the model about the DRY principle or giving it an outline of your project structure. However, that only goes so far. The more we stuff into the Claude.md file, the less room there is in the models context window for the code itself.

We can’t wait for the labs to make this better; it will require a fundamental shift in what they focus on and how they train the models. Since that isn’t happening, we need to find a way to deal with this ourselves. If someone wants to fund a better approach, I’m available. Until then, we deal with what we’ve got.

What gets us out of this mess? TDD? Code Reviews?

Wow, that is a lot of issues. How do we deal with this? Contrary to a few comments, we can’t code review our way out of this mess. That’s putting the burden on humans to tidy up the mess that the AI created. Code reviews are so bad that they will get a blog post of their own. (See also: The Real Cost of AI-Generated Code and Using GenAI to Code? Not So Fast.) And don’t get me started on the idea of LLM reviewing another LLM’s output, again, that’s a misunderstanding of what these tools are good for.

So what about TDD? It helps, but it’s solving the wrong problem. TDD helps developers clarify what they’re solving before how, by expressing understanding as small, concrete, failing tests. It’s a thinking tool, not a testing tool. That makes it valuable for AI-generated code: it forces you to understand the problem before accepting the solution. But TDD operates at the code level. It can’t tell you whether the feature itself is waste. I haven’t seen any evidence that TDD, combined with GenAI, will reduce Technical Debt, duplication, or cognitive complexity. For a concrete example of these quality gaps in practice, see our AI Code Generation and the Tennis Kata experiment.

Where Do We Go From Here?

The models won’t fix themselves, and the labs aren’t prioritizing what matters: well-designed architecture, maintainability, security in context, and respect for your codebase. Some of it can’t be designed in the models no matter how we try.

The Shift Left movement has always had the right idea: Continuous Discovery, Lean Startup Experiments, Lean UX, and real BDD (i.e., collaboration on examples). The job is to build great products, not blindly shovel more defect-laden code into production. When teams automate away collaboration in favour of speed, these quality problems compound.

When it comes to the code itself, give the models smaller, more focused tasks. Start with a small set of acceptance criteria for a single feature and work from there.

Instead of trying to do a better job of building quality into code faster. Why don’t we work on making sure we know what the right product is first? What are you doing to survive this mess? I genuinely want to know.

In our Certified ScrumMaster workshops, we practice building teams that focus on collaboration and quality over raw output.

LLM Usage Note

Parallel.AI for research, NotebookLLM to ground-check claims against source material, and Gemini via Obsidian Copilot for writing critique. Claude Code helps turn the markdown text into mdx file for a blog post.

Footnotes

CodeRabbit, State of the AI vs. Human Code Generation Report ↩ ↩²
Robin Gröpler et al., The Future of Generative AI in Software Engineering: A Vision from Industry and Academia in the European GENIUS Project ↩
Adam Tauman Kalai, Ofir Nachum, Santosh S. Vempala, and Edwin Zhang, Why Language Models Hallucinate ↩ ↩² ↩³
Kaushik Bar, AI for Code Synthesis: Can LLMs Generate Secure Code? ↩
Shuai Wang, Liang Ding, Li Shen, Yong Luo, Bo Du, and Dacheng Tao, OOP: Object-Oriented Programming Evaluation Benchmark for Large Language Models ↩
Mootez Saad, José Antonio Hernández López, Boqi Chen, Neil Ernst, Dániel Varró, and Tushar Sharma, SENAI: Towards Software Engineering Native Generative Artificial Intelligence ↩ ↩² ↩³ ↩⁴
Jamie Twiss, AI Coding Degrades: Silent Failures Emerge, IEEE Spectrum, January 2026 ↩
Jiessie Tie, Bingsheng Yao, Tianshi Li, Syed Ishtiaque Ahmed, Dakuo Wang, and Shurui Zhou, LLMs are Imperfect, Then What? An Empirical Study on LLM Failures in Software Engineering ↩ ↩² ↩³ ↩⁴
OX Security, Army of Juniors: The AI Code Security Crisis, October 2025 ↩
Manish Bhatt, Sahana Chennabasappa, Cyrus Nikolaidis et al., Purple Llama CyberSecEval: A Secure Coding Benchmark for Language Models ↩
Lukas Twist, Jie M. Zhang, Mark Harman, Don Syme, Joost Noppen, Helen Yannakoudakis, and Detlef Nauck, A Study of LLMs’ Preferences for Libraries and Programming Languages ↩
Veracode, 2025 GenAI Code Security Report, July 2025 ↩
Cuiyun Gao, Xing Hu, Shan Gao, Xin Xia, and Zhi Jin, The Current Challenges of Software Engineering in the Era of Large Language Models ↩ ↩² ↩³
The Decision Lab, Primacy Effect ↩
The Decision Lab, Recency Effect ↩

Systems Thinking with GenAI: Solve Deep Team Problems

Thu, 22 Jan 2026 00:00:00 GMT

Inbox zero was sold to us by productivity experts, and yet it never seems to happen in real life. When we take a step back, the pattern becomes clear: Fast responses to email -> People learn you get stuff done -> More requests for your help appear in your inbox -> … . Without a fancy label, we engaged in Systems Thinking, a mental model that looks at a problem not in isolation but as a series of interconnected parts. For once, I will find a use for GenAI.

Systems Thinking Causal Loop Diagram showing email inbox overwhelm feedback loop

What is Systems Thinking in the Agile World?

Systems Thinking is a mental model that views problems as interconnected parts rather than isolated issues, it means:

Looking beyond surface symptoms to find deeper causes
Understanding how changes in one area affect others
Identifying feedback loops that create recurring problems
Avoiding local optimization at the expense of the overall system

Systems Thinking in Scrum Master Training

In CSM workshops, my final major exercise is to give attendees a coaching problem and ask them to consider how they would coach through it.

Throughout the workshop, we cover team-level improvements through:

Retrospectives and clear action items
Working Agreements to clarify how we work together
Improving Product Backlog Refinement
Sprint Backlogs and improving flow
Definition of Done and improving quality
Most groups even ask questions that get us to discuss what motivates people
… the list goes on

Most of these are clear and likely sources of improvement for a good Scrum Master. The final exercise is intended to take them to a higher level, helping them start thinking about the bigger picture and ask why some challenges are recurring problems. The group is given one of several stories about teams that are struggling, and they’re invited to help coach the fictional team. The problems are challenging enough that small improvements at the team level are helpful, but not enough. The idea is to consider many real problems at work and to understand the bigger picture.

My goal is to introduce the attendees to the rudiments of Systems thinking. I give people just a few questions:

What happened weeks ago? months ago? years ago? Many challenges are buried years in the past.
If this continues, what will the effects be in months? years? Delay effects are especially interesting as they hide cause and effect.
Use different perspectives? How would someone with a different background see this situation? How would a manager see it? A senior executive?
If we looked from 30,000 ft, what would it look like?
What assumptions are we making?
…

There isn’t a complete list of questions; I normally suggest attendees look at the Water’s Centre System Thinking Cards¹. However, it’s hard to keep the questions in mind while exploring a problem. I’ve been using systems thinking as a lens or mental model for years, and I still forget to ask some of the questions. For someone new, the whole thing can be intimidating, and that isn’t good.

Using GenAI as a Systems Thinking Coach

I’ve been thinking about how GenAI can aid critical thinking rather than generate more slop. That is when I realized I could create a set of prompts to help with using Systems Thinking as a mental model. I created it as a Claude Skill², so that it can be added to your Claude environment and always be available for use. (The standard has been adopted by OpenAI and others, as Agent Skills so without too much effort, you should be able to use the skill in most LLMs)

Since most people in a workshop don’t already have Claude Code running, they just copied my Claude skill text: https://github.com/mlevison/systems-thinking — specifically this file: references/questions-of-a-systems-thinker.md and put it at the start of their conversations

I also crafted a challenging situation where I thought Systems thinking would help. Let’s run with an example here:

Our Fictional Problem

Case Study: Horizontally Stratified Teams

A senior architect is trapped in what he calls a “vicious death spiral.” His project connects to dozens of external systems, and the Scrum Master decided to split the work: one team handles user stories while another manages technical integrations. Six sprints in, refinement and planning sessions routinely exceed eight hours. Stories arrive incomplete, missing critical integration details. The technical team launches into deep dives the story team can’t follow. Meanwhile, the story team keeps surfacing requirements that expose unexpected integration challenges. Dependencies bounce between groups, estimates become guesswork, and team members mentally check out around hour five.

The architect has watched the same story carry over three sprints because the slicing never works. The Scrum Master keeps extending sessions, believing more time will surface all hidden complexity. The architect is convinced there must be a way to groom, slice, and size stories in under ten minutes. He just can’t see how to get there from here.

As usual with a GenAI model, the conversation is long. I’m excerpting key details and then sharing my response.

Let me start with a foundational question: What organizational forces or constraints led to the decision to horizontally stratify teams in the first place?

My response: In the past, before Scrum, the whole stratified by specialized teams. Since Scrum has come in, nothing has changed. Everyone says it is just more efficient.

The phrase “everyone says it is just more efficient” is particularly telling—it points to an unexamined mental model that may be creating a self-reinforcing loop. … Question for you: When people say “it’s more efficient,” what evidence are they using? Are they measuring:

Individual utilization rates? (people staying busy in their specialty)

Or actual throughput of completed, valuable features to customers?

My response: They’re measuring how much work (output) each person gets done.

There it is. This is a classic systems thinking trap called local optimization at the expense of global optimization. The organization is measuring output (how busy each specialist is) but not outcome (how quickly customer value flows through the system). … What’s happening to the people in this system? You mentioned team members “checking out mentally around hour five.” What are you observing in terms of morale, turnover, or people’s sense of effectiveness?

My response: At the start of each big release people are enthusiastic. As release wears on, priorities change and the pressure to get everything done increases.

The following was the most insightful element of the whole exchange

The system keeps trying to solve a structure problem with a process problem.

Question for you: When a release ends—does the organization do retrospectives or post-mortems? And if so, what explanations do people give for why things took longer than expected? Do they say:

“Requirements weren’t clear enough”

“We didn’t plan well enough”

“The technology was more complex than we thought”

Or do they ever say:

“Our team structure creates coordination overhead we’re not accounting for”?

My response: They tend to comment on the requirements because that is another department.

Visualizing Problems with Causal Loop Diagrams

This could go on forever, and the conversation was already over 300 lines, so I asked: “Before we go any further, let’s visualize what we have so far with a Causal Loop diagram”. Diagrams in the Markdown world are typically done with Mermaid (what a name), and so I rendered them with the free Mermaid editor

Causal Loop Diagram showing local optimization trap in horizontally stratified Scrum teams

This picture illustrates some of the key challenges in the conversation and would make a good starting point for further conversation.

Conclusion: Using GenAI for Deeper Team Analysis

Be careful of taking the outputs of the model too seriously, remember its only job is to predict the next most likely token, it has no understanding. In addition, if you read the much longer version of the conversation, you will see the model made a few logical leaps that would need to be checked.

Systems Thinking a Claude Skill

The skill is found in the repo: Systems Thinking Skill for Claude Code. Please Github issues to make suggestions.

Conclusion: Using GenAI for Deeper Team Analysis

Systems Thinking is most helpful when it is part of a conversation among a group working on a problem together. It is a tool that helps build a shared understanding of the world. The intention of this skill is to make it easier to have those conversations and to ask questions that might have been missed. Please use this with others and not in isolation.

Related Blog Entries

Systems Thinking is much more useful than AI Chatbots for Agile Coaches: Why They Fail
GenAI and the Feature Factory: Automating Away Collaboration - a systems problem where local optimization harms the whole
Agile Bonuses - The Damage They Do - is an example of Systems Thinking
Scrum Anti-Patterns: Micromanagement
Hidden Complexity Tax: How It Kills Organizational Resilience

Footnotes

Waters Centre Systems Thinking Cards: https://thinkingtoolsstudio.waterscenterst.org/cards ↩
Claude Skills are specialized instruction sets that teach Claude how to excel at specific tasks - like creating professional documents, building presentations, or analyzing systems. A big benefit is that skills are only loaded into Claude’s working memory when needed. So our Systems Thinking skill sits in the background, and Claude will pull it in when your conversation calls for it. This saves on tokens and makes it’s use more efficient. ↩

Giving and Taking Design Criticism – with Rebecca Wirfs-Brock

Thu, 25 Jun 2009 00:00:00 GMT

scales with zen stone - image licensed from Photodune

I recently had the opportunity to attend a webinar “Giving and Taking Design Criticism” with Rebecca Wirfs-Brock. The session teaser was: “Have you ever engaged in a design review where people didn’t play fair? Do you have trouble giving design advice that sticks? An effective software developer or designer needs to be skilled at giving, asking for, and reacting appropriately to criticism.”

As someone who has done design/code reviews, I’ve always wondered why the advice didn’t stick and needed to be repeated so often. As a victim of the same reviews, I wondered why the reviewer needed to be so picky and unpleasant Two sides of the same coin?

In this Webinar, Rebecca reminded us what is going on and gave us some tools to do better reviews and be better listeners. She talked about Cognitive Biases (an excellent list >75 biases) and their effect. Key takeaway: Everyone brings a different set of biases to the table, and they cause us to react rather “think and behave logically.”

Presenting

When presenting ideas, keep the following biases in mind (some definitions from Wikipedia):

Confirmation Bias—the tendency to search for and interpret information in a way that confirms one’s preconceptions (Wikipedia). In addition, people will avoid things that disconfirm their biases. To combat this bias, invite the people involved in the review to argue the other’s viewpoint for a while.
Sunken Costs or Loss Aversion—having sunk money into an expensive investment, we’re reluctant to pull out of it. Counteract by telling the audience about the opportunity costs.
Hyperbolic discounting—the tendency for people to have a stronger preference for more immediate payoffs relative to later payoffs (Wikipedia). To counter, break ideas into smaller pieces, each with an immediate payoff.
Contrast Effect—people compare items/ideas against each other and not against a fixed standard. So compare against a lesser option first.
Increase Information Availability—people decide based on what they remember. Complex and uncomfortable information is easily forgotten. Recent, vivid information is easier to remember. Think Garr Reynolds and Presentation Zen.
Ambiguity Effect—people favour options where there is a known probability vs. uncertain options.
Visualize Benefits—reviewers often need to tangibly perceive the benefits. A simple drawing (not a UML diagram, or code) is often helpful in comparing two options.
Primacy and Recency Effects—people remember what they hear first and last.

Advice

Giving and receiving Advice:

Use a triage approach with: Recommendations, Suggestions and Observations. Allows you to share ideas and reduce the defensiveness of the recipient.
Comment on Good choices—reinforce things that the person is doing well.
Use Probing Questions: “are intended to help the presenter think more deeply about the issue at hand.” Examples: Are these ideas complete and accurate? Ask for examples? … (see Changing Minds for more).
Use Clarifying Questions: “are simple questions of fact. … The litmus test for a clarifying question is: Does the presenter have to think before s/he answers? If so, it’s almost certainly a probing question.” Examples: How long will this take? What resources does this require?

Faulty Reasoning

Finally, Rebecca finished with a good recap of the reasoning fallacies (who knew that undergrad logic course would ever prove useful), including:

Red Herring: Distracting with an irrelevancy.
Slippery Slope: Loosely connected statements with a ridiculous conclusion.

All in all, this was a very interesting session. I only wish it had been interactive and not passive so that we retained more of what we there to learn.

Rebecca’s recommended reading includes Wikipedia for Cognitive Biases, Changing Minds, “How to Disagree” by Paul Graham and her own articles: “Giving Design Advice” and “Handling Design Criticism”.

Image via: https://photodune.net/

Good Agendas Make Great Meetings

Fri, 26 Oct 2007 00:00:00 GMT

Agenda - image licensed from Photodune

At Agile 2007, I attended Jean Tabaka’s “Why I don’t like Mondays”. In this session, Jean emphasized the importance of a meeting purpose and agenda. At the time I thought “Well my meetings use the standard Scrum agendas and we get a lot of value out of the meetings.” Wow was I ever wrong. I bought Jean’s book Collaboration Explained and found a revised set of Agendas.

It’s fun to compare the standard review and retrospective agenda

The team demos the product.
What went well? Often a round robin.
What went poorly? another round robin.
What could we improve next time? yet another round robin.

Stunningly we discovered only the obvious issues and did little to fix them.

Compare with what we use now:

Purpose: To demonstrate potentially shippable functionality completed by the team during the sprint, to update the Product Backlog based on the demo and to learn about team practices to keep, change or add.

Outputs: Updated Product Backlog with new items and priorities, any new team practices, recommendations for the next sprint.

Ground Rules:

The core point is to show respect for your fellow team members.
No email or surfing the web.
No side conversations (via IM etc)
No cellphones or blackberries
Join the meeting on time (Global Crossing issues aside)

Agenda for the Review and Retrospective:

What was our commitment for the sprint?
What was our final set of completed items?
What is our demonstration of these items?
What was our final burndown chart?
What did we learn about our estimates?
What changes are there in the Product backlog items, priorities or estimates?
What documented issues/concerns were we able to address? (i.e. from our last retrospective).
What are our current issues/concerns?
What worked well that we’d do again?
What practices would we alter or drop?
What new practices would we want to introduce next sprint?
Based on our last two weeks work what appreciations do we have for individuals? In/outside the team someone who had a particularly valuable affect on our success.
What is our Action Plan?
Have we met the purpose we set out today?

What a difference - we discover new problems and since we have an action plan with people responsible for each item. Things tend to get done. Wow.

To quote one of my team members “the old review and retrospective agenda didn’t help remind her what happened and where we ended up. By breaking things down into smaller more focused chunks the new agenda (and prompting questions) has made our retrospectives more valuable”. Another has said that finally the planning meetings leave them with confidence that we’ve planned well. I just feel ashamed for having taken so long to discover I was running bad meetings.

The agendas in Jean’s book Collaboration Explained also include prompt questions - which help focus peoples minds on the question. Finally I will add that the agendas (she covers Scrum, XP, Crystal) are only a handy appendix at the end of an amazing book. My copy is dog eared.

Image via: https://photodune.net/

How Escape Rooms Teach About Teams

Thu, 19 Nov 2020 00:00:00 GMT

Mark and his wife, Doris, along with a small group of their friends, have become very good at solving challenges and escaping locked rooms.

In their first escape room in 2015, they were two puzzles away from success but failed to get out. So they changed the team membership.

Successful Escape Room Team photo

Over the years, they failed another four or five attempts, but they kept the team together.

Then after one frustrating failure in Jan 2017, they tried again and successfully escaped! It was at this point they realized that they stopped being a bunch of people trying to escape a locked room, and they had become a true team. There was no magic discovery that suddenly made the difference. Part of it was just learning over time how to get out of each other’s way.

This is the general outline of a presentation that Mark gave at the Agile Tour Montréal 2020. Through storytelling, conversation, and a few exercises, Mark helped the audience learn the basics to the science of team building using scientific principles to have more fun, improve, and be successful - in this case, in Escape Rooms, but more broadly, with teams in general.

How Escape Rooms Taught Me Everything I Needed to Know About Teams from Mark Levison, CST

The lessons from escape rooms apply directly to Scrum teams: stable membership matters (why stable teams are important), collaboration beats working in isolation (collaboration over isolation), and the characteristics Mark covers in the presentation mirror the characteristics of effective Scrum teams.

If you would like to discuss having Mark do a presentation for your organization, or at your next Scrum or Agile event, contact us and let us know.

Hidden Complexity Tax: How It Kills Organizational Resilience

Wed, 14 May 2025 00:00:00 GMT

The organizations we work for often pay a heavy but invisible tax: the complexity tax. It shows up in slow decision-making, unnecessary overhead, and warring metrics. In my article “Less is More: Creating Resilient Systems Through Simplicity”, we explored grassroots simplicity - what individual team members and coaches can do to help avoid unnecessary complexity. This article examines deeper examples of complexity that undermine organizational resilience.

We’ve all seen the symptoms: approval by committee, constant need for permission, information silos, etc. Complexity didn’t arrive overnight. Instead, it came one tiny decision at a time. Most of these decisions weren’t harmful. It’s the collective result that hurts. We have a cognitive bias when solving a problem, in that we tend to look for things to add rather than subtract. ¹ But there is no magic solution. Instead of adding things as our workplaces become more complex, we need to ask how to simplify so that our organizations can withstand change and be more agile and resilient.

By recognizing and reversing this dangerous “complicating instead of simplifying” pattern at the organizational level, leaders can build truly resilient enterprises capable of adapting to an unpredictable future.

What is Complexity Tax?

Complexity tax is the hidden cost organizations pay when accumulated processes, structures, and rules slow decision-making and reduce adaptability. Unlike financial costs, this tax compounds invisibly through:

Delayed decisions requiring multiple approvals
Information silos between departments
Conflicting metrics and priorities
Bureaucratic overhead that prevents meaningful work

The result: organizations become fragile instead of resilient when facing change.

Organizational Structure

In software development, Conway’s Law states “organizations build products that resemble their organizational structure”. So when an organization has more departments and committees, it inevitably creates more complex products. Worse, the more groups that touch a product, the longer it takes to get from idea to value delivered. (See Cycle Time and Lead Time).

This isn’t unusual. As organizations grow in size, they often add more hierarchy and structure. The classic mistake is that a small, successful organization attempts to grow rapidly and they start hiring middle managers. Decisions go through an additional layer of people, and communication is reduced. In some cases, the additional complexity contributes to the system’s demise. This isn’t just theory. In the early 2000s, as Nokia did very well with mobile phones, it hired more people to help coordinate the work. On the surface, this helped. Then, as Ran Nyman and Ari Tikka document, the coordination chaos that resulted was a significant factor in the demise of Nokia mobile. ²

Adding additional managers and departments isn’t always bad because the problem isn’t the person or even the role. Instead, the problem is when the decision is made to add a new manager (an increase in complexity) without seeking simplicity first. Once the manager or department is added, people will be invested in this complexity forever.

Decision Making

Remember

You have a complexity problem if you need a flow chart to map out your organization’s decision-making process.

I’ve witnessed organizations where each management layer has an increasing authority to spend money (say, from $5,000 to $20,000, for example). I’ve seen other organizations where individual contributors can make sensible decisions to buy things they need without asking permission first. Still other organizations give everyone a fixed sum of money annually. There are many different approaches but, inevitably, organizations with a more complex approval process have greater waste. Which isn’t unexpected when you think about it. When faced with a painful approval process, people often purchase more than they really need, so they don’t have to ask again.

That’s wasted finances, but what about wasted time? Forcing managers to deal with expenses and other small tasks takes away from their ability to add meaningful value as leaders.

How about wasted opportunity? The same organizations that require a manager’s approval to take training, for example, also have complicated decision-making rules around who is entitled to make product and development decisions. As a result, managers become the bottleneck for decision-making.

illustration of getting lost in the maze of complexity vs a simple decision making processes

After 25 years of Agile, I still see organizations strangling their decision-making process with so much overhead that the teams do low value work, waiting for all of the decisions.

The Agile approach is to push as much decision-making as possible down to the level of the teams and product owner. Instead of trying to make all the decisions perfectly, a resilient system accepts that small mistakes will be made. Instead of avoiding all mistakes, they build mistake recovery into the system.

Rules and Bureaucracy

Many organizations put in place rules and bureaucracy to stop people from doing the wrong thing. Instead, the rules make it difficult for most people to do the right thing. Often, people invent increasingly complex workarounds instead of dealing with the bureaucracy.

As we saw with the subprime mortgage crisis, complex rules don’t provide real protection¹. Each additional rule appeared to help on the surface, however, each addition made it harder to see the big picture. Adding rules doesn’t always protect the system, instead they often make it harder to get quality work done.

When responding to an incident or mistake, first ask what can be eliminated, instead of seeking to add new rules. To help keep things manageable, consider eliminating one existing rule before creating a new one.

Product and Business Strategy

Many organizations have strategic roadmaps that span multiple years. The roadmaps make promises, and the promises become deadlines. The problem, of course, is that a promise made in January has an increasingly high likelihood of no longer being important by August, for example. As a result, many teams are working hard to build things that no longer matter. On top of this, they’re pressured to add new work that wasn’t on the original roadmap to their quarterly goals.

For the same reasons we need resilience in the first place, we need to recognize that long-term roadmaps, with their promise to deliver a list of features every quarter, don’t work. Worse, when teams are held to delivering, they do poor quality work both technically and from a usability perspective.

The Agile approach is to simplify and ditch the long-term roadmap completely, it’s fiction. Instead, Product Managers and Stakeholders talk regularly to make high-level decisions on what to work on next. If long-term roadmaps must be shared with clients, share them without dates and use them to have discussions around high level priorities.

Performance Metrics

“What is measured is managed” is a famous quote I can’t find clear attribution for (often mis-attributed to Peter Drucker). The damage this mindset has done over the past century is amazing. Some quick examples:

During British rule of India, to reduce the cobra population, a bounty was offered for every cobra killed. This had the opposite effect of what was intended because it led to people breeding and killing cobras for income.
In 2002, British officials in Afghanistan were paying farmers $700 per acre for destroying their opium crop. The result was that farmers planted opium to burn it.

Individual performance bonuses lead people to do things that might help get the bonus. This can be hoarding knowledge, refusing to help others and prioritizing your work. I’ve seen salespeople with regional performance bonuses fight over who gets credit for a large corporation buying their product. Instead of fostering collaboration and building client relationships, the salespeople were just as focused on undermining each other.

The more metrics that are in place, the more likely it is that these metrics will come into conflict with each other. For example, Quarterly Sales Bonuses often lead to:

Discounts. If you need to lock in the sale to get a bonus, a 20% discount might do the trick. We win the sale, but it hurts the overall profit.
Pressure on the product team to push more work out the door by the end of the quarter. In these cases, quality always suffers.

In one organization I worked in, we had an annual award to the person who was best at solving difficult customer problems. These same people were so busy solving problems that they also created the quality problems that became next year’s fires.

“Be careful what you measure. You will get it.” - paraphrasing Goodhart’s Law. Another way of saying the same thing is that we will never be able to predict all the interesting ways a measurement will affect the system, so only measure things that matter.

Simplifying Metrics:

Before adding a new metric, can we eliminate one?
Before adding any metric, examine the second-order effects (aka Systems Thinking).

Conclusion

When doing work, always ask the question, how could we simplify this system? What could we eliminate? Every time we make a decision to simplify, we make it easier for the person who follows.

Beware, complex solutions might help in the short term, but it often takes months for the deeper problems to become apparent.

Agile Pain Relief Blog Entries

Footnotes

When Subtraction Adds Value https://hbr.org/2022/02/when-subtraction-adds-value ↩ ↩²
Ran Nyman and Ari Tikka demonstrated from their personal experience that coordination chaos was a contributing factor in the demise of Nokia mobile https://gosei.eu/blog/collapse-of-tayloristic-organizations/ ↩

Scrum by Example - How Sprint Planning Mistakes Can Derail a Team

Tue, 28 Sep 2021 00:00:00 GMT

Sprint Planning is the most underappreciated Agile event. Unfortunately, that leads to a whole host of errors and problems, as we will soon see.

The ScrumGuide says: “Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.”

The Guide goes on to say that the team is expected to cover three topics:

Why is the Sprint Valuable? What can be Done this Sprint? How will the chosen work get done?

So let’s peek in on our World’s Smallest Online Bookstore team that you’ll recall from other blog posts. We’ll use them as an example of a typical Scrum team.

illustration of anxious Scrum team meeting for Sprint planning with the product owner

Dramatis Personae

Steve: A ScrumMaster and the hero of our story

Paula: The Product Owner of Steve’s team

Tonia: Quality Assurance specialist

Don: Director of Development

Tonia: Quality Assurance specialist

Brad: Business Analyst

Ian: Business Logic programming specialist

ScrumMaster Steve creates an agenda for the team’s next Sprint Planning session. The event starts at 9:00 am, and he will allow five minutes for people to drift in. He divides the remaining time (nearly four hours) into four x 50 minute blocks, allowing for a ten minute break every hour. He has allocated one block per topic (Why is the Sprint Valuable? What can be Done this Sprint? How will the chosen work get done?) and leaves the last block for extra time if needed.

Product Owner Paula and the rest of the team met last week to refine the Product Backlog. What can possibly go wrong?

Steve starts the Sprint Planning session by explaining that, during the last Sprint, the team finished six items. Hearing this, the team then agree on their Sprint Goal: deliver five product backlog items and fix two bugs. (Astute readers will have noticed that the team has barely begun, and they’ve already skipped some important stuff. They think they’ve covered Why is the Sprint Valuable?)

They go through the Product Backlog in priority order, selecting the following items:

Reader can add star ratings to a book
Reader can write a review of a book (plain text only)
Reader can add pictures to their reviews
When a review is written by someone who purchased the book through our store, the system highlights their review as a “verified buyer”
Registered site users can click a button to vote that a review is helpful

And then they select the top two bugs to be fixed.

After the Team is done planning the five backlog items and two bugs that they agreed was their Sprint Goal, Product Owner Paula explains that she is under a lot of pressure from the Director of Support to get another feature into the next Sprint. The Bookstore needs to integrate with the support tool HelpFast.¹

Tonia pipes up, “This is just one feature too far.” Brad adds, “And this isn’t a feature we’ve discussed before, so why do they think we can finish it this Sprint?” Paula presses on, explaining, “Being able to log defects directly from the Bookstore will reduce the workload for the overburdened support team.”

Sympathizing with the pressure that Paula is under, the team relent and commit to achieving the new item in addition to the items they had already selected. (They think they’ve covered What can be Done this Sprint?)

Having now selected the Product Backlog items for the Sprint, the team members spend the next hour figuring out how they will get them to “Done”. The plan is challenging, but they think it’s achievable. Since they spent only three of the budgeted four hours, they feel like heroes and use the extra hour of time to work on the Product Backlog Items (PBIs). (They think they’ve covered How will the chosen work get done?). Sprint Planning is finished, so our team rush for the exit and start to do the real work.²

Skipping along to the 8th (or 2nd last) day of the Sprint, the team are in a panic. They’ve mostly completed the integration with the HelpFast support tool, however there are still some rough edges and it can’t be deployed. Two of the book review backlog items are complete, but everything else is half-finished. It’s clear that they won’t meet the Sprint Goal and the quality of work isn’t great.

With great trepidation, the team approach Paula to explain their situation. Ian says, “We overcommitted in Sprint Planning and now we’re behind with lower quality.” Brad explains, “It was the extra feature that killed us. We didn’t understand it well and the effort we put into it detracted from the other items.”

Paula is frustrated, “How do I explain this to the Director of Support? He said that the HelpFast integration was really important to his team right now. How do I go back to the Marketing Director and tell her that our book review system is half-baked?”

Analysis

How did the team get here? Ian provided the obvious answer: the team overcommitted in Sprint Planning. Easy to say, but the challenge ran much deeper than just one problem. Often teams attempt to solve only the surface problem or challenge, but then they play a game of whack-a-mole, where the solution to one problem leads to another.

Challenges in reverse order, from when they happened:

The Developers didn’t ask clarifying questions or spend very much time figuring out how to build the items they had selected.
And while creating their plan for these items, they didn’t involve Paula in making sure they had deeply understood the specific needs represented by the Product Backlog Items/User Stories.
The Developers also didn’t understand the HelpFast integration when they committed to it.
Instead of protecting the team and saying “no” or “not yet” to outside demands, Paula pressured the team to take just one more item (the HelpFast integration) and the team caved in.
Paula raised the importance of the HelpFast integration late in the Planning game. If it was important, it should have been her first priority.
The whole Scrum Team (i.e. Paula, Steve and the Developers) didn’t take the time to discuss why the Sprint was valuable and set a proper Sprint Goal. “Implement five Product Backlog Items and fix two bugs” isn’t meaningful. It’s like going to the gym and saying I want to do bicep curls with 25lbs weights at the end of the week. Why? To win a contest? To look good in someone else’s eyes? To eventually lift a truck?
Steve’s agenda focused on the mechanics of the Sprint Planning process without paying attention to the content and the outcomes.

What could they do differently next time?

Why is the Sprint Valuable?³

Start by having a real conversation about creating a meaningful Sprint Goal. The Product Owner should walk into the room with a rough goal in mind. The team collaborate to take that and make it into something that they co-own with the Product Owner. In our story, a good Sprint Goal might have been “Have basic reader review system in place so book buyers can see a variety of opinions about a book”.

What can be Done this Sprint?

Select Product Backlog Items that support the Sprint Goal. This might not have changed the items that were initially selected, but what would have changed is that, when the pressure for the HelpFast integration came up, the team could have pointed out that it didn’t fit the Sprint Goal, so they would have to either change the Goal or drop the item.

How will the chosen work get done?

Once the team move into this final topic in Sprint Planning, they should take the time to make sure they really understand each item they’ve committed to. The team might:

sketch out the user interface of the items they’re creating
take the time to ask questions about the purpose of each item
break the items down into tasks of a half-day or less in size
clarify vague statements (e.g. instead of “the page loads quickly” specify “the page loads in less than one second”)
discuss who is using the item that the team will be working on. (E.g. Are existing Bookstore users the only ones who will leave book reviews? Can you review a book if you’re a Bookstore user but you’ve not yet purchased it?)
discuss what failures are in the context of this item and how they will be handled. (E.g. If the reader attempts to submit a review with no text, how should the Bookstore behave?)

Overall, one of the biggest things they could do differently is they could start to see Planning as part of the real work. Taking the time to think more deeply about the work we’re about to do can save time and increase quality.

These practices won’t help the Product Owner or the Team avoid potential planning problems, but they will go a long way to creating some rigour in the planning process and reducing end of Sprint surprises, whether from over-commitment or misunderstood items.

Many of these planning problems trace back to poor refinement. For practical fixes, see Product Backlog Refinement Hell: 3 Problems and Solutions.

Image attribution: Agile Pain Relief Consulting (Updated: March 2025)

Footnotes

HelpFast is a purely fictional tool. No real company was harmed in the making of this article. ↩
Hint: thinking that Planning isn’t real work is a trap. When we think that, we rush through the process and miss the chance to avoid many time-wasting mistakes. ↩
These headings are quotes from the Scrum Guide ↩

How to Be an Effective Manager in Scrum

Mon, 24 Sep 2018 00:00:00 GMT

You’re a manager.

You recently helped implement Scrum in your organization. You have received praise for this, because quality of work is now steadily improving and customers are delighted by the steady stream of product improvements.

Your Scrum teams are now self-organizing. Things are flowing so smoothly now, the team has taken on tasks that you used to do.

Did you just work your way out of a job? Are you even relevant anymore?

The good news: you ARE still relevant. And your most valuable work is just beginning.

Why Scrum Still Needs Managers

Self-Organizing Teams are often chaotic, especially in the first few months of implementing Scrum. A traditional manager might be tempted to intervene and guide them along – “Surely they need someone to at least assign tasks?” Nope. It’s an easy, well-worn rut to fall into, but it unwittingly damages a self-organizing team early on. But you resisted the temptation because you knew that it would only cause them to spend more time in the early stages of team formation. Well done! Now that you’ve achieved that important transition, what is the next step for you as their manager?

Traditional vs. Agile

One of the biggest problems with management in the traditional, “waterfall” world is it is often not well-defined. However, to say anything meaningful about Agile management we need a definition of what traditional management does to show how the two differ. The list below is a summary based on “The Wall Street Journal Guide to Management”¹ and the Open University course, “Managing and managing people.”²

How to Be an Effective Manager in Scrum - image owned by Agile Pain Relief Consulting

Traditional Management:

Sets objectives, often in the form of performance objectives or KPIs
Organizes the work (dividing it into achievable chunks)
Makes people accountable and motivates them to do the work
Measures many things, including people’s productivity and the rate at which work gets done
Puts strategies in place to achieve departmental goals
Prioritizes, plans, and assigns project work
Does their own hiring, firing, and performance reviews
Sets policy and helps define it for the organization
Coordinates work among team members
Controls³ the behaviour of people doing the work
Communicates team status and other information to the rest of the organization

Beyond these, in the course of my own career as a manager, I’d also include: set deadlines, make technical decisions, and play favourites.

How to Be an Effective Manager in Scrum - image owned by Agile Pain Relief Consulting

Agile Management

Where Traditional Management emphasizes control, assignment, performance appraisals, and hiring and firing, Agile management focuses on moving from control to capability-building and growing the confidence of people doing the work by helping them find learning opportunities and providing one-on-one coaching.

Instead of managing staff, they invest in team members. They focus on building organizational capacity, flexibility, and strategy, leaving tactical decision-making to the self-organizing teams.

Let’s examine how the above list might change when using an Agile approach instead of a Traditional management structure.

Instead of arbitrarily setting objectives for a Team, collaborates with the Team to determine objectives. The team will feel ownership and responsibility, rather than confusion and resentment if they don’t understand how the objectives were compiled.
Metrics can be useful in the hands of the people doing the work to understand what is going on, but they often cause dysfunction if shared outside of the team. Let the team measure their own rate and performance – they understand what the numbers are telling them and how to make any needed changes. For more see: Measurement For Scrum – What Are Appropriate Measures?
Rather than have a manager organize and assign work with limited understanding of the people, their skills, or time needed, the Product Owner decides on work priorities in the Product Backlog. The Team who will actually be doing the work can clarify their understanding of it during Product Backlog Refinement and plan the work themselves.
Most people, in most circumstances, are already motivated to work. The challenge isn’t motivation but understanding of the vision for the project or product and alignment to strategy. Provide your Team with a clear vision and frequent feedback. Intrinsic Motivation⁴ comes from within the individual — great managers and organizations can help by creating an environment where this is possible, creating a joyful workplace⁵.
Related to this is the strong preponderance of evidence demonstrating that Annual Performance Reviews aren’t effective and should be replaced with regular one-on-one conversations, listening to Team members, and providing feedback.
Business and organizational strategy happens outside the realm of a Scrum Team, so your role as manager remains the same there. But a Scrum Team is well-equipped to take care of their own tactical needs and some of their own skills development. Your job is to ensure the rest of the organization understands your team(s), their needs, impediments and the challenges they face.
It has been abundantly demonstrated at this point that most traditional interview techniques are not effective⁶. What interview techniques do work?
- Structured Interviews
- All interviews stick to standard questions
- Compensation decisions are made independently of the interview team
- The compensation decider isn’t aware of gender, ethnicity etc.
- Focus on communication skills⁷
- Pair programming in the interview⁸
Sadly, the need to fire people doesn’t go away. When it must happen, the authority to do so must live outside the Scrum Team, otherwise the Scrum Team will self-organize according to what they perceive management wants instead of what they need to do their best work.
Management still helps set Organizational Policy, so there’s no practical change in your role in this regard either, the policies themselves will change but Management still plays a large role in designing them. But consciously keeping Agile approaches in mind when setting policy would definitely help. As Herzberg’s work “Two Factor Theory” (motivation-hygiene theory) shows, matters of policy and administration rarely inspire delight from Team members. Given policy is the largest source of employee dissatisfaction and is rarely a motivator, policy ought to be as lightweight and low-impact as possible.

So those are some distinct differences between Traditional and Agile Management. Mostly, though, it’s a change in mindset.

The best managers focus on building organizational capacity, flexibility, and strategy and they leave all of the tactical decision-making to the self-organizing teams.

What doesn’t change is the Manager’s role in communicating with the outside world (although some of this is now handled by the Product Owner). The most significant change is the move from controlling to supporting/developing. Growing the capacity of people to do work is one of the most valuable things managers can do.

As management makes these shifts, we have to ensure that behaviours change and team members perceptions and expectations change too. Many of these points require a bigger conversation, and we’ll discuss them in more detail in the future.

The above is exactly where you will find your role as an Agile Manager. But don’t get hung up on it coming with a shiny new title for your door, because titles are dangerous, as we’ll see in an upcoming post.

Image attribution Agile Pain Relief Consulting (updated March 2025)

Footnotes

The Wall Street Journal Essential Guide to Management by Alan Murray ↩
Managing and Managing People - OpenLearn ↩
Henri Fayol – The source of the “Control” portion of Management – intended ‘Controlling’ to mean the manager receives feedback in order to make adjustments. Fayol’s notion seems somewhat Agile. ↩
Why Motivating People Doesn’t Work and What Does? by Susan Fowler ↩
Why People Really Quit Their Jobs ↩
Joy Inc by Richard Sheridan ↩
Here’s Google’s Secret to Hiring the Best People by Laszlo Block ↩
Why job interviewers should focus on the candidates, not selling their organisation ↩

How to Build a Powerful Team from Scratch

Mon, 17 Nov 2025 00:00:00 GMT

Most teams are not really teams, they’re a group of people who happen to work together. Just because we put the label “team” on a collection of people doesn’t make it true, in the same way that applying a practice such as Scrum or Kanban doesn’t magically create super powers. A working group of people becomes a true team only when they cross a threshold of real collaboration. That’s where the magic kicks in.

Super Powers and Magic of Teams

It isn’t as mystical as it sounds. It’s proven science. When you set a group of people up to truly collaborate, and not just work in isolation, they’re far more effective and productive. They collectively problem-solve to get the right things done faster. Knowing their fellow team members and developing a foundation of trust means that they can feel safe discussing ideas freely, and creativity isn’t stifled out of fear. The shared sense of purpose toward the same goal is motivating. Feeling like you’re part of a bigger thing, with collective ownership and accountability, reduces friction and boosts engagement and morale.

The challenge is that, by and large, as humans we’ve become conditioned to work in isolation, without collaboration, until the problem is too big for us to solve on our own. That’s where Team Launch (or Re-Launch) comes in.

Why Invest in a Team Launch?

A Team Launch can help us cross that threshold and become a true team more quickly and with less friction. Hint: it’s not magic, there is still hard work.

High-performance teams share several essential characteristics that contribute to their success, and a team launch process is designed to help ensure that they’re in place right out of the gate. According to “The Wisdom of Teams”¹, these teams consist of a small number of individuals who possess complementary skills and are committed to a common purpose. They have a specific, challenging performance goal and hold each other mutually accountable for achieving it.

The performance of these teams is underpinned by a collective approach that requires equal contributions from all team members (equal effort rather than skill). It also promotes open interaction, fact-based problem solving, results-based evaluation, continuous improvement, and systematic seeking of fresh input and perspectives from outside the team.

Hold a Team Launch, Step-by-Step

Here are major components and, in some cases, examples and suggestions for how to drill down in more detail. Obviously adapt these to your specific team’s needs.

Sponsor Introduction - The sponsor explains why they are chartering this team.
Team Membership - Who is on the team? (Hint: having part-time team members is a recipe for delays and future challenges.) Remember that there are limits on how big an effective team can be. Nominally, the Scrum Guide says 3-9 people excluding ScrumMaster and Product Owner. This isn’t exclusively a Scrum thing because, having studied the science, teams of 4-7 seem to be ideal, with a hard upper bound at 8 people (again exclusive of ScrumMaster and PO). Of course, if you have 20-30 people, you can still use Scrum, you will just have more than 1 team. See: Large Scale Scrum. (And before you reorganize into Tribes and Squads, read why the Spotify Model doesn’t work.)
Purpose - Why does the team exist? What is its goal? At minimum, the team needs to agree on a Product Vision and Strategy (often an initial Story Map). Without a clear vision and strategy, the team don’t understand what they’re building or how their day-to-day work contributes to the overall product goal. Some teams go further and create a Team mission which outlines their contribution towards the Product Vision.
Product Owner - Who is the PO? What is their availability? What do we do if they’re not available to answer questions? What about missing Sprint Planning or Sprint Review? Vacation? These are all things that, if discussed and known in advance, can avoid issues going forward.
Establish Working Agreements so everyone has a shared foundation of expectations of how they will collaborate (more depth below).
Establish the Team - Outline the skills necessary for delivering the product effectively using a Skills Matrix (more depth below).
Create an initial Definition of Done.
Sprint Events - Review Scrum Events and participation (Planning, Daily Scrum, Review, Retrospectives and Product Backlog Refinement) and decide When/where they’ll be held. Check, do Team members even understand the events? From bitter experience, about 90% of them don’t. When does the Sprint start? Which stakeholders will the team invite to Sprint Review?
Plan - Talk about how you will get to ‘Done’ in the first few Sprints. Pair programming, swarming, limiting Work In Progress? Discuss how you will test your work product. Set up your first Sprint Backlog structure.

How to Create Core Working Agreements

We know from scientific literature that psychological safety is an essential element for teams that perform effectively. Psychological safety is the belief that it is safe to take risks, make mistakes, and it won’t be held against you. All teams, no matter what the environment, make mistakes. The question isn’t whether we make mistakes, but how will our team react to them? In low psychological safety environments. people try to hide and cover up their mistakes. In high safety environments, they’re more likely to admit their mistakes and the whole team learns from them. Working Agreements are a structured way to lay out the groundwork for creating a psychologically safe environment. (Psychological safety doesn’t mean avoiding disagreements or conflict. It means dealing with challenges without blame.)

When creating your core working agreements, the entire team needs to be involved and contributing. Here are some suggestions for common topics to discuss and work into your agreement:

Decision-Making Process and Rules - Establish a clear process for making decisions, including consensus-based decisions or voting mechanisms as needed.
Handling Outside Interruptions - Define procedures for managing interruptions during the Sprint itself, such as setting expectations with stakeholders and limiting distractions within the team.
Protocols and Etiquette for Team Events - What will you do if you’re going to be late? How does the team feel about eating during meetings? Establish guidelines around things like camera usage for virtual events. (Hint: collaboration is more effective when we’re face-to-face wherever possible, even if only on camera.)
Sustainable Pace - How can the team ensure that they’re committing to work that is realistically achievable in the Sprint?
Team Values - Review the Scrum Values and decide how they apply in your world. As a reminder, the Scrum Values are “Focus, Commitment, Courage, Openness and Respect”. Many teams also discuss topics that include collaboration, continuous learning, and customer focus.
Communication Channels - Agree on preferred communication channels (e.g. Slack, Microsoft Teams) for day-to-day interactions and set expectations around response times. (Hint: For many things, instant response is unhealthy. We’re used to responding so quickly that we’re willing to interrupt focused work.)
Collaboration Tools - Choose appropriate tools (e.g. Mural, Miro) to facilitate team collaboration and ensure everyone has access to them.
Celebrating Successes - How will the team celebrate successes?
Handling Disagreements - Establish protocols for addressing disagreements within the team.
Violations of Working Agreements - Define a simple rule on how to point out when someone breaks the working agreements

What a Skills Matrix Is and How to Create One

The matrix is a tool for you and your team to identify what the team already knows how to do. Look for gaps between current skills and what is required to build the product. Take some time to discuss where people want to grow and how that can be harnessed to fill gaps or boost performance. On a personal level, take time to reflect on how you as an individual want to accomplish, and what others need to know about working with you.

While the Kanban/Scrum Board helps the team understand current and recent challenges, it doesn’t do anything to address where the team will likely need new skills going forward, nor where team members would like to grow in their skills.

A skills matrix is a self-reporting system where team members provide their own estimate of their skill in a specific area. To create a skills matrix, get the team to set aside a couple of hours and run a workshop with the following steps:

On a large piece of paper, write down all of the skills you personally have that are relevant to the work. Include your superhero skill (or anything else that will provoke a smile).
Pass your page to the next person. They review your list and add any skills for you that they feel you missed.
Repeat until people aren’t adding any new skills to the lists. Typically this will happen after about three people.
Compile all of the personal lists into a single long list that everyone can see. In skill areas that are of greater value or importance to the team, go into greater detail. For example, inside of Java Development, we might write down specific libraries or tools that team members use.
Team members’ names are written down on one axis, skill areas on the other.
Team members self-rate their skill level in each area. Any scale can be used; for example, mine typically goes from:

Blank – don’t want to learn about this,
0 to 1 – know nothing but open to learning,
2 to 3 – can complete small tasks unaided by an adult,
4 to 6 – expert in the area and others can learn from me

If we compute the average for each skill area, we rapidly get a picture of where the team is strong and experienced, and where it’s weaker.

Sample Skills Matrix

A sample skills matrix showing both non-technical and technical cases

I like to create a Skills Matrix whenever I start working with a new team. Once the Skills Matrix has been created, I recommend teams revisit it every few retrospectives to answer two questions:

“Where have we learned new skills that would cause us to update our self ratings?”
“Where would we next like to put our learning energy?”

An important thing to remember with the Skills Matrix is that it can only be used for the team and by the team. If it is used outside of the team, members will game their numbers to look good, and that destroys the only value of the tool. All too often I hear of organizations where Skills Matrices are a function of Human Resources and the information is used to poach team members for other projects. This approach is 180 degrees from the Agile use of the tool. I’ve also seen it misused by management to pressure team members or in the Performance Review process. If this happens, all value will be destroyed. It is a tool for the team to understand itself. Full stop.

In an organization that is sufficiently mature that it won’t get misused, I like to put the Skills Matrix up on the Team Room wall as a reminder of the importance of ongoing learning.

Conclusion

Whether your team is just starting out, or it needs a reset, a Team Launch is an excellent way to help ground the team and speed their learning process. Assembling a team with intentional design and structure to work from helps them have a foundation of shared understanding, purpose, and respect. This isn’t just about putting individuals together to be more productive. It’s about creating an environment where people thrive, feel supported and valued, and are inspired to do their best work.

Team Launches and team formation are topics we cover in depth in our Certified ScrumMaster training, where attendees practise these techniques with real scenarios.

Agile Pain Relief Blog Entries

Footnotes

“The Wisdom of Teams: Creating the High-Performance Organization” - Jon R. Katzenbach ans Douglas K. Smith ↩

How to Cross-Skill and Grow T-shaped Team Members

Wed, 06 Jun 2018 00:00:00 GMT

As we discussed in “Specialists Are Overrated,” developing cross-skills and “T-Shaped” people in a team has many benefits – for the team/organization itself, the customer, and the individual. That’s all fine and good to say, but how do you figure out where to start?

There are two major ways to discover opportunities for cross-skilling:

Kanban/Scrum Team Board
Skills Matrix

Kanban/Scrum Team Board

How to Cross-Skill and Grow T-shaped Team Members - sample Scrum Kanban board

The Team Board is a rich source of information as to where missing skills exist among a team’s members. If you’re unfamiliar with how a Team Board works or what it looks like, I posted an example of a Kanban Board previously on this blog. Walk along the board every few days, look to see which column work items use up the most time. The board should also help you spot any item that gets blocked or is waiting for outside work. Every time an item is blocked because of an external dependency, record the reason. Over a few months, it will become clear which external dependencies impede work getting done the most. Any of these areas discovered are now opportunities for the team to cross-skill into. Once there is enough evidence to start (perhaps after 3-4 Sprints of collecting), share the data in a retrospective and ask the team two key questions:

Theory of Constraints

Demonstrates that in any system where there is a bottleneck, the rest of the system should be subordinated to the bottleneck until the bottleneck is cleared. Goldratt’s work is, in part, the basis for Kanban and also shows why, in a constrained situation, moving a Developer or Writer from their primary work to the constraint (e.g. Quality Assurance or Editing) is so effective

“What area would we like to put energy into learning?”
“Who has the interest and energy to learn about these areas in the next few Sprints?”

If they do this well, the Team should rarely find itself stuck waiting for an external dependency because it will have grown the skills to handle many previously external dependencies inside the team. In addition, many bottlenecks, like a lack of Quality Assurance or editing skills, will have been resolved when those activities become a constraint¹ for getting work done; the team easily adapts to changing needs.

Using the board as a source of data will also help reveal issues that the team has faced in the recent past. However, it only works as long as the future work looks similar to previous work. So it’s a necessary tool, but one with limitations.

Skills Matrix

A Skills Matrix is a self-reporting system where team members provide their own estimate of their skill in a specific area. To create a skills matrix, get the team to set aside a couple of hours and run a workshop with the following steps:

On a large piece of paper, write down all of the skills you personally have that are relevant to the work. Include your superhero skill (or anything else that will provoke a smile).
Pass your page to the next person. They review your list and add any skills for you that they feel you missed.
Repeat until people aren’t adding any new skills to the lists. Typically this will happen after about three people.
Compile all of the personal lists into a single long list that everyone can see. In skill areas that are of greater value or importance to the team, go into greater detail. For example, inside of Java Development, we might write down specific libraries or tools that team members use.
Team members’ names are written down on one axis, skill areas on the other.
Team members self-rate their skill level in each area. Any scale can be used; for example, mine typically goes from: Blank – don’t want to learn about this and 0 – knows nothing but open to learning, through 2 – can complete small tasks unaided by an adult; up to 4 – expert in the area and others can learn from me.
If we compute the average for each skill area, we rapidly get a picture of where the team is strong and experienced, and where it’s weaker.

Sample Skills Matrix

Cross-Skilling in Scrum Teams

I like to create a Skills Matrix whenever I start working with a new team. If we haven’t started work yet, then I do it at the same time as we create the initial Definition of “Done”, before the first Sprint. Once the Skills Matrix has been created, I recommend teams revisit it every few retrospectives to answer two questions:

“Where have we learned new skills that would cause us to update our self ratings?”; and,
“Where would we next like to put our learning energy?”

An important thing to remember with the Skills Matrix is that it can only be used for the team by the team. If it is used outside of the team, members will game their numbers to look good, and that destroys the only value of the tool. All too often, I hear of organizations where Skills Matrices are a function of Human Resources and the information is used to poach team members for other projects —this approach is 180 degrees from the Agile use of the tool. I’ve also seen it misused by management to pressure team members or in the Performance Review process. If this happens, all value will be destroyed. It is a tool for the team to understand itself.

In an organization that is sufficiently mature that it won’t get misused, I like to put the Skills Matrix up on the Team Room wall as a reminder of the importance of ongoing learning.

Growing Knowledge

Skills Matrices and Scrum/Kanban Team Boards will only get you to the point where you know there is a need for growth, and where. Using that information in Sprint Planning helps remind you to set aside time for skills growth, but we still haven’t grown a skill yet.

T-Shaped people don’t grow on trees.

Cross-skilling is important in every industry, and in each one there will obviously be different approaches to grow these skills. If you are in an IT environment, here are tools that you can use right now to help you grow skills related to software development and design:

Pair Programming – two people work with one computer to produce one work item. Its primary benefit is to reduce the complexity of the system being built, thereby reducing defects. However, another benefit is the rapid spread of knowledge it engenders. “Pair programing [sic] rocks. Taught other developer something last week, he taught to his partner, and I just heard it spread to a 4th team member”². This technique can just as easily be used in non-technical/non-software-related work - Pair Writing³ is just one example, Pair Learning⁴ another.

Coding Dojo⁵ – a safe place to practice, where the team can learn how to learn. A group of team members get together to practice with a programming challenge. The challenge can be any simple programming problem that gives people the opportunity to practice a desired skill (e.g. Test Driven Development, Behaviour Driven Development). Good sources of problems: https://codingdojo.org/kata/ and https://codekata.com/.

Learning Time – related to a Coding Dojo, this pattern formalizes the importance and value of learning. Many organizations expect their people to do professional reading on their own time, however, that sends a signal that work is more important than family or socializing with friends. Consider instead having the team set aside a block of a couple of hours to work on learning. There is a preference for group work, for example a Coding Dojo over personal coding practice; a Book Discussion workshop over individual reading time. Sometimes, instead of reading, it can be a presentation by someone with a different background or skill area for the rest of the team. Learning Time works best when it’s interactive and there is limited formal presentation.

When a team member needs time to read a book, consider asking them to write a short summary of each chapter they’ve read, as a way of sharing their learning back with the team.

Community of Practice – a way of spreading knowledge and skills outside the team. Pick an area that will be of interest to many people outside of one team (e.g. Testing in an Agile world; Use of Scrum Outside of Software). Establish a meeting frequency (e.g. every 4-6 weeks) and time. For the first couple of times, seed the agenda, polling the group to find out what their needs are. By the third event, ideally we want the audience taking control of the community of practice themselves with the goal to make it a self-sustaining entity.

A Final Note

Even with all the cross-skilling in the world, some tasks will always require experts. But cross-skilling still helps in those instances, because the non-experts can help by relieving the expert of simpler tasks so they can tackle the bottleneck.

In the short term, perceived productivity will go down, because learning and growth always slow us down initially. But in the medium term, it improves quality, which increases throughput going forward.

The most important point to remember is that cross-skilling and skills matrixes only work when people don’t feel coerced. We can create the space where people choose to grow and cross-skill, but we can’t force them to learn.

If you want to go faster, stop focusing on the speed. Slow down. Take the time to learn. Focus on the work item and not the worker.

Cross-skilling is most effective when paired with genuine collaboration rather than isolated work. When team members work together on real tasks, skills transfer naturally, which is far more powerful than theoretical study alone.

Other References

Jason Yip – “Why T-Shaped People”https://medium.com/@jchyip/why-t-shaped-people-e8706198e437 Andrew Fuqua on the “Theory of Constraints” https://www.leadingagile.com/2018/03/the-real-first-step-in-the-theory-of-constraints/

Image attribution: Agile Pain Relief Consulting (updated March 2025)

Footnotes

See the Theory of Constraints from Eli Goldratt https://en.wikipedia.org/wiki/Theory_of_constraints ↩
Matt Cholick https://twitter.com/cholick/status/384816643370532864 ↩
Pair Writing - Parliament Digital Service https://pds.blog.parliament.uk/2017/03/29/pair-writing/ ↩
Use Pair Writing to Collaborate with Subject Matter Experts https://gathercontent.com/blog/use-pair-writing-to-collaborate-with-subject-matter-experts ↩
Pair Learning https://www.infoq.com/news/2018/02/pairing-learning/ ↩

How to Get the C-Suite to Support Agile

Thu, 22 Feb 2018 00:00:00 GMT

“I’m not here to experiment. I’m here to get production stacks out the door, and Agile helps us get there.” — Tim Burke, VP of Cloud and Operating System Infrastructure Engineering at Red Hat

Yearly since 2013, Scrum’s certifying body, Scrum Alliance®, sponsors the State of Scrum, a survey of more than 2,000 of their member Agile and Scrum practitioners across 91 countries. The survey data is then analyzed prepared into an annual report. The 2017-2018 report just came out last month and we’ve now had a chance to go through it.

While the numbers were encouraging (particularly the ones that show that once a team or organization becomes Agile, they will almost never go back), one of the most stand-out parts of the report is the short case study on Red Hat Inc.’s adoption of Scrum – a timeless example of how to overcome administrative or executive apprehension about bringing Scrum or any other Agile framework into the mainstream of an organization.

Red Hat, in the business of providing IT product solutions, found itself getting slowed up by traditional “waterfall” structures for building and delivering products to their clients as they got larger. When it came to the implementation of Agile as a solution to this problem, their executive management was concerned that Agile would lead to a loss of control over their ability to deliver.

To overcome this doubt, they implemented a simple approach: use Agile to implement Agile. Instead of rolling out the new paradigm, they integrated Agile methods into their existing waterfall model. Over time, Agile has slowly become the mainstream mindset for work at the company. They focus on how diverse, multinational teams engage and share information, both between themselves and their customers. This emphasizes “individuals and interactions” and “customer collaboration elements of Agile, and is a thoughtful, and focused way of making an organization Agile.

For teams and organizations that are considering following in Red Hat’s footsteps, but like them, find that management is hesitant to commit, there are three things that are always helpful in focusing on when presenting Scrum or any Agile framework for doing work:

Image licensed from iStock

1) Delivering Value

This is, and always been, at the heart of the Agile mindset. Any change that you make to how work is done and how your product is built and delivered should always be centered around delivering valuable software that delights your customers. Any conversation with executives should be framed in terms of how Agile helps the team(s) achieve that goal. Through Agile, your aim is to build a relationship with your client that communicates what their most valuable wants and needs are and then allowing the team to self-organize the team’s efforts in delivering on those, early and often.

2) Improving Effectiveness

When clients we work with ask what Scrum is about, we always tell them it’s about building high-performance teams. When you give teams the space, tools, support, and freedom to do a job well, not only are they motivated to do the work, it encourages them to be technically excellent doing it. Combined with a focus on producing a working, shippable product, creating the best outcome for the customer, and being able to do this continuously, will almost inevitably lead to teams that get more work done, get it done faster, and to higher levels of quality.

3) Participate, don’t Inflict.

In one of our blog posts last month, Mark covered the process of how executive management should go about implementing Agile or Scrum by encouraging buy-in from their teams and getting them to collaborate and join them on the journey to becoming an Agile organization. The same principle applies here. As a team, don’t insist that management adopt Scrum for its popularity or how well it may work elsewhere. Not only will it likely create increased resistance, but the organization will never be Agile if managers are not participants in the change, and will collapse as soon as the organization comes up on any difficulties or changes in management.

If you keep these points in mind, although it may take time, you can demonstrate to executives and managers how Agile is good for the organization, their customers, and their teams.

(Image licensed from iStock)

Human-Powered AI - A Fun Way to Understand How GenAI Really Works

Fri, 12 Sep 2025 00:00:00 GMT

We use GenAI everyday, but have you ever stopped to think about how they work? Are they truly intelligent, or is something else going on? These tools are Mimics. Mimicry isn’t the same as intelligence, is it? So, what’s really happening under the hood of these AI tools?

To demonstrate what these tools really do, I created the Human-Powered Artifical Intelligence Simulation (or HPAIS since the tech world loves acronyms). The world’s first HPAIS was powered up in Canmore Alberta on Tues Sept 9, 2025 at the Regional Scrum Gathering Banff 2025 and it ran for 10 minutes.

You need 5 groups (or even 5 people) and each of those groups has a set of prepared index cards and one die. The groups are numbered 1 to 5.

hand-drawn index card GenAI simulator

When a group is called on, they roll the die. The resulting number determines which of the 3 cards to select. They read the result out and their answer is added to the response.

With an example run at the Banff Gathering, the prompt was “A mysterious package arrived” and the resulting rolls generated this response:

Group 1: “at the front desk of our office”
Group 2: “It was bigger than a small car”
Group 3: “We felt a strange unease about opening it”
Group 4: “So we stood back, observing it from a distance”
Group 5: “A faint scent of ozone and burnt sugar filled the air around it”

In a very simple fashion, we demonstrated how GenAI works. It isn’t intelligent. It selects the next most-likely word (or, more accurately, ‘token’ - a partial word chunk) in the sequence. We also saw that GenAI doesn’t learn and doesn’t have memory. Nothing from the first round of the simulation is carried over to the next round.

ChatGPT 4 has about a trillion times as much data as our human-powered model. So it’s not surprising that ChatGPT and other GenAI tools are better mimics, because they have more parameters. However, they are still not intelligent.

The people who powered the world's first Human-Powered AI Simulator

Play human-powered AI with your teammates to spark discussions around the limitations of GenAI. To create your own version of this game, below is the suggested text for the index cards. You just need to write out the cards and select die rolls to go with it.

Prompt: The mysterious package arrived

Table 1:

Card 1: on our front doorstep.
Card 2: at the front desk of our office.
Card 3: by a large, silent drone.

Table 2:

Card 1: It was bigger than a small car.
Card 2: It was about the size of a shoebox.
Card 3: It was just a single, folded letter.

Table 3:

Card 1: We were eager to open it,
Card 2: We felt a strange unease about opening it,
Card 3: We were genuinely terrified to touch it,

Table 4:

Card 1: so we immediately began to carefully unwrap it.
Card 2: so we stood back, observing it from a distance.
Card 3: so we decided to call for advice or assistance.

Table 5:

Card 1: A low, resonant hum emanated from its center.
Card 2: A faint scent of ozone and burnt sugar filled the air around it.
Card 3: Etched into its surface was a complex, unfamiliar symbol.

There is a lot of uncertainty in workplaces around the use of GenAI, so help your team understand what it is, and isn’t, by playing this simulation and having a conversation about how the resulting understanding of AI limitations should influence the choice of when to use GenAI, and when it’s not beneficial. This kind of hands-on team learning is exactly what we encourage in our Certified ScrumMaster workshops.

Share your ideas for a different prompt and response cards in our Three Percent Better community post. I bet some of them make for very amusing “intelligence”.

Related Blog Entries

In Agile, Where Change is Valued, Why Is a Stable Team So Important?

Wed, 18 Oct 2023 00:00:00 GMT

A stable team is one in which team membership doesn’t change often and, instead, is consistent over time.

Why should we care? Isn’t Scrum like basketball where you can change the players on the court anytime there is an interruption? Let’s find out…

High-performing teams —or teams that gets stuff done with insanely high quality— is the goal of many who arrive in Scrum expecting to get amazing performance out of their system. But building a high-performing team from scratch takes time. The popular picture of Tuckman’s Model of Team Formation shows a team going through the stages of Forming -> Storming -> Norming -> Performing. (Caveat:the picture exists to simplify understanding. The dynamics of a real team will be messier than shown).

Tuckman's Model of Team Formation

It’s easy to form a team and then speed right through the storming stage. Storming is characterized by conflict, as people sort out roles and relationships.

Norming and performing are considerably more difficult in unstable teams, and they occur repeatedly. Every time there is a change in team membership, there is a good chance of returning to storming because of the new interpersonal dynamics. I warn organizations that, when you need to make change, there is a risk that the change will not only send them back to storming, but it might also be damaging enough that the team doesn’t recover at all. How often to you want to roll that die?

Tuckman's stages of team formation in Unstable Teams- image owned by Agile Pain Relief Consulting

Most of the work in academic literature deals with familiarity, not stability. Roughly speaking this means “we’ve worked together enough in the past to understand each other as individuals”. Whether you call it familiarity or stability, the premise is the same – people need time to learn how to understand each other and communicate effectively, the key is familiarity is weaker than stability.

How Stable Teams Affect Quality

When team members are familiar with each other, you see the benefits in the level of quality of work from that team. Take, for example, surgery. I hope most Scrum teams are doing work that is less exciting than surgical procedures, however surgery (for obvious reasons) is well-studied, so it gives us a good source of data.

There’s an orthopedic surgeon who does more than 500 knee surgeries a year, which is 2.5 times as many as anyone else at his hospital. He has implemented dozens of techniques to improve his surgeries. Instead of working with a changing cast of nurses and anesthesiologists, he has two dedicated teams and “he says that few of the methods he has pioneered would be practical if not for the easy familiarity of working with the same people every day.”¹

Killing the patient is the ultimate error. Not killing them is a fairly low bar of quality success. Nonetheless, cardiac surgeons who worked across multiple hospitals but maintained stable teams had a lower rate of mortality, even with more surgeries performed. The study’s authors attributed that level of quality work in part to team familiarity.²

Aviation and aeronautics are also widely-studied fields with data that supports the importance of stable teams. “73 percent of the accidents for which information was available occurred on the first day the captain and first officer had flown together.”³

“A NASA study found that fatigued crews who had a history of working together made about half as many errors as crews composed of rested pilots who had not flown together before.”⁴

And to bring it back down to earth, a study of the Wipro software outsourcing firm found that increased familiarity reduced defects by 19%.⁵

How Stable Teams Affect Predictability

There isn’t any data for predictability of surgeons, which I think might be a good thing.

The Wipro study showed “deviations from budget decreased by 30%”. Let’s ignore the cringing focus on budget, when it should be on building the right product, as it does show that familiarity aids predictability.

In the “Impact of Agile Quantified”⁶, Larry Maccherone showed that stable teams had 40% better predictability.

How Stable Teams Affect Throughput

We shouldn’t really be chasing “more features produced faster” as an outcome. Instead, we should focus on better value and outcomes. That said, I’ve never met anyone who didn’t want to see their team get more stuff done.

At Wipro, “We also found that familiarity was a better predictor of performance than the individual experience of team members or project managers”. More impressive data from “The Impact of Agile Quantified” showed that stable teams are 60% more productive. In many organizations, this is the lever that allows us to unlock the stable teams.

Just remember to focus on outcomes over output.

Why Stable Teams Work

Team Mind (or Shared Mental Model). We know what other people know, and who can be relied on to get certain things done.
Coordination and better collaboration are easier when we know each other well.
Flexibility. Team Mind and ability to collaborate allow the team to adapt more easily when bigger product changes happen.
Continuous Improvement requires the same cast of characters, so we don’t keep on rehashing things we learned months ago.
Team Mind and Continuous Learning Process deepen the team’s knowledge of their problem domain, technical skills and knowledge of their code base.

Why Stable Teams Can Be Difficult

So if stable teams are a good thing, what makes it hard to achieve them?

Matrix organization When team members report to different managers, each manager will have different agendas/needs. As a result, team members may be moved, even when a more elegant solution might work and allow them to remain in the team.
Reliance on outside experts When a team relies on outside help for specialized skills, they often try to include the “expert” in the team. That rarely works well. A better solution is to use them as a consultant/coach but not have them do the hands-on work. Instead, they coach team members how to do the work in question, maintaining the team dynamic and improving skills at the same time.
Organizational Politics Ugh. Enough said.

When Stable Teams Aren’t Desirable

There some cases where the problem complexity (see: Complexity and the Cynefin Framework) is such that team member skills are changing rapidly, stable teams might not be a priority. In this case, we might sacrifice performance, reduction in errors, etc, to have a fighting chance of tackling the problem in the first place. Problems of this nature are incredibly rare. Please contact me if you think you’ve found one, I want to check in.

Reteaming

Sometimes the product that is being worked on is no longer as important, and the organization needs to reduce costs and move team members around. Redgate Software has pioneered a technique to balance stability with adapting to changing market conditions⁷, where the organization annually makes strategic decisions around where to focus. Once the decisions are made, team members can self-select which team they want to move to.

Prefer stable team membership over a cast of changing characters. When you don’t have a choice, examine the circumstances and make sure the organization understands what it is giving up.

If you’re forming a new stable team, see How to Build a Powerful Team from Scratch. When stable teams do need to absorb new members, the guide to onboarding new people covers how to minimize the disruption. And for guidance on how many people should be on that stable team, see What is the Recommended Scrum Team Size?.

Footnotes

The Firm Specificity of Individual Performance: Evidence from Cardiac Surgery - Robert S. Huckman and Gary P. Pisano ↩
A Review of Flightcrew-Involved, Major Accidents of U.S. Air carriers 1978 Through 1990 - NTSB ↩
Why Teams Don’t Work https://hbr.org/2009/05/why-teams-dont-work ↩
Team Familiarity, Role Experience, and Performance: Evidence from Indian Software Services - Robert S. Huckman, Bradley R. Staats, David M. Upton ↩
The Art and Science of Quantifying Agile Performance https://www.infoq.com/presentations/agile-quantify/ ↩
The Hidden Benefits of Keeping Teams Intact https://hbr.org/2013/12/the-hidden-benefits-of-keeping-teams-intact ↩
Reteaming https://medium.com/ingeniouslysimple/reteaming/home ↩

Influence: Science and Practice - other sources

Fri, 03 Nov 2006 00:00:00 GMT

Influence- Science and Practice book cover

](https://www.amazon.com/gp/product/0321011473/&tag=notesfromatoo-20)

After my introductory notes, I’ve received a few inquires about more notes on Cialdini’s Influence Science and Practice. So I dug around on the web and offer up my discoveries.

The best of the bunch (much like my own) is a series in six parts starting on Janin’s (sp?) blog happening-here. Update: Just discovered Marshall Soules class Media studies 205: Promotion, Persuasion and Propaganda. Fall 2006. (at Malaspina University College, Nanaimo BC). Marshall’s course also has an extensive summary.

Other pages of interest:

Scott Foresman’s one page summary: https://pages.prodigy.net/mschnall/cialdini.html
Some good notes from the Mind Hack’s blog
An extended review courtesy of PronettSolutions
Another extended review by Jack Thomas
Back issues of the influence report - a monthly report put out Robert’s company that contain new snippets.
Robert Cialdini’s company offers seminars
Finally the inevitable Wikipedia entry Influence Science Practice

Influence – how and why does it work

Fri, 20 Oct 2006 00:00:00 GMT

Influence- Science and Practice book cover

I’ve never read a book twice and not since undergrad have I taken notes on a book. Yet Robert Cialdini’s “Influence Science and Practice” is so engaging that I’m enjoying a second read.

The book is about the psychology of compliance. How do salespeople (“compliance professionals”) and others get us to do things that may not be in our best interests? Along with the usual scientific experiments Cialdini spent three years doing field research: working, training and interviewing sales professionals, fundraisers and even their natural enemies police and consumer groups.

One of the things that I’ve enjoyed most is the relevance of the book to everyday life. I’m amazed how often that I see the principles that Robert talks about being used. Most recently I noticed the tactics of someone trying to sell me a fixed price gas contract. First he tried to find something we had in common principle: “Liking: The Friendly Thief”. Then he told me ‘all your neighbours have signed up’ principle: “Social Proof”. Finally he concluded with not doing this will cost you money principle: “Scarcity: Loss is Worse”. I felt the tug of his pitch, in the past I might have signed up (and felt like a patsy five minutes later). Now I’m better able to see his manipulative tactics for what they are. I can sit back and analyse the value of his offer (a loss in the ensuing months). Does anyone know where natural gas prices will be in the next five years? Can you predict the futures market for me?

In the coming weeks I will share what I’ve learned about Cialdani’s “Weapons of Influence” and how I’ve seen them used in the real world.

Next up “Weapons of Influence” or why do automatic responses work so well.

Thanks to Guy Kawasaki for helping me discover this book via his Top Ten List and reviewing it here Book Review: Influence—Science and Practice. If the rest of the books on his top ten list are this good I won’t run out of reading for another few years. Now according to the Reciprocity Principle I should just have to ask Guy for a link to my blog.

Is AI Making Your Organization Fragile or More Resilient

Wed, 30 Apr 2025 00:00:00 GMT

“We must adopt AI, it’s an arms race” - I hear this refrain from clients all too often. We seem to have forgotten that AI is just a tool. Like any tool, it can be used well, making us more effective. But it also works rapidly and has an outsized effect on our work, so caution and discretion are needed.

Remember to consider and ask, when we change a system, what other effects will this have? What are the second-order effects? (There is a whole body of work called Systems Thinking that helps explore this in far more depth.)

I’ve created a few simple questions to help decide if we’re using AI in the right place.

Are we helping at the bottleneck? Inside any team or organization, there will be a bottleneck to delivering value. (Theory of Constraints). If we speed up work ahead of the bottleneck, we just make the bottleneck worse.
AIs are creative (that’s good), but that same creativity will lead to errors. Do we have enough safeguards in place to catch the mistakes? Can we afford errors in the part of our system where we use these tools?
Catching the errors requires increased critical thinking and more focused time to do that thinking. Are we allocating enough time for this so it won’t be stolen back for another purpose?
Does our use of AI improve Simplicity, or make things harder to understand? One of the key reasons for the 2008 financial crisis was that the lending system had become too Complex, so no one understood everything that was happening.
Is the AI usage increasing Collaboration or harming it? Agile approaches bake in the principle of Collaboration, but using AI can reduce it if we’re not careful.

Contrasting uses of AI that weaken or strengthen your organization - Image Created with the use of Napkin.AI

Why AI might be harmful

One of the primary things that makes organizations fragile is adopting new technology without understanding its impact throughout the system.

Technical example

Data from a report by GitClear¹ indicates an increased reliance on AI for code generation. Code duplication is up, refactoring is down. AI allows us to go faster now but increases the technical debt we have to pay down later. Further, the DORA metrics² showed that deployment rollbacks increased in 2024. This is likely tied to an increase in defects. When reading the DORA report³, I was shocked that it didn’t make the obvious linkage with the increased use of AI to write code.

Although we will never see a smoking gun, I can already see AIs killing products and companies by burying the team in technical debt. Using AI to write code today will give technical coaches good work for years.

An increase in code duplication, defects and rollbacks means the AI generated code is making the system more fragile. Generating technical debt faster is not a good thing.

Drug Discovery example

The Globe and Mail ⁴ reported that, in several Canadian companies, AI made it faster to find a new molecule. However, did that solve the real problem?

I’m not doubting that it can get us there a little bit quicker,” said Brian Bloom, CEO of Bloom Burton & Co., a Toronto investment bank focused on health care. “But in the 10-year journey of drug development, you may be saving five months.

In pharmaceuticals, the bottleneck in the system is proving that the drug works, not the speed at which they find candidates. Even if the AI model was better than people at finding a candidate drug, it still requires 10 years of human trials. Further, for the drugs described in the article, most of them may be no better than the ones people find without using an AI.

Deep Genomics was trying to use 40 different AI models in their process. It became messy and unsustainable, making their system fragile.

In the above examples, AI has been used where there wasn’t any bottleneck. At a minimum it has wasted time and energy that could have been used to make improvements at the bottleneck. If they had considered the second-order effects, they either wouldn’t have used AI at all, would have put safeguards in place (to avoid duplication, defects etc), or better, they would have used it to help at the real bottleneck. In the software development world, the safeguards to avoid these problems don’t currently exist and so we rely on the individual team member to engage in more critical thinking. There is no evidence to show that is working well.

It’s not all bad. Let’s turn to the good.

What is Generative AI good at?

Finding patterns

Generative AIs are large-scale pattern recognition tools. They’re helpful at spotting patterns that we humans miss. Caveat: beware the false positives and incomplete answers. AIs can find a pattern that isn’t supported by the data, building relationships with things that aren’t related. When conducting weekly and quarterly review sessions, I use these tools to analyze my personal notes. It always makes connections between unrelated items. It also misses patterns that I can clearly see. So why use it? Because it often spots something I missed in my notes. At Product Camp Ottawa, several attendees reported using a GenAI to transcribe and summarize interviews. These people still took the time to read the transcripts, however, the tool saved them several hours of typing to compile their notes like they would have done in the past.

Building a Rapid Prototype

A Product Owner I met recently showed a prototype of his next great feature. He hypothesized that he could speed onboarding for new clients by retrieving key marketing assets directly from their websites. He used GenAI in several places.

First he used Claude to generate prototype grade requirements from a rough idea. Then he used Cursor - an AI programming tool - to generate the app. This enabled him to take his feature from idea to working prototype in only 3-4 days of work. Instead of talking theory, he used the prototype to show his leadership the value of the feature. He got a green light and the engineering team have since built the feature with the care needed to make it sustainable.

Creating Automations

Many small repetitive tasks deserve to be automated, but creating the automation takes time and effort. Generative AI can be very useful at creating automations, especially ones you can easily verify. The AI was useful at taking the drudgery out of creating the automation, and the risks are low because we can verify the result with little effort.

In these cases, the Generative AI was useful because:

Critical thinking was involved
Results could be verified
Duplication and Technical Debt were acceptable (e.g. the prototype)

Bottom Line

The promise of these tools to speed up our work is enticing. But we need to ensure that we’re always asking questions about whether their use will make our systems more resilient and not more fragile. As with anything Agile, we should be assessing the effect of the tool(s) on our system and constantly checking second-order effects, and not just succumb to the promises of the shiny tools vendors. Building this kind of critical thinking into your team is something we practice in our Certified ScrumMaster workshops.

Related Blog Entries

Footnotes

Git Clear AI Assisted Code Quality Report - 2025 https://www.gitclear.com/ai_assistant_code_quality_2025_research ↩
DORA isn’t the child’s cartoon, I still have that in my head. Instead it is this. https://dora.dev/research/2024/dora-report/ ↩
DORA Report 2024 – A Look at Throughput and Stability https://redmonk.com/rstephens/2024/11/26/dora2024/ ↩
Drug Discovery: AI’s Unanswered Questions https://www.theglobeandmail.com/gift/fd9cc6d9dbcf2822e38fa0672568af66ce83a833a12319d6ee09c3b5b4e54d7e/LNNHNIEZ4VHB7D2J2F43G5EYEA/ ↩

Is Your Scrum Team Good Enough?

Tue, 28 Mar 2023 00:00:00 GMT

If your Scrum Team has been together for years and you’ve been following the Agile principles and Scrum structure, you might be feeling quite confident. Scrum isn’t an inherently easy methodology to adapt, especially since it requires change beyond the personal behaviour level to see the biggest results. So if your team has gotten to the point that your retrospectives are empty and your improvement list is slim to none, pat yourselves on the backs!

… And then put your arms down, because there is still much work to be done.

Many teams stop growing because they become satisfied with the status quo. The ScrumMaster is expected to challenge them to continue growing. Just because your team has stagnated and you don’t know where to improve, doesn’t mean that you can’t be even better. Good is good, but great is better. And if you’re a ScrumMaster, your role is critical in that evolution. In fact, it’s your responsibility to not rest on laurels, and to tackle some of the more advanced, but incredibly beneficial, aspects of Scrum.

Scrum by Example Team Member ScrumMaster Steve - image owned by Agile Pain Relief Consulting

Is the ScrumMaster a Temporary Position?

On a regular basis, I have people ask me, “The ScrumMaster role can’t possibly last for more than 6 months, can it?” and “Does a team benefit from the ScrumMaster being full time or is 33% enough?”

Since many invest time and money into becoming a Certified ScrumMaster to advance their career, that seems like an important thing to know. But before we answer those questions, you need to first know the answers to these:

What is the purpose of Scrum?
What is the purpose of the ScrumMaster?

Luckily, we can find those answers in the Scrum Guide. “Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”

The Guide goes on to say that the ScrumMaster role is “accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.”

The Scrum Guide assigns responsibilities to the ScrumMaster under three general groupings: serving the team, the product owner, and the organization. Many of these often get ignored. Do yourself and your team a favour and review it frequently.

The Scrum Master serves the Scrum Team in several ways, including:

Coaching the team members in self-management and cross-functionality;
Helping the Scrum Team focus on creating high-value increments that meet the Definition of Done;
Causing the removal of impediments to the Scrum Team’s progress; and,
Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

The Scrum Master serves the Product Owner in several ways, including:

Helping find techniques for effective Product Goal definition and Product Backlog management;
Helping the Scrum Team understand the need for clear and concise Product Backlog items;
Helping establish empirical product planning for a complex environment; and,
Facilitating stakeholder collaboration as requested or needed.

The Scrum Master serves the organization in several ways, including:

Leading, training, and coaching the organization in its Scrum adoption;
Planning and advising Scrum implementations within the organization;
Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
Removing barriers between stakeholders and Scrum Teams.

If we walk through every element of this, the blog post will be 7–8,000 words long which, in itself, is a hint that there is much more to the ScrumMaster role than is often explored. So I will highlight only a few key items.

Coaching to self-management, what does that require?

Ensuring the team understands its purpose
Helping the team establish role clarity
Finding what motivates each team member
Helping the team to create working agreements for team effectiveness
Empowering team members to make their own decisions
Ensuring that all members of the team have an equal voice, not just the loudest (Cough, cough - I was often the loudest person on a team. Sorry about that.)

Depending on the prevailing culture in the work environment, some of these, like empowerment and equal voice, may take more time to establish and the ScrumMaster is responsible for creating an environment that allows and encourages that to happen.

Coaching to become cross-functional

The team will need to learn skills outside of their normal area of expertise to keep things moving whenever some of the team gets stuck or there are bottlenecks in an area. Ideally cross-skilling starts early, however it will take many months before it becomes habitual.

The ScrumMaster is responsible for coaching team members to pay attention to bottlenecks in the system and for facilitating this learning. Sometimes cross-skilling goes against the corporate grain, on other occasions team members would prefer not to learn new skills or feel reluctant to work outside their comfort zone. Cross-skilling](/blog/how-to-cross-skill-and-grow-t-shaped-team-members/) is critical to an effective team, so it falls to the ScrumMaster to coach in this situation. The ScrumMaster is going to need a good understanding of human [motivation and also how to influence effectively to help people, and organizations, see the benefits and come around.

Creating high-value increments that meet the Definition of Done

This is a very subtle one. Most teams (Scrum or otherwise) struggle to deliver high-quality product at the start. Scrum expects the team to grow their skill and collaboration to improve quality. As a team meet the existing Definition of Done, they’re expected to add more rigour to it. As the rigour increases they will need to slow down for a period of time until they’re more technically skilled at achieving Done. Once again, as they get good at meeting Done, they should increase the rigour. (Hint: this quality improvement cycle should never stop).

DevOps Some teams are satisfied with a product that they hand off to another group for deployment and monitoring. From a Scrum perspective, this is a strange choice. A Scrum team should keep improving Done. In the world of modern software development, the Scrum Team should be embracing a DevOps mindset: the team that builds the product is responsible for deployment and monitoring. Caveat, from experience it can take more than a year for the team to build this degree of technical excellence.

After all, the customer doesn’t see the value of what the team delivered until it is deployed. And if it’s delayed in getting deployed by a different group, that increases the cycle time and so, from the customer perspective, the work is delivered slowly. Even in the modern age, I’ve seen Scrum teams deliver working software every two weeks only to be stuck waiting 6+ weeks for their work to get released. In addition, as the application is being prepared for deployment, problems are often found. The longer it has been since the original work was done, the more time it will take to remember what was going on and fix the problem. Building to a high-quality definition of done and releasing it, all within the same team, finds and fixes problems faster, avoids confusion and conflict over responsibilities, and delivers to the customer quickly.

DevOps Mindset Kanban Board

Agile Engineering Creating high-value increments isn’t limited to DevOps improvements. Teams also benefit from learning to practice the many Agile Engineering practices, from Ensemble Programming to Trunk-Based Development.

ScrumMaster and Product Ownership

Some see the ScrumMaster as having only the responsibility of ensuring the Product Owner established the Product Vision, a Strategy (i.e. StoryMap), and Backlog Refinement. That is a good start, but by no means all that they can - or should - do. When a team has a casual relationship with the Product Owner and the Product Backlog, we have a higher likelihood of quality issues or rejected Product Backlog Items in the Sprint Review.

One way an effective ScrumMaster serves the Product Owner is by coaching the team to have a broad and deep understanding of the Product/Consumer/Need, illustrated here as a Scrum Product Team.

Scrum Product Team

The team implements this in areas such as Behaviour Driven Development (aka BDD) to ensure that the acceptance criteria for a given Product Backlog Item are both clear and agreed on by all. Many ScrumMasters are also discovering that it helps to coach their team in Lean Startup and Lean U/X.

Becoming Lean Lean Startup is useful when the team needs do fundamental experimental work answering questions such as: Will anyone pay for this product? Is this module or large feature area useful to our audience?

Lean U/X involves the whole Scrum Team in improving the experience of the consumer in using the product.

Continuous Discovery Some teams go further still, working with the Product Owner in the Discovery process, ensuring the whole team has a solid understanding of the customer need at that moment. (The best description of this process remains Teressa Torres Continuous Discovery Habits). Like the Definition of Done, all of the improvements the team make to working more effectively with the PO will take time and slow the team down. From personal experience, teams take well over a year to work their way through these skills.

Serving the organization

The ScrumMaster is responsible for looking at the systemic issues in the organization that harm the Scrum Team and their ability to deliver. They’re expected to help others see these issues and then coach their resolution. They might need to coach Stakeholders on appropriate moments to interact with the team (e.g. Sprint Review), and help them see the costs when they interfere (e.g. Hidden or Ghost Work).

Wait, You Didn’t Answer the Earlier Question

Will being a great ScrumMaster lose me my job?

You’re correct, I didn’t answer this, and here’s why. An effective Scrum Team isn’t measured by its velocity; Scrum isn’t about the team churning out more User Stories. Scrum, for all of its simplicity, is actually very complex, and practicing it doesn’t equal using JIRA. When the focus is placed in the wrong place, Scrum is reduced to a mechanical task management system and Developers are turned into robots. It’s not listed explicitly in the Scrum Guide, but it’s a ScrumMaster’s responsibly to not let that happen.

Instead, effective Scrum Teams should eventually discover all of the things described above until they look like a truly cross-functional Scrum Team. Clearly no team will get to this point after six months. I can’t imagine a team getting there in less than a year.

Truly Cross-Functional Scrum Team

Once the team is truly self-organizing, the ScrumMaster should become less and less important. But there are still risks if/when they leave the position:

Will the team fall back into old habits?
Will they keep being challenged to grow?
What will happen when a new team member joins the team? Or an experienced, reliable team member leaves?
Who will tackle the systemic issues in the organization? This may be the hardest part of Scrum. It doesn’t make it any less important. There will come a point where any effective team (Scrum, Kanban or otherwise) runs into limits imposed by the organization. Without fixing these issues, progress of all teams would be limited.

There are also risks if one ScrumMaster stays with the team forever:

The team might become complacent.
The team/organization become dependent on the coach to help them find and solve problems.

Does a Scrum Team need a ScrumMaster full time as they go through the process of discovering and mastering all of these skills? Only you can make that call. But certainly in the early months and years of development, having reliable and consistent access to a ScrumMaster who offers that service and coaching will bring greater benefits than not.

I can say that we all benefit from having a coach. From my own personal experience, my periods of greatest growth have been when I talk to my coach and discover all of the new opportunities standing in front of me. Also consider that, in a complex environment, just as we think things are tidy, safe and well established, something new (e.g. pandemic) shows up to destabilize again.

I suspect the fundamental question that needs to be answered is what are the limits to growth for a Scrum Team? If your team is stuck inside very tight limits as illustrated by the “Typical Scrum Team” arrow, then the team will run out of growth opportunities sooner. In this post I’ve illustrated a few areas (among many) of possible improvement:

high-value increments (DevOps Mindset, Agile Engineering Practices)
broad and deep understanding of the Product/Consumer/Need (Lean, Continuous Discovery)

Some teams improve first by going downstream (DevOps), others upstream (Continuous Discovery), and some improve in both directions at the same time. There is no recipe, just opportunities.

Exploring any one of these with a team will likely take a large chunk of a year. Together, they represent years of work. So, yes, in theory eventually a team might hit a limit where the ScrumMaster is no longer contributing to the team’s growth, however few teams attempt to achieve truly cross-functional Scrum Team status and, even those who do, remain vulnerable to change where coaching would be needed again.

If you’d like to learn more about how to take your team from “good” to “great”, consider our Certified ScrumMaster training. We also offer regular online meet-ups where you can discuss ideas and challenges with Mark and others, and we’d love to hear about your experiences.

Images by Agile Pain Relief Consulting.

Is the Scrum Guide Wrong About the Product Owner?

Thu, 02 Oct 2025 00:00:00 GMT

A recent conversation¹ reminded me that the ScrumGuide says neither the ScrumMaster or Product Owner are required to attend the Daily Scrum. But does that mean that they shouldn’t attend? The Scrum Guide is overly formal and can be hard to interpret. (I get it, I tend toward the formal too often myself).

Here is the entire section on Daily Scrum from the ScrumGuide:

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

The key sentence is: “If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.”

Translation: So if they’re doing stuff for the team, they should attend the Daily Scrum - not as important people but as regular team members.

Good? Bad? Or just poorly written?

Let’s step back and consider why we hold Daily Scrum.

Why Daily Scrum?

The intent is to inspect progress toward the Sprint Goal and update the Plan/Sprint Backlog based on what we learn. When I’m helping people understand Scrum, I frame Daily Scrum as having three main purposes:

Transparency - Check our progress toward the Sprint Goal
Replan - Update the Sprint Backlog
Collaboration - Daily Scrum gives us insights into what others are working on and where we can help. (Hint: Pair Programming).

What is the Product Owner’s Role?

The Scrum Guide defines the Product Owner’s role like this:

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.

It says a bit more than that, however this is enough for our purposes.

So if their job is to help maximize value for the team, should they attend Daily Scrum in their role as the PO?

Should the Product Owner Attend Daily Scrum?

It seems simple. If they can help increase value, they should attend. When do they increase value? Most of the time.

Here’s what I’ve seen work:

Clarifying user story questions immediately: If it is quick, they can clarify in the moment. If not, they can help right after the Daily Scrum.
Request a Demo:They hear about progress and want to know more. They can ask for a quick demo right after the Daily Scrum. They get a better understanding and often help by making minor suggestions. (Hint: the team have a right to say “not yet” if the suggestion isn’t minor.)
Sprint Goal: They keep up to date on progress or impediments related to reaching the Sprint Goal. If the team is missing information about a user story/feature, the Product owner can go find answers. If the impediment is access to resources outside the team, the PO might have the influence to get it.
Sprint Backlog Updates: The PO can stay informed about changes to the Sprint Backlog and provide support if needed.
Collaboration Opportunities: The Product Owner can help by testing usability or digging into the details of acceptance criteria.
Product Backlog Updates: Occasionally, the PO will learn something from the Daily Scrum that helps them reprioritize the Product Backlog.

When should they not attend?

If they’ve not yet learned to balance their authority with the rules of the Scrum game. For example, some POs will yell “fire” in the middle of a Sprint and demand a new User Story.
If they’re acting as an order taker for stakeholders, rather than the person responsible for maximizing value of the product.
When there’s a risk of micro-management. Some POs will try to use Daily Scrum and other opportunities to look over people’s shoulders and tell them what to do. Micromanagement is an Antipattern
When it inhibits open communication. Team members may not feel comfortable sharing information with the Product Owner. If this is the case, I would suggest that the Scrum Master works on improving Psychological Safety.

Takeaway

I think the Scrum Guide is either poorly framed or outright wrong on this point. The Product Owner should attend the Daily Scrum. All of the cases where they shouldn’t attend, are cases where they’re not playing their role well. (With the exception of micro-management, in which case it might be the wrong role for them to be playing). So if PO’s attendance at Daily Scrum is harming the team, the Scrum Master should be coaching the PO on how to play their role more effectively, and/or improving psychological safety. In the long run, the Product Owner should attend Daily Scrum as the Product Owner and not as a Developer.

As for the ScrumMaster attending Daily Scrum, that’s a whole different conversation for another day.

Join us for our next Lean Coffee where you can ask questions and practice helping others.

Image attribution: Agile Pain Relief Consulting (August 2025)

Footnotes

Thanks to Nenad Vukobratović for starting the conversation in Lean Coffee ↩

Is There a Best Day to Start and Finish a Sprint?

Wed, 11 Oct 2017 00:00:00 GMT

No, of course not. So when should your Team start and end Sprints? The usual rules of Scrum apply – ask the Team. Run an experiment.

Calendar image licensed from Photodune

There is an instinctive tendency to want to wrap up things at the end of the work week so we can unplug our brains for the weekend, and start things at the beginning of a new week. This is the biggest reason people cite for choosing Monday to Friday for Sprint cycles. But this doesn’t take into account some factors that your Team may want to consider:

Long weekends force changes to your schedule, and will take out either your Sprint Review and Retrospective, or your Sprint Planning, if that’s how your Sprint cycle lines up.
Friday afternoons are when people tend to be mentally checked out, thinking about weekend plans. Effective Retrospectives require attention and engagement, but holding them on Friday afternoons are more likely to lead to hurried and half-hearted participation.
Monday mornings blues are a real thing. We’re either half asleep, reliving the weekend, or sad that we’re back at work. Putting Sprint Planning on a Monday leads to low energy input.

So, my personal preference is to start and end Sprints somewhere in the middle of the week. But your team should run experiments and discover what works for it! You’ll make better discoveries that way than by just taking my word for it.

(Image attribution: photodune)

Is there Value in the Noika Test

Tue, 28 Oct 2008 00:00:00 GMT

A few years ago Bas Vodde defined a simple test to help his coaching group determine whether teams were trying to be agile and whether it would be worth investing coaching time with these teams.

As described by Joe Little, the test is:

The Nokia Test is in two parts. First, are you doing Iterative Development?

Iterations must be timeboxed to less than 4 weeks

Software features must be tested and working at the end of each iteration

The Iteration must start before specification is complete

The experience is that if you ask a lot of “Scrum” teams if they can pass this part of the test, they can’t. If you are at a conference, often not a single team in the room. The next part of the test checks whether you are doing Scrum (in Nokia’s opinion):

You know who the product owner is

There is a product backlog prioritized by business value

The product backlog has estimates created by the team

The team generates burndown charts and knows their velocity

There are no project managers (or anyone else) disrupting the work of the team

Then recently on Scrum Development, Michael Dubakov started a long-winded conversation by saying: “I don’t think it is a good idea to have such tests at all.” I think Michael’s premise is good, but do see value in a set of questions as a starting point for a conversation. As a coach I use a larger version of this test to give me an idea where teams are at. It’s not the be all and end all but it can be a great starting point - i.e. here are the areas that bear closer examination. Example: In a team of seven every team member but two say the team is doing TDD. Hmmm, what’s going on. Ask more questions.

On the other hand if you actually look and care about the numerical value then you’ve missed the whole point.

What’s your take? Have you used the Noika test or something similar? Did it start a conversation? Did provide value?

It’s not Scrum if…

Wed, 18 Sep 2013 00:00:00 GMT

The rules of Scrum are simple, but too often people forget that to actually do Scrum requires spirit, passion, engagement – and involving the whole team.

This is a lighthearted list of some of the many things I’ve seen going wrong. It’s not Scrum if…

Scrum Implementation Problems and Alternatives

Problem	Why it’s a problem	An alternative
…the team is told what their velocity is.	Velocity is a tool to help predict when you get a certain number of features complete and to plan for the next Sprint. It’s not a proxy measure for productivity.	Allow the team to discover the rate at which they complete their work.
…a burndown, burnup or cumulative flow diagram is confused with reality.	All of these charts are models that give you an idea what is happening. They only measure quantity, not quality; nor what has been completed.	All these charts are useful. Instead of looking for better charts, try “Genchi Genbutsu”:Go See for Yourself. Visit the team and see what Features are complete as part of Sprint Review.
…you’re using the Scrum Task board to micromanage team members.	I hope this is self-evident.	Scrum is focused on the success of the team. Allow self-organization to have a chance. Teams need to learn for themselves how to work most effectively together.
… you enforce Best Practices.	No matter how good the practice (i.e. Test Driven Development, Unit Testing, etc.) enforcement breeds resentment, and compliance without understanding.Scrum is trying to harness the diverse ideas and opinions of the whole; not just an anointed few.	Allow each team to grow/evolve its own practices. Provide them with support and the best information available. They will often find better options locally. Focus on outcomes, i.e. working software shipped every two weeks and not practices.Create community of practice to socialize and share.
… the membership of teams changes frequently.	Creating a high-performance team requires stable team membership.	Create stable Feature Teams.
…you treat your Product Owner as a Business Analyst with a better title.	The Product Owner needs the ability to see the big picture with a product, and the authority to make decisions that cost 1-2 team Sprints (perhaps $150,000) without having their choices overruled.	Find dedicated people who understand the Product area, give them basic Scrum Training. Trust them to make the right decisions at the Feature level.
…you magically turn all your Project Managers into Scrum Masters.	Many Project Managers don’t want to be Scrum Masters.	Ask people what role they want to play going forward. Give them a short period of time to play that role and see if it’s a fit. Don’t make assumptions based on their current title, role, etc. Finally, remember not all people are compatible with Scrum.
…your existing organizational structure remains the same.	Scrum Teams require less formal organizational structure and more coaching.	Agile organizations typically become flatter and more flexible over time.
…you spoon-feed teams their User Stories or Features.	When people aren’t engaged in creating the Stories/Features from conception to deployment you reduce understanding and engagement.	Co-creating knowledge is more effective than knowledge transfer. Involve the team in creating the Product Backlog.
…you break the Stories down into tasks for the team.	Same as above; you’re detaching people from the Story they’re building.
…you maintain your existing roles, i.e. Developer, QA, BA, and Usability.	Formal roles create bottlenecks and foster individual work. In addition, they encourage handoffs.	Scrum wants collaborative work. At the team level, ignore all formal titles. Our goal is high quality working software, not handoffs.
…your Impediments Backlog remains unchanging.	Scrum is about improving the way we do work. An unchanging Impediments list/Backlog signals that no one is engaged in making things better.	Select one or two Impediments per Sprint; find something small to improve related to them. Practice true Kaizen (a continual dissatisfaction with the current state). Often the smallest improvements have a huge effect on morale.
… you have phases – Requirements, Design, Development, …	There are no separate phases.	Scrum Teams are expected to produce working products in the first Sprint. In practice this is hard to achieve at first, yet remains the goal.In addition, we don’t have separate phases within the Sprint. The most effective teams find ways to create Acceptance Tests before starting the Development work.
…you keep repeating the same actions and getting the same results.	Scrum is intended to challenge the status quo. When you create a new status quo, Scrum challenges it again.	Scrum invites a true Kaizen mindset – Congratulations! We’ve achieved a great improvement which allows us to see an even greater improvement just ahead.
…you focus on the tools and not the people.	Remember: Individuals and Interactions over Processes and Tools	Tools are useful but they’re not our focus. Use these tools if the teams feel they’re helping them succeed; not because management requires blow-by-blow reporting on tasks.
…your team members don’t feel professionally challenged and fulfilled emotionally.	Scrum should be fun.	See the above list that leads to disengagement, etc. Remember, it took years to get people into this state—it will take many months, if not years regrow lost spirit.

From all of these rules, remember that Scrum itself isn’t the point. The point is to deliver high quality working software, which we do most effectively by creating High Performance teams. Scrum is a tool to create teams, no more.

Thanks to Neil Killick, Neil Johnson, Amy Neil and Marc Andre-Morriset for their suggestions, which are represented in spirit, if not exact copies of their tweets.

What are your “It’s not Scrum if…” stories?

The Jenga Effect: Why Clients Don't Make Good Product Owners

Tue, 10 Jun 2025 00:00:00 GMT

I recently met with a team where the client was the Product Owner. The team kept saying that their product backlog didn’t make sense. They didn’t understand the product they were trying to build, and they had never seen a vision or strategy. Despite all this, their PO was focused on more features, faster, now, please.

Their product looked like a Jenga tower just before it was about to topple. This impacted quality, usability and, worse, the team was on the verge of burnout. They were getting whiplash from the number of misunderstandings the client had about how products get built.

illustration of client acting as product owner and the unstable product that results

Let’s think about the Product Owner role and how things could go sideways…

Product Owner Responsibilities

The Product Owner owns the vision - why are we building this product? Clients are the initial source for the vision information, but so, too, are ends users. Relying solely on the client’s vision can easily lead to cognitive bias and have a team building the wrong thing at the wrong time.
The PO owns the strategy - how we are getting there? Unless the client is fully experienced and informed, not only in the technology but also in the team, then they have no idea of the how and shouldn’t be weighing in on it.
And the PO also owns prioritization - what do we work on next, and how can I justify it? Clients typically want everything now, or as soon as inhumanly possible, with no experience in matching priority to the team’s capacity.
Along with the product itself, Product Owners also need to understand the regulatory environment, usability, accessibility and security. Clients typically just want to know that it works.
POs collaborate with developers to agree on what a feature or user story is. (Sometimes with pencil sketches or discussions around acceptance criteria.) Clients would struggle to understand both the terminology and the techniques.
POs balance stakeholder needs. If the client is acting as product owner, how unbiased do you think they would be able to be about multiple stakeholder requests?

The PO needs to be empowered to make product decisions. A great Product Owner understands the big picture of product management, and they help Developers (i.e. team members) to understand all of the above.

POs also need to have ability to interview a variety of end users, digest the information, design and run experiments. And they need to develop a relationship with, and understanding of, the team so they can find a rhythm together (e.g. How much detail does the team need? What decisions can they handle independently?) Clients don’t have the time, experience, or relationships to be able to do these.

This only scratches the surface of a good PO’s role. Many people, on discovering the work involved in being a PO, run away after a few months. In government, some people rotate out of their jobs every 6-12 months. That’s not conducive to acting as product owner.

What happens when someone without expertise steps into the product owner role?

Client as a Product Owner

People from the client side understand the business problem well, but not the product build.

Weaknesses

Don’t understand how product development works
Don’t have experience working with a team
Limited experience with all of the responsibilities mentioned above
Not prepared to make it a full-time role
… they’re missing almost all the skills and responsibilities mentioned above

The main issue is that most clients lack the background in product work to play the role effectively. Instead of the client as PO, we’re better off with the client as a stakeholder. The Product Owner ensures the product solves their problem, but they do it while considering the big picture, not just the next feature.

Conclusion

Effective Product Owners have a background in product management. In areas where they’re weak, they take time to learn, as it is their trade craft. Your client makes a good stakeholder, not a good Product Owner.

JIRA is Not Agile

Mon, 29 Sep 2014 00:00:00 GMT

Agile Pyramid - image by Agile Pain Relief Consulting

I’ve heard people say, “We started using Jira and GreenHopper, so we’re Agile now”. Similar things are said of Rally, VersionOne, LeanKit, TargetProcess, etc. In making those declarations, it’s clear that they don’t understand Agile at all.

At its core, Agile is a set of Values and Principles:

….

· Individuals and interactions over processes and tools

· Working software over comprehensive documentation

· Customer collaboration over contract negotiation

· Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Underlying these is a mindset with a focus on self-discipline, self-organization, and adaption to change.

The Practices of Scrum (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), the Roles (ScrumMaster, Product Owner, and Development Team), and the Artifacts (Product Backlog, Sprint Backlog, and Product Increment) only help the team support the principles and achieve the goal of delivering working software.

Electronic tools (Task walls, Development Environments, …) or physical tools (Task walls, …) are only useful in so far as they provide support for those principles and practices.

If your Agile adoption starts with a tool and a scattering of practices, then the whole point has been missed and the core – the essence – of Agile needs to be carefully reviewed until that is obvious. One might say your Organization isn’t taking real change seriously

Image attribution: Agile Pain Relief Consulting

Kanban Portfolio View

Wed, 18 Dec 2024 00:00:00 GMT

Beyond Scrum: Scrum Alone Is Not Enough - portfolio kanban

(Presented as Part 3 in the [Scrum Alone is Not Enough](/blog/scrum-alone-is-not-enough “Scrum Alone is Not Enough”/) series.)

In the last post of this series I talked about Portfolio Management, and how it aims to ensure that a team is always working on the highest priority work, without outside pressure taking their focus away from a manageable goal. Portfolio Management has value, but it also comes at the cost of increased overhead, loss of some control for Product Owners, and reduced ability to adapt in the moment, so let’s use it wisely.

Focus on Delivering Value, Not on Keeping Teams Busy

1. The most important advice for Portfolio Management is to structure stable teams to minimize dependencies out of the gate, or at least cross-skill to reduce them. If we need red yarn¹ to visualize dependencies (thanks, SAFe), we must fix the underlying problem, not mask it.

2. Watch the work items, not the workers. Our job is to deliver value, not keep people busy. Prioritize finishing work items, not starting more work.

3. Make your Product Portfolio visible. When teams see the work, they deliver more value. We’re visualizing the Portfolio so that we can see: - Where the work items (e.g. Features/Epics/Large PBIs) are in their journey - Where work is getting stuck (Is it waiting for other teams? Approval? …) - Dependencies between teams - The flow of work from beginning to end

To make the Product Portfolio visible, we use a Product Portfolio Board. You can use any board to visualize but, in most cases, a Kanban Board is the best to start.

Why do we need a board? Simple, it helps everyone make better decisions about the work, so we’re always maximizing value. How do we do this? Design the board by asking what information they need to make better decisions.

In most organizations, work items spend more time waiting than getting done. Often three times more. If you want to deliver value faster, eliminate the waiting.

Basic Portfolio Kanban Board

Let’s start simple. Gather your team and map out how work flows through your organization. Think big chunks of work (about a week’s worth), not tiny details.

The details: gather the Product Owner(s), ScrumMaster(s), Team Members and Stakeholders. If the group size is large, either do the work in two rounds or invite-only a couple of representatives from each group. You can do this with the formality of value stream mapping, or write down an ordered list of the steps. Each step is a possible column on the board. Since we’re creating a portfolio view, the minutia of what happens inside a single development team will be a distraction. Consider tracking work at the Feature/Epic level (~1 week’s work for each team; T-shirt sizing L/XL; Story Points 13/20/…). Any more fine-grained, and the level of detail will be overwhelming.

I’ve seen a simple board like the one pictured below work well. Your board will be different; don’t copy ours.

With the basic board in place, consider how to visualize the problem children of the kanban board. I’ll explain below.

Visualizing the Challenges

Here are the prime offenders on your Product Portfolio board:

- Dependencies (the domino effect) - use colour or tags to visualize these. I like the use of colour because they stand out. Items with dependencies are the ones that are likely to get stuck in the system. To avoid this, ensure that attention is given to dependencies.

- Waiting For (the silent killer) - Sometimes work waits for the next station to pick it up. Consider a separate column. In most teams, work spends more time waiting than it does being worked on. So use a WIP Limit. Once we have too many items waiting, the team should collaborate to help the people at the station get all of the items closer to the finished state. If we have downstream teams, there will be a waiting-for queue ahead of each downstream team. It also needs a WIP limit.

- Blocked (the full stop) - “Waiting for” was bad enough. Blocked is worse. Blocked implies that until something happens, the item will not proceed. Mark these in any way that they stand out.

- Work Item Age (the forgotten items) - A fancy name for the question: how old is this item? Track how long it has been since work started on an item. As items age, there is an increased chance that they’re no longer relevant to the system. Item Age also correlates with customer dissatisfaction and defects. Also, older items often have hidden dependencies or blockages that stop them from getting finished.

Reviewing and Using the Kanban Board

Product Owners, Scrum Masters and representative team members should review the state of the board a couple of times a week.

- Review each item on the board. Is it in the right column (e.g. Considered, Development, Testing, Deployment)?

- Review the whole board, looking for any items that might have a newly discovered dependency or are now blocked when they weren’t previously.

- With dependencies and blocked items, determine who will do the dependent work or resolve the blockage. Dependencies and blocked items are significant inhibitors of delivering value, so teams must treat the dependency as a higher priority than their own Sprint work. In a multi-team situation, all teams must set aside 10-15% of their capacity to help other teams. When this doesn’t happen, the system will jam up more often.

- Now review Work Item Age. Value is only delivered to the customer when work is truly finished. For the oldest items, check first for unnoticed dependencies or blockages. Then, teams should prioritize finishing these items before starting new work.

Stakeholders review the board with the Product Owner less frequently. Every 2-4 weeks. We’re still keeping the stakeholders in the loop. By the time the Portfolio Management meeting arrives, they already know what is complete. They will have more focused, better-quality feedback on the product and its evolution. In addition, whenever there is a blockage that a stakeholder can help with, bring them to the board and discuss the issue.

Resolve Dependencies

Don’t manage them, especially not with red yarn. If there are frequent dependencies between two teams, this suggests a structural problem. Either change the team structure so the dependency is no longer a problem or cross-skill the team to handle the dependency without outside help.

During your multi-team retrospective (you’re doing them, right?), discuss the use of the board and how to make better use of what it tells us and how to improve it.

If the conversation gets stuck, return to the board’s purpose: Value Delivery over Keeping Teams Busy. Ask questions like: Where do items get stuck the most often? Which dependency can we untangle next? Are there any decision-making bottlenecks to eliminate?

Don’t Self-Sabotage

Want to guarantee failure? Here’s your recipe:

Put on blinders - ignore other teams’ needs - Play hot potato with decisions - toss them upstairs - Start new stuff - because fixing problems is hard work

I wish this was sarcasm. But I’ve seen so many teams behave this way, I have to assume there is an instruction manual that advocates this.

Updated on December 18, 2024

Image attribution: Agile Pain Relief Consulting unless otherwise noted. Elements of first image designed by Freepik.

Footnotes

SAFe Program Dependency Board Retrospective ↩

Learning Best Approaches for your Brain Slide Deck

Mon, 02 Nov 2009 00:00:00 GMT

Brain - image licensed from Photodune

As regular readers of this blog will know I’ve given a talk based on readings in Neuroscience, called “Learning Best Approaches for Your Brain” – several times this year (Agile 2009 and Agile Ottawa). After several requests I’m posting the slide deck (pdf) here – but I’m afraid that it will really only be useful to the people who attended the talk. Here’s the promo I’ve been using:

Do you mentor, coach, teach or just help other people? Do you wonder why after your greatest teaching moments people just don’t get it? In recent years neuroscience has started to provide us with a number of insights into what happens when we’re teaching. These insights make it clear that learning is really about building and reinforcing existing neural networks. Instead of providing lots of new ideas out of the blue, we need to understand the learners existing context and work with that. Instead of focusing on mistakes and errors, we need to focus on what good solutions look like.

Top 5 Reasons that traditional approaches to learning and mentoring fail:

Lead with the Abstract

Not Grounded in the Listeners experience

Passive students – i.e. Those just listening and taking notes, aren’t using all of the brain. They retain knowledge but don’t really understand it.

Rewards don’t work

High Fructose Corn Syrup

Benefits:

Students and Mentees will remember

Learn how to correct mistakes

Workshop Attendees will stay awake

References:

The Art of Changing the Brain (Amazon.ca) - James Zull
Brain Rules (Amazon.ca) - John Medina
The Brain that Changes Itself (Amazon.ca) - Norman Doidge
Presentation Zen (Amazon.ca) - Garr Reynolds

I promise that sometime in the next month or so I will publish the paper that Linda and I originally promised (threatened), that will include all of the details missing from slide deck. The only caveat no paper will every be as good or help you learn as much as an interactive, example driven presentation.

Download: Slide Deck (pdf)

Caveat Emptor - if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

Images via: https://photodune.net/

Learning Scrum through Games

Tue, 08 Nov 2011 00:00:00 GMT

Scrum training session run by Certified Scrum Trainer Mark Levison

2011 Session

Last week at Agile Tour Toronto I had the privilege of working with my friend Paul Heidema to help introduce the basic concepts of Scrum in 60 minutes. This is a really interesting challenge, what’s the minimum amount you can teach people and still give them a taste of Scrum. In end we opted for about ~10 minutes of talking heads (spread throughout), ~30 minutes of simulation time and 15 minutes of debrief.

We invited our teams to create Children’s Books of the Goldilocks story. Along with the basic Story participants were asked to offer advertising, public service announcements etc.

Comments from participants:

A number said it was surprising how well teams of complete strangers came together after two sprints.
Several didn’t like the way I set them up for a mini “failure” by not playing the Product Owner role poorly and not communicating my needs. This is a fair point however it does simulate life with a real product owner

Feel free to use this simple simulation to help teach the very basic concepts of Scrum.

2012 Update

Learning Scrum Through Games

Last year I created a short session - Learning Scrum Through Games - to help people explore the basics of Scrum in a one hour format. This year I rewrote it and took it to both Agile Tour Toronto and Ottawa.

We learned a number of interesting things from both sessions:

Even with a poor quality Product Backlog (the Backlog I gave attendees has many issues) the team was still able to create a pretty good product.
I don’t give the best instructions to start the exercise and yet attendees manage to create some great comics. When a real Scrum team starts, it’s chaotic at first. I would prefer attendees get a sense of this during the exercise so I give deliberately vague instructions.

Learning Scrum Through Games

Done or Not Done - Incomplete Comics lead to a good discussion, there is no such thing as 80% done in Scrum. Working software (or comics in this case) is the only measure of progress. This topic led to a brief conversation around the importance of shippable product after every Sprint.
Many teams jumped around the Product Backlog: choosing whichever stories they felt they could complete. They didn’t ask the Product Owner if it was okay to implement items out of order. Some teams went even further by implementing things the Product Owner didn’t ask for. Quick reminder: if the team wants to do things in a different order or do new things, they have to ask the Product Owner first.
In Toronto several attendees remarked that it was difficult to understand what was going to happen next. In Ottawa I created an Index Card - Scrum Task wall.
Timings - the timings in the one handout didn’t work out as well as I’d hoped. It’s not realistic to run two sprints in one hour. If you’re trying to run this yourself I recommend one and a half to two hours which will allow enough time for two Sprints and a good debrief.

Finally, when running this the goal isn’t a perfectly run exercise or perfect comic book; its aim is to have people experience the chaos that is Scrum and see how it can work.

Handouts

Intro to Scrum with Games Backlog and Schedule (pdf) and Introduction to Scrum Concepts (pdf)

Slides

Caveat - the slides were just indeed as a backdrop and not stand on their own.

Learning Scrum through games from Mark Levison

Photos by Mark Levison

Learning Story Mapping Through Exercises

Tue, 30 Apr 2013 00:00:00 GMT

Attendees in Kitchener Waterloo - collaborating on building their maps

Story Mapping is a simple tool to help you visualize your Product Backlog. The traditional Product Backlog in Scrum is a real improvement over traditional methods for tracking and understanding the work ahead. However it’s still a long To Do List which has some issues:

It’s hard to see the forest for the trees.
It’s easy to miss important items in the morass of detail.
It’s hard to prioritize well since we can’t see the big picture.
It’s not explicitly focused on the user needs.

In other words, flat lists become confusing as the Product grows in size and complexity.

Story Mapping is a tool to help overcome these issues by helping the team visualize the needs of the end-users. Along the top we write out all the “User Needs”. On the Y-axis we create the Stories for each “Need” or task. Some “User Needs” aren’t of interest in the current release – so they might get no Stories. Other needs have a number of things that need to be done for them – so they get many Stories. In addition, each user gets their own map.

Attendees in Kitchener Waterloo - collaborating on building their maps

The key here is that the map acts as a tool to help organize the Stories. The map helps us spot gaps in our product and helps us discover the priorities. However, most importantly Story Maps help start conversations among team members about what we’re building.

The files below are from a series of Story Mapping workshops that I have facilitated in Montreal, Toronto and Kitchener-Waterloo this past year. If you would like to bring me into your company to facilitate a Story Mapping Workshop or teach a Product Owner course please contact us.

The files make the most sense if you’ve attended the workshop.

StoryMappingWalkThrough - the keynote presentation I run in the background.
Story Mapping Basics - the basic introductory handout that all attendees get. It outlines some of the basic ideas behind Story Mapping and provides the core scenario for the exercises
Julia Persona and Rob Persona - the personas that the audience gets to use for their exercises.

Photo by Mark Levison. Image by Agile Pain Relief.

Less is More: Creating Resilient Systems Through Simplicity

Thu, 08 May 2025 00:00:00 GMT

Simplicity isn’t something that we install once and forget. It is both a principle and a value. Whenever a change is made, we should ask the question “What is the simplest way this could be done?” This applies at every level, from small coding decisions all the way up to an organization’s structure.

Simplicity is hard. The natural cognitive bias is to add, not take away. Our default approach to improve a product, a system, or an organization is to add something more. Enhance, boost, augment… these all imply that increasing size also increases strength or value. By default, we don’t think about subtracting or simplifying. We don’t notice an opportunity to subtract, and rarely is it the thing that gets rewarded or praised.¹

Why does this matter? Because complex systems are more likely to break. An excellent example is provided by the financial crisis of 2007/8. The mortgage system had become so complex that no one could understand the whole system ². Not even at a high level. Many banks and governments were caught off guard when it turned out that lenders had offered mortgages to people who couldn’t afford them. Worse, the properties often weren’t worth the stated value. Everyone had assumed someone else was doing the due diligence. Most of us don’t have the power to reform global financial systems, but we do all have the ability to simplify some systems.

Here are some examples of where a typical Scrum Team can create simplicity.

Simplicity in Software Development

In software development, we spend more time reading and understanding code than we do writing it. When we rush through the development work and don’t take time to simplify, there is a price. The people who read the code next will spend far more time to understand it, because the person writing didn’t think about simplicity, they just wanted to save 10 minutes.

Worse, complexity in code is a key source of bugs. When we create a complex solution to a technical problem, as the author we may well use it correctly, however, the people that follow in the years after have a weaker understanding of the work. They’re more likely to use it incorrectly, and that’s when defects can creep in.

Code is not the only source of complexity in software team. In modern programming environments, siimple applications often have dozens of direct dependencies. Each of the direct dependencies will have its own dependences, meaning our simple application really has hundreds dependencies.

Simplicity in Product Design

In any product, there is always pressure to add new features. This happens in software development, but also when designing physical products such as cars, and even refrigerators. Additional features often add value, however they come at a cost.

With software, new features add complexity to the user interface and, worse, to the code base. Take a moment to look at your web browser menu and you might see 60+ items. Then open the options/settings and you’ll probably find well over a hundred more choices. When all of these features were added, they seemed clever. But how many get used? Regardess of whether they truly add value to the consumer, they increase the maintenance burden since one small menu item or preference may require 20-30 changes in the code base.

The automotive industry has tons of examples of complexity. These days, cars have automatic rain, parking, and proximity sensors, to name just a few that are now standard. Many of these features add benefit, but they also make the products harder to use and more complicated —and often more costly— to maintain. New cars now have so many features, a dealer will often spend half an hour with a new owner showing them how all the systems work, just so they can drive home safely. (I still don’t understand our rain sensing windshield wipers after 5 years.) Modern sensor-laden cars may be easier and safer to drive, but when you need to replace a bumper or windshield, you pay not just for the parts, but to have the manufacturer recalibrate the sensors.

Meetings

Most teams are blessed (sarcasm) with too many meetings. When team members don’t have a single two-hour block to focus during the week, we know meeting mania has gone too far. Lacking time to do their actual work, some people have resorted to working evenings.

It’s not the the meetings themselves that are the entire problem. They’re a sympton of something deeper:

Decision-making bottlenecks, or decision by committees
Coordination overhead - when work is spread across multiple departments
Information silos
Process redundancy

Effective organizations audit their meetings on a regular basis, asking questions like: Why does this meeting exist? What is the real problem we need to solve that is causing us to have a meeting?

Not all meetings should be eliminated. Rather, we should always be questioning what meetings tell us about how our systems behave.

In the Scrum process, I frequently need to remind teams that Daily Scrum should replace most other recurring meetings.

Teams and Process

In any kind of work, we encourage people to specialize. In software development that has traditionally been: User Experience; Business Analyst; Programmer and Quality Assurance.

In Marketing groups, this might be: content creator; copy writer; video editor and web developer.

Each additional role creates handoffs, and the handoffs create rules and standards between each role. The rules and standards themselves add complexity. Worse, each handoff increases the likelihood of accidental complexity.

There isn’t a magic wand here, but instead of the default approach to add more people, the Agile approach is to focus on building cross-functional teams and cross-skilling.

When we have multiple teams or groups working on the same product, they have to coordinate their work. All attempts to coordinate will add overheard and increase complexity. This can’t be avoided. The questions should always be, is this the simplest way we can solve this problem? Are we adding the minimum additional overhead? Are we creating additional committees for the sake of making people feel heard?

Complexity comes from many small decisions made over a long period of time - Image © Agile Pain Relief Consulting 2025

Less Really is More

Simplicity is at the core of making our organizations resilient. It isn’t a once and done thing, it is making small choices in our work. Consistently looking for all the places, and in all the layers, where we could simplify will improve our resilience.

The next step is to ask how we spread simplicity throughout the whole organization to reduce bureaucratic overhead and strengthen strategy and performance metrics.

Think about it. What is one area in your work where complexity is masking a deeper issue? Then ask, “What if we simplified this?” The answer might surprise you.

Agile Pain Relief Blog Entries

Is AI Making Your Organization Fragile or More Resilient
How to Cross-Skill and Grow T-shaped Team Members
Simplicity
The Hardening Sprint - an example of unnecessary complexiity

Footnotes

When Subtraction Adds Value - HBR - by Gabrielle Adams, Benjamin A. Converse, Andrew Hales, and Leidy Klotz https://hbr.org/2022/02/when-subtraction-adds-value ↩
The Dog and the Frisbee Andrew Haldane, Executive Director Financial Stability at the Bank of England - pdf https://www.bis.org/review/r120905a.pdf ↩

Lifecycle of a User Story

Mon, 04 Nov 2013 00:00:00 GMT

Lifecycle image via Wikimedia Commons

User Stories](/blog/definition-of-done-user-stories-acceptance-criteria/) are often used as a lightweight form of Agile requirement. Their goal is to replace heavy weight-specification documents with “a Card, a Conversation and a Confirmation”. When people first discover User Stories it’s hard to see how they work because we often take a static viewpoint – i.e. we only see them at Release Planning or during implementation. We’re left with many questions: Where do User Stories come from? When are they created? Who is involved in their creation?

To illustrate this I will use vignettes from the WorldsSmallestOnlineBookStore. Each vignette will show what happened to one User Story.

“As a frequent book buyer I want to save my address so that I don’t have to retype it every time I visit the bookstore” During the team’s first Release Planning Session (aka Initial Product Backlog Refinement) this Story was identified. After a few rounds of planning poker the consensus estimate was that it was size 20, allowing for both the initial entry of the address, updating and deleting old addresses. Since this Story appeared to be low priority in the short term, the team moved to other items.

---------

In Sprint #5, during a Backlog Refinement session, the PO Paula revisited the Story and asked the team if their understanding of the problem had changed in the past two months. They conferred for a few minutes and decided that it was still a 20. Sue grumbled and suggested it was a fairly small piece of functionality for such a large number. Doug suggested a Story split – using CRUD (Create Read Update Delete), he proposed in the short term that the User be allowed to add a new address and use it. However, they wouldn’t be able to update and delete. This would separate the Stories. After a few minutes of conversation around the implications Sue asks them to estimate the three split Stories:

“As a frequent book buyer I want to save my address so that I don’t have to retype it every time I visit the bookstore.”

“As a frequent book buyer I want to delete old addresses so that I don’t have to worry that my books will ship to the wrong house.”

“As a frequent book buyer I want to update my existing address to correct small errors so that I don’t have to retype them from scratch.”

The team determines the “save address” Story is size 8, the “delete address” Story size 5, and the “update address” Story size 8. Based on this Sue moves the “save address” Story to the top of the Product Backlog, “delete address” about 15 items further down and “update address” has been moved so far down it will never be tackled.

Since the slimmer “save address” is now the top Story in the Product Backlog without acceptance criteria, the team spends a few minutes creating criteria for it. They start off by drawing a quick pencil sketch to get the key points across. Based on this sketch they start creating a table of examples:

Address	Status
1 Sussex Drive, Ottawa, Ontario, Canada, K2K 010	Valid
Buckingham Palace, London, UK	Address outside of Canada/US
1600 Pennsylvania Avenue NW Washington, DC 20500	Valid

Rather than try to create an exhaustive list at this point they just create enough to outline the boundaries of the problem.

During the team’s next Sprint Planning session, Sue asks if the team can commit to this Story. They give it the “thumbs up”.

Before the team starts work on the Story, Tonia (QA specialist), Brad (BA), Doug (Developer) and Ian (Developer) meet to finish hammering out the acceptance criteria.

Address	Status
915 E 7th St. Apt 6L Brooklyn NY 11230	Valid
24 Willie Mays Plaza, San Francisco, CA 94107	Valid
24 Willie Mays Plaza, San Francisco, CA	No Postal Code
24 Willie Mays Plaza, San Francisco, 94107	No State
45 Rosenfeld Cr Ottawa, ON K2K 2L2	Valid
45 Rosenfeld Cr, Ottawa, ON K2K 2L2	Valid
45 Rosenfeld Cr Ottawa, ON K2K 222	Invalid Postal Code
45 Rosenfeld Cr, Ottawa, ON	Missing Postal Code
….
(This style is referred to as Specification By Example – where the emphasis is that it provides the specification before something is built).

Brad goes off to see if there are any edge cases that the examples don’t cover. Ian and Tonia pair off to turn the examples into Executable Specifications (i.e. acceptance tests) in Cucumber. Doug starts to take a crack at the GUI, seeing what parts he will need to assemble. Once the initial tests are written Ian tries build the business logic to support the examples.

A few days later when Ian and Doug think they’ve completed the Story and it meets the examples, they show it to Tonia. Once she sees that satisfies the test cases she spends a while doing some exploratory testing – seeing how the application behaves when a real User plays with it. Satisfied, she calls Paula over for additional feedback. Paula is delighted with the behavior but asks for a few changes to the layout. Once those are made she agrees the Story will be complete.

During the Sprint Ian demonstrates the different ways we can now support accepting addresses from both Canada and the United States.

At the end of the Sprint the team takes the completed Story off the wall and archive it in the filing cabinet (they keep them around for later auditing).

---------

During Sprint #6, Brad (BA) sees Ian (Developer) in the hallway and they start chatting about the warehouse runners, i.e. the people who fill the book orders. Brad comments he’s seen the runners spend a lot of time retracing their steps because the list of books in for an order is alphabetical - but unfortunately the warehouse isn’t laid out in alphabetical order. They create a new Story:

“As a runner I want the list of books to be printed in the same order I will find them in the warehouse so I don’t have to run as far”

During the Backlog Refinement session a few days later they bring up the Story. Paula gives it some thought and says, “We’re in the fourth month of operations, and we’re only just starting to see reasonable sales numbers roll in. All improvements right now must be focused on the book buyers and making it easier for them to buy books. At this stage I can’t afford to do any work for the warehouse runners or any other back office staff. Once sales start to increase we can afford to improve the system for our internal Users”. Paula took the index card that the Story was written on and ripped it up.

------

User Stories aren’t static, one-sentence descriptions written by one person. The User Story is most effective as a tool when several people are involved in its creation. They work as a tool to record the team’s share, understanding not as a one-way missive from the Product Owner. In addition a good User Story evolves over time – as the team gains a greater understanding of the business problem they rewrite it, split it and add acceptance criteria.

Lifecycle image via Wikimedia Commons

Measurement for Scrum – What are Appropriate Measures?

Tue, 06 Sep 2016 00:00:00 GMT

We’ve seen the risks of assuming that everything is normal distribution, and also the problem with reporting a single number. What else do we need to be aware of? What can we usefully measure?

Risks in Measurement

Many important things can’t be measured using formal measurement systems. As a result, not enough attention is paid to them. For example, Technical Debt – there are some attempts to measure code complexity but they don’t work well, so organizations sweep the problem under the rug until a code base becomes too complex and expensive to maintain. One of Nassim Taleb’s key points is that Black Swan events couldn’t have been predicted by mathematics before the event, however they look obvious in hindsight. Only better questions will help spot a risk in advance.

Always consider how your metric will be gamed. “Tell me how you measure me, and I will tell you how I will behave” - Eliyahu Goldratt¹. People will do what it takes to meet what they believe they’re being measured on, so we should only use metrics that, if gamed, we would be happy with the result. Example: if we measure Velocity (number of Story Points per Sprint), teams will rapidly find ways of inflating their Velocity (estimate higher, reduce effort on testing, etc.) in ways that produce a weaker product.

People will do what it takes to meet what they believe they’re being measured on.

Focus on a change or trend, and not the raw number itself. A change in a metric is just a hint to go look and see. It doesn’t, in and of itself, tell us anything. For example, Unit Test code coverage (expressed as a percentage) goes down over the course of one Sprint. This may be bad – perhaps new code was introduced without accompanying Unit tests. Or it may be good – well tested code that was redundant was eliminated. So a metric is just a hint to have a conversation.

The Six Sigma² manufacturing process makes significant use of metrics to reduce defect rates by eliminating variability. But applying that same approach to software and product development would have a disastrous effect. Knowledge work, e.g. the work of building products (software or otherwise), is hard to measure because the nature of the work is inherently variable. What’s the standard time to implement a feature? There is none. How long does it take to fix an average bug? There are no average bugs. When measuring, we need to be careful not to use the measure to eliminate the variability inherent to the work.

And then there’s Vanity Metrics. Be careful of metrics that measure things that the customer doesn’t value. LeanKit shows that focusing on 5 ‘9s’ (99.999%) up time might cause us to put energy into solving the wrong problem. In the LeanKit example, 5 ‘9s’ is the goal, and when customers complain about downtime, the DevOps person notices that 75% of the down time occurs when the nightly maintenance scripts are run. So they put time into improving the scripts to eliminate the problems, but the customer complaints don’t go away. Yes, the complaints were about the percentage of downtime… but about downtime during the day! Focusing on the evening downtime misses the point. In another case, American Airlines has promised a response to customer complaints within 20 minutes. However, many of the responses are clearly canned e.g. if you mention power supply problems on a particular plane, you’ll get a response back that suggests that other people in your row might have been using the power, along with a link to the airlines FAQ. Instead of a useless response within 20 minutes, what the recipient really wanted was to know that maintenance had been sent a ticket for the problem.

Recheck your metrics frequently (at a minimum, every 3 months) and ask if they’re still relevant. Ask if they’re still helping to drive change. Drop metrics that are no longer helping.

Effective Measurements in Agile Teams

When considering effective metrics, ask:

How will this measure help our customer?
Does this measure have a “best before” date?
How will a smart team game this metric? (And if they game it, will we be happy?)

Potential Measure	What is it trying to measure?	How does it help?	How will it be gamed? Other concerns?
Defects that escape the Sprint	Quality	It sends a strong signal that zero defects is desirable.	People might argue about whether an item is a defect or just a new User Story.
Static Code Analysis (e.g. tools like Sonar and FindBugs, PMD)	Quality by doing static analysis	Static analysis tools can spot small mistakes in code and warn developers of potential bugs.	Static analysis can give people a false sense of security since the tools only check for bugs that can be proven by examining the code – they don’t check for logic, implementation or intent errors. Tools are often used to summarize health with one or two numbers. As usual, the number is useful if it tells you to roll back the covers, but risky if you assume it means an area of your code base is safe.
Test Coverage	How much of the code is visited by automated tests (unit or acceptance tests)	It can help spot untested or even unused code.	People often assume that code visited by a test has been tested. All a test coverage tells us is the code was used by a test. It shows nothing about whether it was tested.
Customer Satisfaction measured via NPS (Net Promoter Score)	Whether the customer would be happy to recommend your product to their friends on a scale of 1-10. They’re then asked why they choose that number.	Are you delighting your customers?	It can only be measured infrequently, so information arrives a long time after your work has been done. It doesn’t correlate well to the product work your organization has done. The power is in the answer to the “why” question.
Team Member Happiness	Each Team rates their happiness with the Team or Organization on a scale of 1-5.	Happier people are more productive and focused. Jeff Sutherland has correlated Happiness with an increase Productivity and Revenue. When a team member’s happiness dips it can be a warning sign that something we’re doing is harming our organization.	Happiness can sometimes become a trap – a team’s productivity plateaus and they’re happy.

Cycle Time

Potential Measure	What is it trying to measure?	How does it help?	How will it be gamed? Other concerns?
Cycle Time	How long it takes an item to production from the moment the team starts working on it.	Work in Progress – whether it’s in development, test, documentation or some other state delivers no value to the customer. Work only delivers value when the customer has it.
Lead Time	Length of time from the moment the idea is received to when it is delivered to the customer.	Also takes into account the time an item sits waiting in a queue (Product Backlog,or otherwise before the team works on it).

Interruptions

Potential Measure	What is it trying to measure?	How does it help?
Interruptions	How many times during the Sprint the team(s) have to deal with…	Creates awareness around the rate of interruption for the time.
Support Issues	…a support issue	Highlights either quality (product bugs) or usability issues (feature isn’t used as the team intended).
Non-Product Backlog work requested	…work items that didn’t come from the Product Backlog	Highlights quality work that is bypassing Product Ownership and Portfolio Management.
Other Interruptions	… interruptions that are not part of the previous categories	Highlights Dark Work and other things that are distracting the team

Dangerous Measures

Potential Measure	What is it trying to measure?	How does it help?	How will it be gamed? Other concerns?
Velocity	Average number of Stories or Story Points completed per Sprint	Can be used to forecast when a feature will be released. It can also help a team spot long-term trends in their own work.	It is often misused to compare teams or measure productivity, which leads to a culture of velocity above all else (especially quality). If used, it should be used by only the team itself.
Bug/Defect Count	Number of Bugs logged in on the bug tracking system	A measure of quality	At best, measure defects in quality on the surface of the system. Missing: - Doesn’t measure the internal quality of the code - Never complete since we will never find all the bugs - Stale Bugs that can be reproduced or are in parts of the system that are no longer used cloud the measure
Return on Investment	Revenue per Feature divided by Cost		Can’t realistically be measured.
Productivity			Can’t be measured, and if it was, it’s unclear how it would help guide teams.

More Potential Measures

Potential Measure	What is it trying to measure?	How does it help?	How will it be gamed? Other concerns?
Ratio of Fixing Work to Feature Work	Measure very roughly the amount of time spent on fixing bugs vs new feature work. This shouldn’t require tracking hours, we want a rough ratio.	Helps us understand where effort is being spent. Helps a PO make better decisions about where they’re spending their money.
How long does it take to test end to end?	How much testing would it require to have confidence in release?	Reminds us of the overhead/tax we need to pay before releasing our product on the world. Since it’s part of cycle time, we should feel pressure to reduce this from days to hours.
Release Frequency	How much time between releases?	Reducing time between releases can help us get paid more often.
Backlog change rate	How often are Product Backlog items added, removed, reprioritized, etc?	Too little and we should be concerned that we’re not building the product the customer wants. Too much and we should be concerned about our ability to build a stable product.
Skills Matrix/Team Learning	A skills matrix is a tool to help the team understand where it has a lot of knowledge and where it is weak. To measure, just look for where we have changed in the last period of time.	It can help nudge people to spend some of their learning time in a specific area where the team is weak.	If team members perceive they’re personally being measured on this and this measures ties to their performance review/pay, they inflate their self-rating. So rate of change in Skills Matrix or Team learning is only useful if it is used by the team for their own needs.
Cross Team Dependencies	The number of things that one team needs from another team.	The more things we need from other teams, the less freedom we have in prioritizing work (lead time is increased, etc.) The measurement allows us to spot the kinds of dependencies we suffer from. If we haven’t already, this measure should force us to discover Feature Teams. And if we have, it should force us to invest in skills where we still depend on other teams.
Number of recent experiments run	Count the number of experiments run since the last measurement.	Agile Organizations are continually challenging the status quo. Counting the number of experiments can act as a reminder to run them and measure the results.	Experiments for the sake of experiments is also bad, so the trend doesn’t matter as much as being reminded to run experiments.
Unfinished Stories, aka Adherence to Definition of Done	How many Stories at the end of sprint didn’t meet the definition of Done.	Helps by forcing team members to focus on getting fewer stories to truly done every sprint.	By splitting stories into smaller chunks, teams are less likely to have unfinished work. This usually results in greater flexibility for the Product Owner and better throughput – so gaming this measure is a good idea.
Stories that have been Deployed	How many Stories have been deployed?	It forces team members to focus on getting small chunks of valuable work to production where we make money.

As Nassim Taleb points out, the best measures still won’t measure your biggest risks. Risk registers are popular, but since their construction isn’t scientific, they suffer from cognitive biases³⁴.

Some guidelines to help with measurement:

Assume all measures will be gamed.
Measure the simplest things that might help.
Fewer measures create simpler systems and simpler systems create less complex solutions.
Usually the real story is hidden behind the measure, and the measure was just a hint about where to look. Use measures to hint about what questions to ask.
Don’t measure performance, measure outcomes.
Assume all measures eventually stop delivering value and should be dropped.
Don’t burden your team members to collect your measurements.

In general, Scrum favours qualitative over quantitative measures. Measurement doesn’t replace watching and listening.

Footnotes

Eliyahu M. Goldratt Wikiquote https://en.wikiquote.org/wiki/Eliyahu_M._Goldratt ↩
Six Sigma https://en.wikipedia.org/wiki/Six_Sigma ↩
The Impact of Cognitive Biases on Delays in Product Development Teams https://www.academia.edu/6447648/THE_IMPACT_OF_COGNITIVE_BIASES_ON_DELAYS_IN_PRODUCT_DEVELOPMENT_TEAMS ↩
List of Cognitive Biases https://en.wikipedia.org/wiki/List_of_cognitive_biases ↩

Meeting Ground Rules Updated

Thu, 14 Aug 2008 00:00:00 GMT

At Agile 2007, I attended Jean Tabaka’s (author of Collaboration Explained) session “Why I don’t like Monday’s”, among other things she recommended establishing some ground rules for your team meetings. At the time my team created the following set:

No email or surfing the web.
No side conversations (via IM etc)
No cellphones or blackberries
Join the meeting on time

At this year’s conferences in a session entitled “Beginner’s Mind”- Jean mentioned a couple of new ground rules that she offers to teams for consideration:

Focus on the “Art of the Possible” – what could possible work here – the goal is open minds and replace conversations around that could never work here.
“But’s are ugly” – we drop the word the use of the word but – which leads to more conversations like ‘and we could try that’.

Finally we should be aware that the question: “Are there any other questions” (a yes/no question) is the fastest way to shut down questioning. Instead try asking open ended questions like: “What else?” or “What other questions do you have”? are very different. They are very open. Staying with these two open styles of questions and allowing silence for up to 10 seconds can provide a nice nudge toward further information.

Minimalist Coding Style

Mon, 21 Jul 2008 00:00:00 GMT

modern office - image licensed from Photodune

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away” - Antoine de Saint Exupéry. If you’ve ever invited me do some pair programming with you, you probably have a good idea what this quote is all about. I often wind up asking questions like:

Why do you need this boolean named retVal? Could it be eliminated the use of early return statements?
Is the else clause in this if statement necessary? Could it be avoided with a return statement? Or break/continue in a loop?
I noticed that this method has parts that are nested five levels of braces deep. Is there anything we can do to reduce that?

Two recent posts Spartan Programming (Jeff Atwood Coding Horror) taken from the Spartan Programming page on the Technion Wiki and Life After If, For and Switch (Scott Hansleman Computerzen), have reminded me of this subject.

Most of the Spartan ideas make sense to me:

Minimize depth of nesting of control structures
Minimize the number of lines occupied – the idea being its easier to make sense of a method if its all on one screen. I would prefer that most methods be < 10 lines long. Some people read this suggestion to mean all blank lines should eliminated. I would disagree preferring to use blank lines like paragraph breaks, they indicate we’re changing gears.
Minimize Token and Character Count suggest removing braces etc. – i.e. remove every non-essential character. I think these measures can be harmful and wouldn’t use them.
Minimize the number of Parameters to a method and avoid the use of out params.
Reduce the number of Variables – a number of excellent techniques are shown. I disagree with only two: the use of ternary operator and encouraging the use of very terse variable names.

Jeff Atwood codifies the frugal use of variables:

Minimize number of variables. Inline variables which are used only once. Take advantage of foreach loops.
Minimize visibility of variables and other identifiers. Define variables at the smallest possible scope.
Minimize accessibility of variables. Prefer the greater encapsulation of private variables.
Minimize variability of variables. Strive to make variables final in Java and const in C++. Use annotations or restrictions whenever possible. The only caveat here – having tried making both parameters and local variables final I found no benefit and so gave up.
Minimize lifetime of variables. Prefer ephemeral variables to longer lived ones. Avoid persistent variables such as files.
Minimize names of variables. Short-lived, tightly scoped variables can use concise, terse names. On this we completely disagree.
Minimize use of array variables. Replace them with collections provided by your standard libraries.

My additional rules:

Booleans make bad parameters. If you have method that has doStuff(realParam, true, false) – how does someone reading the calling know what true and false mean. At the very minimum use enums with meaningful names.
One letter variable names like i,j,k and e come from the early days of Fortran where variables were 1-6 characters long. With so few characters its not surprise that common convention dictated that i,j,k were loop/index variables. We’ve come a long since then – use names that while concise get the point across.
Rather than for(int index = 0; index < size(); index++) use Java (or .NET’s) foreach. They save an unnecessary indexing variable.
Check arguments at the start of any public or package level method and after that assume they’re right. You can find libraries to simplify this for you (I’ve written one at work) and if you don’t work with me see: “I take exception to that argument” on Code Project.
Minimize the use of instanceof – as your class structure grows these will be hard to maintain. More on this in up coming post.
The if/switch statement you don’t write is one you don’t have to test.

My cardinal rule: Always program as if the person maintaining your code six months from now is an axe murder. The last thing you want to do is give him (or her) an excuse to come visit you in frustration.

So next you invite me to pair program at least you have an idea about some of the questions I will ask.

Image via: https://photodune.net/

Minimally Agile

Wed, 11 Jun 2008 00:00:00 GMT

Recently I had a conversation with a long time friend that made me realize that in my writing and conversation I often come across as a fanatic. Oppppsssss. Time for me to hit the big red reset button. I’m opinionated and passionate but I also believe that you can do good work even if your not push agile limits. There are two things that I’m dogmatic about:

Quality - I can’t stand shit, especially shit code.
Accuracy - I hate mis-information and will pounce on it even when I should know better.

In any case I thought it might help put my core beliefs on the table. If you are working in small achievable chunks and are continuously improving you are Agile. On the other hand you be doing all of the Scrum Practices (Short Iterations, Planning Meeting, Daily Standup, etc.) but are not making any ongoing changes, then you’re not Agile.

Misconceptions with Test Driven Development

Tue, 18 Nov 2008 00:00:00 GMT

a pencil sitting on a test bubble sheet - image licensed from Photodune

In the past few weeks I’ve heard several misconceptions raised about Test Driven Development:

Does TDD really work? George Dinwiddie maintains a list of case studies (including one from IBM). Finally Keith Braithwaite has recently done some research on measuring the benefit of TDD. Currently the results are buried in a presentation (pdf). Key message: “measuring a over 20 projects: if you have a large number of unit tests your code will be an order of magnitude less complex.”
Writing the tests after the code has been written is the same as Test Driven Development. Its not, there are significant benefits to TDD that I outlined in: “Test Driven Development vs Plain Old Unit Testing”.
TDD isn’t useful for helping to design the architecture of programs.

The later is an interesting question. You can find voices on the net that say TDD by itself (with no thought given to the architecture is bad). The best example of this is “Coplien and Martin Debate TDD, CDD and Professionalism” (with some excellent comments) and a few blog posts that follow: “The TDD Controversy - JAOO 2007 ” and “TDD vs good design/architecture principles” - outline the debate.

If we accept that TDD isn’t entirely sufficient for design, then the question becomes how much architecture is required and what would a good project designed with TDD look like?

The real trick is balancing upfront design with the principle of YAGNI. Since like most developers I’m tempted to over design (“I know I will need this method/class later on”), I force myself to wait until the last responsible moment (typically just before I would need the code) to do my design work (saving a lot of waste - in the form of unused code). In the case of the larger architecture I discourage people from thinking more than one iteration ahead, any further ahead and the requirements are likely change. On rare occasions this means missing a big issue that forces a lot of rework. Since I have a rock solid tests I’m not all that upset and I believe I’ve still saved a lot of time with the architecture I didn’t build.

So if TDD can be used on a large scale and to help drive architecture there must be examples. The leading members of the community (JB Rainsberger, Nat Pryce and Lasse Koskela) all have clients with products built and architected using TDD. Unfortunately these are all closed source or clients that don’t want to be talked about publicly.

In the open source world there are a number of applications and libraries developed using TDD:

Obviously all of the Agile related tools (JUnit, NUnit, MbUnit, Gallio, JMock, RMock, CruiseControl, CruiseControl.NET and Hudson) were developed using TDD. However this is just a bit self referential
Bazaar - a distributed version control system, used by: LaunchPad, MySQL and Mailman (Python)
Allelogram - a program for normalizing and binning microsatellite genotypes. (Java)
Jena - a framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS and OWL, SPARQL and includes a rule-based inference engine. (Java) Related: Eyeball - lint for RDF/OWL
Helium - (He) is a lightweight and extremely useful templating engine based entirely on XML. He is 100% Java and 100% TDD (Test Driven Development) (Java)
http.net - a dirt simple HTTP server written in C#. It supports minimal functionality and is primarily intended as example code for TDD et al. (C#)
Joda - provides a quality replacement for the Java date and time classes. (Java)
Joyent Connector (source) - The Connector suite of applications provide cool features such as search, tagging, and RSS feeds that we believe will make your life easier on a day to day basis. (ruby)
Task Coach - a task manager written in Python.
In addition the Google Chrome browser was developed in part with TDD: Chromium has used a combination of test-driven and other development processes. Sometimes we write tests first and then implement features to pass them, sometimes we use existing tests as a guide to what to work on next, and sometimes we implement first and test afterward. It depends on the subject at hand, and on the individual developer.
Mark Shuttleworth remarks TDD is used in developing Ubuntu.

Undoubtedly there are a number of open source projects that are Test Driven, please let me know if you’re aware of some I missed. In addition to proving its possible these projects also act as examples as to the sort of architecture that TDD can help build.

Image via: https://photodune.net/

Mismeasurement Mess - IRCC Leads the Way

Wed, 17 Sep 2025 00:00:00 GMT

Immigration and Refugees Citizenship Canada (IRCC) is measuring how long it takes immigration officers to process visa and immigration applications. Should be a win, right? Not so fast. Imagine working with an immigration lawyer to prepare an application of several hundred pages in length, then the decision is made in less than a minute, with the IRCC officer looking at several files at once. How would you feel if you were the applicant?¹

IRCC's Chinook System - displaying multiple applications simultaneously - from CBC

We have a backlog of visa and immigration applications; the problem is real. Pretending that an immigration officer can review multiple applications simultaneously defies an understanding of how human brains work. The system provides a point and click Approve or Deny system with 3-4 applications displayed at the same time. Some of these applications are over 200 pages in length, so some applicants are getting denials with responses like:

Missing birth certificate - yet it was attached
Not enough income or cash for their stay - yet the application proves that they have more than enough
…

One former immigration officer explains that in recent years, the only thing that matters is getting the file processed and the backlog cleared - a local optimization.

As Canadians, we want our government to treat people fairly, so it feels wrong to hear about visa applications being denied for the wrong reasons. Fairness aside, this approach clogs the system with appeals. So instead of clearing the backlog faster, we’ve created a new backlog. The local optimization created a systematic problem.

This has been seen before in places like call centres when we measure the speed at which individual agents handle calls. The agent learns that if it is a simple problem, they can help you quickly. If the problem turns out to be complex? Find a way to lose the call (hang up 😉️) and the complex customer becomes someone else’s problem.

There are three key problems in the IRCC example:

Only one measure
The wrong thing appears to be measured
The measure became a target and is incentivized (commonly known as Goodhart’s Law)

When we measure systems, we’re better off finding measures that balance each other. For example, in a software development team I want something to measure throughput (how long it takes items to get finished) but also quality and team health. (Ideally, I would also measure value delivered to the customer, however, after 15 years of looking, I still haven’t found this measure.)

If too much focus is put on throughput, the quality and health metrics will suffer.

When building measurement systems:

Look for balance - You wouldn’t measure only throughput without considering quality and team health. Avoid single measures.
Run the “What if everyone maximizes this?” thought experiment - If we measure only speed, what will happen? Probably more defects and burnout and, in IRCC’s case, more appeals.
Ask “How will people game the measure?” - Measure story points and we will get lots of story points. Double your estimates, no testing. How could it go wrong?
Measure the whole system, not just a single station - In Kanban, we learn to study the flow of work through the whole system, not just one station.

Good metrics provide a diagnostic tool; they’re not a target. When I see “Cycle Time” outliers in a team, I use it as a hint to investigate what is going on.

In IRCC’s case, the only measure appears to be the number of applications processed. Worse, it seems managers are incentivized to maximize this number. So officers are doing exactly what they’re measured on.

With a few days studying their system to understand what we want to measure to create healthy outcomes, IRCC could then use that to improve their system, clear the backlog mess and treat applicants fairly and humanely.

Agile Pain Relief Blog Entries

Image attribution: CBC (Sept 2025)

Footnotes

Immigration lawyers concerned IRCC’s use of processing technology leading to unfair visa refusals - Shaina Luck https://www.cbc.ca/news/canada/nova-scotia/immigration-canada-ircc-technology-1.7632130 ↩

Misuse of Velocity in Agile Projects

Thu, 18 Feb 2010 00:00:00 GMT

An image of two architects' hands doing work - image licensed from Photodune

Like clockwork every month, someone on one of the Agile Mailing lists asks a question about “comparing velocity between teams” or “benchmarking data on velocity.” Before we examine the problem, let’s recheck what velocity is—the amount of work completed by the team/time taken to complete it. The amount of work is usually measured in Story Points (a relative measure of size). So velocity is just the number of points the team completes in the average iteration/sprint.

The underlying point is that Agile/Scrum teams use relative estimation (e.g. is this story/feature bigger or smaller than our standard story?) vs. the traditional approach of absolute estimation. The problem with comparisons, benchmarking, or any other attempts to compare velocity is that my story points ≠ your story points, because different projects use different standard stories. They work in different problem domains, and they have different people.

If we could compare velocities across a team, what would happen? Estimation of inflation. Team Better hears that Team Good has just finished their release planning meeting and estimated that they will achieve 200 points before the next release in 6 iterations/sprints. Immediately, Team Better knows it needs to produce more points and so estimates 300 points. Now along comes Team Best… .

To my mind, the real value of Velocity and Release planning is giving the Product Owner a good idea of what can be achieved before the next release. For one client, our release planning told us that the list of required features was roughly double the amount of time in the project budget. For first three iterations, the Product Owner denied reality but eventually the team’s actual velocity made it clear that trade-offs were required.

What matters far more than comparing velocity is whether each of the teams arrived at a common understanding of their work. After each iteration, has the team delivered value? Does the Product Owner always have a good idea of how much value has already been delivered and how much they can expect to be delivered?

Anytime you’re about to spend time and money on something, ask if the customer would be prepared to pay for that.

BTW I smell an Agile FAQ coming out of this and other questions.

Image via: https://photodune.net/

The Modern Guide to the Daily Scrum Meeting

Tue, 06 Feb 2024 00:00:00 GMT

“I worked on JIRA Ticket …, I’m still working on…, No Blockers”. Meanwhile everyone else is staring at their phones or is distracted by email. Does this sound like your Daily Scrum? The problem isn’t the event, Daily Scrum done well is helpful. The problem is what it has turned into: the dreaded status update.

Daily Scrum isn’t a status update. Nor is it about answering three awful questions.

What is the main purpose of a daily scrum meeting?

I don’t run around quoting the Scrum Guide as if it is the final word on anything, however it does provide a good starting point:

“The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.”

In my workshops, I tell people the daily scrum purpose is to:

Improve communication
Prepare the team for the day’s collaboration
Help the team sense whether they will meet the Sprint Goal
Find anything that is slowing the team down towards meeting the goal

If your team is struggling with Daily Scrum, always come back to the purpose to see if you’re achieving it or not. Daily Scrum isn’t the only time adjustments can be made to the Sprint plan, but it’s certainly a great opportunity.

At the end of a Daily Scrum:

The Sprint Backlog should be updated
The whole team should understand their current state of progress towards the Sprint Goal
The whole team should understand what impediments (or slowdowns) exist

Is Daily Scrum the same as Daily Standup or Daily Huddle?

Yes. Daily Standup is the common name for Daily Scrum and, frankly, if it gets the team standing then it’s a better name. Daily Huddle is the term commonly used by the Lean Community.

Who attends Daily Scrum? Does the Product Owner attend? What about Managers?

According to the Scrum Guide, “the Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.”

But I differ with the Scrum Guide on this. I think a good ScrumMaster makes an excellent facilitator and, in that capacity, might help the team. Whether they attend Daily Scrum or not, I would expect the ScrumMaster to work with team members to start removing the impediments, escalating to management if the problem can’t be solved within the team. We say this time and time again in workshops, the ScrumMaster is responsible for removing impediments, but often the best way to do this is to get the rest of the team to help.

And many Product Owners whom I’ve coached attend the Daily Scrum event so they can hear about misunderstandings about their work, and impediments towards achieving the Sprint Goal. In the best cases, I’ve seen Product Owners resolve impediments right after the Daily Scrum event finishes, because they were present to hear more about the obstacle.

Managers don’t attend Daily Scrum unless they’re acting as a Developer/Doer of work for that Sprint. Even in that case, the power imbalance means that the Daily Scrum might turn into a reporting event, instead of a collaborative event.

Daily Scrum standup - Development team reviews the Sprint Backlog, image by Agile Pain Relief Consulting

Where, When and Timebox of Daily Scrum

Where should teams hold their Daily Scrum meeting?

Pre-pandemic, I recommended that teams meet for Daily Scrum in their team room and ensure that everyone can see the Sprint Backlog. Now our teams are often either hybrid or fully remote, and I don’t see many team rooms. However, it’s still important that everyone on the team can see the Sprint Backlog during Daily Scrum. This is their way of visualizing the current state of the work. In addition, seeing the Sprint Backlog makes it easier to determine as a team whether they still believe they can meet the Sprint Goal.

When should Daily Scrum happen?

The earliest in the day that it is practical for the team to meet. If your teammates have younger kids, that might not be until after the school bus leaves. Since the event is truly self-organizing, it has to be up to the team members. The Daily Scrum is timeboxed at 15 minutes long. That keeps the event focused and high level, minimizes the risk of long side discussions.

How to Handle Time Zones in Daily Scrum

When your team is spread across time zones, scheduling gets harder.

If the team is spread from St John’s, NL to Vancouver, BC (a 4.5-hour difference) the obvious choice is to select the earliest time that is practical for the BC team members. Teams with this time difference usually benefit from setting core hours and creating other working agreements.

At some point, the team has no overlap in the day. (Vancouver and New Delhi) What do you do in that case? Others will suggest the use of asynchronous tools. I think we need to ask a more fundamental question. Can a group of people with no overlap become an effective team? Unlikely.

The only band-aid strategy that I have seen work? Have sub-teams in each timezone and then someone attends the other team’s events. In one week, someone from Vancouver is inconvenienced and attends the New Delhi team’s events. In the next week, the circumstances are reversed. This is far from optimal.

In almost all cases, we’re better off not pretending that groups of people who don’t have overlapping time are a team. Instead create two (or more) teams. Each team works from the Product Backlog independently from the others.

Does Daily Scrum Have to Be Daily?

Meeting daily feels like a hassle, does it really have to be daily? Let’s check back on the purpose of the event: update our Sprint Backlog (aka the plan), check progress towards our Sprint Goal and identify impediments.

It’s held daily because of the benefit. If your team isn’t seeing the benefits, instead of changing the frequency take the time to understand why.

Why is the Daily Scrum the same time, same place every day?

It reduces complexity and makes this Scrum event a habit.

The Three Daily Scrum Questions

One thing that people seem to believe about Daily Scrum is that there are three famous questions:

What did you do yesterday?
What will you do today?
What are your blockers?

Back in the mists of time, questions like this did appear in the Scrum Guide. The challenge is that they’re reductive. They get people to focus on task work, but not the Sprint Goal, and not even the current feature or User Story they’re working on. The narrow focus of those three specific questions also misses the collaborative nature of work.

Often the answers reveal no useful information. Common examples:

Yesterday, I spent my fifth day working on …
Today, I will spend another day working on…
I have no blockers.

With answers this repetitive and simplistic, the team has missed an opportunity to more effectively plan the day.

There have been many changes to this section of the Scrum Guide over time. We will just focus on the most recent (2020) version:

“The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.”

So your team might consider getting rid of the list of questions altogether. There is no magic to three questions. Some ideas to spark your thinking:

Which story or feature on the team needs the most help?
Which story or feature is closest to being done? This is asked with the Kanban mindset to focus on finishing work before starting new work.
Where would you like help?
Where is your biggest challenge?
Where is the team’s biggest challenge?

A recent CSP-SM attendee said: “I became a scrum master in 2022, and some of the folks that I work with on scrum teams still default to this format/language. Tactically – it’s easy to understand why as it seems to streamline the standup and quickly ascertain if things are on/off track, that people understand what they’re working on and are making progress, and surface whether there are any issues. The difficulty with this format is that the closed-ended nature of the questions does not foster a collaborative approach. I coach the scrum masters that I work with to facilitate a discussion with the scrum team that is focused on the sprint goal, rather than checking off the box on the three questions. It has helped to shift the focus from viewing their work as tasks that each individual is responsible for to thinking about their work fits into the big picture of what the team is trying to accomplish together and has helped us discover dependencies that might have otherwise been missed until something was broken.”

I believe the above comments perfectly encapsulate the benefit of abandoning the formulaic questions and changing the focus of Daily Scrum.

Story by Story and/or Walk the Board

Some teams change from a person-by-person focus to a story focus. In this case they walk through the Stories that are “In Progress”. If anyone is working on things that are not on the Sprint Backlog, they’re encouraged to add it to the board. (Or drop it if it is not relevant to the Sprint.)

We go further and take a leaf from the Kanban world. Since we’re trying to get items to done, try:

Start with the items closest to done (i.e. rightmost) and work back
Items get discussed by the people working on them
Items that are stalled or waiting for a dependency get additional attention

Why right-to-left: reinforces the Kanban mindset of finishing work before starting new work.

The whole point is to experiment and find a structure that works best for your own team to increase communication and engagement.

Characteristics of a Good Daily Scrum

Replaces all other meetings in the day. This almost needs to be in big, gold lettering. Having planned for the day, team members shouldn’t need to attend any other meetings, other than the obvious Backlog Refinement.
Short. No one feels engaged when a meeting runs on for a long time, so Daily Scrum is timeboxed to 15 minutes. Even with remote Daily Scrums on Zoom, I recommend that people stand. Sit-down meetings often drag on. Standing helps people focus.
Everyone participates. Participation means not just sharing your update, but actively listening to what other people are planning to do. Collaboration happens when you hear someone else planning to work in an area where you have recent experience. You might set aside some of your own plan to help them get through a difficult problem.
Honesty. Team members need to be open and honest about the challenges they face and, if they need help, even a little bit, they should ask. This, of course, requires the team have established Psychological Safety.
Focused on Sprint Goal. Some teams reread the Sprint Goal to start their Daily Scrum. Whether or not they do, their thinking about what they plan to do that day and what impediments exist, should be centered around the Sprint Goal.
Sprint Goal Confidence Check. Some teams ask “On a scale of 1-5, how confident are we that we’ll meet the Sprint Goal?” This makes the Sprint Goal focus concrete and actionable. It surfaces concerns early (someone holding up a 2 forces a conversation).
Solve impediments after the Daily Scrum. Most impediments are only germane for a few people. Rather than try to resolve them in Daily Scrum where it occupies the time of all team members, consider discussing them in more detail after the meeting with only those who are affected.
Parking Lot. If anything in the Daily Scrum turns into a long back-and-forth discussion, use a Parking Lot.
Process Improvement. Along with the Sprint Goal, the Daily Scrum helps track progress on the improvement(s) agreed to in the last Sprint Retrospective.

Signs Your Daily Scrum Is Working

Team members can see the bigger picture of how work is progressing towards the Sprint Goal
Opportunities for collaboration have been identified
Impediments are identified and people are working on resolving them
We’re reminded about Retrospective improvements
People engage with each other, not just report to a leader

What Happens After Daily Scrum?

This is where the real problem-solving happens.

Remind the team of the issues/impediments that were discovered. Invite the people who have the impediments and the people who can help to stay back. If the impediment is a bigger issue, the ScrumMaster may need to reach outside of the team to get more help.

If there was anything in the Parking Lot, either resolve right away or get the people who care to set up a time to solve it.

One pattern that works well: at the end of Daily Scrum, anyone can say “I need 5 minutes with [names] to discuss [topic].”

In a world with widely distributed teams, we often lose the social connection. Some teams I’ve worked with keep their Zoom connection open for a while after to socialize. In other cases, team members post office hours and hang out in Zoom happy to chat with whoever swings by.

Sitting or Standing? How should the Daily Scrum go?

A good practice is for Scrum team members to stand during the Daily Scrum event, if physically able. The thinking:

Nobody wants to stand for very long, so it helps keep the meeting short and focused.
We’re away from our computers so there are fewer distractions.
We stand in a semi-circle and face the Sprint Backlog / task board, so we all share a common reminder of the purpose.
Standing keeps the conversation focused on the tasks and helps us to keep from drifting off track.
Daily standup helps us avoid reporting to a leader, and instead we’re reporting to the rest of the team.
Standing can be done in the team area and doesn’t require a meeting room, which helps us stay in the context of our work.
Standing keeps the energy level up.

Remote Scrum team members are also encouraged to physically stand in front of their camera during Daily Scrum. Sitting in front of their computer creates multiple distractions, but standing away from the keyboard reduces that temptation.

Pitfalls of Bad Daily Scrum

As I wrote in this Scrum by Example post with our fictional ScrumMaster, some teams feel pain in their Daily Scrum. If you know someone who hates Daily Scrum (maybe yourself?), it likely stems from one of more of these common poor practices:

Scrum Master telling people whose turn it is to speak
Too much personal socializing, wandering off topic (Hint: one group I worked with leaves the zoom session open after Daily Scrum so team members can catch up outside of the meeting timebox)
Team members consistently late or not showing up
Directed rather than self-organizing. Example: one person taking over and telling team members what to do
Devolves into a status meeting, where it’s more reporting directly to a manager than it is sharing with the team
Trivial and tedious, reporting in so much detail that no one understands or cares
Repetitive. Example: someone saying that they worked on the same user story several days running
Not raising impediments
Not prepared. It only takes a few minutes of reflection to consider the Sprint Goal and plan what the next most important thing you could do.
Problem solving. The team gets lost in the weeds of a good problem-solving discussion. My suggestion to teams? Consider capping the discussion at 1 min and resolving after Daily Scrum.
Too many people in attendance. If your Daily Scrum is larger than a normal sized Scrum Team, it will take far too long. When this comes up in workshops, the leading cause is that the Scrum Team itself is too large.
Notetaking and meeting summaries. The event is intended to help plan the day, so meeting notes are pointless as they would only be meaningful for a few hours. Further, aside from impediments, there is nothing we would expect to be shared since sharing information from Daily Scrum outside the team will reduce honesty and transparency, and people will protect themselves from the perceived risk.
Some team members attending multiple Daily Scrum. Let’s talk about this one in more detail …

Attending Multiple Daily Scrums

Most of the time when I hear the complaint, “I’m attending three Daily Scrums. When do I have time to work?” the person is assigned to multiple teams. This isn’t what Scrum intends. You can’t effectively be a part-time team member on three teams. This is the classic multi-tasking problem/misconception.

So you shouldn’t be attending multiple Daily Scrums because you’re on multiple teams, but if multiple teams are working together, it might be a different story.

Multiple Teams Coordinating Work During Sprint

If you have 2–3 teams trying to coordinate work during a Sprint, some groups stagger their Daily Scrum events. For example, Team A, B and C hold their Daily Scrums 20 minutes apart. One person from each team (not the ScrumMaster) visits the other teams’ Daily Scrums to hear how the work will affect their own team, and to share how their team’s work will affect the others.

This is taken from the Large Scale Scrum approach and the arrangement is usually temporary. Teams determine in Sprint Planning which other teams they need to work with that Sprint and plan the coordination mechanism.

If there are more than 3 teams, some groups create a separate Scrum of Scrums. For more sources on multi-team Scrum see: Scaling

Tips for Remote Daily Scrum

Kill off Outlook/Gmail/Slack/Teams so there are no distractions
Camera on. Being able to see body language and facial expression goes a long way to reducing miscommunication.
Good microphone. If team members are working remotely, the organization can afford to buy everyone a good microphone.
Headphones or earbuds to reduce audio feedback.
Remind everyone to display the Sprint Backlog.

Many of these types of things get baked into the team’s working agreements.

Can Daily Scrum Be Async?

What does an Async Daily Scrum look like: Slack thread, short video clip or some other update that doesn’t require people to be available at the same time. It gets used when teams are spread so far apart that they don’t have time in common.

The tradeoff: Daily Scrum goes from being about human interaction to reporting status updates. It kills off any opportunity for questions, context, seeing body language and human connection. Even worse, we lose the “oh, I can help there” moments. When I’m coaching a team, one of my measures of team health is how much collaboration gets sparked by Daily Scrum.

If you read other sources I’m supposed to provide advice now on how to conduct an Async Daily Scrum. The advice will be short, it’s an anti-pattern that disrupts teams.

Tips to Improve Your Daily Scrum

Start with the Sprint Goal, not the people
Try Walking the Board for a Sprint and see if it changes the conversation
Rotate who speaks first (avoid the same person always setting the tone)
Use a confidence vote to make Sprint Goal focus tangible
Keep a visible “parking lot” for after-standup discussions
If the same impediment comes up two days running, escalate it
Experiment every few Sprints: change the format, the questions, or the order

Effective Daily Scrum is a skill that ScrumMasters develop over time. Learning to facilitate conversations that actually improve collaboration is one of the core competencies we develop in our Certified ScrumMaster training.

Related reading:

Updated April 2026

More Notes on Story Splitting

Fri, 03 Dec 2010 00:00:00 GMT

Done image licensed from Photodune

In response to my recent Story Splitting post, I had a few questions and couple of confusions that need clearing up.

A few elements of the INVEST criteria need some discussion:

Negotiable – the details are negotiated with the Product Owner as the team goes to implement the story. However that negotiation is a two street and not an excuse to ask for scope creep.
Valuable – the story has to be valuable to a User however that may not be enough value to be worth releasing at this moment. Instead it may take several stories together to be sufficient value for the end user. For example if we imagine the login page for a new site that needs to support its own signup system, Facebook, Twitter and OpenID. It may not be worth releasing the page without all the elements yet they still maybe good places to make a split.
Small – Bill’s original definition says small. I prefer ‘Sized Appropriately’. So things that are to be developed in the near term (perhaps 4-6 sprints) should be broken down into Stories and Estimated. Things that are further out should remain as EPICS.

Should we Slice at all? One person has suggested that if a story doesn’t want to be small then there is no point in breaking down. He went to suggest that Sprints/Iterations are just artificial boundaries. My counter is that even when its difficult splitting stories still gives you several advantages:

The Product Owner has more opportunities to change direction. With my signup example if supporting their own signup takes too long, the Product Owner may choose to drop the Twitter option.
More frequent touch points with the Product Owner and Customer allow for better steering of the direction of the team.
If the company changes direction mid-stream the larger the story the more WIP (work in progress) that needs to be either removed or finished up.
Smaller stories allow more of them to be “Done” early in the iteration, allowing an earlier handoff to QA for teams that haven’t yet adopted ATDD.
Large Stories make it easier to get lost in the details and fall down a rabbit hole (ask any of my team members at Databeacon).
Large Stories make it more likely that we will bottleneck.

Finally I’m always being asked for more Story Splitting Examples. Think back 1995 when Amazon hadn’t launched, we’re developing the site that will become Amazon:

Original Epic: “As a first time user I want the to buy a book so that I can read it in my home”

To start let’s try splitting on Workflow:

As a first time I user I want to add a book to my cart so I can buy it.
As a first time user I want to checkout my cart so I can buy the contents
As a first time user I want to enter my home address so I can get my book shipped home
As a first time user I want to see the shipping costs calculated for my home address.
….

Maybe for calculating the shipping costs for all 50 states and 10 Canadian provinces is still too big. Then let’s split it again. In this case I’m going to assume that shipping costs are the same for certain groups of states/provinces:

As a first time user I want to see the shipping costs calculated to CA, NV and AZ
As a first time user I want to see the shipping costs calculated to NY, MA and PA
As a first time user I want to see the shipping costs calculated to ON, MB, QC

Now a CRUD (Create Update Read Delete):

As a first time Amazon user I want to remember my address so I don’t have to retype it next time I come back

I want my address saved
I want to use my address when I next return
I want to edit my address
I want to delete out of date addresses

The first one is an example of story that isn’t “valuable” to user by itself. Nonetheless if it’s the only splitting possibility you have that it can still be useful.

Finally when do you stop splitting? At the lower end no smaller than two developers one or two days. Smaller than that and the stories have effectively become tasks. Stated another way, a typical team should complete 5-10 stories a sprint, so each story is 1/5 to 10/th the capacity of the whole team. This forces the stories to be small without tying them to days._

Image via: https://photodune.net/

Multiple Returns from a Single Method

Sun, 03 Aug 2008 00:00:00 GMT

Doorway - image licensed from Photodune

It’s funny just about the only thing anyone really objected to from my recent post on Minimal Coding Style was multiple return statements.

Let’s start by looking back to where this idea stems from. As best I can tell objections to multiple returns stem from Dijkstra’s 1968 paper “Go To Statement Considered Harmful”. From David Tribble who has written a Retrospective on the letter, from the introduction:

This paper was written at a time when the accepted way of programming was to code iterative loops, if-thens, and other control structures by hand using goto statements. Most programming languages of the time did not support the basic control flow statements that we take for granted today, or only provided very limited forms of them. Dijkstra did not mean that all uses of goto were bad, but rather that superior control structures should exist that, when used properly, would eliminate most of the uses of goto popular at the time. Dijkstra still allowed for the use of goto for more complicated programming control structures.

Here is what I believe about methods:

Short, Short, Short – at most one screen long – anything more requires the reader to scroll up and down to understand the code.
Do only one thing – for the ultimate anti example of this: Munger (MacOS 7/8/9) the swiss army knife of memory allocation that did different things depending on the combination of parameters. Note the linked article doesn’t describe a fraction of what Munger did. Be afraid.
Have descriptive (but not verbose) name.
Be simple and easy for the maintainer to read – this implies reducing the complexity of the control structures.

Some reasons I dislike the single exit argument:

If there are cases that aren’t applicable (invalid method arguments, …) I like to exit the method early to avoid additional indentation.
Without early exits we have to keep track of whether each additional branch was intended to execute.
Without early exits the ‘result’ might accidentally get changed, meaning the wrong value is returned.
If more code is added later it might accidentally get run even though its author intended the method to be finished.
If you need to clean up use a try/finally block since even early returns pass through finally blocks.
If multiple return statements make a method hard to read then the method is probably too large. In addition most IDE’s will allow you to highlight the control statements in any colour you need to make them visible.

More than a few other people have written on this in recent years: Bruce Eckel, Java Think (Taylor Gauthier), Java Basics, Peter Ritchie.

Do the person reading your code in the future a favour. Use early return statements to minimize the complexity in your code.

Image via: https://photodune.net/

Mythbusting - Collective Code Ownership

Wed, 07 May 2008 00:00:00 GMT

Working together - image licensed from Photodune

In researching “Are there weaknesses with Collective Code Ownership?” for a news item on InfoQ I was struck by the number of myths that get repeated around Collective Code Ownership. I thought it time to burst a few balloons.

A number of writers equated Collective Code Ownership (CCO) with “no ownership” or chaos. Yet nothing could be further from the truth. Let’s revisit Martin Fowler’s definition (he’s a better writer than I):

Collective code ownership abandons any notion of individual ownership of modules. The code base is owned by the entire team and anyone may make changes anywhere. You can consider this as no code ownership, but it’s advocate prefer the emphasis on the notion of ownership by a team as opposed to an individual.

Now its not easy to practice CCO and to make it work you need an agreed on set of coding/formatting standards. You also need to practice pair programming to help maintain the required discipline. But its not chaos.

Simon Lin mentions a team that shared a single version control account. I’m not sure where this myth commons from. CCO says that we all own the code and that we’re all responsible for maintaining it but nothing is said about sharing the same account. I think that responsibility requires that we’re accountable for what we change.

Ralf’s Sudelbücher argues that “Collective code ownership is limiting software quality”, in a rather lengthy note from two years ago. His core argument appears to be that generalizing specialists can’t know all of the domains that they need to code and so produce weaker code. The number of domains that a project might encompass has grown so large (ASP .NET, SQL, ADO, …) that no one programmer on the team can command a knowledge of them all. On this last point we agree. However I don’t think that means that team members who aren’t specialists can’t produce good quality, simple code in other problem domains. Simplicity is easy to appreciate no matter what the problem domain. In addition most new API’s follow well established patterns for a lot of methods (i.e. open/close) that make it easier to pick up the basics. To solve the remainder of Ralf’s problem: when coding in area where you don’t know the speciality well either pair with the specialist or get them to review it after the fact. Effectively implementing Martin Fowler’s Weak Code Ownership. At least this way we avoid the inevitable bottlenecks when we really on the point hats to do all the work.

One fact I’m coming to believe: to achieve the discipline required for CCO to work you need more than just common development standards. You also need to write most of your code using Pair Programming and Test Driven Development (at worst Test Minutes Afterward). Without these practices, consider using Weak Code Ownership where each module/package has an owner/evangelist who’s role is to ensure that the conceptual integrity is not only maintained but explained to other team members.

Image via: https://photodune.net/

New People on Your Project

Thu, 03 Jun 2010 00:00:00 GMT

Two male partners shaking hands at the office - image by senivpetro via Freepik

Your project schedule says that you will get 2 more team members this week and 3 more next month. How do you integrate them into the team? How do you bring them on board? How do you avoid slowdowns? In a word you can’t avoid the slowdown – adding new people to the project will slow the existing team down.

On any project it will take from 2-4 months for the team to integrate a new person and recover from the slowdown:

The person will need to be trained: In your code base, how your application works, what coding style is, how you application works, …
This person will disrupt the Teams Formation (see Tuckman’s model of team formation) – this is an especially important cost when the team has already reached the performing stage. This happens because the new person alters communication paths and will force people to renegotiate relationships around the entire team.
The person will be a drag on the team requiring support to learn new tasks.
The person will increase the communication complexity (i.e. the number of communication paths) within the team.

All of this leads us to discover Brook’s law: “adding manpower to a late software project makes it later” (from the Mythical Man Month 1975, reprinted in 1995). The physics of people hasn’t changed in 35 years.

So what can you do to solve this problem?

Say no – if its too late in the project – in many cases 4-5 months before release is too late.
Can’t say no consider what Project Udall (Surviving Object-Oriented Projects Alistair Cockburn, p20) did: Halt the big project, start a small project and add only the people who can contribute to its success to the new project. While its expensive to have people sitting idle, it may be cheaper than having them slow the project down.
Bring on all the new people at once so at least you pay the costs once in the life of the project as opposed one person at a time.
Create a new team staffed by the new people with one or two old-timers. They won’t get very much done for a while, but at least they get in the way of the others.
Get them to help with the exploratory testing, with the focus being the stories that are being written in that Sprint of iteration.
Ask them to write or refactor some automated acceptance tests.
Get them to read and write Unit tests – start by reading existing Unit tests, after all these should explain the code. If they’re not already Good Unit Tests then take the time to improve. If they’re good then do some small refactorings in the main code base – after you can trust your tests can’t you :-)
Ask them to pair with another developer

Just remember adding more people to a project is a way of slowing your project down.

For a more detailed look at how to bring someone onto an established Scrum team, see Onboard New People Without Losing Scrum Team Magic, and the Scrum by Example episode on new team members.

Image by senivpetro via Freepik

Onboard New People Without Losing Scrum Team Magic

Thu, 07 Mar 2024 00:00:00 GMT

Agile teams have been struggling since the earliest days with how to bring new people on to a team. In one of the first Agile books, there was a story of Alistair Cockburn walking a new hire through the team’s flip charts and telling the story of their work. I haven’t seen a team use flip charts in a long time, however Alistair was onto something. Most of the writing around Onboarding covers the obvious traditional stuff: mission, values, culture, etc. I won’t cover that. I will focus instead on the challenges of bringing someone new onto an effective Scrum team, specifically.

Make onboarding a priority, one that trumps regular work. Helping the new person get up to speed helps the whole organization. As a minimum, I’m going to assume that the team was involved in the interviewing process so they already know the person. Right?

Challenges of New People in Scrum

Why it’s hard to bring a new person into a high-performing team:

A good team will have built trust and a high degree of Psychological Safety. With a new teammate, everyone’s guard goes back up. No one is at fault - people simply don’t know how much to trust the new person.
A good team will also have built a mind of its own. Not literally an external brain (although that might be fun), rather, they have a shared mental model of how they work. This model includes knowing who to ask a particular question of, and what we can trust someone to do well. The model even includes shared language (e.g. abbreviations or words with special meaning). This shared mind is part of what makes a team high-performing. However, the new team member doesn’t have access to this model, so they don’t know who to ask for something nor do they know understand the shared language.

Scrum by Example - image owned by Agile Pain Relief Consulting

How to help new hires join a Scrum team

Review the Product Vision and Strategy with the new team member. Hint: this shouldn’t just be the PO and the new team member. Instead, the whole team takes a couple of hours to run through any of the common vision activities (Product Box, Remember the Future, …). This is an activity to make sure everyone on the team understands the Vision and Strategy.
Take the time to walk through the Working Agreements. Don’t just read the list - talk about how they came into being and what problems some of the more interesting ones solved. Consider doing it in the next Retrospective with the intent to make them better.
Make sure there’s a shared understanding of the Definition of Done (really just a working agreement). A simple way to do this is to take a few items from the Sprint or Product Backlog and review what the team will do to prove they meet “Done”.
Some teams have Decision Making rules as part of their working agreements. If your team doesn’t, now is a great time to add them.
Define Boundaries. All teams have boundaries, but where do they stop? Who is and isn’t part of the team? Who else do they rely on? When do they rely on others?
Share the team history. Maybe not with flip charts, but take the time to tell the story of the team. How was it formed? Who was originally on it? What was the original Product Vision and how has that changed? Understanding a little bit of how a team evolved helps you understand how they work together and the product(s) they’ve built.
Try Appreciative Interviews as a way of sharing how and why this team is successful. Consider doing these for a few Sprints. It’s a great reminder, and validation, for existing team members as well.
Try Pairing or Ensemble Programming. In our Engineering Practices, we make the case why these should be in common use. With a new person on the team, it helps the new team member learn both the toolset and the code more rapidly. Even if the team member is non-technical, I would still recommend pairing to help learn about the work that is going on around them so they have a better understanding of how they can contribute.
Consider a Personal Manual or Readme. Some teams publish and maintain an overview of how they like to work and interact with the world.
Share how the team works. This could be things like the meeting schedule (including: Backlog Refinement), and how they feel about Estimation (No estimates? T-shirt sizing? Story points? Gummy bears?)
Back Channels. When the team needs to get things taken care of, what informal networks exist outside of the formal company hierarchy? (All companies have informal networks, not always for healthy reasons.)
What else does your new team mate need to know beyond the team? What is the company culture?

Scrum by Example - image owned by Agile Pain Relief Consulting

These shared review activities start to rebuild the team cognition, and the work activities build trust.

Note: avoid personality surveys. Most of them are pseudo-science and none are useful in helping teams work together. (e.g. Myers Briggs, DISC, etc.)

Scrum By Example – image owned by Agile Pain Relief Consulting

If you’re the new person on an Agile team

Ask questions. What does Agile mean for this organization? What do leaders expect? What do team members think?
Empathize. If you’re replacing someone on their team, practice empathy. The former member might be missed or loathed. Either way, their leaving will have affected the team. Also, stay neutral. Don’t be tempted to voice opinions on something that didn’t involve you.
Listen, Listen, Listen. Whatever your role, spend most of your first few weeks listening.
Socialize. Pre-pandemic, one of my favourite coaching tools was to invite a team member for coffee. Walking out of the office levels any power differences and promises an informal conversation. In the world of remote work, have a 1 to 1 zoom conversation over coffee.
Document. In the first 3-4 months, note the things you wish you had known when you started. You will make the next person’s onboarding process easier.

Someone will complain that all of this takes time. Yes, it does. However, not putting in the effort up front will cost more later as the team struggles to work well with the new team member. And if we can’t keep our new hire, then we will pay the same price again later in the year when we need to replace with yet another new person.

Geeky research moment… a 2022 study¹ found that organizations that had deeper onboarding processes (months instead of one week) had better performance from the new employee and longer retention. So for the first few Sprints, allot between 15–20% of the team’s time to making the new person feel like part of the team. It will pay off.

Footnotes

The long walk together: The role of institutionalized socialization in shaping newcomers’ future expectations about their networks. Journal of Vocational Behavior, 137, 103757. Jiang, J. Y., Ashforth, B. E., & Li, J. (2022) https://doi.org/10.1016/j.jvb.2022.103757 ↩

Pair Programming vs. Code Reviews - It's a no Brainer

Fri, 14 Dec 2007 00:00:00 GMT

Portrait of casual executives working together at a meeting with laptop. - image licensed from Photodune

Ok so I’m about a month behind. Over on Coding Horror Jeff Atwood asked “I can’t help wondering if pair programming is nothing more than code review on steroids”. In a word ‘No’.

Code Reviews

…(and I’ve done many) are static. One or more people study the code often long after it was written and attempt to understand it. Most code reviews I participated in are very shallow. We tend to find simple issues that tools like PMD and FxCop could find for you: variable could be final, public method could be private etc. At their very best I’ve seen methods (and sometimes classes) rewritten in response to a code review. Rarely do I see the design questioned. In addition it’s often tough to spot the forest for the trees – buried in the minutia of a class the bigger questions don’t get asked – does this class need to exist? Etc. Finally simplifications of lead to more simplifications but due to the static nature these won’t be found.

Pair programming

…on the other hand is dynamic. It’s an ongoing conversation between two partners.

One partner focuses on the details – what test case am I’m writing now, what’s the minimal amount of code that I need to satisfy the test. While the other partner is focusing on the big picture: What’s the best design for this problem.
It’s not just a code review, but ongoing design review.
Changes are made in real time so as simplifications are made new ones are easily spotted.
When one member of the pair is stuck the other can step in with an idea.

Some additional benefits:

Spreads the knowledge of the code base more widely.
More people are aware of problems as they develop.
Helps raise everyone’s skill level as pairs learn tricks from each other.
Reduces the number of places where only one person understands what’s going on.
Fewer bugs – about 15% fewer according to a study by Alistair Cockburn and Laurie Williams (PDF)

One point which Jeff definitely has right – it’s hard work. Pairing for eight hours a day is not an option. Most pairs work in two-hour blocks twice a day. For a more detailed article see Jeff Langr: Pair Programming Observations

So, Jeff, if you want to discover the benefits of pairing in person (or over a remote connection) give me a shout and we will arrange something.

Image via: https://photodune.net/

Planning a Change in Career? Laid Off?

Mon, 06 Apr 2009 00:00:00 GMT

Businessman with clipboard: out of work - image licensed from Photodune

A few good friends have been recently laid off, and I’ve been left thinking what to do after that happens. First up—I don’t have any jobs in my back pocket, and I don’t know anyone hiring right this second. My thoughts are more general than that.

Even if you haven’t been laid off, I would start preparing now. You should start building your profile and be prepared for whatever happens. This is pretty much what I have done the past few years, as I started thinking about moving from day-to-day software development to a full-time Agile Coaching role.

I would recommend building your personal profile so that people will know you and think of you when they have a problem to solve. My approach to achieving that—provide service and value to others—will cause good things to flow from there. So, although the goal is create your personal brand, I think the best way to do it is thinking what other people will find valuable.

My Strategies

Get an email address with your own domain name. Having a hotmail/yahoo/gmail address just looks unprofessional. Domain names are cheap, and you can alias your domain to a Google apps or any other account. It just looks better.
Start a blog. Don’t use blogger—it looks cheap. Pick something you can control the look and feel. Typepad and wordpress are both great choices. Focus on quality and value, not frequency. BTW Use feedburner from the start if you ever migrate; it will save a ton of hassles.
Find your local Agile group (Scrum Community PBwiki has some). Start attending meetings. Ask relevant questions, become known, become a speaker.
Find an Agile mailing list (or two) that interests you (Scrum Development, Agile Testing, TDD, …);start answering questions (when you have something of value to add).
Start twittering. I’m: https://twitter.com/mlevison. If you look through the list of people I’m following, you will find many interesting people in the Agile community. You can also search on “agile.” You will see interesting conversations float by. I use tweetdeck as my tool.
Try LinkedIn—yes, I’ve dissed it before, but you might get something from it. I haven’t. My LinkedIn profile.

Remember your focus is helping other people. Do that and they will pay you back in spades. It may take a while, but eventually it will. In my case, it took about two years, but in the end it helped me land my ideal job: Coaching Agile teams.

Image via: https://photodune.net/

Portfolio Management

Wed, 18 Dec 2024 00:00:00 GMT

Beyond Scrum: Scrum Alone Is Not Enough - portfolio management

(Presented as Part 2 in the Scrum Alone is Not Enough series.)

As mentioned in the introduction to the Scrum Alone is Not Enough series, Scrum is simply the framework and, to work best, other tools and patterns need to be incorporated to build the most effective systems.

In many organizations, we see common challenges:

People being members of multiple teams
People/Teams working on multiple unrelated items at the same time
A focus on Projects and a traditional project staffing model, instead of stable teams
Stakeholders making demands that don’t fit the product vision or strategy
Stakeholders asking for new features without consideration for what is already planned I frequently tell people that Portfolio Management can help solve these problems, but what does that really mean? Let me help break it down.

Principles of Portfolio Management

Portfolio Management in Scrum (or Kanban) aims to ensure that the team(s) are always working on the highest priority work without pressure that dilutes their focus from a manageable goal. This is particularly critical if they are being asked to work in multiple teams or on unrelated projects. Without Stable, Focused Teams, there is no predictability in the system.

Agile Portfolio Management is the art of deciding which big picture items the business wants its Scrum Teams to invest in over the next few months, so a Product Owner can understand the priorities and the Team can work on them in appropriate order.

When your organization has only two or three Scrum Teams, it is entirely possible for Portfolio Management to be conducted by the Team Product Owners. They get together to discuss the big picture and where they want to steer their products over the next few months.

But when the number of teams becomes too large for informal coordination to be sufficient, or when Product Owners frequently find themselves outgunned by stakeholders with more clout, we need Portfolio Management to help keep the focus in the right place.

Agile portfolio management mitigates challenges by:

Bringing work to teams, not people to projects (forgoing traditional approaches that define projects and then staff teams for them)
Establishing boundaries between stakeholders and teams
Emphasizing visualization and collaboration
Encouraging self-organization by prioritizing and providing constraints, then letting the doers make decisions (remove micromanagement)
Encouraging timely decisions, especially when decisions are reversible
Focusing on Value over Cost
Creating Options, not Contracts – Traditional Portfolio Management emphasizes Predictability and Forecasts, but our world now has shorter time horizons and increased Complexity, so focus instead on creating options.
Allowing for agility and slack (spare capacity) – If a team or person isn’t busy with the highest priority work, they can go and help someone else (getting the existing items to “Done” faster) rather than start something new.

SAFe is famous for introducing portfolio management. It’s infamous for creating masses of additional overhead in the name of Alignment. It doesn’t need to be that hard.

How to Make It Happen

If you are – or have – one or two product owners helping ~4-6 teams, this might be very simple. POs should meet with the stakeholders every 6-8 weeks for a portfolio management meeting. Prior to this, the Product Owner should observe how many large items the teams typically complete in this period so they know the team’s total capacity. That number will allow the PO to decide how many new items to pick up in the next cycle. Here’s how it all looks:

Prior to meeting with the stakeholders, the PO and team members discuss the current state of the product so that the PO has a clear understanding of what is truly done.

Review what has been completed/delivered recently.
Review what is being worked on currently.
Take total capacity less the number of large items already in progress to anticipate the number of new items to consider.
The PO and stakeholders consider which features have enough value delivered to wind down investment.
Product Owners and stakeholders work together to decide which items to prioritize next, keeping that capacity number in mind.
Offer options. Instead of promising that a feature will be delivered in a specific month or quarter, try the following framing: “In the next month/quarter, we can deliver one major feature; our choices are …” Now the conversation is focused on the trade-offs.
Make/encourage decisions. Every time a stakeholder asks for more information rather than decide, they’re increasing waste and still spending money. The time and effort taken to gather the information is waste. In the absence of a decision, the team will still build something. Too bad if it wasn’t the highest value.A Story Map often helps the Product Owner and stakeholders have better discussions, visualizing the choices about how features fit in the bigger picture.

The final decisions about what goes into the Product is still the Product Owner’s, but using portfolio management will help the PO understand the stakeholders’ strategic needs at the same time as stakeholders understanding that a team’s capacity isn’t infinite. This keeps engagement focused at the right level.

Outside of the portfolio management meeting, if the stakeholder wants to make a request that has a large impact, ask them to bring it up the next time you meet. The goal is to ensure that large chunks of work are always considered in terms of the product strategy, and that trade-offs are made with other work items.

In larger organizations with more teams contributing to a bigger product suite, we will need more coordinated approaches, but the principles are the same.

Remember, Portfolio Management creates overhead, takes some control away from Product Owners, and reduces your ability to adapt in the moment. So be Agile and take the lightest approach you can right now, and always ask if things can be simplified later.

Updated on December 18, 2024

Images by Agile Pain Relief Consulting. Elements of first image designed by Freepik.

Portfolio Management - Idle Teams

Tue, 07 Jul 2015 00:00:00 GMT

Beyond Scrum: Scrum Alone Is Not Enough - portfolio management

(Continued from Portfolio Management Part 1 in the Scrum Alone is Not Enough series.)

Imagine that the Portfolio Management group is giving the individual Product Owners a budgetary envelope of an approximate size. As Product Owners, we expect to make small bets on individual User Stories that will deliver value to the customer. The Portfolio Management group wants to make mid-sized bets (>1 Team Sprint) that will deliver value to the customer.

But let’s say the current Sprint is one in which some Team members don’t really have a lot to do. This is the type of scenario that often drives management crazy because they see idle workers, and traditional thinking is that idle workers don’t deliver value. This rarely ever happens in real life because there’s almost always more work than there is Teams to do it, but should the rare situation occur when one doesn’t have work in the current Sprint, questions that arise may be things like:

should we temporarily reassign those Team members to other teams/projects that are lagging behind, to help them catch up?
should we give them a feature that is further down the road in the backlog to work on in the meantime, with the thinking that it will give us a head start on it since they’re sitting idle anyway?

The answer is, of course, to do neither.

If the ‘idle’ Team were to join another Team temporarily, it wouldn’t speed things up – just the opposite, it would slow everything down. Disrupting that Team’s effectiveness and cadence, their contribution would be much smaller than their effect in reducing the other Team’s capacity. In addition, it could harm moral by suggesting that the other Team can’t handle the tasks themselves.

And if the idle workers start developing a Feature that is further ahead on the Backlog, it undermines the Product Owner and Portfolio Management’s priority settings and decisions, which leaves room for “hey, could you do me a quick favour” requests within the Sprint that weren’t in the Sprint backlog. By the time the rest of the Team gets to that feature in the backlog, they may find that the work the idle Team had made on it is obsolete and needs to be undone before they can make new progress.

The best solution is have ‘idle’ Team members look at the board and see if there are bottlenecks that they can help with within their own Team. They could also pay down their technical debt, or spend time learning something that expands their capacity as a Team to work outside of their current area/column(s) on the Kanban chart. For example, the Team in the previous examples might teach themselves something about testing or creating effective online help.

The most effective thing (in terms of delivering value) is to not focus on the idle worker at all, but continue to focus on finishing the work and maximizing value delivered to the customer. This is where Portfolio Management can really excel, by understanding this fundamental truth and facilitating it.

Image by Agile Pain Relief Consulting. Elements of image designed by Freepik.

Portfolio Management with Upstream and Downstream Teams

Fri, 20 Dec 2024 00:00:00 GMT

In our Scrum Alone is Not Enough discussion on Portfolio Management, we talked about what it is, and how the use of a Portfolio Kanban Board can help visualize challenges that are inhibiting work, including with parallel teams. That was tricky enough, but now let’s tackle an even bigger challenge: managing work that happens before and after Scrum development teams. We work with many government departments and large organizations and some, for structural or regulatory reasons, have systems that operate in this way with upstream and downstream teams.

This article will focus on visualizing the flow of work from beginning to end, through all of the moving parts and teams. Once we establish a flow, we will learn to monitor it. Most importantly, we will start to make improvements. After all, there is little value in monitoring an existing process if it takes most of a Quarter to deliver value to the customer.

Let’s look at how this works by using an example. Imagine an organization or department with two User Experience people, four Scrum Development Teams, a Documentation and Marketing group of five people, part-time access to one lawyer and access to a Deployment group. (The makeup of this department and the data is fictional; any resemblance to a real organization is just luck.)

Their Portfolio Kanban board might look like this:

All of the same challenges we visualized on the simpler board before still apply and some of them will get worse. Much worse. Before showing how, we will study a fictional value stream map for this organization.

Assuming items never wait (which is unrealistic), it will take from two weeks to a month to get a Feature/Epic/Large PBI deployed. Worse, a system designed like this has a big failure risk built in. What happens if an item is rejected or requires rework after it goes through the legal/regulatory process? Depending on the problem, its UX may need to be redesigned or parts rewritten. Once the rework happens, it must then take another trip through the system. This will exacerbate all of the other problems illustrated on their kanban board.

Let’s break down where time actually goes in this process:

Development Process Flow Analysis

Team	Waiting Time	Active Time	What’s Happening
UX	7-10 days	4-7 days	There are only 2 UX team members working for all 4 development teams. Some items need a few rounds of conversation with customers and stakeholders to make the key decisions.
Development	2-10 days	4-10 days	Work waits, at most, one two-week Sprint before a Development Team picks it up. Once started, items never take longer than a Sprint.
Documentation and Marketing	7-15 days	4-7 days	Many of the features that are worked on have a customer facing impact. They need documentation to be usable, and marketing for people to find them in the first place. This is complex work, and the whole department has only 5 people to do all of this work for all teams.
Legal and Regulatory	14-21 days	2-4 days	There is only one lawyer who can review the work, check legals, and approve regulatory compliance. They only support this department part-time. They do large batches of work and only do approvals when the entire batch is completed.
Deployment	1 day	2-4 hours	The Deployment team have embraced a DevOps type approach. They’ve automated most of the deployment work and so they spend only hours for most deployments.

These numbers tell a clear story: work spends more time waiting than being worked on. Think of this like a relay race. Even if each runner is quick, most of the time is spent waiting for the baton handoff. In our case, work spends more time waiting (31-57 days!) than being worked on (14-28 days).

As Agile Coaches, Scrum Masters and Managers, we usually look first at our development teams to improve the process. In this example, the developers only effect the 2-10 days of waiting time and additional 4-10 days to do the work. If we wave a magic wand that instantly does the work and optimizes for the throughput of the development, it would, at best, affect 20 days of time. Not even as long as the wait for the lawyer alone.

Quick Wins: Monitor and Tune

Let’s start with some immediate improvements. These won’t transform your organization overnight, but they’ll create momentum.

First, monitor the board regularly. Review it with Product Owners, ScrumMasters and representative team members from the upstream and downstream teams a couple of times a week.

As with our Kanban Portfolio View post, the same strategies for visualizing challenges and resolving dependencies still apply to begin making improvements.

Start with the items closest to being finished. What can be done to help them get to Done?
Also, look for the oldest items since, as items age, there is a greater chance that they’re no longer valuable.
See where items are stuck waiting most often or for the longest period of time. In our fictional example, it’s the lawyer and then marketing.
Look for Blocked items and see what it will take to unblock them. At the level of a kanban board like this, blockages often relate to approvals (our board doesn’t model an approval process).

All of our efforts to this point have been steady state. Monitoring the flow of work through an existing system and playing the role of a jockey to get things unstuck. These initial improvements that we get here will help deliver the quick wins that are often asked for.

However, a steady diet of quick wins is like eating ice cream or chocolates all day long. They taste good at first, but too much focus on quick wins is unhealthy. Living within the limits of the existing system will ensure only adequate results for years to come. There will be challenges with both quality, and customer feedback that is so late as to be useless.

Gather Data

Getting beyond quick wins, we need to make real improvements. To do this, we must study the workflow to see where to make change. If there isn’t already a value stream map for your organization, this would be a good time to create one so everyone has a visual representation of all the steps that work items take through the process.

Then start gathering Cycle Time data to understand how long the average item takes and, more importantly, how long the worst items take. This data provides a baseline for the improvement process. Many Agile teams pay attention to velocity, i.e. the number of PBIs completed per Sprint. Velocity (properly called Throughput) is far less important than Cycle Time. Optimizing for Cycle Time is about ensuring the value is delivered sooner. The sooner we deliver value, the sooner it gets used, and the sooner we will get real customer feedback. Remember the principle from earlier in the series: watch the work item, not the workers.

Look for cases where work late in the process (in our example, Legal or Marketing) finds a problem that forces work to return to earlier on the board (e.g. User Experience or Development). Items sent back are a sign of either not understanding the downstream needs (especially legal/regulatory) or defective creative/development work. In addition, items that get reworked are more likely to be a source of defects at a later date. Finally, items that get sent back for rework will have a much longer Cycle Time.

Transform the System

Now it’s time to make deeper improvements. Our goal is to improve the parts of the system that have the largest effect on delivery time. However, we may need more influence to make changes that far upstream or downstream in the organization. There might be issues of organizational politics and resistance to change—which is beyond the scope of what we will cover in this article—but we’ll share strategies that are within general reach.

Here are proven approaches, grouped by type of change and ordered by degree of difficulty:

Help Other Teams

These will be the smallest wins but the easiest to start with.

Using our example for these, ask Marketing and Legal, “What could development teams learn to make your work easier?” Small tasks learned by development can reduce the downstream teams’ workload.
If the legal review process finds problems, it tells us that teams don’t understand the legal requirements. Start by ensuring all team members understand the legal/regulatory issues relevant to their work.
Improve the Definition of Done so teams review their work against legal or other requirements before calling it finished. Yes, this reduces velocity, but it improves quality and reduces overall delivery time.

Reduce Wait Times

Create Work in Progress (WiP) Limits for each “Waiting For” queue. Yes, this means some teams might be idle, so use that time for cross-skilling.
Work with downstream teams to reduce batch sizes. For legal reviews, this might mean more frequent, shorter reviews rather than big batch approvals.
Look for automation opportunities. For example, automate the first pass of legal review so lawyers only spend time on complex issues.

Cross-Skill Teams

Take ideas from LeanUX and bring UX work into the Scrum Team. Over 6+ months, UX people can move from being the only ones who can do the detailed work to being consultants and advisors. Development teams learn basic UI design and experimentation, while UX focuses on higher-level work. This eliminates 7-10 days of waiting and 4-7 days of active work.
Some organizations move marketing team members into development teams. Like the LeanUX approach, this eliminates 7-15 days of waiting and 4-7 days of active work. The trade-off? Again, lower velocity but faster delivery to customers. If this much cross-skilling seems alien, it is the norm in the world of Lean Manufacturing. Many organizations pay more for people who can work across stations.

Bring Work Earlier (Shift Left)

These changes will be the hardest but have the deepest impact.

Move legal considerations to the start of the work, not the end. As we learned to write tests before code, we can consider legal requirements during design. When features are being designed, legal considerations are brought up front to smooth the latter part of the journey. This is the same thing that the Agile community has learned about testing. Move testing to the start of the Sprint, not at the end. Instead of finding bugs after the code is written, we get better quality by co-creating the tests and a test plan before we start the work. (See Example Mapping](/blog/example-mapping-your-secret-weapon-for-effective-acceptance-criteria/), [Behaviour Driven Development and Agile Testing for more).
Apply this same “shift left” thinking to any part of the process that risks rejection.

The ideal end state? Upstream and downstream work happens inside development teams. While this takes years to achieve, each step in this direction reduces cycle time, improves quality, and gets customer feedback faster. Remember why Agile started - long development processes led to poor quality and late feedback. When work takes 47-89 days to deliver value, we face the same problems that sparked the Agile movement.

As long as we work in this environment, we need a board and process to track and manage the flow. Just as our teams inspect and adapt using the Scrum process, we inspect and adapt how we manage the portfolio itself.

Continue the Improvement Cycle

We need to keep asking how we can improve flow in the entire department and how to improve the Portfolio process as well. The Product Owners, ScrumMasters, Development Team members and others who use this board and approach outlined here, should all participate in a Retrospective. They should use the retrospective process to shine a light on how work is flowing through the system.

Measuring Success

Success isn’t just about monitoring metrics - it’s about delivering value faster. Look for:

Reduced average cycle time
Fewer outliers (no more “stuck” items)
Less rework from marketing/legal
Higher quality
Faster customer feedback

Start Small

In some organizations the steps outlined here might take two to three years. Start small.

Find willing partners
Map and measure what you can
Gather data
Make some small improvements
Use the leverage this gives you to go further

Your customers are waiting - what’s the first step you’re going to take?

Product Backlog Refinement Hell: 3 Problems and Solutions

Sun, 08 Mar 2026 00:00:00 GMT

Bad Sprint Planning almost always traces back to the same place: poor Product Backlog Refinement. I’ve said this in workshops for years. The response I get most often? ‘Our refinement drags on forever’ or ‘1hr in refinement feels like 3hrs in real time.’ So here’s what actually helps.

Hint: there is a whole class of challenges around meeting hygiene and decision-making that I won’t cover here. We already have articles on why group decision-making techniques matter and how team friction inspires working agreements.

What is Product Backlog Refinement?

Product Backlog Refinement is the ongoing process of reviewing, reordering, breaking down, and clarifying items in the Product Backlog so the team has enough well-understood work ready for the next Sprint.

At the simplest level, Product Backlog Refinement is the process of preparing the Product Backlog for the next Sprint. If the previous Sprint delivered six or seven User Stories, the Product Backlog now has six or seven empty slots. Refinement is replenishing the queue.

For years, it was called Backlog Grooming, but that term was dropped over a decade ago. Grooming always seemed odd to me. When we groom a pet that has been out of the house, we’re cleaning it up. Why would we do that to a backlog? Refinement means to sharpen or improve; that seems like a better fit.

Refinement includes:

Reprioritizing items in the Product Backlog
Breaking down large items into smaller pieces
Clarifying
Adding and, more importantly, removing items from the Product Backlog
Estimating Effort (doesn’t have to be story points)
Updating the Strategy (i.e. Story Map) as needed

Problem 1: Backlog Refinement Meeting Drags On Forever

Long meetings are exhausting. I’ve never heard anyone say, “I attended a 3hr refinement meeting, and I’m glad I did.” Remote meetings make an already difficult activity even more challenging.

There are a couple of tactics I recommend in every CSM and CSPO workshop.

Split the meeting into parts - max each session to 60 mins. Plan for 3 sessions in a Sprint, and tell the team that if they’re really effective, they can get the job done in 2.
Ask the team to come prepared. Invite them to spend 10 mins reviewing the upcoming Product Backlog Items (or User Stories) and thinking through any questions they have.
Learn what the discussion around a good User Story looks like. I.E. after 5 minutes, the team is mostly done discussing the User Story. Use this as a rough guide. If the discussion is taking longer than 5 minutes, ask the team whether they expect it to finish soon. If not, offer to table the Product Backlog Item for another time. I usually frame it like: “Perhaps this one needs some more digging to clarify key details, let’s bring it back in our next session.”

Silent Backlog Refinement Meetings - A Dream or Nightmare?

Amazon starts every meeting with a table read, everyone reads a six page document silently. Attendees take up to 25 minutes to read the document. Only after everyone has finished reading, does discussion begin.

The idea is that reading is faster than listening and helps non-native speakers engage. Arto Kiiskinen adapts Amazon’s Table Read to Backlog Refinement. Silently read a list of Product Backlog Items; add comments/questions; annotate each other’s comments/questions with: “Don’t understand”, “Agree”, “Strongly Disagree”. In this case, the focus is on the User Story as a written document.

I’m troubled. User Stories are not intended to be read. They are intended to be “an invitation to a conversation”. User Stories were invented to avoid the challenges of written requirements, and here we’re full circle.¹

Movement in Backlog Refinement

Chris Sims reminded me that we didn’t evolve to sit all day. Sitting down for even 60 minutes can be tiring. Change the energy, get up and move around. Lead by example, do it yourself first.²

Problem 2: Estimation Wars Eat Your Week

People have died in the wars fought over estimates. (Ok, not literally, but it feels that way.) Planning Poker was invented to avoid endless debates in meetings. Imagine it like colours. The first team member says, “Green”, the second says, “Chartreuse”, the third says, “Olive”. The debate will continue forever. The answers are close enough that it doesn’t matter.

James Grenning invented the tool to solve this problem³. The irony, of course, is that we’ve all seen Planning Poker turn into a game of endless debates.

The problem is that Story Points were supposed to be relative estimates. However, when a new person joins the team, the first question they ask is, “How many person-days is a Story Point here?” The magic of relative estimation is lost in that moment. There are many sources of this problem:

Leadership focusing on velocity, not value
Increasing pressure to go faster (a problem which GenAI is just making worse)
Feeling that we must cram more into a sprint
Pretending that better estimates will make us more predictable

Replacing Story Points?

Try Complexity Poker, where the first question is which Cynefin problem domain does this item belong to?

Clear - we’ve done this so often before, we know exactly what needs to be done
Complicated - we understand the core idea, but there are some unknowns, either business or technical
Complex - we don’t know what needs to be built or if it is technically possible

Many estimation problems arise because we try to estimate Complex items that require experiments with prototypes, with Story Points that work best for Clear problems.

Items that are Clear could be estimated just by comparing them to similar items in the past.

Complicated items should be broken down into items that are small enough for a few people to implement in a few days. (Often called a T-shirt size of Small.) Complex items need experiments to understand: Should this be built? Do we know how to build it?

Instead of Story Points, consider using T-Shirt sizes: Small, Medium and Large. Small is well-understood, we can easily complete 5-10 of them in a Sprint; Medium is more complicated, likely most of a Sprint; Large is bigger than a Sprint. We should always have enough Small items at the top of the Product Backlog to fill a Sprint.

Magic Estimation

Put columns on the wall for each category: Small, Medium, Large or 2, 5, 8, 13, 20. People grab an item from the Product Backlog and place it in the column they think it belongs in. If no one wants to move it then it’s in the right place. If it gets moved more than once, then we don’t know what it is.

I first learned about this approach from people at Rally Software (remember them). I’ve heard it called Bucketing, Wall Estimation, and Affinity Mapping⁴. Barry calls it Magic.

Context - use when you have a larger volume of PBIs to rapidly sort through: 1 1/2 -> 4 mths worth. This is focused on speed over precision.

Problem 3: Not Ready and Wrong Attendees (Team Doesn’t Get It)

Backlog Refinement is a whole team activity. Not just the Product Owner and a few senior developers. When you don’t have the whole team involved, you’re missing out on additional perspectives; the others don’t understand what needs to be built, and it’s demotivating because they feel excluded.

Domain Knowledge

The team can’t refine what they don’t understand. When candidates fall outside their domain, bring in a stakeholder or subject-matter expert before the session stalls. Use that conversation well. Stakeholder input often reveals something else: items on the backlog that are no longer relevant and are just adding noise.

If an item has been in the Product Backlog for more than a few months, then it is time to ask: “is it really valuable?” If not, remove it.

Disconnect from the Strategy

The Product Owner needs a clear strategy that helps the team understand the direction of the product. I recommend Story Mapping as a way to visualize the strategy. When the team understands the strategy, they have a better understanding of where the item that is being refined fits into the overall product.

Not Ready

If we frequently have items that aren’t well understood, some teams create a Definition of Ready. I’m not a huge fan, as it can become a gatekeeper. However, it can be helpful to have a simple rubric to make sure a PBI is ready for the team to discuss. For example:

Pencil sketch of any UI changes
Happy path examples

Not a Meeting

Not all refinement sessions need to be a formal meeting. Some refinement, can just be the Product Owner reordering the Product Backlog or deleting an item; telling the team about the changes afterwards.

Refinement isn’t a ceremony to survive. It’s the work that makes everything else possible. Get it right and Sprint Planning becomes almost boring — in the best way.

If these problems sound familiar, there’s more coming. Part 2 will cover: Anti-patterns, Lack of Visibility and Stuck on Subscribe below and I’ll send it to you when it’s ready.

And if you’ve solved one of these problems in a way I haven’t covered, I’d like to hear about it: @mlevison@agilealliance.social and LinkedIn.

Product Backlog Refinement in Action

Footnotes

Arto Kiiskinen, Silent Backlog Refinement Meetings ↩
Chris Sims, Five Steps to a Better Refinement Meeting ↩
James Grenning, Planning Poker ↩
Barry Overeem, Magic Estimation ↩

Product Owner Isn't Just a Business Analyst on Steroids

Tue, 16 Oct 2012 00:00:00 GMT

Feedback Listening - image licensed from iStock Photo

There is a common misconception that the Product Owner is just a Business Analyst with a new suit and a better title. While the two share many skills in common, the roles are really quite different. According to the Agile Atlas: “The Product Owner is the single individual who is responsible for drawing out the most valuable possible product by the desired date.”

The key here is that the Product Owner is responsible for helping the Development Team see and understand the needs of the business.

Great Product Owners have:

A clear understanding of the business needs.
A clear vision of where the product needs to go.
Enough budgetary authority that they can make decisions about product features without having them changed later.
They must be able to get answers to the team’s questions rapidly (think minutes and occasionally hours).

The right Business Analyst has these attributes and will make a great Product Owner. In contrast many BA’s are great detail people, but struggle with the vision side. In addition many businesses aren’t willing to give a BA the budgetary authority required of the PO.

Other warning signs of the wrong PO:

Rarely available to answer the team’s questions
Doesn’t talk to end-users directly instead just talks to their managers or admins
In a large organization there are often many levels of people between the PO and the actual users of the Product

So before just deciding that your Business Analyst will become the Product Owner, sit down and examine who has the right mix of skills, authority and access to play the role well.

Image licensed from iStockPhoto

Product Owners and the Art of Saying NO

Thu, 05 Jun 2025 00:00:00 GMT

As a Scrum Product Owner, it is easy to say yes. When we say yes to stakeholders, they’re happy because they know the feature they just requested will be built. The problem, of course, is that when we say yes too often, we build incoherent products.

Caution

When we say yes too often, we’re effectively saying NO. Once the Product Backlog is large enough, saying yes means adding a Product Backlog Item (or User Story) to a queue so long that it will never get built.

The popular advice is to practice saying no in the mirror.¹ Fun? Yes. Practical? No.

There is a better approach, which I call Stakeholder Akido, based on the Japanese martial art “which practitioners could use to defend themselves against attacks, while also protecting the attackers from injury.” ². In our case, we want to mitigate the impact on our Product Backlog without harming the stakeholders.

This approach only works if you have a sufficient understanding of the customer and their needs. Usually, this means you’ve talked to customers, gathered data, and turned it into a clear vision, personas, and strategy (e.g. Story Map or Impact Map). Alternatively, if you’re taking the Lean Startup approach, then a Lean Canvas and a list of initial experiments. Without all of this, we risk saying NO to valuable items.

illustration of Product Owner Focus, © Agile Pain Relief Consulting

Ways to Say No

The goal with every technique we cover is to get the stakeholder to say their own ‘no’. (This won’t always work.)

Vision

If the request is far enough outside of the scope of the product, then review the vision and/or Lean Canvas with the stakeholder and say something to the effect of “This doesn’t fit our current vision. If we take on this request, we will lose our core focus.” Be prepared for pushback; in some cases, powerful stakeholders will demand an update to the vision. The best defence here is to have involved them in creating the original product vision, so that they can see that changing it isn’t a good idea. Caveat: occasionally, we might learn something new that actually justifies updating the vision.

Personas

Similar to the product vision, test whether the request meets the needs of the documented personas. Personas are a lightweight model that illustrates the needs, behaviours, and experiences of a number of end users. When a feature request arrives, ask if any of our personas use this feature. If yes, would they use it in the way that is being suggested?

Here, our PO might say, “I’ve checked the feature for <PersonaName#1>, … and it doesn’t solve a problem any of them have.”

If the request is appropriate for the personas, but it’s not important for now, use strategic focus to show where it does fit.

Strategy

There are several tools that I recommend Product Owners try to help visualize the product strategy.

Impact Mapping is a tool that helps teams focus their work on a feature by identifying portfolio items or strategic changes that will have the most significant impact on achieving their goal. Impact Maps are intended to be drawn, and not just written in words.
Story Mapping is a simple tool to help you visualize your Product Backlog. It indicates which major items the PO is focusing on and which they are not.

Since Impact Mapping is a focusing tool, use it to test whether a requested feature is outside of the current focus. So, in this case, the PO is saying, “Not high enough impact.”

Use a Story Map to show if a feature is or isn’t in focus in the near term. Here, our PO could say, “This area is not in focus now, come back and ask again in 3-4 months.”

If a strategic ‘no’ isn’t working, consider engaging the stakeholder in advance of them making a request.

Prioritization

This tactic works best when we have no surprise requests. Engage the stakeholders as part of the prioritization process. If they’re in the room when the decisions are made regarding prioritization, they’re less likely to try to change the decisions later. Consider using two collaborative games, such as “Buy a Feature” or “Business Value Game”. Both are collaborative activities that use input from multiple stakeholders to help with prioritization. When played well, these games help an individual stakeholder see that their perspective isn’t the only one.

If prioritization fails, demonstrate that an infinitely long queue will become a significant issue.

Product Backlog Size

Once the product backlog becomes too large, a ‘yes’ becomes a ‘no’. Here’s a simple thought experiment that will shock most stakeholders. Ask them to imagine a Product Backlog of 100 items and our team completes an average of 7 per Sprint with no defects, no rework, etc. (This, of course, is impossible). In that case, an item added to the bottom of the queue will take 14.5 Sprints or, assuming 2-week Sprints, over 28 weeks to be worked on. In that time, other priorities will emerge so that it will be pushed down further. Even worse, it does get implemented, but it is no longer relevant. Here our PO should say, “Not yet, let’s recheck the Story Map and discuss how far away it is.”

Portfolio Management

Create a formal space so that the stakeholders aren’t ambushing the PO at random moments with requests. Every 6-8 weeks, the Product Owner invites the stakeholders to review what has been recently completed (focus on large, high-level items). Then review the items currently being worked on (Portfolio Kanban helps engage stakeholders in this respect). Only once we’ve proven there is capacity for new major items does the group discuss which major items are the next priority.

This helps by engaging our stakeholders in the decision-making process. Since they’re in the room when decisions are being made, they’re less likely to make surprise requests. If they do make requests outside of the Portfolio Management meeting, ask them to defer to the next session.

For more depth on executing Portfolio Management, see Scrum Alone Is Not Enough: Portfolio Management.

The Human Side

When dealing with stakeholders, most are not trying to derail your product development. Take the time to listen, understand, and empathize with their needs. When moving away from a traditional approach, many stakeholders are living in a shadow of the past where they had to fight to get their item in the requirements document a year in advance and then, even after that, they had to fight to get it worked on. It takes time for them to understand the new world, where there is a new version of the product every two weeks.

How can a Product Owner say no?

Vision
Personas
Impact Map
Story Map
Prioritization
Product Backlog too big
Portfolio Management

Sometimes, in an attempt to accommodate a stakeholder, the PO will split the difference and give them some of what they want. This results in a product full of half-baked features. If we’re going to work on a feature, commit to it fully or not at all.

We’ve covered seven ways for the Product Owner to say no. However, this isn’t meant to be a complete list. Instead, I wanted to show that saying no comes from engaging the stakeholder and helping them see why their request doesn’t fit the product. Pick at least one new approach to saying no, with empathy to your stakeholders.

Agile Pain Relief Blog Entries

Scrum by Example – Scrum Anti-Patterns & Unplanned Work Disrupting the Sprint

Footnotes

Recommended Books for Scrum Product Owners

Wed, 18 Jun 2025 00:00:00 GMT

Here is a list that I share with my Certified Scrum Product Owner workshop of books that they might benefit from.

(Disclaimer: Some of these are affiliate links. It doesn’t cost you anything more and, at most, I might earn enough for a cup of coffee.)

book covers of recommended reading for Scrum Product Owners

Core

INSPIRED: How to Create Tech Products Customers Love by Marty Cagan - Marty has very strong opinions about Scrum. If we ignore his rhetoric, he is an original thinker and challenges us to do far more than satisfy our customers.

Innovation Games: Creating Breakthrough Products Through Collaborative Play by Luke Hohmann - One of the original Product Owner related books in the Agile world. This book is the source of many popular Vision (Product Box), Prioritization (Prune the Product Tree and Buy a Feature) and other activities. Nearly 20 years after it was originally published, this remains a strong recommendation.

The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web by Steve Mulder and Ziv Yaar - The only book I have ever found that covers Personas. I admit this one is ripe for replacement.

Behavior-Driven Development with Cucumber: Better Collaboration for Better Software by Richard Lawrence and Paul Rayner - While the title focuses on a tool called Cucumber, the real value of this book is in driving better conversations within the team. The conversations lead to better acceptance criteria, which in turn reduce defects. Done well, BDD also increases throughput. Not quite magic, but close to it.

When Will It Be Done?: Lean-Agile Forecasting to Answer Your Customers’ Most Important Question by Dan Vacanti - Companion to the book I offered ScrumMasters on Flow Metrics for Scrum Teams. This book helps you make better forecasts so you can spend your time working with stakeholders to make tradeoffs as to which features they would like to see by a given date.

Strategic Tools

User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton - Story mapping helps you break down your vision into strategic stepping stones. Done well, it also allows you to show others where you’re considering taking the product without fleshing out much detail. This in turn makes it easier to say “not now” when a feature is requested in a product area that isn’t in focus right now.

Impact Mapping: Making a big impact with software products and projects by Gojko Adzic - Impact Mapping helps explore a wide array of paths to achieving a goal. The approach is a highly structured form of mind mapping. The idea is that the goal can be achieved through many paths, and sometimes the obvious path doesn’t get the best bang for the buck. Impact Mapping helps make the choices more clear.

Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects by Johanna Rothman - Impact Mapping helps you explore choices; Story Mapping helps you visualize the options. Neither of these tools makes the choice for you. Portfolio Management is about using all of our strategic information to make better business decisions as a group.

Discovery and Lean Startup

*New addition: Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value** by Teresa Torres - If Continuous Delivery is good for a Scrum Team building product, shouldn’t we invent an approach to speed the flow of discovering features? Continuous Discover Habits sets out to solve that problem.

Running Lean - 3rd Edition by Ash Maurya - The original Lean Startup book covers the concept well, but provides limited ideas around the implementation. Ash’s book steps into that gap. Further, the 1st edition of the book was created using a Lean Startup-like approach where the author posted a list of chapters he was planning to write and asked for feedback. Then he wrote each chapter in the open, asking the audience what he had missed along the way. Now in its 3rd edition, the book keeps improving.

Testing Business Ideas: A Field Guide for Rapid Experimentation by David J. Bland and Alexander Osterwalder - This book is both amazing and annoying at the same time. The amazing: it gives more context on how and when to use a larger variety of Discovery-flavoured experimentation techniques. It also has maps showing how the different techniques relate to each other. The annoying: like other books in this series, it costs the earth but the text is sparse, so the reader is often left hungry for precise implementation details.

Lean UX - 3rd Edition by Jeff Gothelf Josh Seiden - Lean UX is one approach to bringing User eXperience into the Agile world, without the lead time problem of other approaches. If the Lean Startup approach is focused on large-scale experiments (e.g. should we build a product or major feature in this space?), Lean UX focuses on the smaller question (e.g. which version of this feature will work best with our users?) Additionally, the book turns UX into a whole team sport vs. the domain of specialists.

The Human Side of Work

Why Motivating People Doesn’t Work…and What Does, Second Edition: More Breakthroughs for Leading, Energizing, and Engaging by Susan Fowler - The classic book on understanding human motivation (hint it’s not carrot and stick.) This book introduces the ARC Model

Your Brain at Work, Revised and Updated by David Rock - Covers how our brains do and don’t work during the working day. It’s a well-written book, marred only because the science has moved on in at least one area (willpower) and the 2020 edition of the book still relies on the invalidated work of Roy Baumeister.

The Catalyst by Jonah Berger - Cialdini (below) remains the most authoritative book on influence, however Berger has written the easiest read. Start here and then go deep with Cialdini.

Influence, New and Expanded: The Psychology of Persuasion by Robert Cialdini - As a Scrum Product Owner and agilist, you need to use influence on a daily basis. When you want the team to consider an experiment or an idea, you use influence. When you want management to resolve an organizational impediment, that will require more influence. Cialdini shows you how influence works. Outside of work, he shows you how companies like Amazon influence you every day.

Never Split the Difference: Negotiating As If Your Life Depended On It by Chris Voss and Tahl Raz - In theory POs have some authority over product decisions. In practice they need massively good negotiation skills because they don’t have enough in 90% of cases. Negotiation, contrary to popular belief, isn’t about agreeing on facts and finding a win-win. Real negotiation involves understanding the other party’s emotional needs. Until their needs are met, you can’t reach an agreement.

Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts by Annie Duke - Teaches us how poker players make decisions under conditions of uncertainty, starting with the simplest idea: fielding errors. When I play a hand and win, that doesn’t necessarily mean I had good strategy. Maybe I was just lucky. When I lose a hand, that isn’t always bad luck, maybe I had a poor strategy.

Where the Action Is: The Meetings That Make or Break Your Organization by J. Elise Keith - Shows that there are 16 different kinds of meetings and they all need to be handled differently.

Remember

Think I missed an important book? If you’re part of our community, post your suggestion HERE.

Recommended Books for Scrum Developers

Wed, 09 Jul 2025 00:00:00 GMT

For many years I’ve shared with my Technical and Non-Technical Certified Scrum Developer attendees a list of recommended reading, updated when I find new gems. My hypothesis is that a good Developer knows that a short workshop can’t cover everything and they will be hungry for more reading. Here are my suggestions.

(Disclaimer: Some of these are affiliate links because a marketing guru said I should have them. It doesn’t cost you anything more and I might earn enough in a year for a cup of coffee.)

book covers of recommended reading for Scrum Developers

Agile Engineering Practices

Agile Technical Practices Distilled by Pedro Moreira Santos, Marco Consolaro, and Alessandro Di Gioia - A fairly complete introduction to the technical practices worked through in the workshop.

Refactoring: Improving the Design of Existing Code 2nd Edition by Martin Fowler - The Classic.

Clean Code Principles and Patterns, 2nd Edition by Petri Silen - Another soup-to-nuts technical practices book. FWIW, the author likes Microservices more than I do. He approaches them as a default practice. My leaning is to use them less frequently. Python edition is also available.

Your Code as a Crime Scene, 2nd Edition by Adam Tornhill — an entertaining read about remediating technical debt. (Entertaining in the development world - that’s a shock).

Refactoring at Scale: Regaining Control of Your Codebase by Maude Lemaire - A good complement to Adam’s Code as a Crime Scene, covers more the planning and coordination aspect of tidying up a big ball of mud.

Design Patterns and Language-Specific Books

Pragmatic Unit Testing in Java with JUnit, Third Edition by Jeff Langr - Covers JUnit5, however its breadth means there is value even for developers in other programming languages. Caveat, my daughter and I were pre-beta readers and have provided cover quotes endorsing the book.

Head First Design Patterns: Building Extensible and Maintainable Object-Oriented Software by Eric Freeman and Elisabeth Robson - For 30 years I struggled to read the original Design Patterns book. I wish this book had been written at the time. As with all O’Reilly books, given their price, they should be called O’Really.

Learning JavaScript Design Patterns: A JavaScript and React Developer’s Guide by Addy Osmani - JavaScript’s functional programming focus is different from the OO world where Design Patterns originated that helps to have a book that examines them from that viewpoint. Now Free: https://www.patterns.dev

Clean JavaScript by Software Crafters - A short book to help the developer get started on Test Driven, SOLID code.

Outside-In React Development by Josh Justice - Covers TDD from the UI on down the stack.

Agile Testing

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.

DevOps

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren PhD, Jez Humble, Gene Kim - Teaches us how to measure DevOps systems and use those measurements to improve.

The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations 2nd Edition by Gene Kim, Jez Humble, Patrick Debois, John Willis, Nicole Forsgren - The only well-written book that I’m aware of that covers how to implement DevOps.

Team Improvement

Flow Metrics for Scrum Teams by Daniel Vacanti and Will Seele - Shows how to use Work Item Age and Cycle Time to help teams drive their improvement process.

Remote Mob Programming - Home but not alone by Dr. Simon Harrer, Martin Huber, and Jochen Christ - Written just before the start of the pandemic (talk about timing). It covers how to take ensemble programming and have it work remotely.

The Coding Dojo Handbook by Emily Bache - Practices for teams to create a safe space to learn.

The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece by Ron Jeffries.

Remember

Think I missed an important book? If you’re part of our community, post your suggestion HERE.

Recommended Books for Scrum Masters

Wed, 18 Jun 2025 00:00:00 GMT

For many years I’ve shared with my Certified ScrumMaster workshop attendees a list of recommended reading, updated when I find new gems. My hypothesis is that a good ScrumMaster knows that a short workshop can’t cover everything and they will be hungry for more reading. Here are my suggestions.

(Disclaimer: Some of these are affiliate links because a marketing guru said I should have them. It doesn’t cost you anything more and I might earn enough in a year for a cup of coffee.)

book covers of recommended reading for ScrumMasters

Core

Large-Scale Scrum: More with LeSS by Craig Larman and Bas Vodde - LeSS is appealing because it is the lowest overhead approach to organizing multiple teams that I’m aware of. In addition, LeSS was derived through practice. Instead of creating a theory, they tried stuff that worked.

Agile Technical Practices Distilled by Pedro Moreira Santos, Marco Consolaro, and Alessandro Di Gioia - Excellent summary of all of the TDD, BDD, Refactoring, Pair Programming.

Flow Metrics for Scrum Teams by Daniel Vacanti and Will Seele - Vacanti is one of the best people for understanding what measurements help teams improve, and Dan is humane in his application of Kanban/Scrum.

Agile Retrospectives, Second Edition by Esther Derby, Diana Larsen, David Horowitz - The original book on Agile Retrospectives got a rewrite after 20 years.

Making Work Visible: Exposing Time Theft to Optimize Work & Flow by Dominica DeGrandis - A series of exercises that introduce the ideas of Kanban without the dogma.

The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, John Willis, Nicole Forsgren - The only good technical book I know of on DevOps.

Remote work and Distributed Teams

From Chaos to Successful Distributed Agile Teams by Johanna Rothman and Mark Kilby - Mark has been coaching distributed teams for a long time before it became popular in the pandemic.

Work Together Anywhere by Lisette Sutherland - Focused on being an individual contributor in a remote team. Written pre-pandemic, it deals surprisingly well with the hybrid problems we face today. Caveat: hybrid/remote work is continues to change and evolve.

Organizational Change

Retrospectives for Organizational Change: An Agile Approach by Jutta Eckstein - Org change is hard, but using retrospectives to guide the process makes it less painful.

Organizing Toward Agility: Design, Grow, and Sustain Self-Organizing Structure at Scale by Jeff Anderson - Shows how Agile organizations could be structured and evolve. It is chock full of options and tradeoffs, as opposed to a formulaic approach.

The Science of Organizational Change by Paul Gibbons - Examines how organizational change works. Brings a scientific perspective, including material on motivation and where resistance comes from.

Agile Outside of Software

Agile for Non-Software Teams by Gil Broza - Takes Agile back to first principles and helps you build out your own Agile implementation.

Office Lean: Understanding and Implementing Flow in a Professional and Administrative Environment by Ken Eakin - Eakin hardly mentions Agile at all; instead he takes an approach very much inspired by Toyota Lean Production System and applies it to professional work.

The Human Side of Work

Why Motivating People Doesn’t Work…and What Does, Second Edition: More Breakthroughs for Leading, Energizing, and Engaging by Susan Fowler - The classic book on understanding human motivation (hint: it’s not carrot and stick.) This book introduces the ARC Model.

The Catalyst by Jonah Berger - Cialdini (below) remains the most authoritative book on influence, however Berger has written the easiest read. Start here and then go deep with Cialdini.

Influence, New and Expanded: The Psychology of Persuasion by Robert Cialdini - As a ScrumMaster and agilist, you need to use influence on a daily basis. You want the team to consider an experiment or an idea? You use influence. You want management to resolve an organizational impediment? That will require more influence. Cialdini shows you how influence works, and outside of work he shows you how companies like Amazon influence you every day.

Never Split the Difference: Negotiating As If Your Life Depended On It by Chris Voss and Tahl Raz - As ScrumMasters you have no formal power and authority. Along with influence, you will spend a great deal of time negotiating. Negotiation, contrary to popular belief, isn’t about agreeing on facts and finding a win-win. Real negotiation involves understanding the other party’s emotional needs. Until their needs are met, you can’t reach an agreement.

Where the Action Is: The Meetings That Make or Break Your Organization by J. Elise Keith - Shows that there are 16 different kinds of meetings and they all need to be handled differently.

Remember

Think I missed an important book? If you’re part of our community, post your suggestion HERE.

Red-Yellow-Green Status Reports and Other Models - How They Should and Shouldn’t Be Used

Tue, 02 Feb 2021 00:00:00 GMT

Traffic lights image by www.openclipart.org

But what if that simplicity misrepresents reality?

If models are used, you’d better understand what they are, and their shortcomings.

Models

To create a simplified model for quick and easy digestion, you reduce the layers of details down to an abstract representation. This can be helpful because it’s easier to see patterns in a simple model, but it’s important that everyone remains mindful of how many steps away they are from the detailed reality. Let’s examine these successively abstract models:

A little bit abstract: A team’s Task Board, Scrum Wall, or the overall Portfolio Kanban Wall

These are all first-order models of reality. While not perfect mirrors of the current state of the work, they’re fairly close. They help visually demonstrate qualitative information (e.g., which stories are complete, not just how many). Small errors creep in if people forget to move items for a day, and other times what is happening in the team is more complex than the board can represent. But, overall, it’s a pretty good representation.

More abstract: A Release Burndown Chart, Burnup Chart, or Cumulative Flow Diagram

These are all second-order models of reality. They summarize the information contained on the Scrum Walls/Task Boards mentioned above. They’re useful because they help spot trends, but they still have less information than the Portfolio Kanban Wall and they suffer two major weaknesses:

They focus on output (# of Stories or story points achieved) and not outcomes (the right features delivered to the customer.)
They display a precise line called velocity, which represents the average time it takes for work to be done and delivered. But teams don’t typically maintain a steady rate. “Average” means half the time we will do better and half the time we will do worse. Charts that display a velocity line appear to promise certainty about time to delivery, when of course there isn’t any and creates a false sense of security.

With these two shortcomings in mind, these commonly-used charts have value when used for forecasting and diagnosis, but are only marginally better at representing reality than Red-Yellow-Green reports are.

Much more abstract: Red-Yellow-Green status reports (also known as Red/Amber/Green, RYG, or RAG reports)

These are models of the other charts, in that they summarize the already summarized information, hiding almost all details. Green means we’re on track both with time and budget. But missing is important context. A project might be “green” if it’s within 5% of budget. That tells you nothing about the quality of the work. Yellow means there are scope or time problems but, with sufficient re-planning, we can come back to target. Yellow is usually measured by some number crossing a predetermined threshold. Red indicates serious issues but doesn’t give details, what is the issues are, or how they happened.

RYG reports have many shortcomings, but the biggest is that they assume that a plan’s scope, budget, and time are fixed and unchanging. This approach might be adequate in a world where these are true, but in the Agile world where change is accepted as the norm, colour-coded, highly abstract reports are dangerous.

At best, RYG reports measure whether a team is on track to make a target (completely ignoring whether the work is truly “done”). But that reporting target is meaningless since the original target rapidly becomes stale in an Agile world. In addition, since RYG reports usually have “green” as a default state, often there are too few questions asked about possible issues until it’s too late. I do not recommend using RYG reports at all.

What Should We Use Models For?

Just because I’m saying to lose the RYG Reports, doesn’t mean I’m against using models for anything. They can be helpful when used properly and conscientiously, for practices such as forecasting and diagnosis.

Forecasting

For Sprint Planning, you want to have some idea of the work you typically can get done in a set period of time. You can use models like Burndown/Burnup Charts/Cumulative Flow Diagrams to get this information from the past and make a reasonable, educated guess about the future. Here’s the important thing though, that many fail to do: move your focus from output to outcome. When you focus on the volume of work delivered – whether it’s Story Points or just a raw count of items – the game will always be about how many more items you can deliver. This can create a sense of pressure, either from management or self-inflicted by the developers themselves to increase their velocity. Of course we want the team to become more productive, but that should come from a focus on quality, not pressure about quantity. Change focus and, instead of forecasting a velocity, use the information to predict which Product Backlog Items will be completed by a certain date. This will start to move the focus from output (volume) to outcome (which items will be delivered).

Also, consider ranges. Since we’ve already acknowledged the imprecision of the averaging, we need a way of illustrating the best, worst, and average case scenarios. We do that by charting the following:

Best three sprints in the past year – this is the highest you’re likely to achieve
Most recent three sprints – a look at how things have been going recently, you’re 50% likely to achieve this averaged number
Worst three sprints in the past year – the least you’re likely to achieve

Example of a burnup chart, including lines for stories completed and confidence lines

Even this model has a weakness: it assumes your velocity will follow normal distributions. The reality is that you likely won’t. However, forecasting with error bars (or lines) usually gets the idea across that you’re forecasting a range of possible outcomes.

Diagnosis and Improvement

Chart models, in particular a Cumulative Flow Diagram (CFD), can be used as diagnostic tools. A CFD can tell us where the flow of work is getting bottlenecked. We’ve devoted an entire section of our eBook The Guide to Effective Agile Retrospectives to showing a small glimpse of what these tools can do.

Genchi Genbutsu or Go See

Finally, all reports discourage people from leaving their offices and leave us with a false feeling of safety and the sense that we know what is actually happening. Toyota has the practice of Genchi Genbutsu – go and see, literally. Review the model charts, but then leave your office and go to the place of the work. Watch, listen, ask, and review the Portfolio Kanban wall with the team(s). This will bring you back into contact with the reality of which features have been truly done. This will also help you see if all the Story Points in the charts delivered the value that they claimed.

Stop/Do

Stop using RYG reports. They’re too abstract and hide too much information. Do use Burndowns/Burnups/Cumulative Flow Diagrams as a tool to help you spot trends and diagnose issues, but don’t rely on them alone as sources of truth. And most importantly, review the Portfolio Kanban Wall with the Team(s) on a regular basis, as this is your best model of reality.

Reinventing Existing Products – Big Bite vs Small Nibble Rewrites

Tue, 22 Nov 2016 00:00:00 GMT

Big Bite Small Nibble - images licensed from Unsplash: Alec Weir, Bonnie Kittle

Twice now in my career I’ve done a massive rewrite to replace an existing product. In both cases, it didn’t end well. Each time, the new product was competing with an existing product that was making the company money. So, of course, the existing product got enhancements on a rickety structure, and on the new product we never caught up. In one case we solved the problem by getting bought out, in the other, the two products lived side by side for far too long.

It’s tempting to say that we’ll just start fresh, write it greenfield (i.e. from scratch). It’s an attractive idea, because we start off with clean code (no legacy) and we’re not hamstrung by decisions of the past.

The problem is that rewrites never happen as rapidly as promised, and never do they deliver everything that is expected. If it must be a massive overhaul and reinvention of an existing product, why not consider doing piece-meal, in-place replacements instead of a total, big-bang rewrite. There are some considerable benefits to this approach:

Existing Product can gain new features and continue to serve client needs while you’re developing new.
Is more resilient against delays in time to market, which is always longer than you expect.
Allows for the organizational pressures that created the original product to change. If they don’t, then the rewritten product will suffer the same problems as the original.

Use a strangler approach. Replace one small part of the system, adding new features, writing tests, etc. as you go. Do that one small chunk at a time, until the new system replaces the old. Bonus points awarded for going from monolithic to a number of mid-sized services (you’ll note I didn’t say the overused MicroServices word).

Hmm, I think I just summarized Feather’s book](https://www.amazon.ca/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/&tag=notesfromatoo-20) in one paragraph. Another good legacy code book: “The Mikado Method”. Finally, if you need more Legacy Code reading, checkout out our [Legacy Code and Systems.

Image attribution: Unsplash: Alec Weir, Bonnie Kittle

Reviewing the Review Process for Agile 2009

Wed, 25 Mar 2009 00:00:00 GMT

Sorry, I’ve been more than a bit busy lately. Working as an independent coach is very rewarding and time consuming. For the past couple of weeks, I’ve been reviewing sessions for the Manifesting Agility Stage at Agile2009: “This Stage is all about tools and techniques for rapidly developing a deep understanding of the empirical Agile mindset, and then rapidly applying it—as individuals, and as groups.” As you can imagine, even with only 87 proposals, this takes a lot of time. Our stage has 1,440 minutes allotted and 3,750 minutes of proposals.

It’s been hard work. In theory, we should first give every proposal a proper review, even if it’s only a few sentences. While I tried that and was able to provide comments (visible to the public) or reviews (visible only to the author and other reviewers), commented on or reviewed 50+ sessions (across all the stages). Sorry, too, that everyone whose session didn’t get a review. There are only three of us who actually do the work on this stage, and we just can’t provide notes to all of you. Consider these notes your comments.

My number one discovery is that many proposal authors aren’t providing enough detail. As a reviewer, I need to decide why I should give you a chunk of our tiny stage. I need to see what the subject is and how you will present it. You need to sell. I need to understand how you will present. Will it be a straight talk? Will there be an interactive session? What will the interactive session be, etc.? The longer your proposed session takes, the more you need to sell. For a 45-minute experience report, you can say less, but if you expect 90 minutes or even 180, you had better be clear, and I need to see what value people will get. If it’s just a straight talk and it’s 90 minutes long, you need to tell me why audience should sit and listen for the whole time. People I have seen present before will have an easier time here. I know that Mary Poppendieck can be very captivating, even when she’s just reading slides. The rest of us are not. I know that Jean Tabaka always has engaging and interesting sessions.

If you asked for 180 minutes, we had 17 proposals of that length, but each will consume 1/8th of our stage budget. For something this long, it had better be amazing especially, since attendees will have to contend with some of their workshop partners leaving halfway through. We had 4 or 5 that would be amazing, but for time constraints, we can only pick one.

Experience Reports: “captures the story of a real Agile project, summarizing what happened on the project and the key learning points”—these are generally 45 minutes long, so when you propose a 90-minute experience, we want to know why the audience will sit that long to hear your story. This really becomes a case when less is more.

Also remember that what you write in your proposal has to sell not only the reviewers but also the attendees. This is why they have to decide whether your session will be exciting or just a snooze.

Mechanics

On to the mechanics and my discoveries. First, I liked last year’s approach, with the whole community being able to vote on sessions and using the wisdom of crowds to find the best. However, I gather there were problems. In some cases, authors had their friends vote up their sessions, thereby gaming the system. In addition, a system like that means that the more well known a person is the better their sessions will do. So Jeff S. and Mary P. will get their sessions voted up almost no matter what they write, whereas completed unknowns had a much tougher time. This year’s system while harder work for the reviewers—at least levels the playing field a bit. Hopefully, we will find a more elegant approach in future years.

On the whole, the submission system with reviews and comments has worked fairly well, but here’s what I wish were different:

Authors need to know that proposals are being reviewed/commented and that replies/updates are a critical part of the acceptance process.
Authors need to be notified when a comment/review is added.
People who write comments/reviews need to know when replies are made.
RSS is not the only notification system; some of us still prefer email.
The difference between comments and reviews needs to be clearer.
The “Browse session proposals” page needs to display the length of the sessions. It makes it easier to make decisions if we know their length.
The proposal database should be exportable to a spreadsheet. A web page is handy, but once the hard work begins, it would be a lot easier if I could just work in Excel or even Google Docs.
I don’t want recommendations visible to the proposal author. These are often friends and colleagues who I want to work with again. This may be true today, but I can’t tell.

…

I realize a lot of work has gone into making the submission system usable, and my suggestions just create more work, but knowing what matters next year would help the authors and the reviewers by reducing the burden. I also understand that many great sessions won’t be accepted because not enough detail was provided.

Image via: Agile 2009 Conference

Scrum by Example – Same Old Song in Sprint Retrospective

Tue, 26 Oct 2021 00:00:00 GMT

The World’s Smallest Online Bookstore team has just come out of their Sprint Review.

Dramatis Personae

Steve: A ScrumMaster and the hero of our story

Paula: The Product Owner of Steve’s team

Don: Director of Development

Tonia: Quality Assurance specialist

Jasmine: Front end JavaScript/GUI developer

Brad: Business Analyst

Kirby: new guy with 20 years experience, knows both business logic and JavaScript/GUI

Martin: Database Developer

Doug: Front End Developer

Ian: Business Logic programming specialist

For those who are keeping score, the team committed to a Sprint Goal of “Have basic reader review system in place so book buyers can see a variety of opinions about a book”. Their plan included completing seven Product Backlog Items and fixing two bugs as part of that Goal. By Sprint Review time they’d completed five of the seven. They walked into the Sprint Review with heads held high and, with the pummelling they took over not mitigating for fraud reviews, they left with their heads down. ScrumMaster Steve suggests they all go to lunch and reconvene for the Sprint Retrospective in an hour and a half.

Steve knows they need a great Retrospective to turn this experience around. He has heard from others that you should mix up your retrospective style every few Sprints to avoid boredom and complacency. However, this time around he just wants to stick with a retrospective that he knows well. His agenda:

Welcome
Read the retrospective minutes from the last retrospective
What went well?
What didn’t go well?
What can we improve next time?

Before the Retrospective starts, Don – the Director of Development and Steve’s boss – asks to join the Retrospective. Don explains that it was a bit of a bad Sprint and the team need to understand just how important it is to turn things around.

Steve has to think fast. He knows that if Don shows up at the Retrospective, even if he stays silent, his presence will cause the team to stop talking openly. Steve decides to take a chance. “Don, the team really appreciate the support you give them,” Steve begins, “but I’m concerned that if you attend the Retrospective, the team will say a great deal less. The less they say, the longer our problems will continue. So if you want us to improve more rapidly, please don’t attend the Retrospective.”

After a bit more discussion, Don gives in and says maybe he will address the team later in the week. Whew. Steve just dodged a tough problem.

The team return from lunch and the Retrospective starts. Steve welcomes the group and makes a few lame jokes to lighten the mood after the Sprint Review. He starts off by reading the minutes from the last Sprint Retrospective. He then asks the team, “What went well in the last Sprint? I will give people a few minutes to write at least three items on Post-it® notes.”

The team dutifully pull out their pens and start listing what they felt went well. It takes five minutes.

Steve asks the team to group together notes that are similar. Once that is completed, he asks what patterns they see. Tonia says, “There are a lot of notes highlighting how well we handled Quality this time round.”

“Several of us felt that we did a good job Limiting Work in Progress,” Brad remarks.

Jasmine noticed, “Looks like team members were happier with the code itself this Sprint. Most of the new code was easily readable.”

Doug and Ian are silent.

Steve asks the team to repeat the process to answer: What didn’t go well? This time, the five minutes results in over forty sticky notes. Like the first round, they group them and Steve asks his killer question, “Looking over our notes, what is the biggest area for improvement in the next Sprint?”

Two members of the scrum team argue during the sprint retrospective while the rest of the team gets anxious or tune out

At this point Kirby and Martin start talking animatedly. Kirby is really interested in tidying some of their technical debt. He thinks simplifying the worst of their code will make it easier to add the new features that Paula is asking for. Martin, who keeps talking over top of Kirby, says the database is a bit of a mess and he wants help from his teammates. Jasmine and Brad struggle to get a word in, but they do at least try.

Doug and Ian are silent.

In the final portion of the Retrospective - What can we improve next time? - Ian speaks up for the first time and complains that the responses given on the sticky notes are almost exactly the same problems the team faced last time, and the time before that as well. He quips, “Nothing ever gets better around here.” You can feel the overall morale in the room shrivel, as many silently agree.

Steve digs around in his notes and finds a few things that the team has improved in the past few months, and offers them as reminders that help keep things in perspective.

Once they refocus, the team agree to tackle two problems from the last Sprint:

Features rejected by stakeholders in the Sprint Review
Unit Tests that were few and far between during the Sprint

They turn these problems into two improvements:

Paula will consult more with the Stakeholders prior to Sprint Planning.
The Team will write more Unit Tests.

Steve adjourns the Retrospective, confident that these improvements will help avoid another bad Sprint.

Analysis

Credit where credit is due. For a ScrumMaster early in his journey, Steve is well-prepared. He has a plan for the Retrospective. He knows that if their manager is present, psychological safety will go out the window. He uses a silent listing activity (the Post-it® notes) to ensure that the quieter team members have voice. Hint: quieter people have just as much to contribute as the rest of the team. Their quietness is usually a sign that they don’t yet feel safe speaking up in front of the group and taking risks (this is at the core of psychological safety).

Challenges:

Like many first-time ScrumMasters, Steve is using the same agenda for his Retrospective each and every time: Went Well? Went Poorly? Improve Next Time? This leads to a couple of problems: 1) asking the same questions over and over means that we tend to get the same answers, 2) worse, using the same format constantly puts people to sleep. Before they even enter the room, they know what questions will be asked.
Even worse, each activity has the same basic format: list ideas on Post-It® Notes and then have group discussion. I bet 3M is the only one enjoying this repetitive format.
Steve took minutes from the last retro and read them out at the start, which is something he saw recommended by many sources on running effective meetings. In the right meeting context, this can save time rehashing past decisions and help a group see that they’re moving forward. But in a Retrospective specifically, this will violate the team’s sense of safety. They will wonder what will get recorded and, as result, they’ll speak less and keep their comments are mostly positive.
Improvements like “consult more with Stakeholders” and “write more Unit Tests” aren’t action items, they’re vague goals. What is “more”? When should “consult” happen? What is the outcome we expect of these actions?
When you’re talking with your friends over coffee, a discussion that wanders all over the map is fun. In a Retrospective it can become frustrating and lead to team members feeling like the whole event is a waste of time.
The team don’t have real data from which to work. Lacking data, all the challenges observed, and the improvements claimed, are nothing more than opinion and conjecture.
The rounds of open discussion are off-putting for quieter team members, especially in a team new to Scrum. These team members haven’t yet found their place of safety. Steve did a good job using a silent listing activity to start garnering ideas, however, that benefit was lost in the open discussion that followed when two team members who are quite vocal dominated the discussion.

What could they do differently next time?

Add variety with the agenda and activities. Steve really needs to start mixing up his approach to Sprint Retrospectives. Ideally he would never use the same agenda twice. He would be better off if he could facilitate five to six different Retrospectives, and never used the same approach twice in a row. Our free eBook The Guide to Effective Agile Retrospectives has a good start, and the Retromat has more (>100 activities). Doing this will avoid Retrospective boredom. Done well, Steve will also select activities that promote more focused discussion, saving the pain of wandering all over the map.

Note action items, not conversations. Instead of taking minutes, Steve should really only record the Retrospective action items. A good ScrumMaster would take those items and make them front and centre in the next Sprint Planning. A great ScrumMaster would ensure that the same items are checked for progress in the next Retrospective.

When adding action items in the next Sprint Planning, include Improvements in the Sprint Backlog. Otherwise they’re too easily forgotten during Sprint, and you end up with a “Why bother with retrospectives when nothing ever gets better around here” attitude from team members.

Avoid vagueness. Speaking of action items, we need to turn vague statements into concrete, actionable steps. The simplest way is to call the vague action a goal, and then ask: what is the first step towards that goal? For example:

“Paula will consult more with the Stakeholders prior to Sprint Planning” becomes “Paula will schedule a one-hour StoryMapping exercise with key stakeholders (Director of Support, Eric, and Marketing Director, Jan) before each Product Backlog Refinement session with the team.”
“The Team will write more Unit Tests” becomes “When writing a new Object/Class/Function, Team members will attempt to create at least three new Unit Tests.”

These actions can be raised in Sprint Planning, then tracked during the Sprint and reviewed for progress in the next Retrospective. If you want more tools to turn vague statements into actions, see The Guide to Effective Agile Retrospectives linked above.

Use data. The questions “What went well?” etc. lead to vague discussions that wander all over the map. More structured activities like Mad, Sad, Glad¹ or Sailboat² will help focus discussion but are still just opinions. Even better, have data that was tracked during the Sprint that can be shared in the Retrospective. Data can move the initial discussion from opinion to fact-based.

The simplest metric to track might be how long each individual story took to complete (fancy name: cycle time). Discussing why some Product Backlog Items took longer than others can lead to the team discovering things such as: some items were sliced small and were completed quickly (a good thing); some had dependency problems with an outside team; some items were poorly understood and took longer to complete. Discussion around why an item took longer might also shine light on an area of codebase that is harder to work in and needs improvement.

From one small set of data, many discoveries can be made. With a few more observations, deeper and more focused conversations can happen. Consider “Team Morale, Defects that Escape a Sprint and the use of Cumulative Flow Diagram”.³

Make it safe for all. Not only are open-ended discussions less productive, they’re also challenging for quieter team members to participate in. Remember, quieter people need to feel safe to share ideas. A good ScrumMaster will want to select activities that gives everyone a voice. For example, “Mad, Sad, Glad” invites the team members to share their thoughts on Post-it® notes. Since everyone gets the same number of Post-its®, they all have equal voice.

Other strategies might include: giving the team members a specific order to speak in for an activity. Where a quiet person needs more help communicating, some teams find them a partner/advocate to help explain the quiet person’s position. The goal in all of these cases should be to improve the psychological safety situation inside the team so that no one is afraid to give voice to ideas.

If your Retrospectives aren’t yet fun and effective

Retrospectives are more engaging when they’re not repetitive, and they result in meaningful improvements. Improvements are more likely when we have data to act on, and everyone has an equal say. The role of ScrumMaster is to create a retrospective where this all comes together. For the fundamentals, see Agile Retrospectives. If you want more depth on Retrospectives, grab a copy of our eBook – The Guide to Effective Agile Retrospectives. We’d also love to have you join us in our Certified ScrumMaster training.

Image attribution: Agile Pain Relief Consulting (Updated March 2025)

Footnotes

Scrum Alone is Not Enough

Mon, 26 Jan 2015 00:00:00 GMT

Beyond Scrum: Scrum Alone Is Not Enough

To be successful with Scrum in the long term you need more than the basic framework. This is intentional. Scrum provides the structure as a starting point, but it’s designed to work well when applied with other effective patterns.

Like the Design Patterns movement of the late ’90s, a pattern can be used by itself or with others. E.g. the Command Pattern and the Memento Pattern can be combined to build an effective undo/redo system. Scrum is only one pattern for one team. It gives you the bare minimum framework that could possibly work, however in many contexts you will need to incorporate other tools/patterns to build more effective systems.

Beyond Scrum you should consider:

Effective Agile Engineering Practices – such as Unit Testing, Continuous Integration, Test Driven Development, Acceptance Test Driven Development (or BDD), Pair Programming. Without practices like these, the health of your codebase will degrade over time.
Portfolio Management – the art of making big picture decisions about which major chunks of work the business would like focused on next. Organizations need portfolio management to ensure that major priorities are understood by the team’s Product Owners and worked on in priority order.
[Kanban](/blog/kanban-portfolio-view “Kanban Portfolio View”/) – (a tool to understand and improve flow) to help understand the flow of work at both the team and organization level. Without a good understanding of flow of work through the organization, we might make a change that is a local improvement but harms the whole.
Organizational Improvement – many issues that Scrum helps to find can’t be solved by the team or their ScrumMaster. Instead, organizations need to establish an ongoing improvement team dedicated to resolving these problems. (Part 1: Taking Organizational Improvement Seriously | Part 2: Case Study)
Intra Team Coordination – How will you coordinate the work among teams? Scrum of Scrums is the most well known pattern and yet is rarely the best choice.
Team Organization – How will you organize your teams? As Component Teams? As Feature Teams? Using the Spotify model of Squads, Tribes and Guilds?

There are no best practices.

Scrum itself could prescribe all of this, but that would be missing an important Agile point: there are no best practices. A practice that works well in one organization (or context) may not work well in yours. This is especially true when it comes to working effectively at a large scale where repeatable patterns are only just starting to emerge. Even where consistent patterns are starting to emerge (i.e. Large Scale Scrum, Enterprise Scrum, …), it is often unclear which one will apply in a specific context.

Finally, remember that Scrum isn’t intended to fit your current organization and its existing structure. It is intended to force us to consider what is working and what needs improvement.

Scrum is just the starting point.

Image by Agile Pain Relief Consulting. Elements of image designed by Freepik.

Scrum Anti-Patterns: Micromanagement

Tue, 24 Sep 2019 00:00:00 GMT

Unfortunately, we also regularly see recurring patterns of ineffective behaviour. These are called Anti-Patterns.

Scrum Anti-Patterns - image by Agile Pain Relief Consulting

The following is an exploration of one of the most common Anti-Patterns: Micromanagement.

Anti-Pattern¹ Name: Micromanagement

Aliases: Over-Controlling; Someone is Looking over My Shoulder

Scale: Team and/or across multiple teams

Related Anti-Patterns: Sprint Burndown Charts, Velocity is Important, Time Tracking, Individual Incentives

Potential Solutions:

Service or Servant Leadership
Sprint as a Black Box
Focus on Outcomes, not Output
Leadership Focuses on Strategy and Creating an Effective Work Environment

Scrum Anti-Patterns: Micromanagement - image by Agile Pain Relief Consulting

Why Micromanagement Happens

People new to Scrum often struggle to understand boundaries of control between being an effective manager, ScrumMaster, or Product Owner. This is a critical consideration because, at the heart of Scrum, we’re attempting to grow a group of people into a resilient, high-performing team. These roles are not only relevant in facilitating this growth but are equally capable of stunting it. A key ingredient is allowing self-organization of the group to flourish.

Whether you’re a ScrumMaster or manager, when you see something potentially going wrong, you want to help. This is understandable: you have the best of intentions. You don’t think you’re micromanaging; just making suggestions, offering help and ideas, and avoiding risk. However, micromanagement can take many forms. Executives might make suggestions or give orders directly to Team members. Stakeholders might dictate User Stories to a Product Owner. Managers might insist on things being done a certain way because they’ve been done that way a hundred times before. The list goes on, but they all share a common feature: someone other than the people doing the work is trying to influence how the work ought to be done.

There are many ways micromanagement can show up in a Scrum environment. Below, I’ve outlined some common ones, by role:

The ScrumMaster as a Micromanager:

Assigns work to Team members instead of encouraging them to self-organize. This is more likely when the ScrumMaster is given the dual role of ScrumMaster and Project Manager.
Runs Daily Scrum instead of facilitating the Team as they conduct the meeting.
Turns Daily Scrum into a status-reporting event as opposed to an activity to prepare for the day’s collaboration.
Injects their own thoughts and ideas into the Retrospective.
Tells Team members how to do their job.
Tells Team members how to solve problems when doing so harms the ability of the Team to find their own solutions.
Tells Team members what the problems are instead of helping them discover them on their own.

The Product Owner as a Micromanager:

Adds new work mid-Sprint and demands that it be done immediately. Management sometimes does this too.
Attends Daily Scrum to get a status update. Daily Scrum is for the Team to help them collaborate and focus for the day. If the Team invites the Product Owner, the Product Owner must remember that and not interfere.
Uses Daily Scrum as an opportunity to interrogate the Team about their work.
Looks over Team members’ shoulders, checking in on every last detail. A good Product Owner helps to grow the Team to be empowered and make most of the small decisions on their own.

Management and other Stakeholders as Micromanagers:

Attends Daily Scrum and injects their own ideas, calling them “suggestions.” Most suggestions from Management are automatically seen as orders.
- Even having management present at Daily Scrum will cause people to turn the event into a status-reporting event. Instead of looking at each other, Team members naturally make eye contact with the manager. At that point, the Daily Scrum becomes about the manager and not the Team.
- Suggestions from managers, especially executives, are often taken as orders because these same people control a Team member’s performance review, salary increase, and long-term employment status. Naturally, Team members will seek to please those who hold power.
Asks the ScrumMaster for frequent updates on progress mid-Sprint.
Uses the Sprint Burndown chart as a tool to investigate the progress of the Team during the Sprint.
Looks at the Burndown/Burnup/Cumulative Flow Diagram as a measure of progress, rather than using these as predictive tools to see which items in the Product Backlog will get done.
Asks for more velocity or demands the Team go faster. Teams often eventually go faster, but only by focusing on improving their skills and quality of their work.
Tells people how to do their work.
Dictates User Stories to the Product Owner.
Treats the ScrumMaster as an errand-runner.

Hint: words like Tell/Assign/Should are good warning signs that micromanagement is happening!

In the end, all of these boil down to the same basic set of problems: a misguided need or desire to help by exerting control, often founded on a belief that the person telling knows how to do something better than the person doing the work,² and the feeling of being out of control themselves.

We all do some of these things on occasion, so don’t berate yourself if you have. It’s normal human behaviour, but it is problematic when it becomes a recurring and defining part of your management style.

Consequences of Micromanagement

In the last few years, several models for understanding human behaviour in modern work environments have appeared. The authors, and the framework they created to reflect their research, are:

Dan Pink – Autonomy, Mastery, and Purpose³
Susan Fowler – Autonomy, Relatedness, and Competence⁴
David Rock – Status Certainty, Autonomy, Relatedness, and Fairness⁵

Notice how autonomy is at the core of all of the research? Each of them report that people need to have freedom and independence to be able to do their best work. I can also say it is no coincidence that Autonomy, along with Engagement and Self-Organization, is also at the heart of Scrum. These aspects are all undermined when micromanagement is allowed to pervade.

To illustrate how individual effects of micromanagement can lead to larger, self-perpetuating negative consequences, we offer a simple Causal Loop Diagram (CLD) for each, and then a more comprehensive master CLD at the end. To try to keep it as simple as possible, we won’t repeat connections in the smaller CLDs, but you will see the overall effects and connections in the master.

Micromanagement leads to:

A) Disengagement of Team members Worldwide, 67% of employees are disengaged.⁶ They show up to work because they’re paid, not because they care about or enjoy their work. Disengaged people will still do their jobs, but generally aren’t putting much energy into product or process improvement, and they’re certainly not willing to experiment and fail. When there are enough of them in one place, they kill off the energy of others with their zombie-like behaviours. In extreme cases, actively disengaged employees can become destructive.⁷ In 2017, 18% of employed people worldwide were actively disengaged. These people aren’t just bored or unhappy, they’re actively resentful and undermine the works of others.

Disengagement is often engendered when a manager (or ScrumMaster or Product Owner for that matter) finds themselves pressured to work faster. Often, they feel the easiest way to increase work speed is to look at the Team’s work and find a way to “help them.” This “help” almost always impinges on the Team’s autonomy and damages Team members’ engagement with the work at hand. As the Team becomes less engaged, the quality and quantity of work drops, illustrated in the Causal Loop Diagram below by the reduction in Customer Happiness. Unsurprisingly, as Customer Happiness is reduced, it leads to more external pressure on management to work faster.

Scrum Anti-Patterns Casual Loop Diagram: Micromanagement - image by Agile Pain Relief Consulting

B) Reduction in Self-Organization Without autonomy and self-organization, the Team’s capacity is reduced and opportunities for them to experiment, fail, and learn from that experience disappears.

Scrum Anti-Patterns Casual Loop Diagram: Micromanagement - image by Agile Pain Relief Consulting

C) Delays in Decision-Making Delays in decisions will begin to occur because the micromanager causes a bottleneck because Team members will often be afraid to make a decision without the micromanager’s support, agreement or, worse, sign off. So instead, they wait, sometimes making things even worse by doing work that merely keeps them busy instead of the most important work of delivering value to the customer.

These delays obviously harm productivity and customer outcomes, which leads to more pressure to adapt and recover from these building losses. However, these same delays mean that micromanaged groups can’t adapt to changing circumstances fast enough, often making the whole situation worse. This is another negatively reinforcing feedback loop.

The more the manager tries to take control, the more decisions they must make. The more decisions, the longer each decision must wait to be made. As decision time increases, Team members will do lower-priority work while they wait. They don’t want to start something important after all, because if the decision for the original problem arrives, they will have to drop whatever they are doing to attend to the new work. Both delayed decisions and low-priority work mean that less is done to delight the customer.

Scrum Anti-Patterns Casual Loop Diagram: Micromanagement - image by Agile Pain Relief Consulting

D) Limited Communication within the Team As micromanagement increases and the Team increasingly needs the decision-maker before anything can progress, there is less need to talk to your peers, since there is a diminishing number of things to talk about. As a result, Knowledge Silos, prevalent in waterfall-style work, creep in, or possibly never go away in the first place. Additionally, this reduction in communication harms quality by reducing the diversity of thought available for tackling different problems. Siloed micromanagers also harm decision quality directly because they generally don’t seek opinions other than their own.

These problems are often made worse in places where functional managers have a say in who does what kind of work. For example, a functional manager responsible for Quality Assurance (QA) might suggest that only QA people can create and run test cases. This arbitrary and artificial wall prevents other Team members from cross-skilling and learning how to test, which could contribute to better quality work or a faster delivery rate. Functional managers, as a feature of their position, tend to have a vested interest in maintaining personal empires, so they work to ensure that boundaries and barriers stay up. Ultimately, in a healthy Agile work environment, there shouldn’t be a need for functional managers, and they should instead redefine their role to more positively contribute to the growth and autonomy of the teams they oversee.

These Silos subsequently increase the need for heroism since fewer people can only do certain kinds of work. These “heroes” ultimately harm self-organization and often work quality, coming under increasing pressure to work faster while being unable to seek help from their own Team. (We’ve not displayed quality on the diagram above because it was already getting too busy – instead, poor quality is just a subset of what makes customers unhappy).

Finally, reduced communication also harms the ability to experiment, innovate and learn from failure, hampering any hope of improving.

Scrum Anti-Patterns Casual Loop Diagram: Micromanagement - image by Agile Pain Relief Consulting

Micromanaging anti-pattern CLD (Causal Loop Diagram)

Scrum Anti-Patterns Casual Loop Diagram: Micromanagement - image by Agile Pain Relief Consulting

If the above looks bloody complicated, that’s… well, because it is. Human beings are complicated, and trying to herd large groups of us into doing complex work is especially challenging. Trying to do all that with micromanagers is mind-bogglingly convoluted.

Typical Causes of Micromanagement

Matrixed organizations or Functional Managers – which tends to be exhibited by maintaining separate functional teams apart from the Scrum Team
Individual rewards that promote heroism, increase the size of knowledge silos, and harm self-organization of teams
A belief that one person knows better than another, which is closely related to…
A belief that you can better control outcomes by controlling people. This is a delayed negatively reinforcing feedback loop because in every case, these behaviours harm the quality of work and therefore, harm the customer happiness. This is hard to see on a day-to-day basis because the negative effects on the customer are usually delayed. After all, the customer only notices they’re getting poorer-quality work sometime after it has been delivered.
When one person feels micromanaged they will often react by applying that same degree of control to others. Unfortunately, this also is a negatively reinforcing feedback loop.

Solutions for Micromanagement

Insulate the team from some of the above-mentioned dynamics:
- Make the Sprint a Black Box – Explain to stakeholders that once the Sprint has started, the Team needs space to succeed
- Don’t track or display the Sprint Burndown chart – Too often the Sprint Burndown is used by those outside the Team to ask the question “Why aren’t you going faster?”
- If the official electronic tool is used to spy on the Team in Sprint, then the Team might consider using something outside of that tool for the Sprint Backlog. (e.g. Index cards).
- If the Product Owner is micromanaging during Daily Scrum, the ScrumMaster should suggest that they not attend until the relationship is improved.
- Suspend individual rewards for members of your Scrum Teams. (This is a short avoidance, not a fix. Ultimately, individual rewards should end.)
Instead of giving managers one number for team velocity, always use ranges with probabilities. I usually recommend giving three numbers: 20, 50 and 80% confidence intervals.
Never allow the Release Burndown and other charts to be viewed without also providing the context of the Product Backlog – move the conversation away from how much faster can you go, to which items can be done by the end of the Sprint.
Renegotiate the relationship between managers and Development Team members.
Reinforce Working Agreements between Development Team, ScrumMaster and Product Owner so that all have a good understanding of their boundaries.
Educate managers that a “request” from management will be seen as a requirement by many Development Team members.
Educate managers that attending Daily Scrum on a regular basis sends the Development Team a signal that they need adult supervision. Management are best involved at the Sprint Review.
Work on Cross-Skilling to breakdown silos within a Team and the organization at large.
Eliminate individual rewards. Even better, replace the annual performance⁸ reviews entirely and move to a continuous feedback model.
Have organizational leaders focus on outcomes, not the details of the work or how the Team does the work.
The further up the organizational ladder a leader is, the further into the future they should be encouraged to be looking for long-term strategy.
Seek to understand the sources of pressure that are being placed on various managers and stakeholders, so that their Scrum Teams, Agile Coaches – one tool to help model this is Systems Thinking. Once we understand the pressure, then we can seek to change the circumstances to reduce/eliminate the pressure.

An Agile Army Managers and executives talk about their organization as if it were a trained military command. Ironically, modern militaries learned over 200 years ago that non-routine work, such as that on a battlefield, is too complex and changes too rapidly for micromanagement to be effective. Instead, they practice a version of Von Moltke’s brief - describe the circumstances the leader currently knows; outline the goal; ask the subordinate for a back brief,⁹ where the subordinate explains their more detailed understanding of local conditions and a plan to achieve the stated goal.

Learn how to better support your team

We hope this provided you with some useful points and insights that can help you protect your team from micromanagement, or how to be a more effective manager yourself. If you’re still feeling a bit overwhelmed by this issue and want help, we invite you to attend one of our Advanced Certified ScrumMaster (A-CSM) workshops.

In this workshop, designed for experienced ScrumMasters, we go in-depth on how to deal with challenging problems such as micromanagement, overcoming entrenched biases in your organization, and how to introduce real improvements to the way that you and your team work. We look forward to meeting you!

Image attribution: Agile Pain Relief Consulting (updated March 2025)

Footnotes

“An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.” ~ Wikipedia https://en.wikipedia.org/wiki/Anti-pattern ↩
My personal kryptonite: I often assume, without thinking, that I know more than the person doing something, and that if I speak up it will save them time, pain, loss, etc. ↩
Drive: The surprising truth about what motivates us https://www.youtube.com/watch?v=u6XAPnuFjJc ↩
Why Motivating People Doesn’t Work … and What Does: The New Science of Leading, Energizing, and Engaging https://www.amazon.com/Motivating-People-Doesnt-Work-What/dp/1626569452/&tag=notesfromatoo-20 ↩
SCARF: /glossary/scarf-model/ ↩
State of the Global Workplace 2078 – Gallup https://www.gallup.com/workplace/257552/state-global-workplace-2017.aspx ↩
Ibid ↩
Abolishing Performance Appraisals: Why They Backfire and What to Do Instead - Tom Coens, Mary Jenkins https://www.amazon.ca/Abolishing-Performance-Appraisals-Backfire-Instead/dp/1576752003/&tag=notesfromatoo-20 ↩
“The process of giving instructions often leaves a significant amount of room for misinterpretation…” https://www.velaction.com/briefback/ ↩

Scrum Anti-Patterns: Unplanned Work Disrupting the Sprint

Tue, 20 Nov 2018 00:00:00 GMT

Unplanned work disrupting the Sprint is one of the most common Scrum anti-patterns. The Team is in the middle of a Sprint, but the Product Owner has discovered unplanned work and interrupts their flow mid-Sprint to deal with it because it\u2019s now \u201chigh-priority.\u201d How should a ScrumMaster deal with this or similar Scrum anti-patterns?

An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. ~ Definition from Wikipedia

Dramatis Personae

Steve: A ScrumMaster and the hero of our story

Paula: The Product Owner of Steve’s team

The Story So Far…

ScrumMaster Steve, Product Owner Paula, and the rest of the Scrum team have started another Sprint for building the World’s Smallest Online Bookstore. Having learned the consequences of over-committing, this time they have committed to fewer User Stories and are about halfway through the Sprint. They have committed to eight User Stories with sizes ranging from 2 – 8 points:

As a Canadian book buyer, I want the World’s Smallest Online Bookstore to ship my book to Canada so I can get my book home – Story Points: 8
…to calculate the import duty on my books – Story Points: 3
…to calculate the local sales tax – Story Points: 2

Every couple of days, they get a User Story accepted. Things are going just as planned.

Scrum Anti-Patterns & Unplanned Work Disrupting the Sprint

A Scrum Anti-Pattern of the Product Owner and ScrumMaster

Five days into the Sprint, Paula interrupts the team and asks that they add in a new User Story and it needs to be completed during that Sprint. The Story is one that the team had previously sized as 5 Story Points: “As an American book buyer, I would like to use premium shipping so I can get my books sooner.”¹ However, this “Premium U.S. Shipping” User Story is one that both the Team and Paula had previously agreed was not an urgent priority. Paula says it’s really important now because she’s under a lot of pressure from the product investors to get books to American customers sooner. Steve explains to her that the team has made a commitment for the Sprint and it can’t be changed without cancelling the Sprint. Paula continues to press, saying it is a top priority.

A Failure to Respect Scrum Roles

This is an example of a Scrum Anti-Pattern that significantly harms the ability of the team to manage the scope of their Sprints. This scenario isn’t uncommon, especially for teams and organizations new to Scrum – almost every Scrum team will find themselves in this difficult situation, or one similar, at least once.

In this case, the Product Owner has fallen into a micro-managing mindset, imposing their will on the team by assigning work without consulting them or respecting their capacity to self-organize.

The ScrumMaster is also partly responsible for situations like this: it is their responsibility to prevent other stakeholders, including the Product Owner, from disrupting the team’s workflow. Remember, a Scrum Team self-organizes without the intervention of managers or the Product Owner and the ScrumMaster role defends their ability to do so.

What to Do When the Product Owner Adds Work Mid-Sprint

When a Product Owner pushes unplanned work into an active Sprint, the team has three options:

Refuse the Product Owner’s request – For Scrum to be practiced effectively, the team’s time boxes and Sprint Backlog, as well as their capacity to self-organize their own work, must be respected.
Switch User Stories – If the team determines that this is a manageable or one-off request, they could choose to trade out a larger User Story for the one that the Product Owner wants to insert, allowing flexibility while ensuring they have enough capacity to complete everything in the Spring Backlog. This also acknowledges that even though the team hasn’t “started” the User Story that would be removed, effort has already gone into its analysis and design. In addition, it forces Paula to recognize that her request has consequences. It is important to send a strong signal that this is not a good idea and will harm the team if used repeatedly.
Cancel the Sprint – In light of this change in needs, the team and Product Owner can agree to end the Sprint prematurely. As a general rule, this should be the option of last resort because they have come to recognize a radical change in direction is required, or a change in requirements would result in the planned work of the Sprint to be wasted. (In this scenario, Paula’s request does not justify this).

It is the ScrumMaster’s responsibility to prevent interruptions to the team’s workflow.

Handling a Scrum Anti-Pattern the WRONG Way

Steve knows all of the above choices: He could hold a team meeting, invite Paula to explain her request and discuss the “Premium U.S. Shipping” User Story she wants to add. Steve could explain the trade-offs, offering the team the different options, then let them decide the best course of action, perhaps using decision-making tools like Fist of Five Voting or something similar to select the best choice.

However, Steve doesn’t do any of those things. Cracking under the pressure from the Product Owner, the team adds the additional User Story for premium U.S. shipping into the Sprint without trading any other Stories out.

Because they had not adequately planned out the new User Story and had lost momentum from the disruption in the previous Sprint, they not only fail to deliver the premium U.S. shipping, they also fail to deliver on another User Story they had planned for the Sprint. Both are left half-finished and the team suffers a loss of morale, discouraged by the setback. Paula is now extremely stressed and frustrated due to not being able to show results to the investors.

How to Overcome this Anti-Pattern

The above example is one I’ve seen countless times with clients I’ve worked with. It can be a difficult position to be in, where a ScrumMaster’s task is to preserve the autonomy of the team while also trying to accommodate the needs and wants of the customer and Product Owner. That said, situations like this should only be occurring extremely rarely – if they become an even semi-regular occurrence, it is critical you work to discover the root cause and why the Product Owner’s needs are changing so frequently. There are various ways of handling this:

Shorten Sprints – If the Sprint Cycle is two weeks or shorter, we sidestep the problem.
Stakeholders at Sprint Reviews – If the stakeholders (including the client/customer/end-user) are at the Sprint Review, then they will provide feedback earlier.
Product Owner works with stakeholders – if the stakeholders participate in the Backlog Prioritization then they will know what is coming and why.
Clear Product Vision – Does the Product Owner have a clear and well understood vision? Does the proposed change support that vision? If not, it is much easier to say “no” or “not now.”
The Art of Saying No – A Product Owner who has learned to say “no” or “not now” is the team’s best defence against mid-Sprint disruptions. Without that skill, every stakeholder request becomes an emergency.
Strategy and Roadmap – Tools like Story Mapping and Impact Mapping give the Product Owner a framework to evaluate incoming requests against. When a stakeholder pushes for a mid-Sprint change, the Product Owner can check the request against these tools and use them to say either “Not now” or “No.”
Portfolio Management – Engage stakeholders at the bigger picture level so that their requests meet big-picture needs and are not purely tactical. When stakeholders see how their request fits (or doesn’t) within the broader portfolio, they are less likely to pressure the team for mid-Sprint changes.

However it gets resolved, the problem must be addressed and then reflected on if the team is to perform effectively.

Unplanned work is just one form of interruption. For a full taxonomy of what disrupts teams and how to address each type, see Unpacking Interruptions: Why Your Team Struggles to Get Things Done. The More Interruptions episode covers strategies like core hours that help protect the team’s focus time.

Do you want to coach your team towards better solutions?

How to Learn More

If you or your organization are new to Scrum and want to make implementation an empowering process and avoid Scrum Anti-Patterns like the one above, Mark coaches people how to do this in our Certified ScrumMaster courses, where you can learn how to be effective in the ScrumMaster role, supporting and growing autonomous and high-performing teams. If the above is at all a familiar experience to you, we would be delighted to help you grow your team to be the best it can be.

Image attribution: Agile Pain Relief Consulting (updated March 2025)

Updated: February 17, 2026

Footnotes

In reality, this example User Story isn’t critical and doesn’t justify interrupting the Team. I can’t imagine anything that would be so pressing that the Product Owner couldn’t wait until the next Sprint. ↩

Scrum by Example – The Story of an Incomplete Sprint

Tue, 23 Apr 2019 00:00:00 GMT

A Scrum Sprint is incomplete when the Team can’t deliver the working features they committed to. We cover the reasons for this and how you can help your Team.

Dramatis Personae

Steve: A ScrumMaster and the hero of our story

Paula: The Product Owner of Steve’s team

Tonia: Quality Assurance specialist

Brad: Business Analyst

Ian: Business Logic programming specialist

Last time we met Steve, he had discovered that the Product Backlog had not been discussed and estimated by the Product Owner and the Team. At Steve’s suggestion, the Team delayed the Sprint to have a Product Backlog Refinement meeting.

The result was that all User Stories at the top of the Product Backlog were properly discussed with the Product Owner, Stories that were too large were split into smaller ones, and all the Stories now have estimates. They have now completed Sprint Planning and started their Sprint on developing features for the World’s Smallest Online Bookstore.

The Sprint starts out looking okay…

Coming out of the Sprint planning meeting, the Team has committed to five Stories. Their overall Sprint Goal is to get the customer’s book home:

As a book buyer, I want to add my book(s) to my shopping cart so that I can purchase it – Story Points: 13
As a book buyer, I want to tell Amazon where I want my book(s) shipped so that I can receive it from a convenient location – Story Points: 8
As a book buyer, I want to see the price for my book(s) with shipping and tax so I can see whether I’m okay with the price – Story Points: 3
As a book buyer, I want to choose my payment type (MasterCard, Visa, Amex, or Paypal) so that I can pay for my book(s) – Story Points: 3
As a book buyer, I want to pay for my book(s) quickly so I can get my purchase home – Story Points: 13
As a book buyer, I want a confirmation message so I can see that the purchase was successful – Story Points: 2

The Team starts work on the first four Stories right away. Tonia (Quality Assurance specialist), spends the first few days working with Brad (Business Analyst). They clarify the acceptance criteria and she designs her test cases or test plan. When the acceptance criteria are unclear, they circle back with Paula (Product Owner) to get the best answers.

… but then it became clear these were big problems they were tackling.

Scrum by Example – The Story of an Incomplete Sprint

By Monday, the fifth day of the Sprint, Tonia had completed all of this work and was hungry for an application to test. In fact, she was wondering why she hadn’t seen anything yet. Lacking an application to test she found other things to do outside the team.¹ It wasn’t until Wednesday (Day 7) that she finally had the first story (add my book to my shopping cart) to test. Because it was such a big story and technically complex, it took much of the day just to get everything set up to run the test. By the end of the day though, she had found a dozen issues and shared them with Ian, the Team’s Business Logic programmer.

Scrum by Example – The Story of an Incomplete Sprint

By the end of the Sprint, the Product Owner, Paula, had accepted only two User Stories as complete: “see the price for my books with shipping and tax” and “choose my payment type;” a total of five Story Points out of the 42 they had committed to. Everything else was incomplete.

What went wrong with the Sprint?

Most teams will struggle when they start working with a new approach. The heroes of our story created three problems for themselves: Too Much Work in Progress; Overcommitment; and Pipelining

1) Too Much Work in Progress

On the first day of the Sprint, the Team started work on four items at once. This divided the attention of the Team members and slowed work down on all of the items. At first, this result seems counter-intuitive – we expect that by starting more items, we will get them all done sooner. Yet, the experience of Toyota with its Lean Production System,² and repeated in the study “The Impact of Lean and Agile Quantified”, more Work In Progress (WIP) decreases the number of items that a team completes and increases the defect rate.

Since the data we can gather is correlative (e.g. more WIP happens at the same time as the team gets less done), we have to speculate as to the reasons why. More WIP leads to: more Multitasking, Interruptions, reduced Focus time, more handoffs, and limits on collaboration. These combine to harm both throughput and quality.

Does your grocery store limit Work in Progress?

2) Overcommitment

Each Team comes up with its own sense of what a Story Point³ represents, so there won’t be common numbers. When helping people with estimation, I offer a guideline to help calibrate: for a size ‘2,’ or small story, the Team should select something that they believe represents 1/5th to 1/10th of the whole Team’s capacity to do work. I also suggest that the Team select a larger item that might take the whole Team an entire Sprint to complete and call that a ‘13.’ Items that are larger than a ‘5’ typically have enough ambiguity within them that the Team is better off splitting the item before attempting work on it so they have a truer sense of the time that will be needed.

If the heroes of our story had followed this guideline, they would have known that their over-commitment was quite large, and were realistically never going to be able to complete the Sprint.

3) Pipelining

The final problem is a more advanced concept and it is unlikely that a Team in their first few Sprints will be ready to solve this, but it is something they should be aware of as time goes by. This Team is still using a conventional, traditional-style approach to work, where every task is done sequentially by specialist roles. This might work for a problem where the outcome is predetermined and everything can be sequenced, but it often doesn’t work well in software development or any other realm of knowledge work.⁴

In Scrum, Teams are cross-functional to better learn and adapt to constantly changing circumstances.

Scrum by Example – The Story of an Incomplete Sprint

However, Steve’s Team is still learning this. Tonia, Brad, and Ian all have their specializations and, during the Sprint, do little work that falls outside their areas of expertise. This is also known as Scrummerfall, and is common for organizations starting with Scrum to do, as it is usually one of the biggest shifts in the way they do work, and it takes time to make this transition.

The consequence of this is that Tonia is the only one doing QA testing, while the rest of the Team occupies themselves with other things, despite QA clearly needing focus and help. In the long-term, it will mean that the Team has to wait even longer to get feedback on a given User Story, impeding their ability to learn and integrate feedback into future Sprints, ultimately making change costlier for the entire project.

Does your Team struggle with these kinds of challenges?

Like so many Teams that are still learning to practice Scrum, Steve’s team didn’t get everything right in an early Sprint. However, they committed to learning from it and, doing so, took themselves one step closer to becoming a high-performing team. If you are finding these kinds of impediments with your teams or organization, and want to learn how to handle them better, consider attending one of our workshops, where you’ll receive hands-on learning of the challenges – and solutions – and tips on how to help your Team learn and grow to realize their potential.

Image attribution: Agile Pain Relief Consulting (updated April 2025)

Footnotes

Mark’s note: This is not a good thing – having Team members doing work outside of the boundaries of the Team is usually a sign of some kind of dysfunction or larger problem in how Scrum has been implemented, as is the case here. ↩
Lean calls Work In Progress “Excess Inventory” ↩
Caveat – Planning Poker and Story Point estimation aren’t part of Scrum but they’re often useful techniques that are used in conjunction with Scrum. ↩
Knowledge work is where thinking is the largest part of the work: ↩

Scrum Development Team – Who’s In It?

Thu, 22 Jun 2017 00:00:00 GMT

I’m frequently asked if a Tester, Business Analyst, User Experience (UX) person, Database Analyst, or Security Expert is part of the Scrum team?

Short answer: Yes. Long answer: many people misunderstand the Scrum Guide.

Scrum Development Team Membership

The Scrum Guide has a short section called “The Development Team” which says:

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.

It elaborates further on the characteristics of the Team with:

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,

Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole;

Taken in isolation, some misinterpret the third bullet point to say that Scrum teams only include developers and don’t include Testers, Business Analysts, Usability experts, etc. They’re taking too literally the “who”, because the challenge is that the “what” of the Team characteristics contradict that viewpoint. A Scrum Development Team needs “all of the skills as a team necessary to create a product increment” and “Individual Development Team members may have specialized skills and areas of focus.”

white water rafting team photo by Melvin Green via FreeImages.com

Bottom line: the Development Team contains everyone required to get to the definition of “Done” in your business environment. So, I guess if your “Done” is untested code, then… okay, no testers. Otherwise, it includes everyone required to get the work done, for example this might include the following skills: Usability/UX, Business Analysis, Development, Test, Database, Security, etc. Sometimes having the skill doesn’t mean an extra team member - it means someone who has learned enough of another skill to help the team.

Other points to remember: that people can be members of only one Development Team; team membership is full time, and teams are stable (i.e. fixed membership over the long term, other than for normal turnover due to promotions or people leaving the company, etc). Having team members with specialized skills doesn’t mean they work in silos. Growing T-shaped team members helps the whole team deliver without bottlenecks.

The Scrum Guide language around teams isn’t perfect, however it’s a gross – and dangerous – misinterpretation to say that testers aren’t members of the Scrum Development team.

Related article: Choosing the Team Size in Scrum

(Image attribution: Melvin Green via FreeImages.com)

Scrum is Simple and Incomplete

Wed, 22 Jun 2011 00:00:00 GMT

old cannon - image licensed from Photodune

I’ve heard several references recently to the Scrum Canon. I went searching and I’ve not been able to find it. Is it one Ken (et al.) three books? Ken and Jeff’s most recent Scrum Guide? Does it include the ideas that Mike documented in Agile Planning and Estimation? … Is what the majority of CST’s are teaching at this moment in time? In end I don’t think there is a Canon and its absence doesn’t matter. We can all agree on the basics: three roles (PO, Scrum Master and Team Member), Four meetings (Planning, Daily Standup, Demo, Retrospective) and three artefacts (Product Backlog, Sprint Backlog, Burndown Chart). Beyond that is the art of what makes a team truly successful Scrum Practice (in no particular order):

User Stories
Planning Poker
Release Planning
Engineering Practices
Cross Training
….even approaches to Scaling

I teach about all of these in my CSM courses, but none of these is core to Scrum. None is required. Why not? Scrum is incomplete it gives you enough information to get started and says you should improve from there. Its not a straight jacket and it welcomes other ideas/practices. I get concerned when people seek a complete methodology as they discourage diversity, outside thought and even thinking for yourself. So practice Scrum but don’t assume it or any other toolbox has all the answers. Sample from the buffet.

Images via: https://photodune.net/

Scrum by Example - More Interruptions

Thu, 13 Oct 2011 00:00:00 GMT

yellow road warning sign - image licensed from Photodune

Scrum By Example is a series of stories about ScrumMaster Steve who is the ScrumMaster for the WorldsSmallestOnlineBookstore.

Last time we read about our team they were suffering from a very high rate of interruptions after the product had gone live: The Story of Production Support.

After another couple of sprints using the one “person off” strategy the production support problem wasn’t completely fixed but the team was starting to spend less time on support. However Steve started to notice a new problem, even though production support wasn’t the primary cause there were still a lot of interruptions, he still noticed that team members were being interrupted (a mix of drop by, phone calls and email).

Steve spent the next few days just taking notes on the interruptions. Discounting friends dropping by for coffee or smokes and calls on personal phones (presumably family or friends), he could still see that his team members were being bothered 2-3 times a day. Taking the best notes he could without outright spying on people, some of the interruptions were obvious:

a couple of people called Martin every time there was a database problem (big or small)
team members attended meetings (corporate, HR, …) sometimes more than one
Tonia (the world’s best Agile Tester) has become a focus for Agile testing questions with people stopping by her desk 2-3 times a day to ask questions about Agile testing.

To track these issues Steve didn’t need to spy, he just watched the flow of people in and out of the team space, listened for phone calls and read the email trail that filled his inbox.

Once Steve noticed the issue he mentioned into a standup and asked people to start tracking what sort of interruptions they had. In the retrospective the team discussed sources of interruptions (again using a timeline as reminder).

Discoveries:

Corporate meetings that don’t aid directly in the delivery of software
Several team members are the only ones who know their respective areas (Database Architecture, QA), as a result for issues big or small everyone asks them for help.
People outside of the development group don’t appreciate the cost of interrupting the team. In particular they don’t understand the costs of context switching (allow 20-30 minutes to recover if working on a complex task).

Analysis

Caveat Emptor: Remember the Lean Principle: “Optimize the Whole”. In this case ensure that the strategies benefit the whole system and not just one team.

The key issue at play is that your brain can sustain 4-5 hrs of focused “Flow” work in a day. The question at hand is how can we help team members utilise that time?

First the team needs to make the cost of the interruptions visible to the organization. Very often these things happen because people think about their own needs: i.e. Martin knows the database and can answer my question quickly. vs. I can spend 15 minutes trying to figure things out for myself before turning to Martin yet again. This assumes the person with the question isn’t on Martin’s team, perhaps not even in the development organization.

Things the team can do:

Implement Core Hours – example 9:30 – 3:30 (with a break for lunch). During this time the team will focus on development (includes Test/Documentation/…) work. Interruptions from other development teams are expected but people from outside development are asked to wait. This does risk setting up an us vs. them relationship so it has to be handled well. The key is good communications: explain the problem, give specific example of the effects, tell people how core hours will work and seek their feedback after 2-3 sprints.
Email is turned off during core hours. Its best if email is checked ~3 times a day.
Pairing to share knowledge i.e. people from other teams should pair with Martin and Tonia to learn more about the specifics of their work.
Run lunch and learns to share knowledge that’s known by only key people
Reduce committee involvement. For corporate meetings and other events that won’t help the team deliver ask how many people from all of development need to attend.
Move meetings outside core hours. Most meetings don’t require the same amount of mental energy as development. Consider moving them after core hours.
Consider removing company phones from team members desks. This may just shift the problem to people’s cell phones.
Get people to spend at least 15 minutes trying to solve their own problem before asking for help. If nothing else this will deepen a persons knowledge in that area making it less likely they will have to call for help next time.

Perhaps most important make the cost of interruptions visible to the organization. I often use signs at the edge of the team area.

Update: When I say development team I don’t mean coding I mean the people involved to getting the application out the door (Coding, QA, Docs, UX, … - assuming you have separate roles still).

For a comprehensive look at every type of interruption and how to address them, see Unpacking Interruptions: Why Your Team Struggles to Get Things Done. For what happens when the pressure to deliver leads to overtime, see Overtime on a Scrum Team is an Unhealthy Sign.

Image via: https://photodune.net/

Product Backlog Refinement in Action (Scrum by Example)

Tue, 12 Dec 2023 00:00:00 GMT

In Scrum, Product Backlog Refinement is an essential meeting of the Product Owner and the Development Team to gain clarity and a shared understanding of what needs to be done through discussion and sharing of ideas. The following is a guide example of how to run an effective Product Backlog Refinement meeting. We know that many people learn more effectively by example, so the story comes first, using our fictional World’s Smallest Online Bookstore (WSOBS) Scrum team. If you’re in a rush and just need a clear definition and facilitation trick, scroll to the end, or review the general information in the framed areas.

Dramatis Personae

Steve: A scrumMaster and the hero of our story

Paula: The Product Owner of Steve’s team

Remember

Scrum doesn’t require User Stories. However, for relatability purposes of this story, we refer to User Story, but you can substitute Product Backlog Item.

Learning from their recent experience with bad User Stories, ScrumMaster Steve, Product Owner Paula, and the Development Team schedule a Product Backlog Refinement meeting, after lunch,¹ to refine the User Stories and discuss them ahead of Sprint Planning.

A Product Backlog Refinement meeting is where the Product Owner and the Development Team discuss the items at the top of the Product Backlog.

What is Product Backlog Refinement? (Definition)

Product Backlog Refinement is a meeting where the Product Owner and the Development Team discuss the items at the top of the Product Backlog. This used to be known as Product Backlog Grooming, but the term ‘grooming’ (to make neat and orderly) has been dropped and replaced with Refinement. The goal of Refinement is to ensure that the Product Backlog is clear and understood by everyone before the Sprint, not just to make it look good.

In Product Backlog Refinement, the entire Scrum Team –Scrum Master, Developers, and Product Owner– work together to review and update Product Backlog Items (PBIs)/User Stories, so they are well-defined and understood by the Team, and properly prioritized. The Product Owner shares relevant information about the product vision from the stakeholder, and the Development Team works with the Product Owner to gain a deeper understanding of why the product feature is needed and what purpose it will serve.

Backlog items are evaluated on their value to the customer, estimated work required, and any dependencies on other product features, then they’re prioritized to deliver the best value to the client every Sprint. Since Product Backlog Items that were completed a previous Sprint are removed from the Product Backlog, there is room for other PBIs to be moved up in priority, or new ones added, as the product evolves, requirements get added, and/or Product Backlog Items are split into more manageable sizes.

Regular Product Backlog Refinement provides an opportunity for both stakeholders and the Scrum team to communicate any necessary changes and be Agile in response. Communication and collaboration ensures that requirements are clearly understood, and expectations are reasonable and achievable. This gives the Scrum Team the information to begin Sprint Planning and the detail they need to effectively execute their Sprint.

By continuously updating and refining the Product Backlog, the Scrum Team always has a sufficient number or prepared Backlog Items and never has to wonder what needs to be done, or what to do next. This enables them to be truly self-organizing and effective in Scrum.

Isn’t this just Grooming? Backlog Refinement was called Backlog Grooming for a long time. I’ve always associated grooming with removing ticks and fleas from a your pets after they’ve been outside. So why did your Product Backlog gather ticks and flees in the first place? (Backlog Grooming is dead, long live Product Backlog Refinement.)

Getting Ready for Product Backlog Refinement

To prepare for the Product Backlog Refinement event, Product Owner Paula doesn’t use a formal meeting agenda; instead, she has a rough checklist that she shares with the Team:

Story stubs² or ideas that were initially written by herself, to be rewritten into effective User Stories through discussion with the Team
Acceptance Criteria for topmost items in the Product Backlog
Split User Stories that are too large for their current position in the Product Backlog
Estimate³ Split Stories
Acceptance Criteria for newly created Stories
Estimate Stories that don’t yet have estimates
Create New Stories based on newly identified Stakeholder needs

Backlog Refinement Is All About Discussion and Asking Questions

Product Backlog Refinement Meeting Agenda in Action

Paula and the Team review the current list of items in the Product Backlog. They clarify the User Stories by discussing the context for a desired product feature and what kind of value it is meant to give the user. Taking the time to discuss each User Story solves the earlier problem of bad User Stories which lacked a clear ‘Why’ statement. It also gives the whole Scrum Team the needed context and clarity to provide useful estimates. ScrumMaster Steve’s guidance toward having this backlog refinement session, instead of blindly launching into Sprint Planning, has been a huge help.

The topmost items are estimated by the Developers and split into a digestible size (i.e. small or 1, 2, or 3 Story Points). In addition, they have at least two or three Acceptance Criteria associated with them.

In order for a User Story to be useful, it must also be specific and focused. Let’s see where this was a problem during this Product Backlog Refinement session, and how the WSOBS team handled it.

About a third of the way down in the Product Backlog there is a Story: “As a Julia⁴ (a Real Estate Agent and Frequent book buyer), I want to be able to buy a gift card to thank a fantastic recent client.” The estimate on this one is 20, so it’s agreed that they need to split this User Story.

As the Scrum Team discusses the Story, they ask Paula several questions for clarification:

How will the recipient redeem the gift card? Paula says: it’s already covered in a later story, which is also estimated to be 20.
Will the gift card be printable or just electronic? Paula: Electronic for now.
Does the Story include delivering the Gift Card? Paula: Yes, by email.
Are fancy graphics and clever messaging important? Paula: Yes, but in the first version, it would be okay to do without them.
What gift card amounts are supported? Paula: $10, $25, $50 and $100.
Are gift cards refillable, or one-time use? Undecided.

From this discussion, they create some new Stories and estimate them:

As a Julia, I want to be able to buy a $10 gift card so that I can thank a fantastic client. Limitation - not delivered just generated – Estimate: 5 points
As a Julia, I want my newly purchased gift card sent by email to its recipient so that they can use it immediately. – Estimate: 13 points
As a Julia, I want to be able to refill a gift card I previously purchased. – Estimate: 8 points
As a Julia, I want to be able to buy a gift card in denominations of $25, $50, and $100 so that I have choices in how much money I want to spend. – Estimate: 13 points
As a Julia, I want fancy graphics and text on my gift card to satisfy my inner diva. – Estimate: 8 points

On seeing that refillable gift cards will cost 8 Story Points, Paula says, “That’s expensive for the value I get,” and pushes it down in priority. She also sees that the combined cost of the $10 gift card Story and the alternative denominations gift card Story is 18 Story Points – quite large. She asks the Team if it would be cheaper to do gift cards with any amount. They come back with an estimate of 8, pointing out that it’s still more complex than the basic Story.

They create a new Story, sized 8, and move onto establishing some basic acceptance criteria:

Basic “Buy Gift Card” Story

Price Range $5 - 100
Tax not charged to gift card buyer
Receipt displayed
Gift card displayed in buyer’s order history

Basic “Send Gift Card” Story

Get a friend’s email address
Assume valid email and don’t do checking - will be handled later
Send Gift Card via email
Text-only gift card

“Fancy Text and Graphics” Story

Looks good in the browser when the buyer sees it
Looks the same in: Outlook, Gmail, Hotmail, iPad, iPhone, Android phone

All of this discussion leads Paula to realize that being able to use a gift card is as important as buying one. As a result, the Team repeats the whole exercise for the Story to “Use a gift card.”

They wrap up the session by discussing the needs of new publishers who Paula is talking to about selling their products through the bookstore. They outline the rough idea of some Stories to support this need but don’t bother estimating them, as the talks with the publisher are still in their early stages. They can expand and refine them in a future Product Backlog Refinement session if the need arises, rather than spending time unnecessarily speculating now.

Why Hold Product Backlog Refinement?

Every Sprint, the Team finish a number of User Stories, which means the top of the Product Backlog will have some empty space. So we hold refinement to fill those spaces. Either we move older User Stories up the queue, or we create new User Stories.

The leading cause of poor Sprint Planning –and, therefore, crappy Sprints– is the team members not understanding the User Stories they’re working on. So we invite all team members to refinement to create a common understanding about what each User Story is.

When Does Product Backlog Refinement Happen, and How Often Is It Done?

Spread the work throughout the Sprint. No one wants to attend a 2-3 hour meeting in one sitting, so break the event down in two or three sessions of about 45-60 minutes each. I’ve found it effective to schedule a session during the first week of the Sprint and a second one early in the next week. If a third session is required, we still have time left in the Sprint to run it.

Have frequent and regular Product Backlog Refinement sessions. Making it part of the normal and expected routine reinforces the understanding that reviewing and updating the Product Backlog isn’t a once-and-done thing, it’s an ongoing part of the process.

Tips for an Effective Product Backlog Refinement Meeting

Start at the top of the Product Backlog and work down in priority. This ensures that when you run out of time, the most important items will already have been estimated.
I recommend teams have two to three Sprint’s worth of work that are well-refined. This way the team members always know what is coming up next and there are fewer surprises.
Some teams establish an agenda of product areas to be addressed in a session. This allows everyone to spend time thinking about that part of the product. In addition, it gives the Product Owner the opportunity to invite relevant outside experts.
Ask the Team which items are the least clear and address those first.
The Product Owner should not pre-write User Stories. Instead, they should be created collaboratively with the Team.
For every item:
- Read the User Story and associated Acceptance Criteria (if they exist). Have a short, timeboxed discussion to clarify what it represents. If the discussion reveals anything new, either create Acceptance Criteria to document or rewrite the User Story to account for it.
- Estimate the User Story – some teams use Planning Poker and Story Points. Others just use T-shirt Sizing – S, M, L, XL. If I coach your team, I would recommend the latter.
- If the User Story isn’t digestible, then we split the Story into smaller parts.
- After the Story is split, it will need to be re-estimated.
- For items at the top of the Product Backlog, the team should create Acceptance Criteria.

How to Help Your Scrum Team Be Great(er)

Product Backlog Refinement is intended to help your team clearly understand the Product Backlog and the User Stories in it. To ensure you will always have a successful meeting, there are three outcomes I suggest that Scrum Teams aim for:

Greater Understanding – Merely telling people you want something built will likely result in you not getting what you envision. Instead, start with a collaborative mindset that is focused on engaging the whole Scrum Team – Scrum Master, Product Owner, and Developers – and refining the User Stories based on a shared understanding of what function they are meant to deliver, who it’s meant to help, and why it’s important.
Greater Conscious Engagement – When you’re involved in creating a User Story, you get to feel a sense of ownership of the product. As a result, you are much more likely to be motivated to engage in getting the product backlog item to truly “done.”
Greater Subconscious Engagement – Our subconscious does an excellent job of generating connections and seeing relationships between things. However, it works on its own schedule, often slowly. Ideally, you should have a few days separating Backlog Refinement and Sprint Planning, allowing everyone to see the User Stories several times (perhaps on a big whiteboard at the front of the room) before Sprint Planning, giving everyone’s brain time to make connections between seeing the Story and then trying to plan for it.

Product Backlog Refinement is a vital part of Scrum.

It increases the effectiveness and communication of the entire Scrum Team and, as a result, builds a better product for your client.

For common refinement problems and practical fixes, see Product Backlog Refinement Hell: 3 Problems and Solutions.

Do you want to coach your team towards better solutions?

The WorldsSmallestOnlineBookStore.com Team went from facing ineffective User Stories, to having a productive Backlog Refinement session and a clear path for the next Sprint. This was largely due to ScrumMaster Steve identifying the challenge and coaching everyone toward a solution that they could apply collaboratively, which improved communication between Product Owner Paula and the Team. If you would like to learn how to handle some of these common, real-life issues that organizations face in their Scrum evolution, consider attending one of our workshops, where you’ll receive hands-on learning of the challenges – and solutions – and tips on how to integrate them into your Scrum.

Frequently Asked Questions About Product Backlog Refinement

Q: How long should Product Backlog Refinement take? A: Break refinement into 45-60 minute sessions, 2-3 times per Sprint. Avoid long 2-3 hour meetings.

Q: Who attends Product Backlog Refinement? A: The entire Scrum Team: Product Owner, Scrum Master, and all Developers.

Q: What’s the difference between Backlog Refinement and Sprint Planning? A: Refinement clarifies and estimates upcoming work throughout the Sprint. Sprint Planning selects work for the next Sprint and creates the Sprint Goal.

Q: How much of the backlog should be refined? A: Aim for 2-3 Sprints worth of well-refined stories at the top of your backlog.

Post updated: December 2025 Image attribution: Agile Pain Relief Consulting (Updated: December 2023)

Footnotes

Many developers complain that Backlog Refinement interrupts them doing valuable work. We sidestep that problem if scheduled right after lunch or at some other time when they’ve already been interrupted. Key point: decide the time with the team. ↩
Mark’s note: It is strongly recommended that the Product Owner not show up at Product Backlog Refinement with prepared User Stories. My personal experience is that team members see these items as complete/correct and it kills further discussion on them. It’s much better to bring rough ideas to the session and work with the team to make them real User Stories. ↩
Caveat: Scrum works perfectly well in an environment where the Development Team doesn’t estimate – in that case, they can skip the estimation portion of refinement. You would also expect a Team that wasn’t estimating to put more effort into splitting Items at the top of the Product Backlog so that they’re approximately the same size. ↩
In order to better understand different kinds of end users, those working on WorldsSmallestOnlineBookStore.com have started using Personas to give a richer description of each. In this case, the relevant persona is known by the name ‘Julia.’ Two things matter in this context: she is a frequent book buyer and user of the site, and she gives her real estate clients gift cards to thank them for their business. ↩

Scrum by Example – How to Handle Production Support Issues in Scrum

Mon, 24 Jun 2019 00:00:00 GMT

Office workers stressed out by the delivery of an entire box of support tickets

Whenever you are building and deploying a complex system, there are always going to be bugs, defects, and unforeseen problems with usability — commonly referred to as Production Support issues. Today, our ScrumMaster and their Team grapple with these issues, to help you understand how they affect a Scrum Team and what you can do to prevent them from dragging you down.

Dramatis Personae

Steve: A ScrumMaster and the hero of our story

Paula: The Product Owner of Steve’s team

ScrumMaster Steve and his Team have released the World’s Smallest Online Bookstore. It’s live, and books are selling and shipping. This turns out to be a blessing and a curse because the business is making money, but with it comes support issues.

In the first two Sprints after the release, the Team noticeably struggles and often fails to meet its planning commitments. At first, Steve is okay with this, believing it’s inevitable post-release hiccups but, when it’s clear that the trend is continuing into the third Sprint, he starts to get worried. He spends some time watching the Development Team work and notices that Team members are often interrupted several times a day. Most of these interruptions are from production support issues.

When an application is deployed to a live site or system, the system users will inevitably find defects, ways to use it that the development team hadn’t intended, and other small issues. Most organizations that run these kinds of systems have helpdesks for users to raise these issues with.

At the company developing the World’s Smallest Online Bookstore, they have a chronically understaffed helpdesk group who provides two lines of support. They primarily respond to and resolve customer queries, known as first-line support. When an issue can’t be resolved with a simple phone call, chat, or email, they investigate to see if the problem is a defect or the platform being used in unexpected ways, known as second-line support.

It is this second line support that is causing frequent interruptions, as whenever they find a defect or usability issue, they submit a production support ticket to Steve’s Team. To document this, Steve adds a “swimlane” at the bottom of the Team’s Sprint Backlog board, labelled “Production Support and Other Interruptions.”

How to Handle Production Support Issues in Scrum - an example of a sprint backlog with lower section for support tickets

After four or five Sprints, he charts the resulting effect on the Team’s Sprint Burnup (Burndowns and Cumulative Flow Diagrams could be used as well), to show the correlation between Production Support Issues each Sprint and the number of Backlog Items completed.

Example of a release burnup chart

During the next retrospective, Steve chooses a timeline to help the Team review what has happened.¹ He also uses the data from the burnup chart to help them see the resulting effects. They discover that it’s even worse than Steve realized - Team members aren’t just being interrupted, they’re spending most of their time handling support issues.

How to stop production support issues from disrupting the Team

The first line of defence, before the Team even sees a support issue, is the Product Owner. Paula should take a look at a support issue first, then ask herself, “Is this problem worth interrupting the Team during this Sprint?” If the issue, or even a defect, isn’t absolutely critical to delivering value to the customer, it may be best addressed by adding it to the Product Backlog and asking the Team to address it as a User Story in a later Sprint.

The Team can also do a number of things to mitigate interruptions:

Choose one Team member each Sprint who will become the primary point of contact for support issues. This member would involve others on the Team as needed. This job should rotate, so it’s not always the same person. Note: I have, on occasion, called this “Rotating One Victim Per Sprint Strategy.”
If working with multiple Teams, in any one Sprint have one Team handle all production support work. Each Sprint the Team doing the work changes.
Wait until the end of the workday before interrupting another Team member for help on a support issue.
Monitor production support issues and track their effects on the Team’s productivity. I.e. in the days following the resolution of a support issue, measure the cost of fixing the issue in terms of fewer User Stories completed, but also in associated costs, such as time deploying fixes and effects of multitasking on productivity.
Based on historical needs, acknowledge in planning that there is a “tax” of 20-30% of Team capacity needed for production support. Note: This is my least favourite solution because it doesn’t help make the situation better, it just increases the Team’s awareness of it.
Extreme version of this solution is Pattern: Illegitimus Non Interruptus – cancel the Sprint if interruptions exceed the timebox. Note: This works well to highlight the problem, however, I would only recommend it as a last resort.
Limit the number of production support items “in Progress” to one. This forces hard decisions to be made about the value of fixing an item immediately but limits the ability to fix another one before the first is finished.

The obvious problem is that these defects detract from the Team’s ability to finish User Stories in a Sprint. However, the problem is much deeper than just that. When any interruption happens in a Sprint, the Team loses focus. When they lose focus, it harms the quality of the work they were doing on the new Stories.

Handling emergency defects in Sprint leads to fewer completed Stories, more defects in those Stories, and poorer quality fixes to defects as people rush. Which, at a later date, will cause more interruptions in the Sprint. In Systems Thinking this is called a negatively reinforcing feedback loop.

These band-aid solutions help the Team keep going, minimizing harm, but they fail to address the systemic issue. In any environment where a problem occurs, there are always going to be multiple and interrelated causes and effects – there is never just one root cause or single source of problems.

“In accident investigation, as in most other human endeavours, we fall prey to the What-You-Look-For-Is-What-You-Find or WYLFIWYF principle. This is a simple recognition of the fact that assumptions about what we are going to see (What-You-Look-For), to a large extent will determine what we actually observe (What-You-Find).”²

Instead of finding causes and eliminating problems – which suffers from hindsight bias³ – everything is clear looking back. We run experiments that we hypothesize will improve the situation (Unit Testing, Test-Driven Development, Behaviour-Driven Development) and look to see if the data from these experiments supports this outcome.

However, to permanently solve the problem requires a mindset change. In a real-world example, groups at Microsoft have done this by targeting Zero Defects.⁴ By making defects the exception and not the norm, people start building habits earlier to avoid them altogether. You will never get to zero, but you should find changing the mindset around defects has a radical effect on quality.

Small changes can overcome big, systemic problems

It took the Team over 20 Sprints (almost an entire year) to get to this state, so they’re not going to resolve this problem in a few Sprints. Steve, knowing this is going take a long time for the Team to grow past, suggests that the Team make a few small commitments during the next Retrospective that they think will help. The Team decide:

There is a limit of one Production Support issue worked on at one time. When these are being worked on, at least two members work together pair program to find the simplest fix.
All new code has acceptance tests written for it at the time it is created.
When Production Support Issues are found, an acceptance test is created that demonstrates the defect.
They set a goal every Sprint of having zero net new defects, agreeing to drop Stories rather than push new defects out of the door.

This a good start to turning the quality issues around. Six months later we check back in with the Team – they have reduced their support workload to ~20% of the time (still not great, but a far cry from the 50%+ they had before), they have slowed down, and with renewed focus on quality are finally delivering on zero net new bugs every Sprint. The original goal of Acceptance Tests for all new code wasn’t achieved in the first few Sprints after it was suggested. It took the better part of the next two months, but they would eventually get there.

Do you want to coach your team towards better solutions?

The above scenario, and others experienced by our well-intentioned but often misguided fictional ScrumMaster Steve and Team, are topics commonly discussed in our training workshops. Fundamentally changing the way a Team works as it transitions to practicing Scrum is one of the more challenging issues that organizations face in their Scrum evolution. We would love to have you join us to receive hands-on learning of the challenges – and solutions – as well as tips on how to integrate them into your Scrum.

Image attribution: Agile Pain Relief Consulting (Updated March 2025)

Footnotes

Most Sprint Retrospectives focus on the current Sprint, however, it does help from time to time to have a retrospective with a wider remit. ↩
The ETTO Principle: Efficiency-Thoroughness Trade-Off: Why Things That Go Right Sometimes Go Wrong by Erik Hollnagel https://www.amazon.ca/ETTO-Principle-Efficiency-Thoroughness-Trade-Off-Sometimes-ebook/dp/B077315CYY/&tag=notesfromatoo-20 ↩
Hindsight Bias https://en.wikipedia.org/wiki/Hindsight_bias ↩
Microsoft - No Bugs Journey https://docs.microsoft.com/en-gb/archive/blogs/ericgu/no-bugs-journey-episode-2-its-a-matter-of-values ↩

Scrum by Example - Is Your Scrum Team a Victim of Scrummerfall?

Tue, 27 Feb 2024 00:00:00 GMT

Is your Scrum team struggling with questions about who owns quality? Is testing way behind development? Are team members claiming no time for retrospective because they’re focused on delivery? They might be victims of what some call Scrummerfall, or Mini Waterfall. Let’s use our fictional World’s Smallest Online Bookstore (WSOBS) Scrum team to explore what this Scrum anti-pattern is and the damage is causes.

Dramatis Personae

Steve: A ScrumMaster and the hero of our story Paula: The Product Owner of Steve’s team Tonia: Quality Assurance specialist Brad: Business Analyst Martin: Database Developer Doug: Front End Developer Ian: Business Logic programming specialist

What is Scrummerfall?

Scrummerfall (also called Mini Waterfall or WAgile) is a Scrum anti-pattern where teams inadvertently recreate waterfall phases within their Sprints. Instead of collaborating on work items together, team members work in sequence:

Business Analysts work one Sprint ahead of developers
Developers complete their work and hand it off to QA
QA tests work from the previous Sprint, always playing catch-up

The result is that cycle time doubles (or worse), quality suffers from delayed feedback, and Sprint Reviews become meaningless because nothing is truly “Done.”

The Story so far

Martin, Doug and Ian approach ScrumMaster Steve two days before the end of the Sprint and say, “We won’t be attending the Retrospective this week. We’re working fast, we’ve finished this Sprint’s work and have already started work on the next Sprint. We just don’t have time for the retro, but we’re getting stuff done, so that’s okay.”

If half his team is going to be absent, is there any point in Steve holding a Sprint Retrospective? Yes, however, that isn’t the focus for this post. Scenarios like I’ve just described are a proverbial canary in the mineshaft. When Scrum team members lack time or interest in the Retrospective, that tells us there is a problem somewhere else in the system. Rather than find a band-aid or quick fix, a Scrum Master is better off trying to understand what is happening that leaves their team in this position.

A general working assumption when we see good people doing something strange is that we should examine the system to understand what it is telling us. In this case, why are our developers working a Sprint ahead?

When we see a team struggling, if we take the time to review the Sprint Backlog it will often tell us a good story. So let’s dive into the recent flow of work of the World’s Smallest Online Bookstore team, through the lens of their Sprint Backlog.

It’s day 8 of a 10 day Sprint and their board looks like this:

Sprint Backlog - Scrum by Example Scrummerfall example

From this we can see that:

the Sprint’s work is still untested
our Business Analyst and Developers have raced ahead and picked out work that might happen in the next Sprint

Steve sits down with the impatient threesome and asks, “What is up that you’ve already started work on stories for the next Sprint?”

Martin answers, “Well, we handed off all our stories to QA, so we had nothing to do. Instead of twiddling our thumbs, we grabbed more work. Isn’t Scrum about giving us autonomy and getting stuff done? In any case, Retros aren’t that important. They just take up time and the real pressure is to get more work done, faster.”

Not understanding the value of Sprint Retrospectives is, sadly, not a new issue with these team members. Read also: Same Old Song in Sprint Retrospective.

Signs Your Team is Stuck in Scrummerfall

Some team members have completed their work for this Sprint so they are working ahead on the next Sprint. Great, right? No idle workers, and all that. The organization is all about speed, and the team all need to be seen being busy.

Except it’s the exact opposite of great. Because while our developers moved on, the testers can’t get everything tested by the end of the Sprint. So starting the next Sprint, they’re still testing the last Sprint’s work. The Product Owner is scrambling to stay ahead of the devs and still keep up with the rest of their responsibilities. On top of all this, the team is being pressured to “maintain” velocity. Even worse, the Sprint Review becomes a fiction because, instead of reviewing completed work that can be delivered to stakeholders, the review is of partially completed work that will have unknown defects.

The simplest thing to say is that this resembles a mini waterfall. However, that doesn’t help our team. In practice, the team have created what’s called Scrummerfall.

Scrummerfall Staggered Sprint Starting Point

Why is Scrummerfall (or Mini Waterfall) in Scrum a problem?

First and foremost, because quality suffers in Scrummerfall. The longer the time span between finding a problem and fixing it, the harder it is to fix well. When a defect is found with work done in a previous Sprint, the developers might be reluctant to go back and fix it right away, claiming this is slowing them down. This is especially bad in an environment where teams are focused on velocity. The bug was already hard to fix because it was found later, and delays in fixing it just make the problem worse.

Handoffs harm quality (e.g. from BA -> Dev -> Test). Every handoff from one person to another causes a loss of information, which increases the likelihood of a bug.

Working ahead of the rest of the team also affects cycle time. Cycle time is the time from when work is started on an item to when the customer gets the value. In the case of our Bookstore Team, this is going to be at least two Sprints (4 weeks), because items are delayed waiting for testing and aren’t truly ‘Done’ and deliverable.

And that’s even assuming that deployment is instantaneous and there are no defects - neither of which is likely to be true. Cycle time matters because it is what the customer sees. They see the team has started work on the item and they see when they get the item. They don’t care what order the work was done in or who did which part. They care whether or not they waited an eternity and if their feature works as expected on delivery.

What Causes Scrummerfall?

How did our team end up doing this Scrummerfall version of Scrum to begin with? This is where, if you dig down, you’ll find the underlying issues (Hint: this is the Start of Systems Thinking which we cover in our A-CSM). In this case it often stems from a mindset issue within the organization:

An assumption that Scrum is like the traditional approach, only faster.
An adversarial relationship between development and test.
A focus on throughput or velocity above all else.

Assuming we agree that Scrum isn’t just the traditional process done faster, we need a better approach. What is a more effective way of working?

Better Ways to Work Than Scrummerfall

Introduce Cycle Time as a measure so we can see what we’re improving. In the short term I would expect the Bookstore Team to focus on reducing their cycle from 4 weeks to 2 weeks. This is guaranteed to reduce their velocity. Since velocity is a dangerous measure and often not even a good forecasting tool, we need to wean people from its use. Cycle time is a better measure because it challenges us to optimize getting the value to the customer sooner.
Consider another measure like “Defects that Escape the Sprint” as being a proxy for quality. This will help us understand what happens to our quality over time. Our eventual goal is zero defects that escape the Sprint. Even if we never get there, it challenges the team to focus on quality over nominal speed.
Reset the relationship between Dev and QA. QA isn’t trying to find bugs, so their performance shouldn’t be measured by the number they find. QA is trying to prevent bugs. Many teams have an adversarial relationship between Dev and QA because they see it as critiquing and looking over the shoulder of each other’s work.
Encourage collaboration. Since QA, Dev and BAs are all attempting to build the best quality, they should start the Sprint by collaborating on getting the detailed acceptance criteria for the User Stories, with a strong preference for examples (aka Behavior Driven Development). They might even pair-program with the Devs to create automated tests for the acceptance criteria. Collaboration on acceptance tests, BDD, and test automation are all longer term steps that increase quality. As collaboration becomes more natural, it would be a good opportunity to run a cross-skilling workshop.
Encourage cross-skilling. As team members start to collaborate more, some cross-skilling will start to happen naturally. You can’t help but learn more about other disciplines when you spend time working together every Sprint. Cross-skilling strengthens relationships and morale, and significantly reduces bottlenecks.
Support the team to grow into Pair-Programming and the whole host of other Agile Engineering Practices.

Scrummerfall happens when team members stay stuck in traditional patterns and roles. Scrum (and all flavours of Agile), expects us to continually reconsider how we work and ask what small changes we can make next.

When some or all of a Scrum team goes to the Scrum Master and resists the basic framework of Scrum, don’t force the issue. Instead, use it as an opportunity to look deeper for what’s really happening. If you find problems like the team feeling they have no time for a retrospective or no interest in holding one, don’t solve the surface problem by canceling or replacing the retrospective or, much worse, forcing them to attend. Instead, dig into the why to find the deeper problem.

The Scrum framework leaves a lot of wiggle room to adapt it in unique ways to best suit your own team’s needs. But don’t abandon the basic structure (like retrospectives) when something isn’t convenient. All of the Scrum events serve a critical role in the overall effectiveness of Scrum.

Key Takeaways

Scrummerfall doubles your cycle time because items wait for testing across Sprint boundaries
Watch for warning signs: developers working ahead, QA always behind, team members skipping retrospectives
Measure cycle time, not velocity to expose the real cost of handoffs and delays
Quality degrades when bugs are found Sprints after the code was written
Collaboration beats handoffs: have QA, Dev, and BA work together on acceptance criteria before coding starts
Cross-skilling reduces bottlenecks and helps team members understand each other’s work
Don’t skip retrospectives when teams resist them, dig deeper to find the systemic problem

Related Blog Entries

Updated: Jan 2026

What is the Recommended Scrum Team Size?

Fri, 13 Mar 2020 00:00:00 GMT

Nearly every client I work with asks me this question: ‘What’s the optimal Scrum team size?’ 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 research and 20+ years of experience reveal a more nuanced answer that could dramatically impact your team’s productivity.

In many cases this question comes up as a side effect of Sprint Planning from Hell or Daily Scrum that goes on too long.

There isn’t one universally correct answer for optimal team size, but there are a number of factors and trade-offs worth considering when figuring out what will work best for your team.

In this post, we’ll explore the research, and I’ll share my personal experiences about effective team size. While this is primarily about Scrum, the lessons are applicable for any work that is collaborative and knowledge-based.

What is the Recommended Scrum Team Size? This is a larger than ideal scrum team size!

Key Takeaways: Optimal Scrum Team Size

Best size: There is no best size. However teams of 4-6 or often a good choice
Communication cost: Relationships grow exponentially (N(N-1)/2 formula)
Avoid: Teams of 8+ show diminishing returns
Critical factors: Skills, stability of membership, and psychological safety matter as much as size
Evidence: Multiple studies support smaller teams for knowledge work

Effective Scrum Team Size is More than Just a Number

When you’re trying to determine what will work best, your Team’s needs should be more important than any arbitrary number. Factors you should consider include:

A sufficiently broad set of skills to build their product – aka Cross-Functional
Team members dedicated to one, and only one, team
Stable membership – i.e. team membership that is consistent over a long period of time¹
Diversity of thought – a sufficiently broad set of beliefs, attitudes and thinking patterns²

Once the Team is formed, these are often just as important as team size when predicting success:

Psychological safety – the environment is safe for all team members to share their ideas³⁴
Collective Intelligence of the Team – strongly correlated with average sensitivity of team members⁴
Equal Communication – the most expressive team member is no more than twice as expressive as the quietest⁵
Open-Mindedness and Willingness to Learn⁶
A Shared Vision of which all Team members are committed to achieving⁷
Clear Roles and Responsibilities⁸
Dynamically Shared Leadership⁹
External Coach – in Scrum this is the ScrumMaster

These factors don’t exist in a void, so let’s explore the evidence that supports what others, including myself, have discovered about team size, to help you consider what’s most important for your Team. After all, there is no universal answer, there is only a range that will likely work best for your needs.

The Problem with Arbitrary Numbers for Optimal Team Size

The earliest Scrum and XP books all suggest a team size number of 7+/-2, applying Miller’s number,¹⁰ believed to be the number of integers you can hold in short-term memory. I’m troubled by this, since I can’t see why one’s ability to keep track of numbers should be correlated with team size. In addition, more recent research¹¹ has shown that, as the things you’re keeping track of become more complex, the number of items you can keep in your short-term memory drops to 4 or less. Clearly, we need more useful sources.

Many other coaches cite historical examples going back to the Roman army, which used small military unit sizes of around 8 people. Others observe bonobos, one of the closest genetic relatives to humans, often split into groups of 6-7 to forage for a day. Both of these conveniently support the 7+/-2 number, but since neither example is about teams doing knowledge work, the relevance of these for Scrum is limited.

What Happens to Relationships When Teams Get Large?

Optimal scrum team size - small team of 5-6 members collaborate more effectively than 10.

In a team, each individual will connect with another individual and form a unique relationship. The bigger the team, the more the relationships. The equation that describes this is N (N – 1)/2. But what exactly does that mean? More importantly, how is it supposed to help you? Let’s start by treating it as a high-school math problem, then turn it into something we can actually use in real life.

The above equation tells us how many different relationships will exist within a team of a certain size. N = the number of people in the team. So, in the first example of a team of 5 people, for N=5 you have 10 relationships: 10 different combinations of team members relating with other team members.

In the second example, n=7, you have 21 relationships, and at n=9 in the third image you have 36 relationships. Each pair of people represents one relationship, and that relationship is how they collaborate. High-performing teams, by their nature, must have strong relationships between each of the team members to collaborative effectively.

Why does this matter, and how can it help you? Each new person adds some individual productivity to the Team, but they also increase the communications overhead in the form of an exponentially growing number of relationships. To increase a team from 5 to 7 people, you have to more than double the number of relationships. To go from 7 to 9, you don’t quite double it, but the jump is still large.

Just how expensive is it to maintain these relationships? Anecdotally, having studied team member interactions at clients’ sites, I can say that in teams of 7-8 people, upwards of 90 minutes per person each day is spent interacting with other team members.¹² This excludes pair programming time. Some of the interaction is talking about work, but just as much is spent socializing. This is good and important because it’s the combination of work and socializing that builds a team’s resilience and ability to handle challenges effectively (see the water cooler section in “Five Steps Towards Creating High-Performance Teams”).

So the number of relationships between team members, and the time investment they require, needs to be a factor considered when choosing team size because it will influence productivity.

A general rule of thumb suggests that people typically have from 3½ to 5 hours of productive time at work each day. As a team gets larger, we either lose productivity or, more often, we start to withdraw socially rather than sacrifice productive time for interacting with our peers because the communication costs for each team member is becoming too high to afford. We need strong relationships to become a high-performing team but, as group size grows, we start to avoid the interactions that build those relationships.¹³

Many Hands Make Light Work… But Only to a Point

We all want to believe that if we go from 1 person to 2 people, or from 2 to 4 people, we will get a doubling of the amount of work done. Yet, we know intuitively that isn’t the case.

What we’re missing is why. Enter “Amdahl’s Law.” The formula, first presented in 1967, estimates how much of a speedup might be gained if we took a computing task and ran parts of it in parallel. If that sounds like gobbledygook, it just means sometimes programs have parts that can be worked on by multiple processors at the same time (i.e. parallel processing), but other parts that must be done one at a time (i.e. serial programming).

Scrum Team Size - Parallelizable vs Serial Work.

The first picture imagines work done by one processor. It takes 5 units of time.

If we take the 5 units of work and apply 3 processors to the parts that can be done concurrently (parallel), it doesn’t take 1 and 2/3 units of time (5 divided by 3) to complete. Instead, it takes 3 units because 2 of the units of work can only be done by one processor (serial). It’s certainly an improvement in time, but not as much as you might expect.

The math to explain the problem might look intimidating at first:

Parallelizable vs Serial Work.

Work in teams has similar properties. In fact, if we turn it into a graph, we see just how inefficient increased team size can be:

Amdahl's Law graph.

Just focus for now on the 80% line (teal, at the top) of the graph. Let’s be optimistic (and unrealistic) and assume that 80% of the work can be done by working in parallel. This suggests that the more people doing it, the faster it will get done – right? Ah, but wait. If we go from 1 person to 2 people, we don’t get twice as much done. To get a 2 times improvement in work completed, we actually need 3 people. 7 people only create a 3.2 times improvement over 1 person. To get 4 times as much work done as 1 person, we would need 16 people!

What happens if even less of the work can be done concurrently (parallel)? What if 50% of the work must be done in serial (red line on the graph)? Then with 9 people, we still have only a 1.8 times speedup.

What’s the solution? There’s no easy fix, but there are things you can do to mitigate the effect of Amdahl’s Law:

Make it so as much of the work as possible can be done in parallel. This may mean increasing cross-skilling and collaboration.
Reduce cross-team dependencies, so there are no bottlenecks and delays.
Increase the speed of the work process overall by improving quality and practices.

Speed doesn’t come from throwing more people at the job and making bigger teams. It comes from building a high-performance team that is an optimal size for effectiveness, communication, and quality.

Research-Backed Evidence on Team Size

The American Sociological Association published a study by Hackman JR, Vidmar NJ on the “Effects of size and task type on group performance and member reactions.”¹⁴

Source: Hackman JR, Vidmar NJ. Effects of size and task type on group performance and member reactions. Sociometry. 1970;33 :37-54.

In this study, they had participants complete a number of tasks – a mix of Production (writing), Discussion, and Problem-Solving. The participants were placed in different groups sized from 2 to 7. After completing each task, volunteers were asked a number of questions, including two that this graph displays: “was your group too small?”, “was your group too large?”. As you can see from the graph, groups around 4-5 in size seemed to have the least negative reaction. The oft-cited number is 4.6. The participants were undergraduate students (all men, sadly), the tasks had a cognitive load but were not programming, and the groups weren’t together long enough for a real sense of a “team” to form. Nonetheless, it is an interesting data point.

By the time Hackman wrote the book Leading Teams, his rule of thumb for team size was 6.

Jennifer Mueller cited in “Is Your Team Too Big? Too Small? What’s the Right Number?:”

if companies are dealing with coordination tasks and motivational issues, and you ask, ‘What is your team size and what is optimal?’ that correlates to a team of six. “Above and beyond five, and you begin to see diminishing motivation,” says Mueller. “After the fifth person, you look for cliques. And the number of people who speak at any one time? That’s harder to manage in a group of five or more.”

It’s not just personal opinions from team members that teach us about optimal group size: we also have objective statistics. Putnam and Myers surveyed data from 491 software projects in a large corporation.¹⁵ These were projects with 35,000 – 90,000 source lines of code. They broke projects down into buckets based on the number of people involved in the project: 1.5-3, 3-5, 5-7, 9-11, and 15-20. On average, the smaller groups (3-5, 5-7) took significantly less time (11.9 and 11.6 months, respectively) than the larger groups (17.1 and 16.29 months) to complete similar-sized projects.

When you multiply the number of team members times the number of months, you get a graph that is even more shocking:

Putnam Myers study graph.

A team of 9-11 people took around2.5-3.5 times as long as teams of 5-7 and 3-5 to complete projects of a similar size. That suggests that teams larger than seven in this dataset were just a way to spend money faster because of the increased team size but reduced net performance.

Evidence from Agile Projects

Larry Maccherone, in his work through both Rally, Tasktop, and AgileCraft, has helped build large datasets about practices in Agile Teams. His data shows:

Used with Permission from Larry Maccherone – from Impact of Agile Quantified Late 2014.

Based on Larry’s data, it would appear that teams of 1-3 are more productive but have lower quality. Teams of 3-5 are marginally more productive than 5-9, although they might still have slightly lower quality – the difference is small. Larry’s notes suggest he thinks the entire range of 3-9 is fine.¹⁶ The reason for the lower quality in smaller teams is not apparent. Maybe a lack of stability? A lack of diversity of thought and experience? Reduced cross-functionality? We can’t know, but it bears consideration.

WAIT! Before you read on, remember that the whole point of this article is to stress that your mileage may vary! Don’t substitute the opinions or evidence of others for your own knowledge of, and experimentation with, your teams. Start with this information, then tweak to find what works best for your team.

Small Scrum teams of 5-6 members have better engagement with each other.

My Experience

So, when clients and attendees of my training ask me what size Scrum teams should be, I don’t have a “correct” answer. But I share the above data and my personal opinions and suggestions based on years of experience. Most of it is rooted in simple logic and common sense. For example, larger teams spend longer in forming, longer in normalizing, and therefore longer to reach high performance. Why? Because there are more relationships to be negotiated. As we saw before, on a team of 5, there are 10 relationships that need to form, a team of 7 has 21 relationships, and so on. More relationships take more time to build and establish trust, so that has to be factored into the decision of team size.

Assuming everything else is equal (e.g. skills required to get the job done, diversity of thought, etc.), existing evidence supports the idea that teams of 4-6 work well for most situations. They take less time to form and are as productive as larger teams. In addition, teams of 5-6 can typically cross-skill enough to cover the loss of a team member after they win the lottery.

Personally, I would only choose a team of 7 if other pressures, like a required breadth of skills, forced it to happen. I no longer recommend teams of 8, because the additional overhead overwhelms the value of the extra person.

With teams of 9 or larger, I recommend splitting into 2 teams. My own experience mirrors that of other Scrum trainers and coaches – separate teams of 4 and 5 get more done than their original large team.

Why not 3 or fewer? Because it would result in too little diversity of thought, and would likely be very challenging to find 3 individuals with sufficient skills to get the job done on a complex project. There also will be very little collaboration, which correlates with the reduction in quality that Figure #2 shows (data from “Impact of Agile Quantified”). And don’t forget the obvious 2-on1 power issues that may make the journey more challenging for one team member.

All of the focus has been on the number of people in the team, but the more important question should be this: does the team have the capacity to get to truly “done” (i.e. shippable) at the end of every Sprint? If it doesn’t, then you will want to re-examine and reconfigure to achieve a more effective team size.

What has been your experience with team size? Too small? Too big? Just right?

Check out the 5 Steps to High-Performance Teams

As we’ve learned, big teams don’t mean more work gets done faster. High-Performance Teams though… that’s where the magic happens. Check out our 5 Steps to High-Performance Teams and get your own copy of the e-book by subscribing to our newsletter, and see what changes could help your team improve.

Thanks to: Peter Stevens and his own digging, Larry Maccherone and access to all of his work, Joseph Pelrine for pointing me to original research papers, Brent Barton for telling me about Putnam and Myers, Manoj Vadakkan and Angela Johnson for other references, and Pawel Brodzinksi, who offers an alternate view.

Related Blog Entries

Frequently Asked Questions About Scrum Team Size

What is the ideal Scrum team size?

The optimal Scrum team size is 4-6 members, based on research and practical experience. This range balances productivity, communication overhead, and team dynamics while maintaining cross-functional capabilities.

Why does the Scrum Guide recommend 3-9 people?

The Scrum Guide doesn’t provide a clear reason. Neither Jeff or Ken are known for providing explanations of the Scrum Guide.

What happens if my Scrum team is too large?

Teams larger than 7 experience exponentially growing communication overhead, reduced productivity per person, longer time to form high-performing relationships, and decreased individual contribution.

Can a Scrum team have 2-3 people?

While possible, teams of 2-3 lack diversity of thought, struggle with skill coverage, and show reduced quality in Agile metrics. Teams of 4+ perform better overall.

All images by Agile Pain Relief Consulting unless otherwise noted. Updated Dec 2025 6 March 2020: Updated for 2020 from 2016

Footnotes

“The Impact of Lean and Agile Quantified” - Larry Maccherone demonstrated that dedicating team members to one team doubled productivity and stable teams improved productivity by 60%. ↩
Wilkinson, David. Group decision-making. What the latest research says. The Oxford Review, December 2019 ↩
“What Google Learned From Its Quest to Build the Perfect Team” ↩
Psychological Safety and Learning Behavior in Work Teams – Amy Edmondson Administrative Science Quarterly 1999 44: 350 DOI: 10.2307/2666999 ↩ ↩²
Anita Williams Woolley, Christopher F. Chabris, Alex Pentland, Nada Hashmi, Thomas W. Malone. Evidence for a Collective Intelligence Factor in the Performance of Human Groups. Science 29 Oct 2010: Vol. 330, Issue 6004, pp. 686-688 ↩
“The New Science of Building Great Teams” - Alex “Sandy” Pentland and also “Evidence for a Collective Intelligence Factor in the Performance of Human Groups” ↩
Shared Vision or Common Goal - in Scrum this should be the Product Vision ↩
Clear Roles and Responsibilites - as part of Team Launch, we recommend Team Members negotiate roles ↩
Dynamically Shared Leadership - Neither the ScrumMaster, nor Team Lead nor Manager run a self organizing team ↩
Miller’s Number ↩
“The Magical Mystery Four: How Is Working Memory Capacity Limited, and Why?” by Nelson Cowan ↩
These have been very informal observations – just sitting watching what was going on in team spaces and around the water cooler. This time didn’t include lunch breaks. ↩
This is also documented in: Mueller, J. S. Why individuals in larger teams perform worse. Organizational Behavior and Human Decision Processes (2011), doi:10.1016/j.obhdp.2011.08.004 ↩
“Effects of size and task type on group performance and member reactions” - stable online reference ↩
Familiar Metric Management - Small is Beautiful-Once Again - Lawrence H. Putnam and Ware Myers ↩
Mark’s Note: I wish the data had split the 5-9 group into separate sets of 5-7 and 7-9 so we could see if there is a noticeable difference in his data at the larger end. ↩

Scrum Without Removing Impediments Isn't Scrum

Tue, 04 Aug 2015 00:00:00 GMT

Mechanical Scrum Versus True Scrum – What’s the Difference?

Speed Bump Sign - free image from Pixabay.com

Recently I was talking to a friend about their company’s implementation of Scrum. They don’t see the point. Before Scrum was implemented, they often had to wait an hour or more to access a test machine. After several years of using Scrum, it’s still a problem. The same company has its test servers in another country and there are often network issues that cause the running tests to fail. These were problems before they started using Scrum, and nothing has been done to address them since.

Scrum only works when we use it to address the problems that exist in our environment, and then work to resolve them.

Consider the basic principle that a Scrum Team is required to produce high quality working software (or hardware) at the end of every Sprint. Shippable quality.

Anything that stops the Team from achieving Shippable Quality Software every Sprint is an impediment, and must be resolved.

Here are some of the common reasons that impediments don’t get resolved:

Definition of Done¹ doesn’t exist, isn’t honoured, or isn’t published in a truly visible place (usually the Team room wall).
Definition of Done isn’t frequently updated and improved until the Team is at least able to ship at the end of every sprint; preferably able to ship continuously.
There are no Component or Feature Teams². Scrum doesn’t require Feature Teams explicitly, but it does require that the Team has a sufficient supply of skills that it can get a small vertical slice (not just one component) of software to truly done at the end of every Sprint. Component Teams, while legitimate in Scrum, increase the coordination effort required to get to done every Sprint.
Pressure exists to deliver more every sprint. Many Teams feel a constant pressure to deliver significantly more than they’re able to. The pressure is so intense, that they constantly take shortcuts to try to meet the demand. Scrum was created to give the doers more freedom in deciding how much work they could achieve and how they could achieve it. It only works when the Team takes a stand and makes clear their capacity. Real improvement is only possible when the Team has sufficient slack to pause, reflect, and improve.
Organizational impediments are not removed. For example, network issues between one office and another, coordination issues between Teams, or anything else that can’t be resolved at the Team level.

Remember, Scrum is a problem-finding tool, not a problem-solving tool.

Your organization has to solve the problems that Scrum highlights, for it to work effectively. Since Scrum doesn’t solve the problems for your organization, you’re not actually practicing Scrum if you don’t follow through and resolve the issues that it finds. Instead, you’re practicing Mechanical Scrum.

Image attribution: https://pixabay.com

Footnotes

Definition of Done - a checklist used by a Scrum Team to test if a Product Backlog Item is truly completed. Learn more ↩
Feature Teams - A feature team is “a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.” Source: Larman and Vodde ↩

Scrum by Example – ScrumMaster for Three Teams? What are the Alternatives?

Tue, 22 Apr 2014 00:00:00 GMT

Pulled In Many Directions - by FreeImages.com

Scrum succeeds because it helps build a high performance team, i.e. a team that is capable of delivering significantly more work than the individuals are capable of separately. The role of the ScrumMaster is to help build the high performing team through observing their relationships, helping them understand Scrum, improving their technical practices, improving their relationship with their product owner, and improving the organization they’re part of.

Scrum by Example is a narrative-style blog series designed to help people new to Scrum, especially new ScrumMasters. Let’s use the series’ fictional WorldsSmallestOnlineBookStore team to look through the lens of building team(s) and ask what the ScrumMaster could have done.

Dramatis Personae

Steve: A ScrumMaster and the hero of our story

Paula: The Product Owner of Steve’s team

Don: Director of Development

Jeff: Chief Technology Officer and Don’s boss

After the stress of the last release, Steve and his team are slowly paying down the technical debt (mess) they created. They maintain a technical debt backlog, knocking off a few items every sprint in addition to the work they do creating new features. If they keep this up it will take only another three to four months before they’re as productive as they were before the release.

Jeff (CTO – Jeff -> Don -> Steve) calls Steve and Don, into his office. He says, “I have great news. The VCs have given us the go ahead to hire two new teams right now. Unfortunately they don’t think there is enough need to justify the hiring of any more ScrumMasters”. He continues, “Steve, I’m sure you can play this role for all of our teams. There can’t be anything more than scheduling a few meetings. Steve, we’re counting on you to make this a success.”

Steve has learned to speak up more than he had in the past, and he tries to explain that the role is far more involved than just booking a few meetings. Jeff, however, stands his ground. “I’ve just attended SAFe training and my trainer told me we could get away with a 1:4 ScrumMaster to Team ratio.” He continues, “Steve, I know you can make this work for us.”

In the following weeks, two additional teams are hired and Steve does his best to split his time fairly between them. He mostly abandons his own team (we will call them Alpha) and splits his time between the other two new teams. Steve, being an aficionado of personal improvement, keeps track of roughly how much truly productive time he has for each team just by measuring the number of Pomodoro he completes. Perhaps unsurprisingly, this number goes down. He used to average six a day, and now he only achieves four. (Steve has just discovered Multitasking - which is a great way to get everything done later at both the team and individual level.) Luckily, he’s figured out that he can mostly ignore his existing team since they’re already so far along the team performance curve.

Three months in, and let’s see how the teams are doing. The two new teams, Beta and Gamma, are struggling. Team Beta run all the mechanical elements of Scrum correctly, and they have all the meetings (Sprint Planning, Review, Retrospective and Daily Scrum). They have - and consistently meet - their definition of done, but it is so weak and watered down as to be useless. So the letter of the Scrum law is being practiced, with no spirit. There is limited collaboration and everyone is working in silos. Worst of all, the Beta Product Owner writes all the user stories for team members, treating them as order takers and not partners.

Our fearless ScrumMaster Steve has a fair idea about what needs to be done, but little time to act. Complicating things further, team Beta have decided that they’re really not a big fan of Steve since he never removes any of their impediments directly, instead challenging them to solve their own problems.

Team Gamma are off to a better start. They’re trying to follow not just the letter of Scrum law, but also appreciate that there is a spirit of collaboration. They’re really struggling to make it happen. They’ve heard all about Test Driven Development, Acceptance Test Driven Development, Continuous Integration, Collective Code Ownership, Refactoring, Simple Design, etc, however they’re having trouble getting past rudimentary Unit Testing. It took them several weeks to get a Continuous Integration server up and running as they were snowed under with requests from the Product Owner.

They need someone to hold their hands and act as a backbone when required. They need someone who can coach their collaborative skills, in addition to the technical ones. This team has a fair chance of becoming high performing, but are unlikely to do so by stumbling towards their goal. Their issues are two fold: they don’t really understand what’s going wrong, and Steve doesn’t have the time to coach them correctly.

Meanwhile Steve’s regular team is suffering under his almost complete absence. In an attempt to get the other teams up and running, Steve is only booking meetings for Alpha, he helicopters in to facilitate meetings, and then disappears again. As a result, Retrospective meetings are happening but the action items aren’t being completed.

The team had been focusing on improving their technical practices, but this has fallen by the wayside. They’ve been using Sonar to track historical information around their builds including Build Failures, # of Unit Tests run, Code Coverage, PMD warnings, and more. In the past few months, it’s easy enough to see that their technical quality has slipped. It would appear that, without Steve to question, they struggle to finish their commitment every sprint, even when it’s clear that they overcommitted. Worst of all, they seem to have forgotten about the importance of regular backlog refinement, because the product backlog has hardly changed in the past six weeks. This makes it increasingly likely that the team isn’t actually working to meet the current needs of the customers. Since they spent limited time collaborating on acceptance criteria, they’ve had more surprises where Product Owner Paula says that feature doesn’t work the way she wanted and it needs to be fixed.

Analysis

What happened? Steve can’t possibly win here. His boss, Jeff, thinks that the role is part time. But he can illustrate that the role requires a lot more than part time, and help people around him see the costs of their choices:

Use Sonar history from Team Alpha to show the general decline in technical quality (Be careful to make it clear that these are just general indicators.)
Demonstrate that Alpha is achieving fewer backlog items per sprint than they did in the past. (You can measure velocity to do this but I would just count stories.)
Demonstrate that the code being produced by the Beta and Gamma teams is harder to follow and making it more difficult to add new features.
Show that all the teams are struggling to deliver features at all, and when they do, the features aren’t what the customer wanted.
Show that the Alpha team hasn’t made any real changes in the past few sprints.

…

In all cases, Steve can focus on the outcomes that the business cares about: Happy Customers, Useful Features Delivered, Quality and Ongoing Improvement. Don’t focus on Scrum words, as the management couldn’t care less about those.

When you’re responsible for many teams, you don’t have time. So you will need to:

Facilitate well - instead of taking the time to facilitate, Steve fell back to his prior command and control habits (alienating team Beta).
Coach the Product Owner - a Scrum Team that doesn’t have a close relationship with their Product Owner will do a brilliant job of building the wrong thing.
Coach the Technical Practices of the Team - once the mechanics of Scrum are in place, much of the productivity improvement comes from team members learning Test Driven Development, Acceptance Test Driven Development, Continuous Integration, Collective Code Ownership, Refactoring, Simple Design, et al.
Coach the Scrum Process - Steve only has time to run meetings at this stage, not facilitate retrospectives, and certainly not to work with individual team members. (Normally I expect ScrumMasters to facilitate meetings, in this case, Steve is so rushed he doesn’t have time to facilitate, and instead he just tells people what to do in the meetings. Running meetings will quickly impinge on the team’s ability to self-organize.)
Witness the Team in Action - part of coaching effectively is just observing - seeing what is happening both as individuals and between team members. Without witnessing the activities and actions, it’s harder to facilitate an effective retrospective that gets to the heart of matters.
Definition of Done - the team needs to be consistently reminded what they’ve already agreed with respect to ‘Done’. They need to be consistently challenged to ensure that they honour their definition.
Retrospective Action Items - it’s easy to commit to take action in the retrospective, but harder to follow through. The ScrumMaster provides the reminder of the importance of following through.
Team Impediments Backlog - the ScrumMaster is responsible for maintaining the team’s impediments backlog, for keeping it up to date, and for highlighting problems that team members themselves can take.
Technical Mess (or Debt) Backlog - effective teams maintain a list of their worst pain points in the code and are always paying them. Their goal is to extend the useful life of their codebase and lower the cost of change.
Discipline and Focus - helps the team stay focused on the highest priority work and helps provide them with the discipline and backbone to make it work.
Change the Organization - many of the problems that the team faces are at the organizational level, and any fixes we make at the team level are sub-optimizations. A good ScrumMaster is always thinking about the big picture as well as their own team.

This is far from an exhaustive list - just a start.

When you’re faced with the tough situation like this, what is the best way you could handle it? Some options in rough priority order:

Full time, Dedicated ScrumMaster - gold standard.
If one team is already doing well, have one full time ScrumMaster split over two teams. We have one person learning to play the role of the ScrumMaster more effectively and we already have one team working well. In this case our ScrumMaster can focus much of their time on growing the capacity of the new team.
Full time ScrumMaster split over two teams - similar to number #2 - one person focused on playing the role well might be a better option than part timers. In this case the organization needs to acknowledge that it is delaying (possibly forever) both teams’ achieving high performance.
Team member playing part time ScrumMaster at least 50% of their time focused on their team. Guarantees some time for the role to be played adequately well. Problem: the team won’t perceive you as neutral in dealing with conflict; personal task work often takes priority over the team. Solution: wear a hat when playing the ScrumMaster to remind yourself to stay neutral; work for the team trumps individual task work. In this case the organization needs to acknowledge that it is delaying the team’s achieving high performance.
ScrumMaster for three or more teams - doesn’t work, refuse the role and ask for one of the above options.

If you need more help in showing someone the full time nature of the ScrumMaster role, try:

ScrumMaster Checklist from Michael James: https://scrummasterchecklist.org/
Cases for Dedicated ScrumMaster - Melinda Stelzer Jacobson: https://www.infoq.com/articles/case-dedicated-scrum-master

Scrum is difficult enough to do in the first place. Don’t stack the deck against yourself by accepting more than you can possibly handle.

The research on team size and why stable teams matter explains the science behind Steve’s struggles: splitting one person across three teams undermines the very stability and relationship-building that high performance depends on.

Image attribution: FreeImages.com

Scrum by Example - Impediments are Holding Back the Team

Wed, 07 Dec 2011 00:00:00 GMT

Stop Sign. Image by FreePik

The team are holding a daily standup mid-sprint. During the meeting Tonia the world’s best tester answers the obstacles question by saying: “The test server is down for the third time this week and I will spend the day writing new test cases.” Meanwhile Doug doesn’t raise any impediments but notes that he has spent his third day trying to write Unit Tests for a previously completed class (Ed: The team doesn’t know about Test Driven Development yet). This task was originally estimated to take one day.

Analysis

What is an impediment? Anything that stops the team from delivering value. ANYTHING. Anything that stops code from being written, tested, deployed and making money. Some examples include:

Dead computer
Noise from neighbouring teams
Missing tools i.e. you need to find memory leaks but the company won’t pay for tool to find leaks
Lack of training i.e. you’ve been switched from writing Cobol to Java, but provided no support beyond a couple of books to make the transition.
Focus on Roles
Mandated to use a company wide tool without an ability to make local decisions
Focus on reducing costs over delivering value
Unwillingness to seek new ideas outside of the organization. This often happens in larger companies that just assume they’re the best
People who talk agile but walk a more traditional approach
Focus on tools to solve problems without talking to people first

The standup raised two impediments. Tonia seems to be treating ScrumMaster Steve as ticket taker, i.e. just hand Steve the problem and go onto something else. Her few words in the standup seem to indicate that she believes that the problem is beyond her control so she just gives up assuming it will get solved for her. Doug on the other hand doesn’t recognize he has an impediment he’s just struggling to to get his work done. The impediment here is subtle, it can either be: Doug is unfamiliar with Unit Testing and needs help to learn or some knurly legacy code that isn’t unit testable as it stands. In either case Steve needs to understand what the problem is so he knows what kind of help Doug needs.

We will help Tonia and Doug resolve their issues in a few minutes but first lets equip Steve with some simple impediment removal tools. Once an impediment has been raised we need to make it visible. The best way to do this is to maintain a highly visible list in an area on the team’s task wall. (N.B. a wiki or other online tool isn’t considered highly visible.) Impediments that involve individuals should be written to remove the focus from the person and put on the issue, example instead of “Doug needs training for Unit Testing”, “Training for Unit Testing”. Along with the change in focus it also recognizes that Doug is probably not the only one with the issue. Impediments that can’t be easily fixed just by making them visible and doing some work should be raised in the next retrospective. During the retrospective the team can spend more time planning to tackle the issue.

Scrum will discover many organizational impediments that can’t be resolved quickly, it is important that we acknowledge these impediments and don’t just sweep them under the rug. In addition we can’t just say “That will never change, that’s just the way we work”. This is the hard part of Scrum.

Back to the Story

Right after the standup Steve goes and talks to Doug. He discovers that while the legacy code has issues, Doug has very limited experience writing Unit Tests. They sit down together and write up an impediment card that identifies the issue without Doug feeling like he is being singled out or attacked. Steve also writes an impediment card for the test server issue. Steve invites Tonia to join him in tracking down someone from Operations to find out what the test server problem is. Operations reboots the server but suggests the problem is systematic and that they don’t have the time to investigate. Later in the day Don (Steve’s Director) walks into the team room and reviews the impediments list. Talking to Steve he discovers that the Test Server has become a recurring problem, he promises to start digging from his end to find out more about the deeper issue. Don also promises Steve support in getting books/training around Unit Testing if that will help Doug.

Analysis

By making even subtle problems highly visible the team is able to resolve problems faster. Sometimes the help to remove these problems comes from unexpected places in this case Don, but it could just as easily have been someone else who walked into the team area and offered to help. For example seeing the need for help around Unit Testing maybe someone from another team would volunteer to help.

How does your team address its impediments? How does it make them visible?

Image via: Freepik

Scrum By Example – Learning How to Estimate

Wed, 27 Jun 2012 00:00:00 GMT

Hand of cards - - image licensed from Photodune

Scrum By Example is a series of stories about ScrumMaster Steve who is the ScrumMaster for the WorldsSmallestOnlineBookstore.

Product Owner Paula has learned from her past mistakes (See Not Ready for Planning) and she now holds Backlog Grooming/Refinement Sessions whenever she has enough Stories to be worth Estimating (typically every 2-3 Sprints). During these meetings, team members estimate New Stories, split Large Stories, and develop Acceptance Criteria.

With 10 new Stories and a couple of “Epics” that need to be split, Paula has scheduled a Grooming session for the middle of the Sprint. She has invited all the team members to attend; Kirby (see New People on the Team) comes but is grumbling, “I don’t see the point in this. It’s just going to waste precious coding time. Why can’t this just happen in Sprint Planning?” (Editor – Kirby hasn’t quite found his rhythm yet). Paula reminds the team that the meeting exists so the team can ensure that Product Backlog is well prepared for the next Sprint Planning meeting. In addition, it helps her understand how much of the backlog they can realistically complete before the next release in three month’s time (Editor – yes they have infrequent releases).

She asks that they start estimating her first new story: “As a frequent book buyer I want the store to remember me so I can add books to my shopping cart without having to login.”

Team members start asking questions requiring clarification:

Is it okay to leave a cookie behind? Paula -Yes, although it will need to comply with our privacy policy.
Ian asks, “Are there any other technologies to consider?”
Does this include being able to see the book in the shopping cart? Paula - No.
What if we don’t have accounts implemented when we start this story? Paula - Then just use a fake/sample account for now.

When the questions peter out, Team Members begin flipping through their Planning Poker™ cards (I will have some for my readers soon),looking for the right numbers. Kirby just looks around in confusion. Nobody had checked to see if he understood the estimation process. There was a pause and Scrum Master Steve asked, “What do you know about our estimation process?” The reply was, “Nothing.” Steve asked if he understood the flaws of traditional estimation – Kirby was sure he had this one down cold, “Yeah, you need to double the figures and then add a fudge factor, but never tell the developers otherwise their work will expand to fit the time available.” There was some nervous laughter, as Kirby has had trouble fitting into the team in the past (see New People on the Team).

Analysis

What are Steve’s options at this point?

Explain Agile Estimation from scratch – snoozefest for the rest of the team.
Ask Kirby to sit out and watch – better – but we learn more by doing than watching.
Explain the bare minimums to Kirby and invite him to participate.

As usual Steve doesn’t take my advice and forges his own path.

Story

Steve decides to explain the flaws with traditional estimates.

At best they’re in ideal days – which is a problem because management will often assume that a normal day is the same as an ideal day; as humans we’re not adept at estimating in time; estimates in ideal days decay as the team gets better at doing its work.
Experts do the Estimation (at best) or sometimes it’s the Project Managers (not all of whom have development experience). However, experts are the people who have forgotten many of the details it takes to get the work done.
Estimates are only valid for one person – the Estimator.
They miss the chance to sample the diverse ideas of the Team.

Instead Steve explains that we use relative estimation. All stories are compared to an existing gold standard much like the original metre stick. This “standard story” is arbitrarily given a size of ‘2’. In addition the team have also selected a story approximately 4 times larger and made it an ‘8’.

Editor’s note

When coaching new teams, I suggest stories of size ‘2’, are very small. I expect the typical team to complete 5-10 stories of this size during a Sprint. Stories of size ‘2’ should have few unknowns. When they pick the prototypical ‘8’ I suggest this should be a story that isn’t completely understood and still has an unknown or two.

Story

Now Steve says, “Instead of more explanations, let’s just start Estimating.” Someone hands Kirby a set of estimation cards with values 0, 1, 2, 3, 5, 8, 13, 20, … . Steve suggests that anything over 20 is too big and will need further splitting (Editor – Anything over 13 is too big). Paula rereads the first story: “As a frequent book buyer I want the store to remember me so I can add books to my shopping cart without having to log in.” Steve asks if everyone is ready with their first estimate. First round results:

Tonia	Brad	Martin	Doug	Ian	Kirby
5	3	13	5	8	8

Steve asks the low (Brad) and high (Martin) estimators to explain their thinking. He also starts a 3 minute countdown timer on his iPhone. Brad leads off by saying,“This is a very simple standard shopping cart feature; it’s exactly the same thing I did when I worked on ShopMore; we just have to use a standard shopping cart.” Martin replies, “Yes, we can use a standard shopping cart, but the last time I used the ShoppingKart engine it required a lot of small changes to our database.” Ian points out that ShoppingKart have updated their engine since then and the new version claims to be easier to use. Steve asks the rest of the team if they want to ask any clarifying questions, when the answer is no, they estimate again:

Tonia	Brad	Martin	Doug	Ian	Kirby
8	5	8	5	8	8

Again Steve asks the low (Doug) and high (Ian) Estimators to explain their thinking. This time Ian says, “While it’s been improved, ShoppingKart always present problems,” and Doug says, “I’ve solved this same problem before at another Ecommerce site – it was pretty easy.” Steve calls for a third round of estimates. Little has changed from the last round; the numbers are 5 and 8. Kirby says, “Why not average the numbers?”

Analysis

An image of two architects' hands doing work - image licensed from Photodune

What are the team’s options at this point?

A difference of one size, i.e. 5 vs. 8, or 8 vs. 13, isn’t meaningful. But a difference of two steps, i.e. 5 vs. 13, is meaningful. Editor: In this case the team could easily just pick one.
Averages lead to arbitrarily precise numbers – a precision that doesn’t really exist. In addition, averaging takes away the power of the individual voice.
Just pick ‘8’. Agile estimation is trying to give equal voice to all opinions; when we pick the largest number we’re saying the other opinions didn’t matter.

In my experience the best thing to do is set aside the story until the end of the estimation session. Often when we return, its size is now entirely obvious when compared with other stories we’ve estimated since. Finally if there is still no agreement, this is telling the team there is uncertainty in the problem. Coming up with an estimate is papering over the uncertainty. Instead, I recommend the team schedule a Spike: 1-2 days rapid work on the problem, the goal of which is to help the team explore the boundaries of the problem and come up with enough information to produce an estimate. A Spike is committed to, the same as any other work in Sprint planning. When you do run a Spike, you should appreciate that the result is almost always throwaway code.

Tips

Story Points are self-calibrating so it does not matter precisely which ‘2’ and ‘8’ the team pick, just as long as they’re used consistently.
Blind estimates are important – no one shares their estimate until everyone is ready, otherwise people will naturally follow the senior team member’s lead.
Many ask the question, “How can I make our estimates more accurate?” Don’t spend the time on that; estimates are only useful for answering the question of, “Roughly when will we be done with this list of features?” Focus improvement efforts on getting better at doing the work, i.e. learn Test Driven Development and make your build run faster.
Timeboxing the discussion in Agile Estimation is critical, otherwise the team can get bogged down when there is already broad agreement. Timebox the discussion to 2-3 minutes per round.

With Estimation the focus is on how big the thing is that we’re building, but an additional benefit of the process is that team members gain a much deeper understanding of the system they’re building.

What have you learned from your Estimation Process? What Estimation tips do you have?

Images via: https://photodune.net/

Scrum By Example – New People on the Team

Wed, 11 Apr 2012 00:00:00 GMT

playing in the sandbox - image licensed from Photodune

After six months ScrumMaster Steve has finally found someone to fill the role of Senior Software Developer on the team. The goal is to find a person who can round out the team and play many roles (see: Bottlenecks). After many interviews, they’ve settled on Kirby¹ who has over 20 years’ experience developing software, both server-side and GUI. He is a self-proclaimed expert in most of the technologies the team uses, and that’s where the problems start. In addition, the team members assume that he is being very well paid, perhaps better than any of the rest of them.

Attempting to learn the basics of the code base in his first few Sprints, Kirby takes on GUI, Middle tier, Server and Testing Tasks. He asks his teammates for code reviews and the code is pretty good, however it becomes clear that he can be touchy on some subjects and isn’t eager to receive negative feedback. On the subject of feedback he says, “I’m a Senior Developer, I don’t need to learn from you, it should be the other way round.” At first the team just try to accommodate his needs, but after five to six weeks, tensions begin to rise. Ian (the Middle Tier guy) feels threatened; he sees Kirby trying to occupy the niche he has occupied on the team. To compensate, Ian spends more time doing server side work, which in turn causes Doug some concern. Even Tonia feels a little bit threatened as Kirby starts doing some automation work.

Seven weeks into Kirby’s tenure, during a daily stand-up (Daily Scrum), he is describing his work to display book prices in the local currency when Ian (usually a calm individual) blurts out, “He’s stealing my work”. Steve swings into action saying, “Ian, thanks, this seems important, could we discuss after Standup and let Kirby finish?” Ian agrees sheepishly. Steve turns back to the team and just says, “Why don’t we pick up again with Kirby.” After standup, Steve grabs Ian and says, “Let’s go out for coffee.” Over coffee they chat, and Steve hears Ian’s view on the situation:

Kirby isn’t open to suggestions or comments about his code
Kirby is pushing him out the work that he does regularly
Kirby often denigrates the quality of the existing code
Kirby makes it clear that the other developers should be learning from him

After coffee with Ian, Steve goes for a walk with Kirby to hear his point of view:

Kirby sees that the code doesn’t have the quality (see Technical Debt) he would expect of it
Kirby is aware that he’s sometimes seen as pushy and isn’t sure how to solve that problem
Kirby understands how Ian feels push aside but isn’t sure that this is his problem to help solve

Steve spends the rest of the day buying coffee and tea for the rest of team, talking to one person at a time. While they don’t feel as much pain as Ian, they feel some of it.

The question is what to do now?

Analysis

First and foremost, Steve can’t take sides here. He can look to find the positives he sees going on, but can’t champion anyone’s viewpoint. As soon as he starts to do that, he will erode his credibility as a neutral ScrumMaster. The best he can do is get the various players talking and see if they can resolve the problem. To see some of the problems here, read Brian Buzzoto’s “Watch for Triangles”.

My viewpoint as Editor: Many of the things Kirby is doing - working across the code base, doing testing work, writing unit tests, generally raising the code quality - are good for the team. The problem is that in doing this, he comes across as a know-it-all.

The key here is remember Tuckman’s Model of Team Formation (Forming, Storming, Norming, Performing). When even a single team member changes, the team reverts to Forming, and after seven weeks they’ve rediscovered Storming. The Storming part of process can’t be avoided, skillful ScrumMastering aka interference, in fact interference makes it last longer.

Story

The next day Steve gets Kirby and Ian to sit down and talk. He sets out ground rules: talk about your feelings, talk about events, use “I” statements not “You” statements. He suggests the goal isn’t to solve any problems today, just understand how the other feels. Even if they still disagree, they need to understand the other person’s viewpoint. In future, Ian suggests that checkin every day with how their working relationship is with the other person.

… The story could/should continue for weeks. At this stage let’s assume that they’ve at least started to understand each other. Maybe we will see hints of this story in future posts.

Analysis

It’s striking that this problem occurred in part because the team weren’t involved in the interview process. Hiring well is a very difficult problem, it’s even harder when the people who will spend the most time with the new hire haven’t met them before. I find it very effective to involve team members in the interview process.² I would even get the potential hire to pair program with the rest of the team as part of the interview. There is nothing like a few hours of coding (spread across the entire team) to get a sense of what working with them will be like.

Images via: https://photodune.net/

Footnotes

Any resemblance to the author of this blog is purely accidental as Kirkby is a fiction of my imagination. ↩
To make this work, the team need some basic interview training so they avoid the various legal pitfalls. Ragnwald had some great examples recently in: “I hereby (fictionally) resign” ↩

Scrum by Example – Overtime on a Scrum Team is an Unhealthy Sign

Sat, 01 Mar 2014 00:00:00 GMT

clock-arms-Freepik

Scrum By Example is a series of stories about ScrumMaster Steve who is the ScrumMaster for the WorldsSmallestOnlineBookstore.

Dramatis Personae

Steve: A ScrumMaster and the hero of our story

Paula: The Product Owner of Steve’s team

Don: Director of Development

Kirby: new guy with 20 years experience, knows both business logic and JavaScript/GUI

Martin: Database Developer

Doug: Front End Developer

Ian: Business Logic programming specialist

Ellen: Chief Executive Officer

Things have been going well for our ScrumMaster Steve and the team as they build out the WorldsSmallestOnlineBookStore. The team is ramping up towards their first public launch and, in the past week and a bit, they could feel the tension increasing.

Three weeks before the scheduled release date, Ellen, the CEO, comes to the team’s Daily Standup (without asking permission first). At the end of the standup she says, “It’s really important for this release to be a success. I want to see lots of overtime in the next three weeks and no slacking. Everyone must be busy.” After her speech, a few people mutter “Okay,” and then the team quietly walk to their desks.

For the first week the team manage to deal with the added pressure, then Ellen has her bi-monthly meeting with the investors. The investors say it’s not acceptable for the product to go to market with only one credit card supported (currently Visa), nor is it okay to do a soft-launch in Canada first. The site must be able to ship anywhere in North America.

Ellen returns to the team room and she is clearly on fire. She interrupts the working day to announce the additional requirements. “I realize this will be hard and there will some additional work but our investors think these changes are critical. Save time, stop writing those Unit Tests or trying to do any other engineering stuff.”

Steve and Doug try to warn Ellen of the damage this will cause, but Ellen says, “Damn the torpedoes, we’ve got to get this out there. These two new features must get in, but don’t drop any of the existing features. They’re all priority one.” In a panic, the team just start work. Of course the team aren’t able to release after two more weeks with sixty hour weeks. In fact, they’re struggling to release six weeks after the investors meeting.

During the overtime period:

Thirty new defects were written, more than in the previous three months.
Ian spent most of week working on supporting Amex as a credit card, before Ellen decided it wasn’t as important as MasterCard/Visa support. So the feature got dropped but the code was left in the system.
Ian’s code for the Amex feature created a bug in the previously working Visa feature that wasn’t noticed until after the release because the team had stopped working on updating the existing automated acceptance tests.
Most team members stopped collaborating, and as a result Kirby misunderstood and spent several days writing server code that didn’t fit with a client side code that Doug was writing.
Tonya got sick.
The late hours were having a significant effect on Martin’s family life. He walked into Don’s office (Steve’s director) and threatened to quit if the overtime didn’t change soon.

The release finally went live after six weeks, but instead of the rave reviews the team hoped for, users gave the store mixed reviews. They liked the basic system but found it had many bugs and subtle usability issues.

Analysis

Why did a little overtime cause all these problems?

Overtime - never hurt anyone

Some key causes:

Focusing on 100% utilization of team members (Ellen’s comment – “no slacking”) ensured that when people didn’t have an obvious high priority user story to work on, then they would do anything to look busy. It turns out that systems (both human and mechanical) that are run at high utilization rates become fragile, inflexible, and error prone. (For more detail see Steve Gamble – The Importance of Slack)
Lacking clearly defined priorities, all the work got started at once. Later on when it was decided that Amex support wasn’t as important, a week of Ian’s time had been wasted.
With all the features being started at once, there was limited collaboration and no swarming. Limited collaboration meant that defect rates went up since there were fewer brains involved in each design decision.
When there is a lot of work in progress, multi-tasking becomes the norm. After every context switch (i.e. moving to a new task, even answering an email) it takes 20-25 minutes to regain the highly productive state of work called flow that high performance teams seek to achieve. In addition, error rates go up in part because we don’t always correctly remember the context of a task when we switch back.

In a case like this, it often boils down to the CEO not having a good understanding of the Product Backlog for the team. In addition there is no map of the overall portfolio to help make the choices clear. Lacking better information, Ellen believed she could just keeping demanding more output with few consequences.

How could Steve have handled this better?

The day Ellen first came into the room with the demand for overtime (before the investors meeting), Steve could have taken her aside later in the day and discussed the costs. The simplest explanation might have been that any system has a “hull speed”, i.e. a maximum speed that can achieved without dramatically increasing the amount of effort. Adding more pressure won’t make a significant difference to the speed and in some cases just risks damaging the hull. Instead of overtime, Steve could have suggested this would be a good time to reinforce core hours, shutdown outlook for most of the day, and cancel most meetings outside of the team. They could even tell the company not to interrupt the team at all during the core hours. All of these changes have the goal of giving the team members more focused time.

When the investors demanded more features in the same timeframe, Steve and Product Owner Paula could have shown Ellen the product backlog as it stood. They could have asked her what she would either drop completely or delay until after the release to achieve the new goals. In addition, they could have asked her for the priorities of each of the new items. Even during a crunch, the team would still benefit from spending a couple of hours doing backlog refinement with the new features. This would ensure that the team members have a common understanding and get at least minimal acceptance criteria for each. This would increase the chances that team members would collaborate during the crunch period.

In the future, Ellen would benefit from seeing a map of the overall project portfolio of the work in flight and queued - a portfolio map that gets updated every few weeks so she always has recent information to share with the investors. In addition, it would help with realistic expectations management.

But those positive Scrum practices didn’t happen for our hapless team this time, and instead they will spend the better part of the next three to four months undoing the damage of the overtime.

For a broader look at the different types of interruptions that harm teams and practical strategies for each, see Unpacking Interruptions: Why Your Team Struggles to Get Things Done.

Clock image designed by Freepik. Remaining image by Agile Pain Relief Consulting.

Scrum by Example – Stop Digging New Holes

Tue, 28 Feb 2012 00:00:00 GMT

Yellow vector working sign - image licensed from Photodune

The first law of holes is “When you’re in one, stop digging”. In the last sprint the team discovered that they’re in a hole – in this case they had dug themselves into technical debt.

We join the team this week in their Sprint Planning session as they start by rechecking their Retrospective action items:

Respect the “Definition of Done” – write Unit Tests (their complete “Definition of Done): Checked In, Peer Reviewed, Unit Tested, Manually Tested)
Temporarily add Unit Test column to their story board
Install Sonar (a platform to help visualize Code Quality) to help improve awareness of Code Quality and Technical Debt
Spend 20% of their time in the next couple of Sprints to tackle Technical Debt Issues (Ed note: From experience this seems a bit low for teams that have accumulated a fair amount of technical debt, but the team will have to learn on their own)

They start by discounting their historical velocity (currently at ~20 Story points) by 20% to account for paying down the Technical Debt (16 Story Points). Then they recheck the “Definition of Done” for each story they’re about to commit to. At this stage Product Owner Paula pipes up to protest that all this focus on technical debt doesn’t help her get features out the door. She’s concerned the CEO will be banging on her door soon. Doug explains that if the team doesn’t start to tackle the technical debt now, the delivery of new features will slow down even more, while the bug count rises. He explains that the next 3-4 sprints will be rough as the situation needs to be stabilized (Ed: He’s optimistic) . ScrumMaster Steve reminds Paula that she is responsible for the product that the team delivers. In turn the team is responsible for deciding how much they can deliver and for ensuring its quality. Paula raises the flag of surrender but says she is really concerned and wants to revisit this two sprints from now.

Once the planning actually gets going, the team finds that they can’t even commit to 16 Story Points of work. They realize that it will be hard to write Unit Tests for some of the new stories. The team commit to installing Sonar and then look at the Technical Debt Backlog for key items. Based on what they’ve picked up from “Laurent method” they’ve found a few large files that change frequently. They’ve discovered that several of these are 10,000+ line “God/Monster classes”, the class that everything else hangs off. When something small changes in these classes, it ripples through the entire code base.

After the Sprint Planning Meeting, Steve modifies the Story/Task Board to look like:

Scrum Story / Task board

Adding the “Definition of Done” at the top (permanently) and a “Unit Test” column (only until Unit Testing becomes a habit).

Screenshot from Sonar's own Nemo

After having some fun looking at the worst violations, they come to realize that the default configurations of PMD can be very noisy (with warnings for method name too long and too short). They quickly decide to load up PMD in Eclipse and make a first pass at simplifying rules. Even after simplification they find the code base still has over 10,000 rule violations. They agree to raise the issue in the next Daily Scrum. They also decide to write a short note to the team explain which rules they dropped and why. In addition they discovered that their existing Unit Tests only provide 10% Code Coverage.

Day 2 During Daily Scrum – Ian describes what they’ve learned from installing Sonar and trying to configure PMD. After the meeting the developers have a five minute chat to agree on a strategy to handle the PMD issues. They agree just to eliminate PMD warnings as they work on a class. When there are too many warnings to eliminate in one sitting, they agree to at least chip away at some and create a technical debt card/postit to capture the bigger issue(s).

Day 3 Splitting the God/Monster classes proves painstaking and slow, first the functionality has to be moved to a new class then that class has to be passed in to all the places it’s required, …, finally test cases need to be written.

…Ed we could keep going but it’s clear that the process is slow and painstaking. Let’s take a step back and find some options for the team.

Analysis

I happen to know that the team haven’t got a lot of experience with Unit Testing or Restructuring Legacy Code. Let’s give them some reading/study options. From experience I start with the simple Unit Testing before growing them to Test Driven Development (and beyond):

Unit Testing in Java (Manning MEAP) – Lasse Koskela (early access as the book isn’t completely finished)
The Art Of Unit Testing (Manning) – Roy Osherove (.NET)
Pragmatic Unit Testing in C# (Pragmatic Bookshelf) – Andy Hunt and Dave Thomas with Matt Hargett

Once they’ve mastered the basics they will need to start thinking about how to make the larger scale changes that will be necessary. Good reading choices here include:

Working Effectively with Legacy Code - Michael Feathers – its from 2004, but the problems the book helps you solve remain the same
Mikado Method (Draft PDF) and Book Wordpress Site - Daniel Brolund and Ola Ellnestam – while still in draft the book looks close to being finished.

In the course of breaking dependencies in the legacy code, the team will likely find a mocking framework handy. In the world of Java things have evolved a lot in the past few years:

MockIto – uses a literate style (my personal preference) without also requiring states i.e. recording/playback so I would definitely take it out for a test drive
PowerMock – promises to handle some of the difficult things to mock (statics, final, etc.) in legacy code
JMock hasn’t had a release in a couple of years but is probably still worth a look

Story

By end of the Sprint the team have completed the Stories they originally committed and they have made some of the Monster classes a bit smaller, and the team realize the size of the problem. They’ve also started to do some of their reading and appreciate the tools that they have available to solve their problems. In addition, since they’ve got Sonar installed they can already see some of the improvements.

With a spot of luck perhaps in the next few sprints they will make their codebase marginally cleaner and easier to work with.

First image via: https://photodune.net/. Remaining images by Agile Pain Relief.

Scrum By Example – Story Splitting Fun

Thu, 19 Jul 2012 00:00:00 GMT

Different colors sliced apple - image licensed from Photodune

Picking up from: Learning How to Estimate

The team are still in the Backlog Grooming/Refinement session. They’ve estimated a heap of stories and spotted several that need better Acceptance Criteria. However, there are several stories that Product Owner Paula would like to have worked on which are too large to commit to in a single Sprint. While they could estimate the Stories as they are, this seems like a waste of time. They’re better off getting out the scalpel and splitting the stories into smaller parts.

First a quick reminder from – Why Split User Stories:

Why not just give the team large stories that span iterations. Why slice those stories into smaller parts? A number of reasons:

Small stories provide focus and a short horizon for the team. It’s easier to get lost in the details with a larger story.
When you still have development to test handoffs (i.e. before you start doing ATDD (Acceptance Test Driven Development), smaller stories enable more frequent handoffs and allow testers to work on smaller chunks of code.
Small stories give you the flexibility to reconfigure and adapt to new discoveries or changes. Perhaps the PO discovers that an existing story is now irrelevant; or while coding you discover a surprise. Small stories make it easier to adapt.
Small stories provide more feedback opportunities at all levels of the system and more opportunities for personal satisfaction; think of the small dopamine rush that happens every time you complete something!
Large stories increase the risk that your team will deliver nothing at the end of the iteration.
Your team has a capacity like a drain pipe and just like a pipe the larger the object you try to push through it the more likely it is that blockages and bottlenecks will occur. Perhaps one person who is tied up in the large story may also be the only person who can complete a key piece of another story.

Story #1: “As a first time book buyer I want to find the perfect mystery novel so I can while away the time on my next plane flight”. Size: 100

Brad makes the quip that this appears to be the core of the website in a single story. (Mark L. - Early on in our story writing career this often happens. We write large chunks of our product in a single User Story. Rather than trying to avoid it, just get it out and then split it.)

After they finish laughing, the team get involved in discussion around the parts of the story. In the first round the discussion focuses on the database (Pythia 22x); how difficult it will be to get right; what the right format for the staff reviews would be; and how to get a book home in time (FedEx vs. UPS vs. Purolater). They crank out some new stories:

As a first time book buyer I want to find the perfect mystery novel quickly with an Pythia 22x database
As a first time book buyer I want to have my perfect mystery novel shipped home via FedEx so I get it in time for my next flight
As a first time book buyer I want to see the star rating on a review before I read it so I can see whether the book is worth reading
As a first time book buyer I want to select my book and place it in the shopping cart so I can buy it
….

Analysis

Most of these revised stories have in common a focus on technology vs. solving the need of the end user. A User Story is “a single sentence that describes a small piece of valuable functionality from the point of view of the end user”. Real end users don’t care about our database technology nor our shopping carts. They just want working software. By writing User Stories from their point of view we delay making technical decisions until it’s useful from the Point of View of the application.

Story

Scrum Master Steve reminds the team to place the focus on the value for the end user; in this case, the “first time book buyer” and not the technology.

In their next attempt the team break the stories down:

As a first time book buyer I want to find the perfect mystery novel by reading staff reviews so I won’t waste my money reading bad books
As a staff member I want to enter book reviews so I can delight book buyers
As a first time book buyer I want to see only books that get five star reviews so I don’t waste my time reading reviews about weaker books
As a first time book buyer I want to select a single book for purchase so that I can read it (Mark L. – the team have elegantly avoided solving the whole shopping cart problem for the moment by handling just a single book. Clearly they will later need to handle multiple books but if they can’t get one book home they can’t get more home).
As a first time book buyer I want to ship my book home within two days so that I can get it before my next flight

The team estimate the revised stories, this time most of them are reasonably small except: “As a staff member I want to enter book reviews so I can delight book buyers” which is estimated at size 20 (they started off at 40). Paula says at first it would be fine to support only plain text and a star rating. The reviews wouldn’t have to be updated once written. She’s willing to offer a lot. Nonetheless the team say it’s a large problem to enter text, save it in the database, and display it on the book page. Paula asks the team, “Can we display the reviews first and solve the problem of entering them in the system later?” “Ludicrous,” says Martin, “What’s up with that? How can we display reviews before we even have the text? Even if we could, we need to get the database right.”

Paula explains that she needs to talk to the Product Steering committee in the next few weeks. Her goal is to have a Minimum Viable Product (i.e. a down payment on the vision) in place. To get continued funding for the product the team needs to be able to demonstrate the basic flow for the “first time book buyer”, i.e. Read a review –> Buy the book –> Ship the book home. While the reviews need to exist to demonstrate the product we can live with reviews that were entered directly into the database. Paula goes on, “For the next couple of Sprints I could even live with fake reviews if that helps. It’s about being able to demonstrate the basic experience whilst not having the back end working right now.”

If the product gets continued funding from the steering committee’ then they can decide how to flesh out the support for staff reviews. After some more discussion the team come to see Paula’s point of view. They write a new story: “As a first time book buyer I want to read staff reviews that are displayed on the book’s page so that I can buy the perfect mystery novel.” After a couple of rounds of Planning Poker the team agree to estimate the story at 5 points.

Analysis

In this case Paula was trying to get the team to consider “Independent” from INVEST (Bill Wake’s criteria for good User Stories): “Dependencies between stories limit the flexibility of both the Product Owner and development team. The Product Owner should be able to ask for stories in whatever order they make sense.” When the team said that they needed to write the staff side of the review system before displaying any reviews they were taking prioritization over from the Product Owner.

N.B. If the dependency is just around sizing/effort then it’s okay for the team to say, “This type of story requires a templating engine; the first one will be sized 13, all subsequent stories will be sized 2.”

End Story

Image via: https://photodune.net/

Scrum by Example – Stuck Waiting for Other Teams

Fri, 29 Aug 2014 00:00:00 GMT

Speed Bump Sign - free image from Pixabay.com

Getting stuck waiting for people outside your Scrum Team? Let’s use our fictional Scrum by Example team to explore how to handle this situation.

Dramatis Personae

Steve: A ScrumMaster and the hero of our story

Steve (ScrumMaster) and the team are humming along nicely building great new features for the SmallestOnlineBookStore. With the huge success of the first big release nine months ago, venture capital money has come flowing into the company. Significant investments have been made in Operations, Security, and Networking in addition to creating several new Development Teams. Unfortunately, all these new people are making it more difficult for the team to get the software they built deployed.

The new groups are often imposing their own reviews and processes on the software before it’s deployed. Some changes are going to increase the load on the network and require review by the network team. Other changes affect the payment gateway, backend administration, and the services team who have a lead time of three weeks. All of these reviews, while increasing safety, have greatly slowed the delivery of new features.

The Development Team is getting frustrated because they feel their work is slowed artificially by the teams downstream of them (i.e. Networking and Security). The customers are getting annoyed because the previously great flow of features has slowed down to a crawl.

In addition, the team has created a Work in Progress (aka WIP) of one story per developer. This is both exacerbating and revealing the problem. It’s exacerbating because the team doesn’t have background to work on whenever their main task is stuck. It also reveals that the real problem isn’t at the team level where the work is getting to “almost” done.

Steve creates a short list of options for the team: Increase individual WIP limits to 2; Change the Definition of Done so that Security and Network reviews aren’t part of Done; Add a column to their Scrum Task Wall to account for both other groups and start working with the other departments to clear work more quickly.

Analysis

Before we explore options in a situation like this I prefer to gather data. The best way in this case would be to create a Kanban wall that tracks the progress of a Story from initial idea to the moment it’s deployed and is delighting customers. This, combined with a Cumulative Flow Diagram, will help the source of the Team’s stress.

Steve, being aware this might be an issue, has been tracking the data for just over a month:

ScrumMaster_Tales_-_Stuck_Waiting_for_Other_Teams_data_table

From the data we can produce a Cumulative Flow Diagram that looks like this:

ScrumMaster_Tales_-_Stuck_Waiting_for_Other_Teams_CFD_chart

So what does this chart show? The team isn’t the bottleneck in this case. A simple test I use to tell is this:

“If we had a magical way to double the rate at which you deliver stories/features, would that make any real change in the rate at which customers get the features?”

At the development team level - Code, Code Review, Testing - clearly that isn’t the case, the bottleneck is in “Done in Development”, which is really just a buffer, and Network/Security review. Rather than make changes at the team level, we need to see what we can do to optimize the downstream work.

Based on this data, let’s re-examine the team’s options:

Increase Individual WIP Limit from 1 to 2 - This really just masks the problem giving something else for someone to work on when their original item is stuck in Network or Security. As we’ve already seen the limit isn’t at the team level, so optimizing there won’t help.
Change the Definition of Done so that a Story is considered Done when it’s handed off to an outside team. - This doesn’t really help the customer since the item still isn’t deployed, it just makes each individual developer feel better. However, in creating an additional column for the downstream groups, we have effectively created a Definition of Done for each column. Kanban calls these “policies”. So we have changed “Done” but only in the name of making our problems more apparent.
Add a column to the Scrum Task Wall - We didn’t quite do that, instead we created a Kanban wall that acknowledges some of the work is beyond our team’s span of control.

So let’s add a new option:

Start working with the other departments to clear work more quickly - In a Kanban oriented world, teams swarm downstream blockages. This would definitely be a good idea in our case.

Were I coaching Steve, I would get him to setup the Kanban tracking wall with the other teams and departments so that the entire company gets a view of where the work stands. I would invite people from each group to come update the wall every couple of days. By getting their involvement in set up and tracking, people from the other teams (i.e. Security and Networking) will appreciate that the data reflects their world and they will be more open to acting on the data. In addition, Steve (and his team) will gain greater insight into what is affecting Networks and Security - perhaps the company was suffering from a Denial of Service attack at the end of June and for a few days both teams were pulled from reviewing to handle the operational problem.

The team might also discover that they’re found to frequently be violating security practices. In this case, mentoring from Security might increase the team’s level of skill in this area, and reduce time spent in the review phase. Very often in cases like this, cross-training the team (see: The Team Gets Bottlenecked) to help reduce the downstream bottleneck will help, however we won’t know until we’ve gathered data and worked with the other teams to find out what the real problem is.

As an aside, I don’t recommend individual WIP limits when working as part of a Scrum Team - instead focus on the WIP for the entire team. It’s a small change, but it makes it clear that the productivity of the team is more important than that of any one individual.

First image from Pixabay.com. Remaining images by Agile Pain Relief Consulting.

Scrum By Example - The Team Collaborate on Acceptance Criteria

Tue, 05 Feb 2013 00:00:00 GMT

Group of people - licensed from Photodune

The team has just completed Sprint Planning, committing to four stories:

As a first time book buyer I would like to read a review so I can see if a book is worth reading.
- A review has text and isn’t empty
- A review has an author name
- A review has a title
- At most a review is 2500 characters long
As a first time book buyer I would like to see a star rating associated with a review so I can quickly assess if the book is even worth thinking about.
- Rating from 0 to 5
- No ½ stars
- Rating appears at the top of the review
As a first time book buyer I would like to see reviews by staff members marked separately so that I know whom to trust.
- The word “Staff” appears in bold before the reviewer’s name
- All reviews posted from computers inside the Smallestonlinebookstore offices will be considered staff reviews (This avoids having to tag users as having different roles for now).
As a first time book buyer I would like to see reviews by friends highlighted so that I know whom to trust.
- …

Right after Sprint Planning, Kirby decides he wants to take: “As a first time book buyer I would like to read a review so I can see if a book is worth reading.” He invited Brad and Tonia to sit down with him and create some examples that illustrated the acceptance criteria to make sure they were completely fleshed out:

A review has text and isn’t empty
At most a review is 2500 characters long
A review has an author name:
- “Mark Levison” – valid
- “mlevison” – invalid – not a proper name
- “Levison” – invalid – we need at least two names
- “C. J.” – invalid – initials alone aren’t enough
- “John C. King” – valid
- “J C King” – valid
- “J. C. King” - valid
- A review has a title

After 30 minutes they think they’ve fleshed out most of the edge cases, and Kirby invites Brad to pair with him as they start writing the first tests. Brad is skeptical, saying, “I’m a BA – how can I contribute while you write code?” Kirby persists, saying, “Let’s just try it for an hour.” Kirby makes a real effort to name the tests to describe the behavior he’s looking to build.

Sample Tests (Java pseudo code):

@Test public void simpleTwoPartName() {…} // Mark Levison @Test public void oneNameAreNotEnough() {…} // Levison @Test public void initialsAloneAreNotEnough() {…} // J. C. @Test public void initialsAndLastName() {…} // J. C. King

While he’s struggling to read the implementation code for now, Brad discovers it’s very easy to read the test code. In addition, his questions help Kirby to better name the domain objects because they’re forced to make sense to a non-technical person.

Kirby checks in as soon as the first part of the review system is completed – in this case just the business logic to process and store a review. That happens before reviews can be entered via the GUI, let alone be displayed with books.

The next day Kirby pairs with Ian as well and drives out the GUI for the story. However, they’re having a lot of trouble with trying to spot the difference between real names and user ID’s, i.e. “Mark Levison” vs. mlevison. Rather than get hung up, he shows Tonia (the World’s Best Tester) what he’s got working so far and asks her to give that a test. While she is open to the idea, she’s still dealing with testing Stories that weren’t tested in the last Sprint. So Kirby asks Martin (Database Guru) if he can pitch in. Martin protests that he has no testing experience. Kirby explains that a rough and ready test by another person is better than waiting. He points out that Tonia will still test the Story; he just wants early feedback. Martin downloads the application from the CI server and fires it up. He remembers hearing about buffer overflow attacks. He tries pasting in over 10,000 characters of text into the review text box. The app crashes. For his next act he tries pasting in all the Unicode Symbols into the review text box. Another crash. He shows Kirby, who laughs and then duplicates the tests and subsequent failures on his own machine. Before trying to solve the two problems Kirby writes two failing Unit Tests. Now he sets about solving the problems. Within half an hour he’s fixed both problems.

Analysis

This time the team is doing better than it has in the past without anyone’s help. Here’s what I see going well:

Working with a minimum of three people to ensure that the acceptance criteria are well understood.
Team members pairing to do the work.
Brad, the Business Analyst, being open to pairing to write test drive code.
Martin being open to trying Exploratory Testing.
When testing, Martin didn’t rely on the code from his machine. By testing with a build from the CI server he ensured that he was testing Kirby’s work, and not his own code.

What seems odd:

Tonia is testing Stories from the previous Sprint and yet the team has claimed they’re complete.
Stories are being written to enter reviews before the reviews can be displayed with a book. That seems odd. It would be better to display the book reviews first. After all, we can add reviews to the system in any number of ways; directly in the database, through an API, etc. These options don’t require a GUI. However the reviews are useless if we can’t show them to the customer.

What do you find odd? What do you take away from the team’s experience this week?

Image Credit: Photodune

Scrum By Example – Technical Debt is Slowing the Team

Sat, 18 Feb 2012 00:00:00 GMT

Cross Skilling is starting to happen and already there are fewer bottlenecks. Steve is starting to have more time to step back from the day to day and look at the big picture. He’s heard that most Scrum teams become more productive over time and he wonders how is team is doing. He pulls up the CFD for the current release:

CFD-for-Technical-Debt-annotated-image by Agile Pain Relief Consulting

and immediately notices that the rate at which stories are being selected has slowed down in the past few sprints. Historically the team has a trailing average of 30 story points a sprint. In the past few sprints they’ve only achieved 25 and 22. Is this drop meaningful? Is it related to the team’s cross skilling efforts? Steve decides to ask the team what is going on. He writes a short note, describing the problem he’s seen (without his own suspicions) and asks the team to reflect on the discovery. After Daily Scrum Steve invites the team members to talk about the problems they see:

Cross Skilling has slowed the team to a small extent
Interruptions are down, so if anything the team should be more productive
Unit Tests aren’t getting written for very often
Ian and Doug report that they’ve spent a fair amount of time in the past few sprints implementing a new story only to find it broke an existing story.
Its also noted that there are several places in the code that have become rather hairy and are difficult to change safely.

Analysis

The team have just discovered Technical Debt (see my article “Technical Debt a Managers Perspective”) or a mess (where Uncle Bob would argue that I misuse technical debt). Either way it would appear that the code is slowing the team down. At the start of the project they appeared too fast but now they’re slowing down. In reality they weren’t really going fast, instead they weren’t ensuring that they were really done.

Back to the Story

Doug remembers reading about the problems of technical debt (aka a mess) recently and suggests that this is probably what they’re starting to see. The team agrees to run a 2 day spike to investigate this issue and they warn Product Owner Paula that this will affect what they’re able to deliver.

Coding Java the team have a rich supply of tools available to them:

PMD – “scans Java source code and looks for potential problems” examples: Dead code, Duplicate Code, missed private and final markers, over complicated code etc.
Sonar – “Sonar is an open platform to manage code quality” – it uses static analysis tools (including PMD), code coverage tools et al to measure the state of the code. It plugs into the CI server and keeps data on an ongoing basis.
Sort – Laurent Bossavit taught us this year’s ago: “getting a file list of all source code files, then sorting that list by (decreasing) file size. I start with the largest source file, and see if there’s a reason it’s the largest”

Doug and Ian decide to use PMD and Sorting by filesize as a starting point, as Sonar takes a bit longer to configure. Each time they find a major issue they take write it down on a large postit note along with some reference information (i.e. the files involved anything else. Ed note the precise format doesn’t matter – what matters is that the developers understand the issue its describing and will be able to guess which stories they might affect in the future). By the end of the first day they’ve come up with over 50 postit that contain noteworthy items (vs. a missing private or final which can be fixed in a few seconds). On the 2nd day they sit down with the rest of the team to prioritize the items using slows us down the most as criteria. During the remainder of the Sprint team members tackle smaller technical debt items (< 2hrs) when the items are related to the story they’re working on.

During the retrospective the Technical Debt problem comes up and the team start to discuss where it comes from. Steve starts by asking the team to review the existing “Definition of Done”:

Checked In
Peer Reviewed
Unit Tested
Manually Tested

A few minutes of conversation led the team to realize that the while most code was peer reviewed, very little was Unit Tested. Perhaps the bigger issue was that they didn’t have a good idea roughly how much of the code was unit tested or if the existing Unit Tests where of good quality.

Their SMART Actions (see: Agile Retrospectives):

Respect the Definition of Done – write Unit Tests
Temporarily add Unit Test column to their task wall
Install Sonar to help improve awareness of Technical Debt
Spend 20% of their time in the next couple of Sprints to tackle Technical Debt Issues

Steve promises to post this above the task wall to ensure that the team sees them.

Next week we will see how the team fare (Ed – I’m stretching this out over several stories because Technical Debt takes time to be weeded out).

Related Blog Entries

AI-Generated Code Quality and the Challenges we all face

Image attribution: Agile Pain Relief

Scrum by Example – Technical User Stories or The Team Try to Pull a Fast One on the Product Owner

Wed, 27 Mar 2013 00:00:00 GMT

Diverging paths - image licensed from Photodune

Scrum By Example is a series of stories about ScrumMaster Steve who is the ScrumMaster for the WorldsSmallestOnlineBookstore.

While working on the FedEx 2-day shipment story Martin discovers some very crufty code in the Foobar class. He doesn’t need to work in the class to complete the story, nor can he see it causing any bugs right now. He doesn’t want to ignore the issue so he grabs an index card and writes “Foobar class is very crufty and it will slow us down later”.

Later in the day the following conversation occurs:

Martin: “We need to rework the underpinnings of the Foobar class so that we can work faster.” Product Owner Paula: “Martin, why is that important? Help me see that.” Martin: “It’s slowing us down. Every time we work in Foobar we spend an extra 20 minutes just trying to understand the mess that is there. If you write a User Story and give us 5 days it will all be perfect.” Paula: “Can I trust you? Will this be the last time I ever hear about the Foobar class? Where should I put this is in the Backlog?”

Analysis

As we can see, there are several problems at play here:

We’re expecting Paula (the Product Owner) who is the business domain expert to make technical decisions.
Martin is making promises they can’t guarantee: “Give me 5 days and Foobar will be perfect.”
User Stories must deliver real value to actual users.
Making this problem a User Story pretends this work has real value, but we’re doing it because we weren’t really done with the original work in the first place.

The Product Owner should be focusing on work that affects the actual Users or other Stakeholders, not technical issues inside the system we’re building.

Instead of bamboozling the Product Owner I find it more effective just to pay an ongoing tax in the range of 15-40% (depending on the state of the code base) and then maintain a separate list of technical impediments/items.

Such a list would include notes like the Foobar class that needs simplifying; tasks such as configuring a CI server or upgrading a test machine, or anything else that the team is doing to help themselves. I wouldn’t bother including small refactorings (less than an hour or two of work); I just do those and get them finished.

In addition, issues like the Foobar class are best addressed when the team is already working in that part of the code or the issues are causing problems elsewhere.

If for some reason you really, really, think you must have it on the main Product Backlog (for reasons I can’t see) then don’t bother writing a User Story. Not everything in the Product Backlog needs to be or wants to be a User Story.

To be clear - the work must be made visible; just don’t try to bamboozle the Product Owner into prioritizing it.

Story Take Two

Martin writes up an index card for the Foobar class and posts in the ‘Technical issues’ list. Since it’s close to lunchtime and everyone is already getting ready to leave, he grabs Kirby and Doug. They debate the priority compared to other issues and decide that upgrading the CI server to get faster builds is more important. They point out to Martin that “Foobar” is in a rarely-visited portion of the code.

Image licensed from Photodune

Scrum By Example – The Team Gets Bottlenecked

Tue, 07 Feb 2012 00:00:00 GMT

Old fashioned glass bottle with cork stopper. - image licensed from Photodune

It’s day four of the sprint and ScrumMaster Steve is studying the Story + Task wall to see how the sprint is progressing. After a few minutes he sees three things that standout:

Martin, the only team member who knows how to make changes to the database, has his name on four tasks that are in progress. Two of those tasks are blocking the remaining work on their respective stories.
Ian, the business logic developer, has his name on three tasks, two of which are blocked by Martin. The other task is blocking continued work on another story.
There are six stories in progress even though the team has previously agreed on a WIP (Work In Progress) limit of 3 stories in progress at one time.

Analysis

The team is currently blocked on Martin’s database related tasks. However even if that bottleneck were resolved they would still be blocked on Ian’s tasks.

The team isn’t respecting its own WIP limits.

Risks

With this many stories in progress, many of them will remain incomplete by the end of the sprint.
Many of the stories require multiple handoffs, example: Brad (BA) –> Ian (Middle Tier) –> Martin (Database Specialist) –> Ian –> … –> Tammy (Tester). Each handoff increases the risks of miscommunication, bugs and other mistakes all due to incomplete knowledge transfer.
The teams lottery number sits at one. I.E. if any of Martin, Ian or Tammy win the lottery and decide to leave the organization the team will struggle because no one else really knows how to play their role.

Story

Steve raises this as an impediment at the Daily Scrum and asks for quick meeting right afterwards. He shares the three observations and asks the team what they think. Team members say things like: “Database work isn’t my speciality/skill” and “I wouldn’t be as productive on that”. As a result they say that they moved onto lower priority work. To get through the sprint without another disastrous ending (see: The Story of an Incomplete Sprint), Steve asks what they can do to offload Martin and Ian allowing them to unblock higher priority work. Among other ideas the team decide:

to temporarily abandon work on the lower priority stories
to pair with Martin and Ian to get the higher priority stories sooner

During the retrospective the team focused on the problems with only one team member being able to do certain key tasks (Database work, Business Logic). Rather than address it piecemeal Martin suggests that they create a Skills Matrix.

That shows the inventory of skills across the team. (Ed note – when I facilitate one of these we spend 15-20 minutes coming up with a list of potential useful skills for the team). After an hour of work the team assembled a matrix that helped spot many areas where they only had one person who could do the work. It turns out the gaps are larger than can be addressed in the next couple of sprints, so the team decides to focus. They choose:

Grow Database Skills so at least three team members can make database changes without requiring Martin to oversee all aspects of the work.
Grow understanding of the Business Logic so that coding team member can work safely in that layer without requiring Ian’s help.
Teach all team members the rudiments of Exploratory Testing so that stories are tested sooner and developers get earlier feedback on their work. Tammy will receive an additional benefit because most Stories will really be done by the time they reach her. (Ed Note – they still haven’t discovered ATDD, BDD or even TDD yet).

To grow skills in those areas they agree to us a mixture of pair programming, interactive workshops and one on one coaching. While these activities will slow the team down in the next few sprints, the benefits of getting higher priority work done faster will soon out weigh.

Finally the team posts the skills matrix in the team area and commits to revisit it in six to eight weeks.

Images via: https://photodune.net/

Related Blog Entries

GenAI, Systems Thinking, and Team Problems

Scrum By Example – The Team Learn How to Learn

Wed, 28 Mar 2012 00:00:00 GMT

dark dojo - image licensed from Photodune

The Team is struggling to pay off the Technical Debt (or mess) that they’ve spent the last six months accumulating. They’ve started to institutionalize writing Unit Tests (by adding it to “Done”) and they’re using Sonar to help track Code Coverage, PMD warnings, et al. (Ed: Don’t take Sonar or any other measure as more than a first order view of the code. It hints where you need to look, no more).

Story

During the Standup Ian reports that he is starting his third day of refactoring¹, a monster class called BuyABook. ScrumMaster Steve’s antenna goes up immediately, after all the team had split all tasks in one day or less. After standup he stops to have a quick chat with Ian to find out what is up. Ian explains that this class depends on many other classes and as a result it is very difficult to test. He continues that he’s been reading the Feathers book: “Working Effectively with Legacy Code” but it’s a struggle to put the ideas into practice. When he’s finished, Steve talks to Doug and Martin finding that they’re having similar problems.

Steve puts on his thinking cap. He knows the team needs practice and knows that they need a safe place to do it before they use the ideas in the main stream code. After a few minutes Goggling, he stumbles on the idea of coding dojos and, based on the experience of others, TDD Randori Session, TDD Randori Workshop and My First Coding Dojo. The idea behind a Coding Dojo is taken from the world of Martial Arts. It is just a safe place to practice. In this case Steve imagines the team would like to be able to practice the ideas that Feathers proposed, either on an artificial problem or on a small problem in their own code base. He sees them getting together in a meeting room with a projector and solving a small problem as a team.

Reading the experience posts, Steve learns:

It’s best to start with small problems
Bring a real mouse, not just a laptop trackpad
Pair Programming is best – one driver and one navigator
Ask the pair to explain their decisions, making it clear to the audience what is happening. In addition it keeps the audience engaged.
Rotate the pair partners every 5-7 minutes
Get enough Pizza for everyone
90-120 minutes is about the right length
Small steps
Ask questions if you don’t know what’s going on
Hold a retrospective at the end

Steve gathers the team together and proposes the idea. They agree instantly, but Ian points out that “BuyABook” class is awfully large to get their heads wrapped around in 90 minutes. Instead they agree to tackle a smaller problem and get the “ChargeBookToMasterCard” under test.² They agree to run the Dojo the next day at lunch.

They gather in a meeting room with a projector, a laptop, and a couple of other developers from a sister team that is also working on the bookstore. Steve had invited everyone to spend a few minutes preparing for the session by studying the code beforehand. After a brief introduction to Coding Dojos (see Wouter Lagerweij’s presentation via Slideshare), Ian frames the problem. ChargeBookToMasterCard is difficult to test because all the existing constructors require access to the MasterCard processing server.

After a few minutes of struggling to understand the myriad of methods on the Mastercard, they realize that “ChargeBookToMasterCard” really only uses three of those of methods. They conclude that using a Facade to wrap the MasterCardProcessor is the simplest way to go. With the Facade they can either pass in the real MasterCard processor, or a fake that can be used for testing. (Ed: Yes, this essentially manual mocking and real Mock tool would be faster to use). Once they’re able to construct a “ChargeBookToMasterCard”, now they can start trying to test the public methods and refactor the ones which are complex. At the end of 90 minutes they’ve got a good start at refactoring a previously challenging class. If they’re happy with the code quality they could check it in, otherwise a developer can use the work as inspiration to do the actual tidy up. Since Coding Dojos invite us to take risk, they usually don’t result in code that you can use.

During the retrospective, Ian says that the exercise has helped him see a way of biting off smaller chunks of work when paying down technical debt. In addition, Doug says he now has a much better understanding of the payment system. The team agree to hold another Coding Dojo next week.

Analysis

For a couple hours of time and the price of some pizza the team members have gained a little confidence at doing something that had previously seemed hard and risky. While there are still many more hills to climb, knowing that it’s possible is often one of the biggest barriers to paying down Technical Debt. When we see just how small some problems are, it becomes a bit easier. In addition, all the developers on the team have learned some new ideas today. It will take months to get the team to the place that we see as possible, but they will only get there one step at a time.

Images via: https://photodune.net/

Footnotes

I always take exception to this misuse of the word “refactoring”. Refactoring is “a series of small behavior preserving transformations”. When we have to talk about a multi-day refactoring it’s long past the point of small. If they must happen, I call them rework or rebuilding. https://refactoring.com/ ↩
Serendipity. Just after inventing “ChargeBookToMasterCard” I grabbed Feathers’ Legacy Code book of the shelf, opened a random page, and found a very detailed example of the problem we will tackle on pages 106-113 The Case of the Irritating Parameter (link to Google Books) ↩

Scrum by Example - The Trouble with Sprint Burndowns

Thu, 19 Jun 2014 00:00:00 GMT

Dramatis Personae

Steve: A ScrumMaster and the hero of our story

Paula: The Product Owner of Steve’s team

Brad: Business Analyst

SprintBurndownEstimateHrsRemaining

It’s six Sprints after the “Overtime/Disastrous Release”, which set the team back by several months. During the current Sprint Planning, the Team committed to completing the following nine User Stories:

Julia and Rob – are personas used by the BookStore Team to keep them focused on the needs of real users. Julia is a Frequent Book Buyer and Rob is Rookie or First Time Book Buyer.

As Julia I want to be able buy a $10 gift card so that I can thank a fantastic client. Limitation - not delivered just generated - Size: 5
As Julia I want my newly purchased gift card sent by email to its recipient so they can use it quickly. - Size 3
As Julia I want to be able to refill a gift card I previously purchased. - Size 2
As Julia I want to be able to buy a gift card in denominations of $25, $50 and $100 so I can have choices in how much money I want to spend. - Size 2
As Julia I want fancy graphics and text on my gift card to satisfy my inner diva. - Size 3
As Rob I want to be able to use my new received Gift Card so that I enjoy another book without the pain of paying for it. - Size 3
As Rob I want to be notified by email when I receive a Gift Card so I can use it quickly. - Size 2
As Rob I want to see the remaining balance on my Gift Card so I know how much I have left to spend. - Size 1
As Julia I want to be notified when the Gift Card I sent runs out of money so I can replenish it. - Size 3

The stories have estimates (sized 1, 2, 3, with one 5), are reasonably well split and initial acceptance criteria (not illustrated here to save space). Their total of 24 story points seems quite achievable based on the past few sprints velocity. In addition, they break the Stories down into tasks with a total of 323 estimated task hours.

Day by day during Daily Standup, they update the number of Estimated Task Hours of work they currently believe are remaining in the Sprint. This table shows their progress:

Day	Stories in Progress	Stories Completed	Task Hrs Estimated Remaining
1	4	0	300
2	4	0	265
3	5	1	235
4	5	1	178
5	5	1	153
6	5	2	116
7	5	2	101
8	5	4	60

Every day during the Sprint, Steve (the ScrumMaster) asks the team, “Are you still on track to hit our goal of nine stories?” At Day Eight, the team has approximately sixty hours of work left, four completed stories and five in progress. Steve asks his Daily Question, “Are we really going to make it?” All of a sudden, the answer is No. Steve asks, “Which Stories can we realistically complete?” The team pick two and immediately go and find Sue to tell her which three stories they’re dropping.

As they leave the Daily Scrum, Brad quips, “That’s really not so bad, is it?”

Analysis

Is it really that bad? Yes.

If the team can’t regularly hit their commitment, the Product Owner and the Business as a whole will rapidly lose faith in them.
When the team’s commitment in Sprint Planning doesn’t mean anything to them, then they won’t be focused or motivated to achieve their target.
When the team miss the commitment on more than a few occasions, predictability goes right out the window.

How did this happen? Sprint Burndowns tracked estimated hours of work remaining to get people to focus on an ideal line (properly called a ‘rhumb’ line). They tend to focus on the rhumb line because that’s what they think management want. They also pay attention to it even when it isn’t drawn, because we assume the natural path to done follows that line. In reality, real Sprint work rarely fits that line.

In addition, tracking task hours tends to get people to focus on the delivery of tasks hours, instead of delivering value. Consider two Teams on Day Eight of a two week Sprint. Assume that they worked on the same Stories for the same Sprint. Team ‘B’ paid careful attention to Sprint Burndown and Team ‘A’ focused on delivering value.

Team	A	B
Estimated Hours Work Remaining	100	60
Completed Stories	6	4
In Progress	2	5
Not Started	1	0

Clearly Team ‘A’ is better off even though they have more task hours remaining, since they’ve focused on getting their Stories to complete. With Team ‘B’, even though their Burndown will look closer to the ideal line, we’ve no idea what will really get done - very likely not all of them, since the team will bottleneck on Testing. If Team ‘A’ focus on delivering, they will definitely get at least one of the In Progress Stories to done, and perhaps two. They definitely won’t get the last one done, but the Product Owner won’t be surprised.

Tricks that help

Measure your Sprint Burndown in Number of Stories or Story Points. Only burndown when a Story is completed.
Limit WIP (Work In Progress) - this forces the team to finish Stories, collaborate, and share knowledge. Rally showed in a recent study that reduced WIP correlates with getting more Stories to Done and fewer Defects.
Choose a clear and effective Sprint Goal - in this case a good Sprint Goal might have been: “By the end of the Sprint the Basic Gift Card should be available”. The Sprint Goal allows team members to ensure that their work is driving towards a greater goal. It helps maintain focus more effectively than a random grab bag of Stories. And if something needs to be dropped, it gives greater clarity around that choice.

Some of the most effective Teams I’ve seen dispense with Sprint Burndowns altogether and just focus on the flow of work across the Scrum Wall. They focus on getting the Stories themselves to completion and the tasks are just aids. For those who prefer to use a Sprint Burndown consider - Sample Improved Sprint Burndown:

Sprint Burndown Number of Stories Remaining

Just counting the number of Stories puts the emphasis on getting Stories to done. Even Story Size in Points can be distortive because it makes large items seem valuable making a cliff like burndown more likely. Just counting Stories puts the emphasis on the delivery of value.

If the team had this, they would have seen sooner that they weren’t going to get everything complete. They could have adjusted their approach to get some Stories done sooner.

Images by Agile Pain Relief Consulting.

Simplicity

Mon, 14 Mar 2016 00:00:00 GMT

In 201x, the global financial markets collapsed. Reason: mortgages were given to people who couldn’t afford them. This debt was then repackaged and sold to banks and other institutions as good debt. (“The Big Short” by Michael Lewis is an excellent indictment of this time). However, the bigger question remained. Why didn’t the financial regulator system catch the problem early, while it was still small?

The answer? Complexity.

Dog and frisbee - Image attribute - Photodune

In “The Dog and the Frisbee” (pdf), Andrew Haldane, Executive Director Financial Stability at the Bank of England, explains all the things a dog would have to know and understand to catch a Frisbee: wind speed and direction, rotational velocity of the Frisbee, atmospheric conditions, and gravitation. It might require a degree in physics to know how to express the control problem involved in catching the Frisbee.

Yet dogs, without physics degrees, do this everyday. They obey a simple rule/heuristic: “run at a speed so that the angle of the gaze to the frisbee remains constant”. Empiricism and Simplicity. Agile works because it is an Empirical process using constant feedback to update both the work itself and the way we work.

Haldane goes on to show that the financial regulatory system evolved from something simple that many people at a bank could understand, to something only a few people could understand. Eventually it became so complex that no one person understood the system as a whole. The earlier regulatory frameworks worked well in part because many people understood, and therefore many people could spot problems early, before they got too complicated and large to resolve.

As we deal with ever-larger organizations, it’s tempting to say that this increase in complexity is okay because we’re larger. But if financial crisis taught us anything, the answer should be no. The bigger the system, the more important it is to use simple control mechanisms, simple feedback loops, and simple measures that can be understood by all. Decreasing complexity - not increasing it - has to be at the heart of all of our decisions. And coupled with that has to be the ability to respond quickly and change appropriately.

Image attribution: damedeeso, via photodune

Software Development is Not a Form of Construction

Tue, 28 Apr 2015 00:00:00 GMT

icon of a person in overalls with a wrench, with various acronyms of well-known scripting and programming languages in the background

For years the software industry has used an analogy, with construction as its defining metaphor. The comparison is applied throughout the language of software: architecture, foundations, constructor, projects, building code. The language is so pervasive that it affects our thinking around software development, but unfortunately the metaphor is fundamentally broken and the flaws have led us down a number of bad paths.

In construction, a lot of emphasis is placed on predictability, getting the requirements correct up front, and cost reduction. These are all signs of a mature industry. We run into problems when we try to apply the same emphasis in software.

Rules of Thumb, Construction Codes, and Materials

Modern construction can trace its routes back hundreds or thousands of years, depending on where you put the starting line. As a result of all this history, there is a great deal of expertise codified in rules of thumb:

In most areas the construction costs per square foot are a well-known constant. For instance, we recently did some home renovations and were warned by friends in the industry that the typical renovation in Ottawa costs from $35-50/sq ft. They were bang on.
A good estimate for the depth of a concrete floor slab is the same as a 1/180 of its unsupported perimeter.¹

Software, on the other hand, is at best 70 years old. Its rules of thumb don’t have the same solid history to warrant unwavering application.

Eventually rules of thumb are codified and fixed as building codes. When constructing houses, building codes determine everything from how far apart the studs in the wall are, to the amount of insulation in the walls and roof. These codes mean that all houses meet a minimum standard and greatly increase the predictability of cost.

It is possible to have these construction codes because there are limited sets of building materials (wood, steel, etc) and tools (hammer, saw, etc). The properties of the materials and their failure modes are predictable, and the toolset that is used to work with the materials is small and well understood. Sure, materials and tools continue to evolve in the construction industry, but at nowhere near the same rate as evolution in software.

It’s much harder to keep up with the list of new materials and tools in software. Programming languages, libraries, and supporting tools appear and evolve every year, as does their content. And even if we just stick to our existing languages and libraries, it may take years to explore all of their details and nuances to the extent that would be required for standardized codes.

It’s the well-understood, stable materials and tools that make building construction codes possible. The instability of the software world guarantees that we will never have construction codes in our field.

There are no useful Rules of Thumb or Construction Codes in the software industry.

Physical Constraints and Stable Requirements

Buildings, bridges, and other construction works are governed by well-known physical limits. These limits dictate the size, shape, and use of a structure depending on the materials used. For example, wood framed buildings are limited in height from four to six stories. Bridge spans are limited in length by the materials used and how the properties of those materials relate to the physics involved.

The construction of buildings and bridges represents a problem domain that has been studied and tested for generations. As a result, the questions that have to be asked of the client are predictable and the range of possible answers is constrained.

Construction design has to fit into the constraints of site and function. As much fun as it might be to imagine an office building that spins around a single point like a gyroscope, it’s both physically impossible and wouldn’t meet the functional need. When building bridges or roads, there are clear standards for each jurisdiction based on the type and size of vehicle that you need to support.

Software isn’t subject to these same constraints. If the customer really wants the equivalent of a gyroscope, we can probably deliver it. The types of users - and uses - that we need to support are far more widely varied than those in construction.

Once a building has been started and the foundation has been poured, you can’t easily change the size or location on the site. Once the internal structure of a building has been started, you can’t just decide to add a new elevator shaft or new wing to the building. When the footings of a bridge are in place it can’t be moved 20m because the customer decides the bridge was in the wrong place. (Okay, you can, but effectively it requires you to throw away all existing work and start again from scratch).

With software we can make almost any change we want - from the simple to the complex, such as increase the number of supported users from 100 to 1000; change the product direction (Yelp – started life as a tool to send friends recommendations for restaurants, doctors etc. It took on life as a review site only when the original functionality flopped.), change the programming language (I’ve worked projects that moved from Java to .NET and back to Java) - all for much less cost than starting again from scratch.

Because we have much greater flexibility in software, we are also able to accept changing requirements throughout the development process. Requirements that are discovered early in the development process often change a number of times before they’re finally implemented.

In the world of construction, the architect can hand the builders a set of blueprints with fair confidence that the builder will interpret them correctly. While there will still be dialogue and a need for changes, the degree of change is nothing like the world of software. In software we have no effective way (even UML) to hand a blueprint to the developers and walk away. Instead of a blueprint, we have a series of ongoing conversations between the customer and the people building the software.

Software is open to far greater change than construction.

People

In construction, tradespeople are generally considered interchangeable and replaceable. It’s assumed that if you change carpenters while framing a house, the results of their work will generally be the same.

In the game of software this is clearly not true. Because of the complexity and variance in both the tools (programming language and libraries) and problem domain developers, business analysts, testers and UX designers can’t just be moved from one area to another.

People who see a relationship between software and construction often assume that people are replaceable and interchangeable. That is far from the truth. All substantial pieces of software are built by teams of people, so if you interchange or replace one team member with another, it costs a team in three major ways:

They lose the tacit knowledge that their former team member had.
They have to train the new team member on what they’re building and what they have built so far.
They have to spend time establishing an effective working relationship with the new person.

As a result, replacing or adding a new person slows the whole team down for at least 3-4 months. Individually, the new team member often takes even longer than that to become fully productive. While construction also suffers slow downs when people are changed, it will be to nowhere near the same degree as a software project.

Over 40 years after it was first written, the old Fred Brooks quote still applies: “Adding more people to a late project just makes it later”.

Conclusion

The construction metaphor that is often used to describe software is wrong. Sadly, because of its implications, we put a lot of emphasis in the wrong places:

· Getting the requirements right upfront instead of accepting that change is the norm

· Emphasizing the importance of architecture and architects instead of accepting that software is adaptable and can be change by anyone on the team

· Assuming people are replaceable and that problems related to time can be solved by adding more people instead of accepting that people are unique

· Seeking predictability instead of accepting our domain that isn’t well understood

Software is in no way related to construction. We’re not building, we’re exploring.

We’re exploring the problem space of our customers. We’re creating new ideas that happen to be expressed in code. So let’s leave the old construction metaphors behind, because they’re crumbling the foundation of the roads we’re travelling together.

I’m not the first to explore this vein. Other views:

Martin Fowler: The New Methodology Thomas Guest: Why Software Development isn’t Like Construction Mishkin Berteig: The software construction analogy is broken

Image by Agile Pain Relief Consulting. Elements of image designed by Freepik.

Footnotes

Designing With Your Thumb – Thomas Michael Wallace ↩

Solve your Task Estimation problem in Scrum

Wed, 06 Feb 2008 00:00:00 GMT

I’m often asked about improving the estimates of task hours generated during planning meetings. Years of waterfall development have taught us - if we improve the estimates we will do a much better job of tracking the sprint progress.

When this comes up I like to ask two questions:

why estimate task size at all?
what value do we gain improving our project tracking?

Why estimate?

We produce estimates to help us decide how many tasks we can fit into an iteration (aided by Velocity/Yesterday’s Weather). As a side effect our estimates help us discover wildly different expectations around a task - one person thinks it three lines of code while another sees a whole subsystem.

Why track progress?

We track progress so that the team can tell if its on track to meet its goal for the iteration.

Instead of trying to improve estimates I recommend that the team focus on ensuring all of the tasks are:

Small - not larger than 8 hours work
Well understood - any one on the team would feel comfortable grabbing any one of the tasks

Recently Jeff Sutherland has described something even more radical. On experienced teams, such his own at PatientKeeper or some at Google the time taken to estimate tasks in hours just wasn’t productive. Instead these teams tend to know how much work they can take on and just look at how many tasks they can get done a sprint. Sprint tracking has become a matter of looking at the task board and seeing where the bulk of the tasks are. In the sprint is 1/3 complete but over 1/2 the tasks haven’t been started, then you have problem.

So Jeff still recommends that teams new to Scrum estimate their tasks in hours - but experienced teams might take off the training wheels and not estimate hours a for few sprints. See how it feels. If it works keep it.

So instead of improving your estimates - kick the habit, give up the estimates in hours.

Specialists Are Overrated

Mon, 07 May 2018 00:00:00 GMT

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” – Agile Manifesto

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

Traditionally, notions of efficiency have been to minimize cost by utilizing experts (i.e. expensive people) only on the most difficult problems and having cheaper workers do the other work. This approach is effectively the underpinning of a matrixed organization. The problem is, as soon as we create a special role to solve a problem, the expert who fills that role has every incentive to ensure the problem never goes away. Agile is different —its focus is to find ways to deliver the best product possible that fits the customer’s need in the shortest possible time using a team that works collaboratively to tackle both the difficult problems and the more mundane tasks.

Scrum, and Agile generally, work by forming stable teams, which operate cohesively and focus on one feature at a time. Because they’re stable, Scrum teams can grow and become better equipped to deal with both bottlenecks and changes in demand. They do this by developing “T-shaped” team members, effectively distributing “expensive expertise” across multiple team members, rather than consolidating it in singular experts.

What is T-Shaped?

Specialists Are Overrated

A specialist (i.e. an expert) is someone who has the skills and knowledge to work highly effectively at one station or one type of work. The drawback to having many specialists, and the downfall of matrixed organizations, is that, in any system, they are often just piling up inventory². If they keep producing when their work isn’t in immediate demand, such an unused specialized work product becomes a source of risk for the business. It might contain defects or represent a misunderstanding of the customer need, but because the work is not in demand, it is unlikely to be checked for errors. This is a waste and does nothing for efficiency.

Some Examples

A Senior Developer writes server-side code only. If the team currently has a bottleneck in testing work (i.e. there is more work than can be tested soon), then any new server-side code the developer writes becomes a form of unused inventory.
A marketing department has a clear separation between writers and editors. If editing of work is currently backed up, any new writing work contributes to the backlog, becomes stale, and increases team frustration because they aren’t seeing any meaningful results from their work.

We often call specialists “I-shaped” people. At the other end of the spectrum, we also have generalists, the infamous Jack-of-All-Trades.

In Scrum, we have discovered something in the middle is far more effective: “T-shaped” people, aka the “Generalizing Specialist”. That’s a mouthful. A generalizing specialist is very good at one or two skills areas, but can also possess working knowledge to help out in some others.

Why Have Generalizing Specialists?

How to Cross-Skill and Grow T-shaped Team Members

There are many advantages and rewards to developing T-shaped individuals in the team. These include:

Benefits for the Organization

They reduce how often the organization is constrained by bottlenecks. (Example: Toyota trains employees to handle multiple stations, so they can contribute where the workload requires.)
They are stuck less often waiting for other teams (aka external dependencies).
They are predisposed to share knowledge across the team, increasing the lottery/bus number (i.e. The number of team members we would have to lose - they win the lottery or get hit by a bus - before our project stalls due to lack of knowledge ³).
They are better able to adapt to changing demands, instead of only being able to work on features that fit their narrow skillset.
The team is better able to complete work in the Product Owner’s priority order instead of having high priority work wait for specialist skills.

Benefits for the Customer

By reducing bottlenecks, the customer gets the work they asked for sooner (in Kanban this is measured as Lead Time⁴).
Quality is higher because more people have the skill (and flexibility) to review the work for errors or bugs.

Benefits for the Team Member

T-shaped people have a greater number of marketable skills and proven adaptability than I-shaped people, which makes job opportunities more plentiful.
Since it’s human nature to enjoy novelty and variety, being T-shaped makes it easier to find satisfaction inside a project since they are not restricted to certain tasks because of skill limitations.

Where are the Limitations of T-Shaped People?

Testing or editing your own work often leads to blind spots. To avoid this, try swapping with someone else so you can review each other’s work for errors.
With some knowledge areas (e.g. Hardware Development, User Interface Design, or foreign language translation) there are limitations as to how far any non-expert can develop functional expertise. Realistically, while having T-shaped team members can minimize the need for specialists, in some cases it will be impossible to eliminate the need for them entirely.

How to Become T-Shaped

You become T-Shaped by cross-skilling (also known as cross-training or multi-skilling). This involves learning and practicing skills relevant to delivering the product. Examples of this could be a marketing writer, learning the basics of copyediting, or in the case of web development, having a back-end developer learning to read and write CSS (normally the work of a designer or UX specialist).

To be effective, cross-skilling requires an organization committed to supporting its teams in this endeavour. Ideally, this would be accomplished by establishing a plan for cross-skilling that is created collaboratively with the team. This plan should include the reasons why the team is learning to cross-skill, set out sufficient time and resources to accomplish this, acknowledge the additional workload required for a person to learn until they are proficient in new skills, and some kind of recognition mechanism for team members that successfully cross-skill. It also should outline where the team will focus on developing cross-skill strengths.

So, How Do We Decide Where to Cross-Skill?

There are two major ways to discover opportunities for cross-skilling:

Use your Kanban/Scrum Board to discover bottlenecks
Use a Skills Matrix to find opportunities

Agile Pain Relief Blog Entries

(Original image design by FreePik)

Footnotes

Donald G. Reinertsen, [[The Principles of Product Development Flow https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009 ↩
Lean Software Development: An Agile Toolkit – Mary and Tom Poppendieck https://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783/&tag=notesfromatoo-20 ↩
See: for more depth https://en.wikipedia.org/wiki/Bus_factor ↩
See Cycle Time /glossary/cycle-time/ ↩

Speed Trap: How the Obsession with Speed is Building Fragile Organizations

Thu, 24 Apr 2025 00:00:00 GMT

Most of the oxygen in the online sphere these days is being swallowed up by the AI hype. AI is a valuable tool, however, when misapplied, it makes organizations more fragile, not more resilient, and that’s not a good thing.

I’ve long said —and research supports— that a fragile organization that goes faster will be knocked over in the slightest wind. So the current fascination with using AI to produce code faster baffles and concerns me if organizations use it as a general crutch, rather than a tool in specific and select ways.

Attempts to speed up a system without first ensuring that there is a focus on quality, everyone is aligned on strategy, and ensuring the speed up is targeted at a bottleneck, just means piling up more of the wrong thing, probably full of defects.

What Makes Organizations Fragile?

Focusing on speed over quality
Adopting new technology without understanding its impact throughout the system
Heavyweight change management process
Involving every stakeholder in every single decision
Standardization overkill
Centralization of decision making

Characteristics that weigh Fragile Organizations down compared to the benefits seen in Resilient Organizations - Image Created with the use of Napkin.AI

Why We Need Resilient Organizations

Resilience is “the ability of a substance to return to its usual shape after being bent, stretched, or pressed” ¹.

It’s more important than ever to have resilience, as the number of things that affect our organizations is increasing.

Climate change has made more frequent floods, forest fires, hurricanes, tornadoes, and atmospheric rivers (the last one wasn’t even a thing 15 years ago).
AI and other technological changes are affecting our businesses at an ever-increasing rate.
The complexity of the problems we tackle at work is increasing. Complex problems require experimentation and learning to solve, instead of the traditional plan and predict.
We have increased interconnectedness. Even when our systems are simple, we’re connected to other teams or organizations. A sudden change in their environment will affect us, and vice versa.
New and increased global threats —for example, pandemics, tariffs, and trade wars— affect both vulnerability and daily operations. When COVID came along, the organizations that could adapt quickly fared well. Their resilience was seen in switching to remote work and/or manufacturers changing product lines to build respirators, for example. As tariff barriers go up around the world, businesses that export need to pivot rapidly. Are they going to absorb the tariff? Find new export markets? Change the product line?
Supply chain issues are another place the need for resilience is clear. Whether trade wars, geopolitics, or just transport bottlenecks, organizations need the ability to adapt quickly when pressed. An example is when the Ever Given container ship blocked the Suez Canal in 2021, and goods backed up in Los Angeles and Vancouver ports because of a lack of transport options to get them out.

Thriving in the presence of these and many other problems requires building teams and organizations that can adapt.

Characteristics of Resilient Organizations:

Networked, not hierarchical
Coordinated across boundaries
Continuous change is normal
Attention is paid to the health of the system
Psychological safety
Learning from mistakes, not blaming
Information is shared, not hoarded
Embracing improvisation over following a plan
Room for slack (i.e. they maintain spare capacity)
Feedback loops
Simplicity is preferred

Resilience is not an afterthought; we must bake it into our organizations. It isn’t a fixed characteristic but something we must constantly work on.

In upcoming articles, we will explore more deeply these challenges and what it takes to build resilient organizations.

Where have you seen things that make your organization more fragile?

Related Blog Entries

Footnotes

Cambridge English Dictionary https://dictionary.cambridge.org/dictionary/english/resilience ↩

Sprint Goals Provide Purpose: A Guide

Fri, 01 Mar 2024 00:00:00 GMT

Learn why Sprint Goals are essential for Scrum teams and how to create effective goals that drive focus and value. Includes examples and best practices from the Scrum Guide.

A Development Team looks at two targets; one is in focus and has arrows that point directly toward the Sprint Goal; the other target is out of focus with arrows that miss the bullseye

Go Beyond Merely Completing Work Lists with a Sprint Goal

Research shows that people, whether acting individually or as a team, achieve more when working toward an objective that is specific, challenging, and concrete.¹ For that, we need clear Sprint Goals.

A Sprint should be so much more than just completing a number of User Stories or fixing bugs. If your Sprints are merely about ticking off items on a scattered work list without having a shared understanding of why they’re important or what purpose they serve, your Development Team will struggle to keep focus in the short-term and will take longer to become highly effective in the long run. Sprint Goals provide purpose for the Scrum Team to work together effectively.

What does the Scrum Guide say about Sprint Goals?

As part of Sprint Planning it says:

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.

As far as typical standards of the Scrum Guide go, this is clear 🙂. Key takeaway is that it’s about the value that the team will deliver in Sprint and it should help the stakeholders. This is going to be a handy measuring stick when we test bad Sprint Goals.

The Scrum Guide is also neatly answering questions that frequently come up in workshops:

When is the Sprint Goal set? During Sprint Planning.

Who is involved? The whole Scrum team, meaning Scrum Master, Product Owner, and Developers.

Should the Product Owner set the Sprint Goal? No. It’s good for them to go into Sprint Planning with some business or product objective in mind, but it’s through negotiation with the Development Team that the actual Sprint Goal emerges, as all grow towards a shared understanding of what is desirable and achievable in the Sprint. “Achievable” means possible to accomplish while upholding the quality agreed to in the Definition of “Done.”

Does the Goal Change in Sprint? It’s very hard to hit a moving target, so the answer is no, the goal does not change within each Sprint. However at the start of each Sprint, the team sets a new goal.

Are Sprint Goals optional? The Scrum Guide is clear on this, goals aren’t an optional part of Scrum. As we will see below, there occasions where goals aren’t practical, but they are still part of the game.

Why Do We Have Sprint Goals?

In Scrum, we ask a Team to undertake Sprint Planning to agree on what they will achieve in the next Sprint, based on their expected capacity. As an outcome of this, the team should leave their planning session with a clear goal.

This provides stable direction, with flexibility to re-evaluate work, throughout the Sprint. It is the WHY of a Sprint, establishing purpose and commitment.

By participating in setting a Goal, Team members experience a sense of ownership of it and gain a better understanding of the overall problem. On occasion, it also helps them find better solutions than originally planned because that overall perspective can help see things during the Sprint that aren’t obvious if looking only at the individual parts.

The Sprint Goal provides focus in Daily Scrum and an opportunity to refocus if the Sprint goes off-track. When distractions occur (e.g. new User Stories or other outside interference), a clear goal gives Team Members a way of saying “no”. They ask the question “Will this new thing help us get closer to the Sprint Goal?” If not, the distraction gets set aside and, if still relevant, considered in the next Product Backlog Refinement session.

Finally, jointly identifying and achieving shared goals is a key element for growing a group of people from a working group to a true team.²

When Not to Use Sprint Goals in Scrum

Sometimes a team will have a Sprint of work with no focus. If this is rare, I wouldn’t try to set a Sprint Goal. Rather, I would acknowledge that, on this occasion, there isn’t a Sprint Goal. I have seen teams using Scrum to serve the needs of 4-5 distinct clients in a single Sprint. If their needs don’t have any overlap, then the team will not be able to set a Sprint Goal. Lacking a goal, this team will have a longer path to high performance. (I wouldn’t abandon Scrum altogether - see Limits of the Framework). However, the key point is that this should be a rare occurrence, not license to skip Sprint Goals normally.

Spotting Unhelpful, Meaningless Sprint Goals

In my experience, most Sprint Goals are not clear. Some poor examples I’ve seen are:

Fix 10 bugs – This lacks any sense of purpose. Why is it valuable to fix this batch of bugs vs any other bugs that are in the system?
Finish 7 unrelated User Stories – Similar to the previous example, there is no sense of purpose.
Complete the work assigned to the team in JIRA – Yes, this is remarkably anti-Agile and ineffective, however, I see it all too often. This implies the team is a group of robots whose job it is to move a task from one column on Sprint Backlog to another.

None of these examples help focus the Team. Nor do they clarify the value the team will deliver. The best test to spot unhelpful, meaningless Sprint goals is when the Stakeholders have no idea what they’re getting at the end of the Sprint.

How to Make Better Sprint Goals

So, what makes a better Sprint Goal? A good Goal answers questions such as: Why is it worthwhile to undertake this Sprint? Are we attempting to solve a problem? Are we implementing a feature or clarifying an assumption?

Improved versions might include:

Reduce the shopping cart abandon rate from 50% to 30% by improving usability and performance – Solves a problem. We’re losing sales because we have a poor checkout experience.
Add filters to the existing product search results so that buyers spend less time finding items that meet their needs – Implements a feature.
Offer free shipping for orders over $40 – Tests an assumption that free shipping will increase the amount people spend per transaction.

Agile Coach Bob Galen suggests that you imagine crafting an email to invite your whole company to your Sprint Review. What will you put in the subject line and first few sentences to entice them to attend?³ Then use that as your clue for your Sprint Goal – the shared understanding created between the Product Owner and the Development Team of the desired outcome of the Sprint.

Frequently Asked Questions About Sprint Goals

What is a Sprint Goal?

A Sprint Goal is a short statement that describes the value and purpose of a Sprint. It’s collaboratively created by the entire Scrum Team during Sprint Planning and provides focus for the team throughout the Sprint.

When should the Sprint Goal be set?

The Sprint Goal must be finalized during Sprint Planning, before the end of the planning session. The Product Owner proposes ideas, but the entire Scrum Team collaborates to define the final goal.

Can a Sprint Goal change during the Sprint?

No. The Sprint Goal remains fixed throughout the Sprint to provide stable direction. However, the team sets a new goal at the start of each new Sprint.

Who creates the Sprint Goal?

The entire Scrum Team creates the Sprint Goal together - this includes the Scrum Master, Product Owner, and Developers. It’s not set by the Product Owner alone.

Image attribution: Agile Pain Relief Consulting

Updated December 2025

Footnotes

Sprint Planning from Hell

Sun, 07 Dec 2025 00:00:00 GMT

Imagine Sprint Planning meetings with a team of developers, business analysts, one lonely tester, a Product Owner, and a Scrum Master. They sit for 2+ hours, debating the size of user stories that no one understands. They leave the room with an alleged plan, but no real belief that they can deliver it. They spent all of that time, and left with the feeling that their opinions didn’t matter. The PO and stakeholders told them, “We need these items done by the end of the Sprint. You’re committed, right?”

Variations of this story are so common, it makes me sad. This wasn’t a collaborative planning activity, it was a waste of time. This is the kind of thing that people mean when they say “Scrum (or Agile) in name only”. As usual, the problem isn’t the planning event itself - it’s just acting as the canary in the coal mine. There are many potential causes for why Sprint Planning goes awry.

Poor Product Backlog Refinement

I’ll be blunt. The leading cause of poor Sprint Planning is poor Product Backlog Refinement. When looking for the problem, odds are that you can start here:

Not enough time was spent refining the candidate items. In Planning, when we don’t understand the items, we can’t commit to them. This is closely related to…
Not all team members participated in the Refinement session and so they don’t understand the Backlog Items.
The items at the top of the Product Backlog are too large, making it difficult for team members to commit to them. If the team is using T-Shirt Sizing for Estimation, items at the top are Small (S) or Extra Small (XS). If still using Story Points, numbers like 1, 2 or 3.
Dependencies, especially on other teams, haven’t been identified.
The Items are too technically complex, making it unclear for the team how they will build them.

Inadequate Definition of Done

An unclear Definition of Done means team members can’t agree on the amount of rigour required to finish a Product Backlog Item. (Hint: Definition of Done should cover: how we test the Feature, security, accessibility, usability and …)
Worse, some teams don’t even have a Definition of Done or, if they do, it’s buried in SharePoint.

Core Planning Problems

Attempting to estimate the Product Backlog Items in the Planning event when that should have happened in the Refinement session.
No Sprint Goal. Having a clear Sprint Goal makes the rest of the Sprint Planning much easier because it tells the team what they’re working towards.
Lack of clarity on the priorities in the Product Backlog means the Product Owner won’t be able to articulate a clear Sprint Goal.

Facilitation Issues

Forgetting to account for small improvements that the team committed to in the last Sprint Retrospective
Failure to account for unfinished work from the last Sprint (if there is a consistent carryover, that is another problem that needs to be addressed)
Planning event is poorly facilitated

Morale and Communication Challenges

Senior team members dominate Sprint Planning and everyone else is expected to say yes
Team members don’t ask questions or speak up about concerns because they don’t think they will be listened to
Team members haven’t taken the time to review the Product Backlog Items before attending Planning
Lack of engagement from team members, whether in person or remotely
Wrong people are in the room - some team members are missing or some stakeholders are present

Delivery Pressure

Pressure from management to go faster
Pressure from ourselves to go faster for the sake of going faster (we don’t even need management to apply pressure, we do it ourselves)
Stakeholders trying to override Product Owner priorities
Commitment based on past velocity without understanding the Product Backlog Items
Outcome of the Planning session is treated as a hard and fast commitment, not the best forecast we can make at the start of the Sprint

Ironically, going faster is rarely the answer. If we go faster building the wrong thing, we’ve wasted our time and effort. Focus on Outcomes (did we solve a real problem?), not Output (story points).

Technical Debt

Not taking into account the Drag Effect of Technical Debt. When a team accumulates enough debt, they pay a tax in the form of reduced velocity, meaning, they will get less done then they expect. Worse, the increase in technical debt reduces predictability and increases the risk of bugs.

Why does this all matter?

If we don’t have a good Sprint Planning session, we will have a difficult Sprint. Poor planning leads to mid-Sprint scope changes, reduced throughput (aka velocity), decreased quality, loss of stakeholder confidence, and more. But the good news is that, by now, some of the patterns should start to become clear. Resolving the problems isn’t magic but it does require hard work.

Many of the problems are tackled in...

Stable Teams Really Do Matter

Tue, 01 Oct 2013 00:00:00 GMT

3D men holding hands in a circle. - image by PhotoDune

For years now Rally has been performing a large ongoing experiment on the Agile world. As a side effect of providing one of the better known tools they’ve managed to see a lot of data accumulate about what makes an effective Agile team. In a report called “The Impact of Agile Quantified” they’ve sanitized the data and then run some statistical analysis on it.

Here’s what they saw:

Dedicating Team Members to one team doubles productivity, reduces variance throughput and leads to a small reduction in defects. They note that this is a fairly common practice among teams.
Stable Teams – keeping a team intact for the long term resulted in 60% more productivity; teams were more predictable and responsive.
Limiting Work In Progress – reduces defect rates; however, if your WIP limit is already low, reducing it further might affect productivity.
Relative/Story Point Estimation[1] – They divide the world into teams that: A - Don’t estimate; B - Estimate Stories in hours; C - Estimate Stories in Points – tasks in hours, and D - teams that only Estimate using Story Points (i.e. teams that have dropped task hours). Their discovery – the teams (A) not using estimates had 2.5 times as many defects as the teams (C) using Story Points and Task hours. An additional surprise – teams (C) using Story Points and task hours had fewer defects than (D) teams only using Story Points. Some of the discoveries in this one could use further investigation.
Team Size – 7+/- 2 – the findings suggest that teams before the Agile norms are more productive, but have a higher defect rate and reduced predictability, whilst larger teams were more predictable. The authors note that the larger teams typically also used “Story Point Estimation for Stories and Hours for Tasks” – this might explain some of the productivity differences. The authors recommend sticking to the traditional recommendation of 5-9. Before switching all your teams to 3 people or less – which is tempting with the promise of more productivity – also consider the effect on the work if even one team member leaves. This is another datapoint that bears digging into.

I was surprised to find that stable teams are less frequent among the Rally customers than my own. Rally noticed that 1 in 4 people changed every 3 months. Experience at my regular clients suggests that it should be less than that. No matter what the frequency, we have to appreciate that every change is expensive; both in terms of the knowledge lost and the consequent slowdown while team members renegotiate their relationships. It’s hard to build the high performance teams that we all seek when we have frequently changing membership.

As with any set of measures, I think the value isn’t so much in the number as the signal regarding what to look at in our teams. In addition, I suspect some high performing teams will probably be doing things that don’t show up well in the larger dataset. For instance, I’ve seen many high performing teams with less WIP than the number of team members. Instead they swarm all work, etc.

The report from Rally is well worth reading, although it’s sixteen pages long. (You will have to give away your email address).

To my friends at Rally, there are many interesting questions to be asked here. If we look only at stable teams – what do we learn about team size? If we look only at mature teams (>1 yr old and stable) – do any of our discoveries around team size and estimation change? What about time to fix defects vs. productivity or quality? What about time to fix defects vs. team size? Story size vs. productivity vs. defects? Distributed teams’ productivity? What about the highest performing teams – what where they doing…? Have you considered releasing your dataset to the rest of the world so we can help you mine it? Two reasons: more eyes will spot more ideas and the Agile ideas have always been developed and evolved in an open fashion. Perhaps you could release with the rule that anything someone else discovers from it has to be shared openly.

Hat tip to Dave Nicolette who first pointed this paper out to me

[1]In the paper this is referred to “Full Scrum” – which is odd since Scrum doesn’t require Estimation at all.

Image attribution: Photodune.net

Story Slicing, How Small is Enough?

Mon, 27 Sep 2010 00:00:00 GMT

Story Slicing. Cutting - image licensed from Photodune

When Agile/Scrum Trainers teach about new teams about User Stories, we usually talk about Bill Wake’s INVEST criteria, which includes Small:

Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what’s in the story’s scope. Saying, “it would take me more than month” often implicitly adds, “as I don’t understand what-all it would entail.” Smaller stories tend to get more accurate estimates.

This statement is a great start, but it doesn’t explain why or give you much guidance about what to do.

Why Small Stories?

Why not just give the team large stories that span iterations. Why are always asking if you can slice those stories smaller? A number of reasons:

Small stories provide focus and a short horizon for the team. It’s easier to get lost in the details with a larger story.
When you still have development to test handoffs (i.e. before you start doing Behavior Driven Development), smaller stories enable more frequent handoffs and allow testers to work on smaller chunks of code.
Small stories give you the flexibility to reconfigure and adapt to new discoveries or changes. Perhaps the PO discovers that an existing story is now irrelevant; or while coding you discover a surprise. Small stories make it easier to adapt.
Small stories provide more feedback opportunities at all levels of the system and more opportunities for personal satisfaction; think of the small dopamine rush that happens every time you complete something!
Large stories increase the risk that your team will deliver nothing at the end of the iteration.
Your team has a capacity like a drain pipe and just like a pipe the larger the object you try to push through it the more likely it is that blockages and bottlenecks will occur. Perhaps one person who is tied up in the large story may also be the only person who can complete a key piece of another story.

So what is my guidance for new Scrum teams when they’re trying to decide on Story size? Two people for half an iteration. Why two people? Because most stories require collaborative effort and I want to encourage pairing/collaboration. Why half an iteration? Because any larger makes it quite likely that the story will not be completed in a sprint. Even stories of this size are still a bit large, and they shouldn’t commit to more than one of these per sprint. For some strange reason with most teams I coach, stories of this size are 13 Story Points, I don’t really know why this happens.

All this suggests that most stories are going to be in the range of 1-5 story points by the time the team is ready to commit to them. You can still have Epics and Themes they should just be split into much smaller parts before the team attempts to commit to them.

But That’s Really Small

If we’re working in bite size chunks, how do we get any meaningful work done? How do you slice them so small? Part of the problem is a frequent misunderstanding around value in stories. The ‘V’ in INVEST stands for valuable, many people assume that equates to business value or a feature that you can sell for a dollar. When we combine user stories together, they represent features that customers will pay for. But on their own they’re too small for that. Instead value refers to the point of view of the user for whom the story was written in the first place.

So the hard part how do you slice? Some simple ideas:

CRUD (Create, Read, Update, Delete) boundaries
Acceptance criteria – often the acceptance criteria on the back of the Story Card will give a good hint.
Happy Path – many stories have exceptional conditions, consider splitting them out
Simple versions of an algorithm. With a complex algorithm and complex UI, it might be worthwhile to do a simple version of either first and then fill in the detail in the next story. Sometime this can come from making some elements constants instead of looking them up or calculating them

What not to do: Split along architectural or technology boundaries, as this will create stories that don’t deliver value to an end user.

When slicing stories imagine using a scalpel and not a butcher’s knife. Go create some story sashimi.

Update: I was asked for some examples and I’ve written some in More Story Splitting.

Image via: https://photodune.net/

Story Splitting – a Play – Spike Sherman

Tue, 03 Sep 2013 00:00:00 GMT

User Stories are a common tool used by Agile Teams to capture the spirit of a requirement without too much detail. Sometimes User Stories are too large for the team to complete safely in one Sprint. In fact, I recommend that you split the Stories into small enough sections so that you’re completing 5-10 Stories per Sprint; it improves the flow and makes it easier to deliver complete chunks of value at the of the Sprint.

In my classes I frequently ask teams to present what they’ve learned to their peers. At UBC they took it one step further. The teams were challenged to summarize Richard Lawrence’s Story Splitting Flowchart:

Story Splitting Flowchart by Richard Lawrence

They created a play, “Spike Sherman”. Our story opens with Diane preparing the original User Story, “Cong + Sherman”.

Clearly too large – so the team’s splitter, Jason, applied the patterns from the handout and broke the Story into its constituent pieces: Cong and Sherman. Once split, the Story was sent to Yurika to be checked against INVEST:

(Original idea from Bill Wake: https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/):

Independent - dependencies between Stories limit the flexibility of both the Product Owner and development team. The Product Owner should be able to ask for Stories in whatever order makes sense.

Negotiable - the elegance of a User Story is that the precise details are left until later. 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.

Story Splitting – a Play – Spike Sherman

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.

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

Sized Appropriately - 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. Stories in the middle of the Backlog (between 4 -10 Sprints out) should be larger. The team might only complete 1-2 of these in a Sprint. Stories of this size are often called Epics. Further out and the Stories are very large.

Testable - It is clear how you will test this.

Cong was tested against INVEST and was found to meet all of the criteria. He was returned to the Product Backlog for estimation and implementation in an upcoming Sprint.

Sherman was also brought before the INVEST checker; unfortunately, it was discovered that he couldn’t be Estimated. He was immediately taken out into the hallway, and a Spike was conducted by Jack.

Story Splitting – a Play – Spike Sherman

Spike: a special User Story the team uses when there is some special risk involved. Usually the team don’t have enough information to give an estimate.

Spikes are:

Timeboxed usually 1-2 days work for one pair
Experimental solutions that touch all relevant layers
Are always throwaway code

The purpose of the Spike is to give the team enough information to do an estimate later. It’s written quite rapidly without any real concern for code quality.

Eventually Sherman was returned, and now it was clear a split was required. He was returned to Jason who applied the splitting patterns again. Once he was split, the two halves of Sherman were appropriately sized.

All’s well that ends well. No harm came to Sherman.

Thanks to Cong, Sherman, Diane, Yurika, Jason and Jack for the most entertaining presentation I’ve seen in a long time.

“How to Split a User Story” image by Richard Lawrence. Photos by Mark Levison.

Taking Organizational Improvement Seriously - Case Study

Mon, 09 Nov 2015 00:00:00 GMT

Beyond Scrum: Scrum Alone Is Not Enough

(Presented as an accompanying case study to Part 4 in the Scrum Alone is Not Enough series.)

In the Taking Organizational improvement seriously, we discussed how it’s not enough to practice Scrum at the Team level and expect that it will solve all problems. Senior Management has to get involved for real Agile change to happen and high performance to be achieved. An important aspect of that is Systemic Problem Solving, which we’ll look at closer using the World’s Smallest Online Bookstore as a case study for examples.

Systemic Problem Solving

Most teams that I encounter are very good at solving specific problems locally (at the team level). What is missing is a bigger picture, holistic view. Systems thinking is a tool that helps you take a Systemic - or bigger picture - view of whole systems.

Let’s look at a couple of common organization problems as examples – namely “Long Regression Cycles” and “Product Owner can’t seem to stay focused on the big picture”.

Long Regression Cycles

Hereafter: LongRegressionCycle

The Org Team recognizes that it has a problem with the regression cycles as illustrated:

Regression Runtime in Days

When long regression cycles are an issue, without a systemic approach the organization might first try adding more people to do regression testing. As a second step, they might try automated testing through the browser/GUI using a special team who has access to an expensive tool. Unfortunately, as we see below, this will likely lead us down the wrong path:

Long Regression Cycle Casual Loop Diagram

This is a simple causal loop diagram – it’s intended to help us look past the initial problem and see deeper causes.

Variables create cause and effect within a system. In a causal loop diagram, you start with a single part of the system that you can already identify and just keep asking “what influences this part?” then draw links between the interconnected parts using arrows pointing in the direction of influence. Once you can no longer think of additional parts or influences to add, you have a closed loop.

In this example, we can envision what may happen by playing through the loop, starting at “Features added” and following its influence to the “Regression Cycle Length”. Keep going, and we can see that the often-used simple fix of asking a special team to automate regression tests through the Browser/GUI influences many variables and eventually exacerbates the problem that it was intended to solve.

The diagram makes it clear that GUI based automation is fragile, and having all the work done by a special team is creating an island of knowledge. These two problems combine, increasing the time it takes to find bugs and eventually even increases the number of bugs themselves.

To solve the underlying initial problem, we would have to also find an approach that doesn’t recreate these same issues! Instead of a special team doing all of the test automation, the work should be done by every team. Instead of doing all the automation through the browser, do most of it through public api’s (or their equivalent) that exist at the boundaries of the system.

Before making any change, the team creates a new version of the causal loop diagram to see if their proposed solution is an improvement on the original.

Product Owner Can’t Stay Focused on the Big Picture

Hereafter: UnfocusedProductOwner

In a second example, the Team sees a Product Owner making frequent revisions to the Team’s work in Sprint. We can talk to the PO about this, but we can’t just expect the PO to change unless we also identify and fix the underlying problem.

Product Owner Can't Stay Focused

As this image illustrates, we can see that the real problem is that the PO is under daily pressure from stakeholders to solve real and perceived customer problems. The challenge is how to set aside enough time to deal with those issues, while still making progress in the bigger goal. A causal loop diagram like this should help the organization discover the need for Portfolio Management, which would give the Product Owner some boundaries on how much short term work they should accept from the Team.

In each case, the key point is that the Org Improvement Team must make sure that they’re solving the systemic - and not just surface - problem.

So let’s look at how the World’s Smallest Online Bookstore teams might do that, using a Scrum-like framework to achieve it.

Our World’s Smallest Online Bookstore Organizational Improvement Team is working in two-week Sprints to stay in sync with their Development Teams. As we learned in this post, the Org Improvement Team operates in a manner similar to a regular Scrum Team, just with a few slightly relabeled components.

Organizational Improvement Team

Let’s see how the Organizational Improvement Team will tackle these problems.

Organizational Improvement Queue (aka Product Backlog)

Since the causal loop diagrams above showed us that creating special teams for test automation and simply asking the Product Owner to change weren’t going to solve the problems.

The Org Team can avoid wasting time on ineffective, localized solutions and focus the Improvement Queue on finding specific things that will contribute positive systemic results. Such as:

LongRegressionCycle - Involve more members of each Development Team in test automation;
LongRegressionCycle -Find alternate means to test automation that don’t involve the browser;
UnfocusedProductOwner - Support the Product Owners in saying no to more expedited customer requests…

Organizational Queue Refinement (aka Product Backlog Refinement)

After discussion with the Development Team representatives and the Team level Product Owners, it is agreed that the pressure that the POs feel to respond to all customer issues within two days is getting in the way of the Teams delivering on both quality (which leads to more customer issues) and the big picture. They also identify the need for site license JetBrains IntelliJ and “Reducing Product Build Times from 15 minutes to 5 minutes”.

Sprint Planning

The Org Improvement Team commit to running several experiments to resolve the UnfocusedProductOwner challenge. Since this problem will need several months to address completely, they decide to do the following:

Limit the number of Customer Expedite Issues that a team will be asked to handle in one Sprint to two (down from the four that currently happen most Sprints).
Suspend the current PO bonus system for 6 months – taking the bonus pressure out of the equation for now. Wisely they don’t try to get rid of this altogether yet – while bonuses are often distortive and lead to strange behaviours in the short term, this is too big of a problem to tackle at this time. Instead, they’ve delayed dealing with until a later date.
Give the existing Portfolio Management Team a stronger mandate. Once decisions are made at the Portfolio level, these goals supersede the needs of any one customer. If there are special customer needs, they need to be approved at the Portfolio level and not just left to an individual PO.
In addition, to stem the worst of the problem with LongRegressionCycle, they suspend the current automation through the browser approach for now. This isn’t really a solution, it’s just avoiding making a bad situation worse. In the context of the SmallestOnlineBookStore, this may be the best that the Org Improvement Team can do for now.

The first three tactics are really just trying to give an already good PO some better tools to say no to all except the most important customer issues.

In addition to the big item that the Org Improvement Team committed to tackling, I would also find a couple of smaller, high-priority items that are likely achievable in the first sprint, such as the JetBrains Site license and “Improve Build Times by at least 5 minutes.” This won’t solve all of the problems for the Product Owners – just a manageable first step for one Sprint, which will be valuable to get the Team started, show the rest of the company that change is coming and prove to the Organizational Improvement Team themselves that they can make change.

In Sprint

Org Team Members work with ScrumMasters, Team Level Product Owners and some team members to update the Portfolio Kanban Board. They review the Portfolio Kanban Board with the rest of the management team including the C-level execs so there is a clear of understanding of which features will delivered in the near future.

Daily Scrum

Several times in the week the team members gather on the edge of the Dev Team work areas for their equivalent of a Daily Scrum. They make it clear that the events are open to all and share information about the progress on their commitments for the Sprint.

Sprint Review

At the end of the Sprint, the Org Improvement Team review how many Customer Expedite Issues each of the Development Teams had to deal with. While there was a reduction, it is still higher than their commitment in Sprint Planning. This hints that on the next Sprint, the Org Improvement Team might consider more action.

In addition, the Build Times have reduced by 3 minutes, from 15 to 12. The people who put the effort into this explain that the simplest improvements have now been done and further reductions will require upgraded hardware or parallel builds.

They invited all interested Dev Team members to the event so that the news of the improvements (small as they were) started to spread.

Retrospective

The Org Improvement Team realize that part of the reason they didn’t meet all of their goals this Sprint is a lack of time dedicated to solving the systemic problems. For their SMART goal, they commit to each helping drive at least one issue to truly done, setting aside other executive work if required.

Conclusion

In our last post we saw what we needed:

“Respondents report that senior management sponsorship and support is far and away the most important factor in adopting Scrum.” (2015 State of Scrum Report)

To succeed:

Small Wins – the Org Improvement Team are making an effort to start to resolve the bigger challenges
Communicate – the Org Improvement Team engaged the Dev Team Members in the formal events (Daily Scrum and Sprint Review) and informal conversation to share their progress
Show how we’ve engaged Management to constantly review Portfolio Board, to understand Scrum, and to be involved in solving the problems that Scrum finds – the Portfolio Kanban board was reviewed by Senior Management with Dev Team Members present
Build on the previous successes – they haven’t been working long enough at this yet
Tie changes back to the bigger reason that the organization is undertaking the change (usually Quality or Time to Market). – the Org Improvement Team explains to all that the solving the Product Owner focus problem will help improve Time to Market and also Quality

Even with an Organizational Improvement Team, problems still aren’t easy to solve, but they’re solved more easily when addressed at the right level.

Images by Agile Pain Relief Consulting. Elements of first image designed by Freepik.

Taking Organizational Improvement with Scrum Seriously

Tue, 15 Sep 2015 00:00:00 GMT

Beyond Scrum: Scrum Alone Is Not Enough

(Presented as Part 4 in the Scrum Alone is Not Enough series, and accompanied by this case study of Organizational Improvement in WorldsSmallestOnlineBookstore.)

If Agile change initiatives don’t produce at least the doubling in productivity that is possible, it’s often because Scrum is used as a wrapper around the current state of work, but the organization has failed to introduce the fundamental changes that Scrum should inspire.

Failure happens when Senior Management doesn’t understand the impact of their lack of involvement in the change.

Some managers don’t understand the principles that underlie Scrum: self-organization, the importance of delivering working software every sprint, the impact of multi-tasking, etc. They fail to recognize that Scrum isn’t about improving one team in isolation and, as a result, they can act in contradiction to the principles.

Other managers have teams that have established Portfolio Kanban Boards but they don’t review the boards with their teams. Management hears about problems, but lacks proper understanding of their context. Lacking context, management fails to act.

Either way, people in the organization begin to feel that Scrum is just being wrapped around the existing state and that nothing changes. They feel that Scrum is only being paid lip service.

Scrum isn’t intended to work this way. Scrum is a tool to optimize the whole organization.

From the 2015 State of Scrum Report:

Interestingly, 71% also believe that using Scrum causes tension with other parts of the organization not using Scrum.

We expect some tension to be a perennial challenge, just as with any organizational change. After all, Scrum requires a shift in an organization’s culture.

… though senior management support is considered critical in Scrum adoption, only 7% of respondents reported that as visible in their organizations.

Solving these problems requires Senior Management to be involved in solving issues and obstacles on an organizational level.

One approach is to create a Change (or “Improvement”) Management Team to help coach the Leaders through the transition, to migrate toward improving to empower, and to assist those who work for their groups. This should involve a Scrum (or Kanban) like approach to organize themselves and do the work. To minimize confusion in this article, we will call this team the “Org Team” and regular Scrum Teams “Development Teams”.

Goal

Create an Org Team whose focus is working to understand what obstacles may need to be removed or mitigated to help the organization as a whole, regardless of what level within the organization that may be. Their aim should be to:

help both Management and the whole organization deeply understand what Scrum is and how it instigates change throughout the organization;
help Management see the impediments their teams face on a regular basis;
help Management improve communication with their doers;
focus on the Strategic Goals, not just the tactical needs of the individual “Development Teams”; (See the upcoming article on defining your Organizational Goals and helping teams align with that.)
and solve problems systemically and not just the surface issue.

Membership

Select the Org Team ¹ with an eye to personnel who can bring about effective change. Consider:

knowledge of the internal challenges as well as what is happening outside the company;
knowledge of how the company is actually working – not the organizational structure or policies but what is really happening on the ground;
sufficient influence and power, so that once decisions are made, they can be implemented without much more debate.

In many organizations this will mean the Org Team will be comprised of Directors or Vice Presidents; in smaller organizations this will include the CEO/President.

Some of these people will also be part of the Portfolio Management Group. It’s also important to look beyond the existing Management team to ensure we get greater diversity of thought, and that existing approaches are challenged.

Since we’re going to utilize a Scrum-like approach to self-organize the Org Team, an individual who has a deep understanding of the organizational problems that the development teams face should be chosen to play Product Owner. In many cases this will be a Scrum Coach or an individual team’s ScrumMaster. The person needs a deep enough understanding of the issues to help bring clarity and provide a sense of priority.

For the ScrumMaster, you should look to someone who has a solid understanding of Scrum, and who can facilitate the Org Team sufficiently to allow things to happen, but also has sufficient influence to help their executive peers achieve the commitments. It is critical that this person be an employee and not an outside consultant. We can’t afford to have the knowledge that is grown here leave when a coaching/consulting engagement ends.

The remaining team members, unlike a normal Scrum Team, will not be full time, however they must dedicate a significant amount of effort each week to resolving issues that are harming their teams.

Working Group vs Real Teams - this needs to behave more like a real team, which implies a core full time membership

Mechanics

Run the Org Team with a Scrum-like approach where they organize themselves and do the work.

Product Backlog – aka Organizational Improvement Queue. Instead of a list of User Stories, the queue will consist of a list of changes or improvements. Like User Stories, it’s best if the items state the underlying problem rather than the solution. When the statements stay focused on the problem and not the solution, we keep the door open to more creative ideas than previously imagined.

The Improvement Queue must be public and any team and their members should be able to add an item to it. In organizations where many of the teams are in the same place, it is best to maintain the queue next to the Portfolio Kanban Board, giving everyone a place to go and see a good summary of the state of the organization.

All of a good Product Owner’s standard prioritization tricks will come in handy here: Buy a Feature, Business Value Poker, Impact Mapping, and more. The key to all of these activities is to ensure that they involve stakeholders: Development Team Members, Team ScrumMasters, and others who are affected by the changes.

Also, with the queue being public, team members can see why their current problem - while important to them - may not be the highest priority for the whole organization.

Sprint Length – 2 to 4 weeks. Shorter is better as it gives more opportunity to adapt to the changing needs of the teams and more opportunity to demonstrate small wins. See: Choosing Sprint Length for tradeoffs

Sprint Planning – At the beginning of every Sprint, the Organization Team sit down and, just as with Development Teams, it works well to break planning into two parts:

Goal Setting (which problems do we commit to resolving that Sprint)
Task Breakdown (team members take a crack at potential solutions to get a rough idea of what they need to do to solve the problems)

Who: Organization Team Members and stakeholders (i.e. Development Team Members) whose problems are at the top of the Queue.

As we create this Org Team - aka Change/Management Team - are you starting to notice some familiar concepts with the why/who/when of it?

Are you seeing similarities to a regular Scrum Team?

Good. Keep that thought.

So far we have established the Goal – why an organization would create an Org Team and what purpose they’ll serve. We’ve discussed the Membership – who should be on the Team and the strengths they need to contribute. And now we’re into the Mechanics – how to make it all work effectively. Let’s dig further into that.

Product Backlog/Organizational Queue Refinement ² - (the Org Team version of Product Backlog)

Just as effective Development Teams refine their Product Backlog, the Org Team does the same at least once per sprint for a couple of hours at a time, to ensure the Organizational Improvement Queue is ready in detail for the next couple of Sprints and to ensure that they have a sufficient understanding of the work in the medium term (3+ Sprints).

The recommended focus is on Organizational Challenges rather than Stories, but the outline remains the same. Also, I have not found the basic planning poker estimation to be as effective in this context. Our Organizational Team needs to meet a group of ScrumMasters and members from Development Teams to refine their collective understanding of the problems that need to be solved. This will be a time-consuming exercise. Some clients have short-changed this, and I’ve seen them waste considerable time solving the wrong problem.

In addition, as part of the Queue Refinement Session, the Organization Team should review the Portfolio Kanban board to see if there are issues that they can help address easily.

It’s important to note that this is not a forum for Senior Management to complain about their teams or to hold the team’s feet to the fire. In general, Development Teams want to be more productive. They want to hit their goals in terms of delivering greater value to the customer.

This is a mechanism to give management an opportunity to be true leaders by resolving the issues that are getting in the way of their teams.

Daily Scrum – Given the part-time membership of this team, having daily meetings is likely to be too frequent. Instead, they should meet 2-3 times a week. With many clients we’ve done this just before any of the team level Daily Scrum, then Org Team attendees can go on to share the progress towards resolving their issues with their teams.

Along with the usual goals of Daily Scrum (prepare for collaboration, check if we’re on target, and sense impediments), there is an important additional goal: help all Development Team members see that change is coming even when it is slow.

It is most effective if this event is held in a public place, often in front of the Portfolio Kanban board.

Who: Organization Team members and representatives of Development Teams.

Sprint Review – Development Teams normally demonstrate working software to their stakeholders. In this case, the Org Team’s demonstrable product is solutions to organizational problems. Where practical, actually showing the solution is best. This activity is the primary means to let people know how problems have been solved and how this will make their world better, so it needs to be fun and engaging.

In addition to the regular Sprint Review, the Org Team needs to share their successes and changes through whatever channels they can – internal email newsletters, posters on walls, town hall meetings etc.

Who: Organization Team Members and a large cross section of the Development Teams.

Tracking – We can either maintain a separate Sprint Backlog or include these as part of the Portfolio Kanban board.

Retrospective – While all of the other activities need to be public, the retrospective needs to be internal to the Organizational Team so they can be open and honest about how they’re using Scrum and how they’re working together. Like all Scrum Teams, the improvements that the Org Improvement Teams agree to make in their own should be made public.

Conclusion

From the 2015 State of Scrum Report: “Respondents report that senior management sponsorship and support is far and away the most important factor in adopting Scrum.”

To succeed

Small Wins – early on it’s important to show that this group isn’t just another committee that doesn’t make real change. Find small things that can be improved and do them.
Communicate - use the Sprint Reviews and Daily Scrums as a opportunity to share successes and help people know what has happened on their behalf.
Show how we’ve engaged Management to constantly review Portfolio Board, to understand Scrum, and to be involved in solving the problems that Scrum finds.
Build on the previous successes.
Tie changes back to the bigger reason that the organization is undertaking the change (usually Quality or Time to Market).

Risks

Where I’ve seen this fall apart – when Management feels this is special and not part of their **work**. To succeed, it is important that this becomes part of their normal work. Consider bringing all Management work through this group.
Not closely tied to vision or strategy.
No real urgency – See Jon Kotter – “It all Starts with a Sense of Urgency” (pdf).
Not enough energy from Management to solve the problems revealed. Will signal to the teams that Scrum is fine at the team level, but the organization doesn’t believe in real change.
Tactical and not Systemic focus will wear out the people who are involved in the change without making the real changes needed.
Without sufficient backing and support for real change, this just turns into a gripes forum.
Wrong people in the room – usually people without enough organizational heft and skill.
Lack of leadership skills and Change Management Experience.

Alternatives: Some people take the same approach except the Org Improvement Team uses Kanban instead of Scrum. Personally, I prefer them to use the same approach as the majority of their development teams, but whether they use Scrum or Kanban is less important than clear and visible progress towards solving their organizational impediments.

Scrum requires real change from an organization at all levels, not just the team level. This pattern describes one way of ensuring that the executives are involved, that this becomes the core of their work, and that they truly understand Scrum. (See this in action though the case study example.)

Integral to doing this well is an approach to Visualizing all the work items (see Portfolio Kanban - part 1, part 2) and Managing the work itself (see Portfolio Management - part 1, part 2).

References: https://www.forbes.com/sites/stevedenning/2015/07/22/how-to-make-the-whole-organization-agile/

My thanks to Zuzi Sochova for their feedback in writing this.

Image by Agile Pain Relief Consulting. Elements of image designed by Freepik.

Footnotes

Derived from Jon Kotter’s change model – see “The Heart of Change” – one of his several books on change. https://www.amazon.ca/The-Heart-Change-Real-Life-Organizations/dp/1422187330/&tag=notesfromatoo-20 ↩
This is really the same as Product Backlog Refinement – however like many I find “Backlog” an odd word because it implies you’re late even before you start work. ↩

TDD Randori Session

Wed, 08 Oct 2008 00:00:00 GMT

We ran our first TDD Randori session at lunch today (approx 15 attendees). I was inspired by Dave Nicolette’s session at Agile 2008 and used the Danilo Santo’s paper on their Brazilian Coding Dojo as a guide.

In a Randori we work as a group trying to solve a small problem using TDD:

There is one computer with the video output projected on a screen so all participants can see it.
Coding is done at the single computer by a pair of developers.
One half of the pair switches out every 5 or 10 minutes.
The pair on the keyboard should continuously explain what they are doing.
The pair on the keyboard should stop when someone from the audience falls off the sled — and only continue when that someone is back on track again.
The audience should give comments on design only when there is green bar. (During red bar audience can only ask questions)
The pair should not continue on writing new code if other participants are not happy with the current design (The code should be always well refactored before starting to write new code)
The pair will use TDD (Test-Driven Development).

I picked the problem based on a complaint I’ve heard from people after many of the TDD classes: “the examples are too trivial and don’t speak to real world problems. I also hear that we don’t enough chance to practice TDD”.

For our initial example to trying working through we tried: Brian Marick’s “A workbook for practicing test-driven design”. The problem and sample code come from the world of Hierarchical Data Format (HDF), a library for storing large amounts of scientific data. Brian provides an initial simple implementation and then invites the reader to make some changes:

…
Add the ability to read and write unsigned 4-byte integers, something like:
```
dataset.defineMember(Like.unsignedInteger(4));
```
Add the ability to write arrays of Strings…
Surprise the PO changed their mind_._

So far so good. In the 60 minutes of coding time we had we were able to make solve #2 with an elegant solution, but got hung up in #3. To introduce Strings we had to take a big step, much bigger than TDD would encourage. Net result we got caught in a bit of tangled mess and ran out of time before could tidy it up.

After the session we conducted a very short retrospective using happy and sad post it notes and dot voting (both from Agile Retrospectives: Making Good Teams Great).

In the Happy category we had:

Live Exercises are fun.
Talk about the advantages of TDD were good.
Good to go through an example with everyone and the discussion that was raised.
Excellent discussion of choices around refactoring
The example was good. Oddly enough this will be contradicted later on.
Initial Tests went well
Good Practical Introduction to TDD.

In the Sad category we had:

Just use a simple Java class and grow it using TDD.
The problem domain for the example was too abstract for most people and was hard to make sense of. Solution try a problem domain that people are familiar with i.e. Ron Jeffries Bowling game etc.
The Example required too much assistance and special knowledge from the moderator.
Start with no tests on an existing project.
Too much discussion from the audience.
The moderator (me) was too involved in the exercise. Solution maybe I shouldn’t be moderator for these sessions.
Topics not directly related to the exercises should be parked. Oooppss. I’ve was so focused on the content I forgot to put up a parking lot.
Let people make mistakes.
The pilot and co-pilot were often too quiet
A separate high level introduction to TDD and its advantages was requested.
We ran out of PIZZA. 2 extra large pizzas will not feed 15 people.

Going Forward

A single session will not hone anyone’s TDD (nor my moderation) skills. I suggest that we continue to meet in the future (every two weeks). For the next session I will find a smaller problem - perhaps a few classes of untested code. We can set the goal testing it, simplifying it and making changes as requested by a mythical product owner.

Beyond this it would be useful to have sessions that focus on: Mocks, Test Doubles, GUI’s (Presenter First?), Web Apps, Databases?, other real world problems that teams are encountering as part of TDD. Test Driven: Lasse Koskela is an excellent source book for ideas in this area.

BTW Brian’s HDF workbook is an interesting problem I just wouldn’t expect to tackle it 60 minutes of coding time.

Update: I forgot to mention the TDD Problems site.

Update 2: The followup session: Another TDD Workshop.

TDD Randori Workshop

Thu, 23 Oct 2008 00:00:00 GMT

A few weeks ago I ran my first Coding Dojo/Randori and while the participants learned from the session there had been a few key flaws:

The problem was too big
The problem was in a domain that was unfamiliar to everyone
The facilitator (me) participated too much Ouch. It was true.

This week we ran a second session and had a much better time. The key to success - pick a smaller problem and let people struggle for a good long time before making suggestions. In addition remind them frequently to ask the audience for help.

This week’s problem:

Score a bowling game, (credit to Bob Martin and Ron Jeffries for the idea) based on the following rules:

A single bowling game consists of ten frames.
For each frame, a bowler is allowed a maximum of two rolls to knock down all ten pins
When a Strike is thrown, the current frame is finished
Scoring: • 0-9 pins knocked down: score the number of pins • Spare: 10 + number of pins knocked down by the next throw • Strike: 10 + number of pins knocked down by the next two throws.

Effectively this means the ball after a Spare is counted twice - once for the spare and once for the strike. With Strikes the next two balls are counted twice.

Scoring Examples (from wikipedia): A Single strike:

Frame 1, ball 1: 10 pins (strike)

Frame 2, ball 1: 3 pins

Frame 2, ball 2: 6 pins

The total score from these throws is:

Frame one: 10 + (3 + 6) = 19
Frame two: 3 + 6 = 9

TOTAL = 28

Mulitple strikes:

Frame 1, ball 1: 10 pins (Strike)

Frame 2, ball 1: 10 pins (Strike)

Frame 3, ball 1: 10 pins (Strike)

Frame 4, ball 1: 0 pins (Gutterball)

Frame 4, ball 2: 9 pins

The total score from these throws is:

Frame one: 10 + (10 + 10) = 30
Frame two: 10 + (10 + 0) = 20
Frame three: 10 + (0 + 9) = 19
Frame four: 0 + 9 = 9

TOTAL = 78

It appears this problem was much better suited to where the group is at now. To start the process off I seeded the work with a few tests (TestOneThrow(), TestTwoThrows(), testMutilpleFrames(), testMidFrame()) and a trivial amount of code to satisfy the problem. As the product owner I asked the team to add the following features:

The bowler throws one spare
Scoring reverts to normal after throwing a spare
The bowler throws a strike
Scoring reverts to normal after a strike
Score successive spares
Score successive strikes
Score a perfect game (300 pts).

We made fairly good progress through the feature list but didn’t manage to tackle the last three features. With one of the failing tests early on we had good example of why the parameter order matters in JUnit’s asserts. The asserts are written assertEquals(Expected, Actual) = if the test fails JUnit says “Line XXX epxected 42 was 22”. Get the parameters in the wrong order and more than a few minutes will be wasted trying to solve the wrong problem.

Towards the end (working on the the bowler throws one strike) the pair at the computer was bogging down unsure why things weren’t working. At this stage I intervened and helped add sysout’s in every branch to illuminate what paths were being followed, It turns out that several mistakes had been made and the wrong paths were being followed in test cases. While I shouldn’t have intervened it did break the log jam and allow the team finish the feature. At this stage the team feels the code is a bit of a mess and so we will pick up the exercise from the same place next time.

Our retrospective generated a much smaller set of notes this time: Happy:

Lots of pizza
Good problem (everyone understands the rules of bowling)
Fun to learn about bowling
Good hands on experience
Much better level of involvement from the facilitator
Having some working tests and code to seed the exercise is much better than starting from a blank file.

Sad:

Need more involvement from the audience.
Should’ve brought a mouse - I did last time Doh.
Didn’t really understand bowling until halfway through the session

So net result I picked a better problem than last time and we all learned a little about TDD. In addition we all discovered that scoring in bowling looks deceptively simple but in actual fact is a non-trivial problem.

Problem sources for Coding Dojo’s:

Coding Dojo Wiki
TDD Problems Wiki
Danilo Sato mentions a few others that I’m not familiar with.

Have you tried a Randori or Coding Dojo? What was your experience?

Scrum by Example – Team Friction Inspires Working Agreements

Thu, 23 Nov 2023 00:00:00 GMT

Team Friction? Working Agreements may be the solution you need.

Scrum team Working Agreements are a simple, powerful way of creating explicit guidelines for what kind of work culture you want for your Team. They are a reminder for everyone about how they can commit to respectful behaviour and communication. In this post we’ll see how the fictional World’s Smallest Online Bookstore (WSOBS) Scrum team struggles without a Working Agreement, and why having one would be useful.

Acceptance Criteria

Dramatis Personae

Steve: - A scrumMaster and the hero of our story

Paula: - The Product Owner of Steve’s team

Kirby – one of the Team’s software developers

Tonia – the Team’s Quality Assurance specialist

Doug – another of the Team’s software developers

Ian – the Team’s Business Logic programming specialist

In the past few Sprints, there have been moments of social friction noticed by both Steve and the rest of the WSOBS Team. They included:

Kirby was blunt when discussing a defect with both Tonia and Ian.

Some discussions with the whole Team became so heated that the quieter team members stopped speaking up for several days.

Doug was late for Daily Scrum on several days.

On multiple occasions, Team members needed to ask Paula some questions, but she wasn’t available by email, and they often didn’t know how to find her.

None of these individual issues was truly bad, however, taken together and left unchecked, they harm the Team’s cohesion. When that happens, people opt to stay silent when there is an opportunity to share an opinion, and events like Daily Scrum becomes less useful when Team members signal their disrespect by frequently being late.

During the next Retrospective, Steve mentions a few of these issues and says that he wants to talk about making their environment better. Tonia shares that she knows another one of their peer teams has created their own Working Agreement to reduce some of the friction and improve respect.

Before we see how Steve helps his team in this episode, let’s make sure we understand what a Working Agreement is, and should be.

What is a Working Agreement?

A Working Agreement is a short set of guidelines created by the Scrum Team, that establishes what the expectations of the team members are for one another. A well-written Agreement should help establish and reinforce a clear, shared understanding about what team members agree is good behaviour and communication.

Why do Working Agreements Matter?

Working Agreements help make implicit social expectations explicit. (Whoa, that’s a mouthful.) They invite team members to tell each other what matters to them on a whole host of topics. This leads to a shared understanding and, in return, a reduction in friction. Done well, they also invite open and honest communication which helps create psychological safety.

Characteristics of an Effective Scrum Team Working Agreement

A Working Agreement doesn’t have a police force to ensure that it’s followed. Its effectiveness comes from being:

Public and Visible – preferably written in a large font and posted in a prominent space (perhaps where Daily Stand-up takes place)
Collaborative – created by all, not imposed by others
Short – a small list of agreements that are easily remembered and lived up to trumps a big list that overwhelms people and gets forgotten
Updated Frequently – Taiichi Ohno once said: “If the kanbans do not change for one month, you are salary thieves”
Consequential – when the agreements are violated, Team members call out the violation with respectful reminders

Working Agreements Should be Unique to Team Needs

Each Scrum Team will create its own Working Agreement based on the context of its work. Elements of an Agreement might include some of these examples:

Core hours – times during the day that all Team members agree to be present and available for collaboration.
Daily Standup – the time that it happens.
Attendance for meetings or events – whether or not you agree to support decisions made. in your absence, whether you will let your team know in advance if you can’t attend.
Product Owner – availability and contact information.
Definition of Done - an agreement about quality
How the Team limits Work in Progress.
How the Team ensures everyone has an equal voice and feels respected. For example, use of a talking stick, where the person who has the stick has the opportunity to talk and everyone else focuses on them. My favorite tool is a bean bag or ball that can easily be tossed from person to person, rather than a stick.
Decision-Making Process and Rules - establish a clear process for making decisions: consensus-based decision-making or voting mechanisms as needed. (See Why Group Decision-Making Techniques are Important for more depth.)
Skill development – maybe it’s agreed that during each Sprint at least one Team Member will work on growing a skill outside of their core strengths.
Technical Debt - in the case of software development, maybe there’s an element that states every Sprint the Team will make an effort to improve some part of their codebase.
Impediments - Guidelines for handling them.
An understanding of how to resolve conflict – for example, ask for a facilitator, or echo back your understanding of the other person’s viewpoint, etc.
Handling Outside Interruptions - define procedures for managing interruptions during the Sprint itself, such as setting expectations with stakeholders and limiting distractions within the team.
Sustainable Pace - how can the team ensure that they’re committing to work that is realistically achievable in the Sprint?
Team Values - review the Scrum Values and decide how they apply in your world. As a reminder, the Scrum Values are “Focus, Commitment, Courage, Openness and Respect”. Many teams also discuss topics that include collaboration, continuous learning, and customer focus.
Communication Channels - agree on preferred communication channels (e.g. Slack, Microsoft Teams) for day-to-day interactions and set expectations around response times. (Hint: instant response is unhealthy.)
Collaboration Tools - choose appropriate tools (e.g. Mural, Miro) to facilitate team collaboration and ensure everyone has access to them.
Celebrating Successes - how will the team celebrate successes?
Handling Disagreements - establish protocols for addressing disagreements within the team.
Violations of Working Agreements - define a simple rule on how to point out when someone breaks the working agreements.

Co-located teams might have working agreements for:

Cell phones – if or when it is appropriate to use them during Team events.
Headphones – when it is fine to use headphones, versus when Team members will not use them so they’re available to communicate and collaborate with others.

Remote teams might consider:

Use of cameras in online meetings - establish guidelines around camera usage. (Hint: collaboration is more effective when our cameras are on where possible.)
Commitment not to use other tools (email, chat, phone, …) during team events.

Hybrid teams:

The day(s) of the Sprint that all team members commit to being in the office (Hint: where practical, Sprint Planning, Review and Retrospective are more effective in person.)
How to include remote team members in a meeting when half the team is in the office and the other half is online.

Working Agreements and Scrum Values

As part of a team coming up with their own list of elements to have in their Working Agreement, it is worth considering the Scrum Values as a source of guidance:

Focus: Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
Courage: Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
Openness: As we work together, we practice expressing how we’re doing, and what’s in our way. We learn that it is good to express concerns so that they can be addressed.
Commitment: Because we have great control over our own destiny, we become more committed to success.
Respect: As we work together, sharing successes and failures, we come to respect each other, and to help each other become worthy of respect.

Teams normally create a Working Agreement before their first Sprint by setting aside an hour or two beforehand. In the case of our fictional World’s Smallest Online Bookstore (WSOB) Team, they haven’t yet. No time like the present!

How To Build a Scrum Team Working Agreement - How Can a ScrumMaster Help?

Sensing the atmosphere of the Team, Steve starts by helping them learn about Working Agreements. He first ensures that the Team understands what Working Agreements are, and how they will personally benefit from having them.

Mark’s note: Spending some time on a good setup will reduce cynicism among Team members. Giving people some categories or areas in which Working Agreements will help, gives them a framework. For instance, in our workshops, categories are cell phones, laptops, break times, and punctuality. In the context of a Team, you might use some of the areas mentioned above, and perhaps draw on the Scrum Values, but ultimately the Team chooses what works best for them.

Steve then facilitates a Retrospective to help the Team and Product Owner come together to sort out some of their problems. During the process, they discuss the friction they have felt over the previous few Sprints. They agree to create a Working Agreement and, since it will likely take over an hour, they elect to make it an action item for the next Sprint Retrospective.

There isn’t an official or correct way to create Working Agreements, so Steve uses the approach that I share in my workshops. As usual for a ScrumMaster, good preparation pays dividends. Consider canvassing the Team beforehand about categories/areas for agreement.

Facilitating the Creation of a Working Agreement

Check-In

As with Retrospectives, asking check-in questions helps to give team members an opportunity to engage with the purpose (in this case, create a Working Agreement) and to understand what might have your teammates worried or preoccupied. Try using a round-robin format, where each person speaks one-on-one with everyone else, in turn.

Some opening questions you might use:

What has your attention today?
What keeps you up at night?
How would you describe where your head is? And your heart?
What are you grateful for?
How are you feeling today?

Once we’ve established where our teammates are at as people, we can move on to crafting the working agreements proper.

Coach, But Don’t Lead

Use prompt questions such as the following examples to help the group craft their Working Agreement:

“What are the decisions that, if made now, could help us in the future when the pressure is on, or things haven’t gone our way?¹
How do we envision our interactions and behaviours?
What are our shared values and principles?
How do we handle conflict and challenges?
How do we hold each other accountable?
How do we uphold these working agreements?

Get everyone to answer. Explain the format you will use and any ground rules that you have in place. For example, you might have ground rules:

Assume positive intent
If you say ‘no’ to a proposed item, you’re expected to try to make it better.
Use the Decider Protocol:² Thumbs Up – I’m good; Sideways – I can live with it; Thumbs down – I will block this proposal.

Break groups larger than five people into sub-groups. In my experience, it’s easier to get small group agreement first, then bring it back to the whole.

Invite the small groups to create a potential Working Agreement in each area or category. Invite them to create any additional Working Agreements they feel are needed to address concerns or conflicts.

At the end of 5-10 minutes, get the groups back together and review the proposed items.

After a couple of rounds of proposals, if there isn’t any consensus on a particular item, move on —they can’t establish an agreement in that area for now. Consider revisiting the item the next time Working Agreements get deliberated.

Every few Sprints, the Working Agreement should be updated, often by checking it in Retrospective and asking a question like, “Are these still our working agreements? What would we like to update? What areas need new agreements?”

After talking to Team members, Steve selects “Daily Scrum Start Time,” “Respect,” “Phone usage in Team Events,” and “How to give everyone equal voice for discussion” as elements to include in the Working Agreement. He explains that if there are other categories that the Team would like to consider including in the Working Agreement, they’re welcome to add them as they go.

Given the previous friction between some Team members, he opts for a 1-2-4 model³ for discussing possible agreements. This model is designed to ensure that everyone has a voice in the process:

Each Team member (1) takes a few minutes to share to the whole group their ideas for potential agreements in each category.
They then work in pairs (2) to record the best ideas from each person. As facilitator, Steve is paying attention to the conversations and outcomes. It should be a red flag if one person is dominating their partner during this step.
Next, they move to groups of four (4) to further consolidate their ideas and present them to the group for discussion. In the case of Steve’s Team, there are only six people, so they skip this step and move straight to final group consensus.

Steve starts asking for proposed agreements in their first area of focus: Daily Scrum Start Time. After each potential working agreement, he uses the Decider Protocol[2] to check for consensus rapidly. When there isn’t immediate consensus, the person who said ‘no’ to an idea suggests what they think is a better one. If multiple people have an issue, then each is expected to offer a better idea. If too many people say no, then the proposer should consider withdrawing the proposal.

In the case of Steve’s World’s Smallest Online Book Store Team, after 20 minutes, the team have their first set of Working Agreements:

Respect – when another Team member is talking, don’t interrupt. When they’ve finished, pause, reflect, and share back your understanding of their idea.⁴
Make sure everyone has a voice – more vocal Team members volunteer to speak last to give quieter Team members an opportunity to speak up.
Daily Scrum is 9:20 am, allowing all Team members to get their kids to school before coming in to work.
Cellphones in Team Events – they stay outside the room.
To improve the quality of all ideas, we encourage respectful dissent. At least one Team member volunteers to be the dissenter. Even if they think the original idea is good, they’re expected to find criticisms of the idea with the goal of making it stronger.⁵
Focus – during the Sprint, the Team is focused on the Sprint Goal. If something comes up that doesn’t fit the goal, Team Members are expected to say no.

Notice that the last two items weren’t among those previously suggested by Steve, instead, they appeared organically. For more on how psychological safety and collaboration contribute to team effectiveness, see Characteristics of Effective Scrum Teams.

Steve then offers a suggestion of his own: “If you miss a meeting/event it is expected that you will support the decisions made there.” Kirby, who has previous experience facilitating, reminded Steve that if he truly is playing the role of facilitator as part of his ScrumMaster duties, then he is expected to remain neutral and not inject his own ideas.

Working Agreements - the solution to create the work culture you want for your team.

The Team compiles all the individual agreements in the Working Agreement and posts it on the Team room wall. In the months afterwards, Team members slowly get used to the idea of reminding their peers of behaviours that don’t honour the Agreement. Every few Sprints, Steve asks in a Retrospective “Is this still our Working Agreement? Is there anything you would like to change?” The list evolves as Team members find more areas where they see benefits. After six months, they find themselves much better able to deal with tense problems within the Team, or when the outside pressure increases on them.

Want to learn how to put together really effective Working Agreements?

If there is one idea at the heart of Scrum and Agile that is most important, it is respecting the people you work with. When you empower teams to make decisions about how they work, you use one of the most powerful methods to help them be more effective and become high-performing. Working Agreements are a great step toward that improvement. In our Certified ScrumMaster workshops, attendees discover how to support and facilitate these kinds of agreements. If you are committed to helping create a respectful environment for your team, we invite you to join us to learn how and to gain practical, hands-on experience.

Image attribution: Agile Pain Relief Consulting (Updated November 2023)

Footnotes

Test Driven Development vs Plain Old Unit Testing

Sun, 24 Feb 2008 00:00:00 GMT

Lighthouse and a boat- image licensed from Photodune

Scruffy Looking Cat Herder (aka Jacob Proffitt) recently wrote Test Driven Development considered harmful. Jacob is writing about why he believes that TDD zealots have caused people to skip unit testing altogether. I allege that Jacob is missing the boat here.

The gist of Jacob’s hypothesis has five points which I summarize:

Unit testing provides benefits when used regularly.
Ensuring that developers write unit tests is the prime benefit of test driven development.
Most unit test advocates are also TDD proponents.
Looking for information on Unit Testing? You’re most likely to find a piece encouraging you to test first.
Many developers skip Unit Testing altogether because TDD seemed too hard or too much of a change.

Jacob starts off by assuming one and two proven and so moves on a lengthy demonstration that the most important mentions of Unit Testing in Google have some discussion of Test Driven Development. I will grant Jacob points three and four. Although in part I would expect this to be true since Unit Testing and Test Driven Development come from the Smalltalk community which invented both concepts. We have Kent Beck to thank for writing the earliest frameworks and also the seminal book on Test Driven Development. So they get mentioned together because they were invented together.

The most important fallacy of Jacob’s writing is to assume that TDD is merely about forcing test case to written. TDD is about:

Simplifying design
Writing cleaner API’s
Decoupling
Reducing the number of bugs written right at the start.
Thinking about how the caller will see and use your code.

In addition Jacob says that TDD is harder than “Plain Old Unit Testing”. Perhaps, at first as the developer learns TDD, it will be harder but not over the length of a reasonable sized project.

I’ve been on projects where we tried to write all of our tests after the classes were written. Our test suite was valuable and prevented many regressions. But it allowed many issues to slip through. Weaker elements in API’s were often missed and were changed only at a later date at some expense. Tightly coupled code was allowed to evolve making some elements of the application very difficult to test without having to create dozens of other (often unnecessary) objects. As a result of all this it became more difficult to write test cases over time. Would TDD have solved all of these problems? Perhaps not but it would have forced us to confront many of them sooner.

Unlike Jacob I’ve encountered very few people who avoid TDD because they think it’s too hard. Instead the objections I’ve heard are:

“I don’t understand the benefits”
“I don’t believe all the claims I’ve heard”
“TDD won’t work for my project because we build XXX” (Where XXX is your favorite specialized application type: GUI, Web Apps, …)

My suggestion to anyone who tells me it won’t work: Find a mentor; Commit to trying for at least two months. At the end of that time if it still doesn’t work for you then so be it.

Have you been scared off from TDD by the amount of work you believe will be involved with trying to adopt it? Have you been scared off Unit Testing by TDD zealots (such as myself :-) Have you encountered other reasons that people use for avoiding TDD?

Image via: https://photodune.net/

Test Driven Development is Not a Quality Assurance Technique

Tue, 21 Nov 2017 00:00:00 GMT

Effective testing should be done to ensure that a Product solves the business problem, in the way it was intended. It also seeks to prove that no change to the Product harms an existing working system. (It’s a much deeper topic than we can cover here.) These are the goals of Quality Assurance.

So I frequently get asked the question: “Should my testers learn Test Driven Development?” The answer is that, usually, this is not the right technique for them. Because Test Driven Development is not a Quality Assurance technique. Nor is Unit Testing. These are techniques to help shape a Team member’s understanding of a problem, but they do not ensure quality itself. So let’s explore the difference, and common confusion, between these things.

Unit Testing image created by Agile Pain Relief Consulting

Unit Testing is low level development technique where a developer tests one path through a method, in a single class. The goal of a Unit Test is to prove that the developer wrote the code they intended to write and, after writing it, subsequent changes don’t harm that intent.

Unit Testing does reduce bugs by finding some unintended side effects of change, but it doesn’t actually test whether the code solves a business problem, only if it was written as intended. Although it’s useful, one weakness is that unnecessary cohesion and coupling can cause Unit Tests to eventually become brittle.

Test Driven Development image created by Agile Pain Relief Consulting

Test Driven Development (TDD) is Unit Testing where the test cases are written before the code is developed. Again, TDD only proves that the Team Member is writing the code that they intended to write, and it doesn’t test against the business needs themselves. Since the tests are written first, it’s more accurate to say it’s a coding design technique, rather than a quality assurance technique. It is a way for someone with coding skills to ensure that the code they’re writing is a simple solution to the problem they currently have at hand. The benefits are design simplification and refactoring safety net. It reduces bugs mainly by forcing us to write simpler, more readable code, and by finding more unintended side effects of change.

TDD is generally more effective than simple Unit Testing because it forces the person writing the code to think about the problem they’re attempting to solve before any code is written, but it still doesn’t test against acceptance criteria.

Behavior Driven Development image created by Agile Pain Relief Consulting

Behaviour Driven Development (BDD) – also known as Specification by Example and Acceptance Test Driven Development – is where Team Members with coding, testing and analysis skills work in a small group to write tests together. Since many people with testing/analysis skills don’t think in Java/C#/JavaScript/etc, these tests need to be expressed in a simpler language. The most effective approach (from my experience) is to write the tests in a manner that is readable by someone who understands the product but not the code. Even if you don’t have the tools to automate these tests, the act of collaborating to agree on the precise ensures that:

Team members have a common understanding of what is being built
development can move faster because most product-related questions are settled before the work is started
there is less Team conflict when a Product Backlog Item is tested, because all parties have the acceptance criteria they agreed to
clear acceptance criteria encourage Team Members to write the simplest code possible, which reduces defects
defects are reduced even further when you have running automated tests, as they’ll continue to show whether or not the acceptance criteria are still being met

But an important note: even BDD, for all of its value, doesn’t replace manual testing.

So what should Team members with test background learn? I get them to learn BDD collaboratively with their peers, so that everyone understands that it is primarily a “Team member agreement tool” and only secondarily a “test automation tool”. I might even give them a very small taste of expressing tests collaboratively, with simple examples in a tool like Cucumber (or FitNesse or even RobotFramework).

In all Product Owner trainings and many ScrumMaster trainings, we practice a simple version of this technique. My goal would be to simply hint to them what is possible, and then open the door.

If this intrigued you and you want to learn more, see: Behaviour Driven Development in our glossary.

(Image attribution: Agile Pain Relief Consulting)

The Culture Game - Book Review

Fri, 02 Nov 2012 00:00:00 GMT

The Culture Game: Tools for the Agile Manager book image

The Culture Game is a book to give Agile Leaders¹ a tool to help change the culture of their companies. It is intended to help organizations that aren’t ready to adopt something as radical as Scrum or that want help in speeding up the cultural change that Scrum requires.

Taking a leaf out of Dan’s book - the review will be written using the Perfection Game. The Perfection Game is one the Core Protocols that Dan mentions in Part 2 of the book. In the Perfection Game - you give a numeric rating and state what you like and what it would take to make it perfect.

I rate the book 8 out of 10.

What I like:

Part 1 shows how all work is really a game and that taking our games seriously can help improve the quality of work for all involved. Dan also shows that Agile practices help to create a ‘Peter Senge style’ Learning Organization at the team level and that these teams are laboratories for the rest of the organization.
Part 2 is organized as a series of sixteen Patterns that can be used independently of one another or they can reinforce each other.
Core Protocols (mentioned in the ‘Structure Your Interactions’ chapter) - a set of protocols (from …) that help teams create safe rules for engagement in difficult circumstances. It’s been years since I first encountered these and I was delighted to be reminded of them. Formalizing their use is another tool to help create safe places for the teams we coach. They are especially powerful in the context of the Scrum Meetings where all too often we expect people to attend without having gained their explicit agreement.
Run Frequent Experiments - run frequent small experiments and learn from them. Rather than one large experiment, which is what happens when we run a large waterfall project, Dan encourages us to run many small experiments and learn from their outcomes. Failed experiments are not waste. The only waste is when we don’t learn from the failure. This is one of my favourite suggestions to clients. Don’t over analyze, just run lots of small experiments with the goal of learning as quickly as possible.
Manage Visually- post information on the walls. Find information that others will care about (i.e. project status, …) post it on the walls and update it on a regular basis. Most Scrum teams get as far as creating a task wall; few take it further. Borrow from the Kanban world, visualize your workflow, post your Working Agreements, etc.
Game Your Meetings - Think of every meeting as a game - are the rules clear, did the team create them (this section reminded me to use Working Agreements more explicitly), is the goal clear? If we made participation voluntary and made them fun perhaps they would be energizing.

Other Patterns/Chapter Titles (not commenting on them here):

Be Purposeful
Facilitate Your Meetings – hint: ScrumMasters, this is part of your job.
Examine Your Norms
Be Punctual
Announce Your Intent
Inspect Frequently
Get Coached
Manage Your Boundaries
Socialize Books
Pay Explicit Attention
Open The Space
Be Playful
You don’t have to be using Agile to start using these Patterns; nor do you have to be in IT. - The patterns are independent; they can be used in order with any team. Start with a few and grow from there. - The book is full of references to other sources, both books and free online reading. - Dan explains that many good practices have an initial period where they don’t look like they’re delivering benefit, and may even cost in the short term. This is a great reminder for anyone adopting a new practice; before we get good at it, the practice will slow us down. - Tribal Learning only works when all participation is voluntary

To make it perfect

Rewrite Part 1 - the language didn’t seem to fit the topic; as a result I spent more time focused on the style than the content - Better examples in the Subject/Verb/Object - present tense conversation section. Instead of the supplied examples, Dan could have shown a misunderstood communication, then rewritten in the SVO-p style. This would have helped the reader see the power of the style and how it reduces miscommunication. This refers to the Structure Your Interactions chapter. - Provide more examples throughout_. I would have been happier to trade less content for both more and deeper examples_

----------------

These next two sections aren’t part of the official Perfection Game but I’ve added them, as they suit my needs.

What surprised me:

I had never thought of the Core Protocols as a way to increase engagement on a conference call or web meeting. I will need to give this a try.

Unsure of: Part 3 explains how to amplify the effectiveness of your efforts by creating Triads (literally groups of 3), using these Triads to help support your message and grow the use of the book’s other ideas. This is an interesting idea - I’ve never thought about working in groups that small and have reservations. I suppose as an informal alliance it might work well; I will need to see them in action before knowing how well these work.

Missing pattern: Dan couldn’t have known (since I didn’t tell him), but I think he’s missing a 17th pattern. Learning Time….. I will document this pattern in the near future. Caveat Emptor - I received a free review copy of the book and have known Dan for a number of years.

Footnotes

An Agile Leader is anyone who influences others to improve their organization ↩

The Human Cost of GenAI

Fri, 01 Aug 2025 00:00:00 GMT

Generative AI is helping people be more productive (sometimes). Of course, if you’re worried about defects or accuracy, it’s not all that it’s cracked up to be but, sure, for things like reviewing writing for grammatical errors, prototyping features and applications, and gathering data when accuracy isn’t essential, it’s helpful. It also speeds discovery and brainstorming (sometimes¹).

So, yes, it’s (sometimes) helping people be more productive and there are (some) places where it does make (some) things get done faster.

But forget about speed for a minute, which is what all the focus seems to be on, and let’s put some thought into the consequences of all this so-called productivity. The human cost.

(*Caveat: the research in this area is new and will evolve.)

Productive But Less Motivated

From the Harvard Business Review: “Research: Gen AI Makes People More Productive—and Less Motivated”² and ³

In this study, people who used GenAI for tasks like writing emails, social media posts, and brainstorming were more productive. But this productivity came at a cost.

As GenAI takes over the demanding tasks, people report lower intrinsic motivation and increased boredom. This leads to disengagement and dissatisfaction with work and, if unchecked, burnout.

Using the ARC Motivational model, we know that we need to feel competence in doing our work. The use of GenAI is taking away from that sense of effectiveness and confidence, leaving people to ask: Why am I here?

Loss of Control and Connection

Employees who excel with AI tools are twice as likely to consider leaving their organizations, pointing directly to the pressure of their overwhelming workload.

Upwork Research Institute surveyed over three thousand people to understand how GenAI is affecting people at work.⁴ Since it is a survey, this is self-reported information and not a rigorously designed experiment, so we need to be careful about the strength of the conclusions we draw.

Adam described his company’s owner as someone who “thinks every new AI function will propel us to the next level with minimal effort,” a mindset with which he strongly disagrees. … the challenge wasn’t resistance to AI but rather overenthusiasm without a grounded understanding of what AI can and can’t do.

Many organizations are mandating the use of GenAI to increase productivity, without considering the broader consequences. When poorly implemented, these mandates lead to the feeling that we have no control or agency in the work. Even when the use of AI isn’t imposed, people report that they feel less in control if the tool is doing many of the tasks for them.

Autonomy is central to both the ARC and SCARF motivational models. As humans, we need to feel that we have choices and agency. The use of GenAI is reducing that for many workers.

sketch of the diminished human connection with AI

Loss of Connection with Others

This finding was the most surprising. The heaviest users of AI come to see it as a teammate; in many cases, they report they’re more polite to it than their real colleagues. In turn, they appreciate the AI for being more empathetic and non-judgmental than their human colleagues.

When we would rather turn to a GenAI tool than our teammates for help, this undermines the social fabric of the team.

Group cohesion is a key variable of effective work teams. It is often conceptualized as consisting of social cohesion, task cohesion, and individual attraction to the group. We generally speak of teamwork when all three of these are present. Otherwise, it is just a group of people occupying the same (virtual) space.⁵

So the more we rely on GenAI to replace our teammates, the weaker the team itself becomes. It also negatively affects us as individuals when we diminish relatedness and connection with our colleagues. The SCARF motivational model emphasizes a need to connect with other people, not with Generative AI tools.

Burnout

Lacking control and social connection, people are getting less satisfaction from their work. Hence, there is a rise in both burnout and people leaving workplaces.

What Can We Do?

GenAI isn’t going away, so we have to look into reducing the damaging effects.

For teams that are already practicing some flavour of Agile, most of this isn’t a surprise. Scrum has always been focused on building effective teams and increasing the use of GenAI requires us to put emphasis on the principles of this game.

Consider:

Talk with your team about the problems with loss of control and human connection.
Focus on increasing collaboration. Try Pair Programming or Ensemble Programming.
Run small experiments around the use of AI, where the team set explicit exceptions and parameters. The goal is to design experiments that allow us to make decisions about if/when/where we’ll use it as a tool, based on data rather than on hype or perception, which can be flawed.
Give team members back their automony. Let them see where GenAI is beneficial to them, and where it comes with a cost, and let them decide usage.
To address loss of purpose, go back to the beginning. Effective teams have collaboratively agreed on:
a) Product (or Team) Vision for where they’re going in the next few years,
b) Strategy for the focus of their work in the next 4-6 months to support the Vision, and Story Maps or similar to visualize that,
c) Product Backlog and Sprint Goals so team members see, day to day, that their work is an important part of achieving a bigger purpose.
Use AI to help reduce the drudgery instead of replacing the creative work.
Try any other things that help the team members increase their psychology safety and sense of belonging. This is part of the playbook, we call Effective Scrum. These are the kinds of team challenges we work through in our Certified ScrumMaster workshops.

AI is just another tool in the list of options we have to help us with work. The difference is that it is having larger social effects than tools we’ve used in the past. As we learn and understand the effects of GenAI —and as the tools themselves evolve— we can lean in to our Agile toolset to help reduce uncertainty and fear and ensure that our people thrive as our toolset changes.

Related Blog Entries

Image attribution: Agile Pain Relief Consulting (August 2025)

Footnotes

The Sprint Backlog: A Truly Complete Guide with Examples

Wed, 08 Nov 2023 00:00:00 GMT

We might not be able to make Sprint Backlogs exciting, but we can make them more effective. Let’s look at what a Sprint Backlog is, what purpose it serves, and how to create, manage, and improve it.

What is a Sprint Backlog?

A Sprint Backlog is a list of Product Backlog Items (PBIs) that the Developers think they can complete during the Sprint, along with the work needed, described in small enough chunks (e.g. User Stories) that progress can be tracked throughout the Sprint. These items are selected from the Product Backlog by the Scrum Team during Sprint Planning.

The Sprint Backlog is essential because it is the Team’s clear plan for how to achieve the Sprint Goal that they committed to for the Sprint. The team’s work is visible and updated on a daily basis to encourage transparency and collaboration within the team itself. By having a clear plan for the Sprint, it allows the team to focus and bring the highest value work to completion.

Who creates the Sprint Backlog?

The Scrum Team is responsible for creating the Sprint Backlog. Sadly, many Scrum Teams simply use whatever their online Scrum tool feeds them for their Sprint Backlog. This harms the Team’s capacity for engagement because it reinforces the sense that Scrum is happening to them, not something that they choose.

Since the Sprint Backlog is solely for the use of the Scrum Team to organize their own work during a Sprint, they are the only ones who create, change, and manage it — not a tool, and not an outsider.

When is the Sprint Backlog created?

The Sprint Backlog is created in the Sprint Planning session at the beginning of each Sprint. Prior to the start of the Sprint the Product Owner has prioritized the items and discussed them with the team (this is called Product Backlog Refinement). By doing it before Sprint Planning, the whole team better understand what they’re committing to. This collaborative effort ensures shared understanding and ownership of the Sprint Backlog. During the Sprint, the Sprint Backlog is updated by the Scrum Team when something changes, a task or Product backlog Item (PBI) is completed, or a new item is started.

How does a Sprint Backlog work?

After the Scrum Team creates the Sprint Backlog, the Developers (Scrum’s poor way of saying all the people who do work) break down the Product Backlog Items (PBI) into smaller size and estimating the work needed, the team works through the Sprint Backlog with each individual team member selecting PBIs to work on. This promotes autonomy and allows Developers to work on things they feel most comfortable with or have the necessary expertise in. As a PBI is completed, the Scrum Team updates the Sprint Backlog to reflect that. There is no required work order for items. Since the Scrum Team is truly self-organizing, they could work on the Sprint Backlog in whatever order they see fit, but effective teams usually work from highest to lowest priority.

How should the Sprint Backlog be managed?

Since we look at the Sprint Backlog during Daily Scrum, most Scrum teams update it there. The frequent visibility and review are intended to improve transparency and collaboration among team members. No one is assigned work in Scrum, instead, team members have the freedom to choose what they want to work on themselves, so any team member may update a Sprint Backlog item. They might mark it as done, or as needing feedback from the Product Owner, etc. If a particular item in the Sprint Backlog is confusing:

it should not be brought into the Sprint and, instead, turned into a conversation at the next refinement session, or
it can be turned into a Spike – a timeboxed investigative effort to better understand the problem, or
t can be committed pending further clarification right after Sprint Planning. (This is a common practice and is almost always a bad idea. Options 1 and 2 are better choices).

A Sprint is dynamic and evolves so the Sprint Backlog changes as the Sprint moves along. The Sprint plan that helped you start the Sprint often doesn’t last the whole Sprint. Did the team realize that a User Story (aka PBI) won’t be completed this Sprint? Remove it and tell the Product Owner. Hit by a product support defect mid-Sprint? Add the emergency fix to the Sprint Backlog, or put an existing item on hold and swarm the defect. (Hint: if this is a frequent problem, we’ve covered reducing the Production Support burden in this Scrum By Example entry).

Fixed Scope or Variable Scope?

People get themselves tied up in endless knots on this subject – are the contents of the Sprint fixed (i.e. Fixed Scope) or can they change (Variable Scope)? These notes won’t settle all debates, but they should help reduce them.

Sprint Goal – This shouldn’t change during the Sprint.
Product Items committed to the Sprint – If the Sprint isn’t going well, the team might drop an item. On rare occasions when something important is discovered by the PO, the Scrum Team might accept a new PBI mid-Sprint. My normal recommendation is that they remove a larger existing item to accommodate the new item. I would expect the Team to discuss in their subsequent retrospective what happened and how to ensure that it doesn’t happen again.
Task Items – Any amount of change is fine here since tasks aren’t officially part of Scrum and the task list can change on a daily basis.

If change is made to the work in Sprint, it needs to come through the shared agreement and collaborative understanding of the team, not as something imposed from the outside.

What are the characteristics of a Sprint Backlog?

The Scrum Guide doesn’t provide any guidance on the structure or format of a Sprint Backlog: “The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal.”¹

Since Teams are unique, there is no single correct practice that they all should follow when creating a Sprint Backlog. 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 tool.

The Sprint Backlog is created by the Team, for the Team, so there are no set-in-stone rules. If your Team wants it to include a XKCD comic, go for it. That said, there are some things that people have found to be effective, so they’re worthwhile considering.

Swim Lanes and Columns

To keep the board organized visually, Teams use horizontal swim lanes and vertical columns to create a rough grid. At the front of a swim lane is their Product Backlog Item (e.g. User Story or task). Then there is a series of columns moving left to right (instinctive to how we read English text), indicating progress of that Backlog Item through the Sprint.

When teams transition from traditional project management methods, they might be tempted to use the Sprint Backlog to recreate familiar phases such as Analysis, Design, Development, and Test. Teams do this, but it misses the collaborative nature of Scrum and introduces unnecessary handoffs between team members.

Example Sprint Backlog 1:

Illustration of a sprint backlog board, with various placeholder columns and sticky notes

To someone new to the Agile world the picture above may look a bit alien. Let’s break it down further and make sense of it.

Does a Sprint Backlog have tasks – yes or no?

Tasks are not a required element of the Sprint Backlog. If tasks are included, it’s recommended that they’re decomposed into parts small enough to be completed in a day or less, so that Team members can share tangible progress on a daily basis. If the PBIs are already very small – perhaps completed by two people in a couple of days – then breaking them down further into tasks is probably not productive.

”Finished” or “Complete” vs “Story Accepted”

If a Team does put tasks on the Sprint Backlog, they might find it helpful to create a boundary between tasks that the Team members themselves declare finished, and the User Story/PBI being accepted by the Product Owner.

Work in Progress

Many Teams benefit by stealing a page from the Kanban playbook and limiting Work in Progress, then including that in their Sprint Backlog structure. To sense whether they’re on track to meet the Sprint Goal, they simply look at the number of completed PBIs. If by the third or fourth day of a ten-day Sprint there isn’t at least one item finished, then it’s unlikely that the Team will get everything completed by Sprint end. By the sixth or seventh day, we would expect a Team to have at least half the items complete.²

Teams that limit Work in Progress to only two or three Product Backlog Items at one time, tend to:

collaborate more. They often discover practices like Behaviour Driven Development (or BDD) and Pair Programming. In the long run, these teams improve their throughput.
cross-skill faster, since the bottlenecks become self-evident.
eventually eliminate the problem of having unfinished work at the end of Sprint. If you limit WIP and you’re only a few days away from the end of the Sprint, then the team could swarm the remaining work one chunk at a time, making it likely that there will be no unfinished work at the end of Sprint.

So, used well, a Sprint Backlog combined with the Kanban WIP limit can solve challenges that many teams face.

Bringing Retrospective into the Sprint Backlog

The example Team has also put a swim lane at the top for their actions or improvements that they committed to in the Sprint Retrospective. It’s at the top of the picture to act as a visual reminder that continually improving their process and Team is important. It’s recommended that the Developers include at least one action item from their previous Sprint’s Retrospective.

Adding the Sprint Goal

Finally, the Team in our above example has placed their Sprint Goal atop the Sprint Backlog as a visual reminder that it is the overarching goal of the Sprint, rather than just finishing individual tasks.

These additions encourage the Team to focus on more than just delivering a collection of User Stories. Instead, they’re achieving the Sprint Goal while making improvements that, in the mid-term, help increase their work quality and effectiveness.

This next Team has a slightly different view of the world, so it’s appropriate that their Sprint Backlog looks different as well.

illustration of an example sprint backlog, with different lanes for different aspects of work

The Team above has a product live in the field. They have added a swim lane to visualize Production Support work as a separate activity in their Sprint Backlog.

Real Life Examples of a Sprint Backlog

The above two examples are obviously graphics created to illustrate common Sprint Backlog structure. Here are some photos of actual Sprint Backlogs, and you can click on the smaller photos to open full-size images.

Photo of a whiteboard with a sprint backlog on it, featuring multiple lanes

] Image courtesy of Sameer Bendre.

Sprint Backlog Example 3: This Team has Expedite Lanes at the top, and column headings include “Challenge”, “Analysis and Planning” and “Unit Test”.

Photo of a Sprint Backlog board, with a unique Calls column

Image courtesy of David Koontz.

Photo of a sprint backlog on a white board, with team-unique columns

Image courtesy of Sameer Bendre.

Sprint Backlog Example 5: This Team has chosen columns for “WIP” (Work in Progress), “Ready for CR” and “In CR”, “Validate in Prod”, and “Closed in TFS”.

Some of these examples might have contents that make no sense to you, or your environment, and that’s okay. They don’t have to, because a Sprint Backlog has to only make sense for the Team that created it.

More Ideas for Your Sprint Backlog

Here are other things you might try for the structure and contents of your Sprint Backlog, based on what some Scrum Teams have found effective for them. Remember, your mileage may vary, so experiment and make it your own.

Put tick marks on a card for every day it has been worked on and a ‘B’ for everyday it was blocked/stuck. This helps the team by providing information on how long individual work items took to complete, or how long they got delayed. Most teams discover that work items often spend longer waiting for something (approvals, another team, etc …) than they do getting worked on.
Create a separate column for items that are Stuck/Waiting For/Blocked and make a note of the why. A separate “Waiting For” column visualizes the blockages in the system. Visualization makes them easier to measure, and attracts greater attention to resolve them sooner. After all, our teams don’t want to measure blockages, rather we want blocked items unblocked as soon as possible.
Track Interruptions (e.g. management requests), requests for help from another Team… basically, track anything that causes the Team to lose focus on the Sprint Goal. These are usually tracked in their own lane. By tracking them, it highlights opportunities to work to reduce them.
Create an Impediments area to track open and resolved impediments. This helps the team see where their problems are. During the retrospective, these impediments can make fodder for good discussion.
Have a visual reminder of the Definition of Done on the boundary between Finished (for a task) and Accepted (for a User Story). This helps the team by making them think about the meaning of Done and therefore what level of quality is expected.
Some teams that use Tasks find it useful to create task items that correspond to the Definition of Done. Other teams find that keeping the Definition visible at all times is a sufficient reminder.
Hidden or Ghost work³ – Sometimes we discover that team members are working on things outside of the Sprint Backlog. On discovery in Daily Scrum (or any other time), make it visible. Many teams use the interruptions lane above, since this work from outside the Sprint Backlog is an interruption.
Include a Calendar to note vacations, birthdays, special events, etc – anything that might affect the time available for work, as well as morale. Being reminded of our peers’ schedules and lives makes them more relatable. On a simple practical level, seeing a teammate’s upcoming vacation plans reminds us to address questions before they disappear, minimizing the number of items that get blocked by their absence.
Consider noting any other events that affect the Team during the Sprint, e.g. an all hands meeting, other meetings,⁴ server outage, Zoom or MS Teams outage.
Track mood, energy, etc using something as a simple as a spreadsheet view with people’s names in rows, calendar/weekdays across the top. On a daily basis, they mark happiness, satisfaction, engagement or some other simple measure, which will help document whether the Team’s energy or focus was negatively impacted.⁵

All of the information that the Team tracks via the Sprint Backlog becomes data that should be brought into the Sprint Retrospective.

When your Sprint Backlog is designed and prepopulated by an outsider (or an electronic tool), it’s unlikely to contain any of these improvements that can help make the Backlog – and what it tells you – more effective and informative. But at the end of the day, if a tool helps the team improve collaboration and focus, then it is useful.

(Note, if having to maintain a tool for the Sprint Backlog slows down the Team, that is an impediment and it’s up to the ScrumMaster to help find a better solution.)

Sprint Backlog: End of Sprint

The Sprint Backlog is reviewed during Sprint Review at the end of the Sprint. The Sprint Backlog is finished and completed work is deployed. The Sprint Backlog cards can now be disposed. (One team I worked with archived them in a shoebox and put a rubber band around each Sprint’s worth. Honestly, I don’t think anyone ever looked at them again.)

What happens to incomplete work in a Sprint Backlog? It is returned to the Product Backlog wherever the Product Owner deems it belongs. In the next Sprint Planning session, a new Sprint Backlog is created.

Sprint Backlog Anti-Patterns

(aka Avoid Doing These)

Pre-assignment

When the Sprint Backlog is created during Sprint Planning, some teams decide who will work on which PBI or task. When it’s kept to only one item, this isn’t bad, however when all items are pre-assigned to team members, we have just planned for the first bottleneck.

One Person Doing Many Things

This happens when Team Members are signed up for one than one task or PBI at the same time. We can’t multitask like we think we can because our brains just haven’t evolved to do this. The more we multitask, the less we get done overall. So when Team Members sign up for more than one task at a time, they’re promising to get less done. Exception: if a team member has one item stuck in Blocked (or Waiting for), they might start work on another. If it happens again, the team should look into why one person’s work is so frequently blocked. Alternative: when a team member has a item blocked, they might pair with another team member to help that person through the item.

Reporting

The Sprint Backlog loses its value if used for external purposes like reporting, or for micro-management. When leadership uses it to look over the shoulders of the people doing the work — even if it’s not to direct the Development Team’s actions — it often leads to overloading the Sprint Backlog with details that undermine and eliminate transparency. The Sprint Backlog is used only by the Scrum team, and is not intended to be viewed by anyone else.

Multiple Sprints

Since Scrum is about adapting to the evolving work, it is pointless to plan which items will go into the Sprint Backlog beyond the current Sprint, so we shouldn’t try to create Sprint Backlogs in advance. I think this happens because some of the popular electronic tools make it possible and people assume, based on the tool, that this is a good practice. Planning future Sprints before they happen reduces flexibility and increases workload for all involved.

Phases

When people come from a traditional world into Scrum, some try to use the Sprint Backlog as a tool to recreate the phases they’re used to. For example, they create columns in their Sprint Backlog for Analysis; Design; Development; Test. While strictly speaking legal, they’re recreating the boundaries between traditional roles, making collaboration less likely and ensuring handoffs between team members. As mentioned in the Limiting WIP segment, effective Teams work collaboratively through the Sprint to get a PBI to complete before moving onto the next. These phases tend to lead to another Scrum sin – Staggered Sprints.

Forecasting with the Sprint Backlog

The Sprint Backlog is also the Developers’ forecasting tool. Each day during Daily Scrum, they replan their work and update the Sprint Backlog , using it to help them assess whether they’re on track to meet their Sprint Goal. If they realize that their Sprint Goal is in jeopardy, they work with the Product Owner on replanning.

In the past, Teams used to use a Sprint Burndown Chart that tracked task hours remaining to be done. Now, most of us would suggest that the focus on Tasks, versus focusing on User Stories/PBIs, is anti-pattern so we don’t recommend Sprint Burndowns.

Sprint Backlog vs Kanban Wall vs Product Backlog

While the Sprint Backlog is the Team’s plan for the Sprint, the Product Backlog is the Teams queue of work. So the funny thing is that the Sprint Backlog and Product Backlog have easily confused names, but vastly different meanings. In my workshops, whenever an attendee answers a question with, “Backlog”, my instant response is, “Which one?”

A Sprint Backlog is far more like the (better-named) Kanban board. A Kanban board is a visual control system from the world of Kanban. It combines the Product Backlog with the Sprint Backlog. The key difference between Scrum’s Sprint backlog and Kanban’s board is that Kanban has a Work In Progess Limit. As you’ve already seen, I strongly recommend Scrum Teams steal a leaf from the Kanban world and do this.

Key Points on Sprint Backlogs:

Created by the Scrum Team
An output of Sprint Planning
Updated by the Scrum Team often during Daily Scrum
Is better at progress tracking and forecasting than the Sprint Burndown
Is used by team members to foster collaboration
Contains whatever the team find useful - often includes the Sprint Goal and Improvements
Tracks impediments, blockages, interruptions, production support issues and hidden work
A great data source to use for your next retrospective

Good Scrum teams know that they own the Sprint Backlog. Great teams experiment every few Sprints to find what they can do to make their Sprint Backlog even better.

Still Unsure How to Create an Effective Sprint Backlog?

Image attributes: Agile Pain Relief Consulting (updated April 2025). Other Images credited inline.

(Updated November 2023)

Footnotes

Scrum Guide on Sprint Backlog ↩
This isn’t a hard and fast rule. Instead, it’s a pattern. As ScrumMaster or Agile Coach, if you see that the board is hinting at a problem, use that hint and look further to understand what is going on. ↩
This term describes work done out of sight of the team. It is also sometimes referred to as “dark work” (as in done in the dark), but “Hidden” or “Ghost” work is more culturally sensitive. ↩
Github did a Developer Good Day survey and discovered that the more meetings someone is involved with, the less work they get done. My strong recommendation is that your only meeting most days should be Daily Scrum. ↩
These are called Niko Niko boards and not everyone thinks that they’re a good idea. ↩

The Real Cost of AI-Generated Code: It's Not All It's Cracked Up To Be

Fri, 18 Jul 2025 00:00:00 GMT

There is a lot of hype surrounding the use of GenAI for Development. “Anthropic CEO Dario Amodei said earlier this week that AI will write 90% of the code for software engineers within the next three to six months and every line of code within the next year.”¹

I’ve been working in the software industry for nearly forty years. When I hear big promises about how a technology will revolutionize the world (e.g., Crypto, 4GLs, Digital Audio Tape, Smell-o-Vision, Segway), I want to see what’s happening on the ground. Years of work in the Agile world have taught me to engage in Systems Thinking and ask: what are the second and third order effects of what I see in front of me? I also want to understand if the claims I see are well-founded. Under what conditions are they true?

Remember

If we’re going to gain value from GenAI, we need to examine what really happens, rather than just the promises made by those who profit from selling the tools.

In this article, I will focus on the effects of GenAI on the quality and maintainability of our code bases. In subsequent articles, I will examine their impact on the people who use them and the promise of increased productivity.

Bold Claims

GitHub CEO says Copilot brings

55% faster coding, 46% more code written, $1.5 trillion added to GDP

In “Sea Change in Software Development: Economic and Productivity Analysis of the AI-Powered Developer Lifecycle”², GitHub CEO Thomas Dohmke claims that the AI-powered tool Copilot is helping developers write code faster. The research has been submitted to a reputable journal and will undergo peer review. Reportedy, developers:

Accepted 30% of the suggestions that Copilot made
Completed tasks 55% faster
Wrote 46% more code
75% felt more fulfilled

Here’s the problem with those claims. The core of the paper assumes that all code added to a repository is equally valuable, but that assumption is invalid. The core claim of the paper is based on the age-old belief that more lines of code are better, and that is a flawed premise.

More code != more value:

Some (many ;-)) changes introduce defects.
Some features are poorly understood, and so the Copilot built the wrong thing.
More code increases the attack surface and makes it easier for an attacker to break into the system.
More code increases the complexity of the system, making it harder to add new features later.

In this case, more code appears mostly to equate to more Technical Debt. As the debt increases we end up with a big ball of mud that has other adverse effects:

It takes from 2x to 10x as long to add new features as the code becomes a mess.
Changes or new feature work in messy code is 15 times more likely to have defects.

(See CodeScene: The Business Impact of Code Quality³. Key takeaway - messy code is more expensive for your business.)

Reality Check

GitClear conducted a thorough analysis of data⁴ based on the users of their “Software Intelligence System” and they saw: an increase in the volume of code added; an increase in churn; an increase in copy and pasted code; a decrease in the amount of code moved.

They define churn as code added, changed or removed in a 2-week period. Churn is often code that was written, committed, and later found to be defective. This is not a number we want to see go up. Before 2022, Churn was around 3-4%. In the years since, Churn has grown at a rate proportional to the uptake of Copilot/ChatGPT usage. (Caveat, they’ve demonstrated a correlation and not causation - the correlation coefficient is 0.98.)

Technical debt is also increasing because there is more copy and paste code (the LLM didn’t notice it was a duplicate) and a reduction in refactoring (less code moved).

All told, GitClear’s analysis suggests that Copilot didn’t add $1.5 trillion to the economy. If anything, the users have spent money from the future economy for no short-term gain. This analysis compared 2023 to prior years, so it is based on a period before the largest growth period for LLM use. I expect this understates the problems we will see in 2024 and beyond.

sketch of Feature Factories creating hidden technical debt

Summary

I’m not saying that GenAI can’t help; I think we will get there. With prototyping and exploratory work, GenAI is already making possible things that didn’t exist previously. However, current GenAI use often creates bigger problems in the long term.

I’ve said this several times: the Theory of Constraints tells us that if something isn’t the bottleneck, don’t optimize for it. Don’t optimize for individual productivity; optimize for the team. Measure how long it takes to deliver value to the customer (probably Cycle Time). Use LLM-based tools where they help you with that, not because the CEO of an AI company promises more code faster. In our Certified ScrumMaster workshops, we focus on helping teams identify their real bottlenecks and deliver value, not just write code faster.

Agile Pain Relief Blog Entries

Footnotes

Sherin Shibu, “‘I Do Have a Fair Amount of Concern’”, Entrepreneur, May 14, 2025 https://www.entrepreneur.com/business-news/anthropic-ceo-predicts-ai-will-take-over-coding-in-12-months/488533 ↩
Thomas Dohmke, Marco Iansiti, and Greg Richards, “Sea Change in Software Development: Economic and Productivity Analysis of the AI-Powered Developer Lifecycle”, arXiv, June 26, 2023 https://arxiv.org/abs/2306.15033 ↩
CodeScene: The Business Impact of Code Quality https://codescene.com/hubfs/web_docs/Business-impact-of-code-quality.pdf ↩
“Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality”, GitClear https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality ↩

The Role of Agile Managers: Why Job Titles Are Dangerous

Mon, 29 Oct 2018 00:00:00 GMT

Managers transitioning from waterfall to Agile will need to renegotiate their relationship with their teams if they are to succeed. A manager cannot simply become an Agile Manager – a big part of a transition requires a rethinking of how job titles are assigned and the leadership responsibility that comes with them.

I was recently approached by a client who asked about effective Agile Organizational Structure. That question spawned these preceding articles:

The Role of Agile Managers: Why Job Titles Are Dangerous

Scrum Team Titles

The first thing to understand is we need to stop using title promotions to ‘reward’ employees. Leadership is not a badge, it’s a task to be shared.¹ The number of titles in an organization inversely correlates with the effectiveness of the collaboration.

As teams grow, job titles (e.g. Business Analyst, Quality Assurance, Software Developer, …) get in the way of working together to deliver the most value to customers. Many Agile Teams set these titles aside – either by ignoring them or by making the “Team Member” role the label for everyone on the team.

Traditional titles can be toxic at the team member level because they imply a limitation. Can a Quality Assurance Lead help with Usability? Can a Developer contribute to database administration? Of course they can! When people see titles, they see boundaries. When managers don’t reconsider their role and titles, their lack of action implies that Scrum changes the Team but not Management.

Titles are also toxic because they promote specialization. As Noika² and others have proven, as soon as we create a special role to solve a problem, the specialist who fills that role has every incentive to ensure that the problem never goes away. They’d be doing themselves out of a job if it does.

Scrum Management Titles

We get too specific with management titles too. For example, “Development Manager” rather than “Quality Assurance Manager” makes the Team members whose background isn’t within that area - in this case, software development - feel a few things:

they have no career path themselves
their management team doesn’t have an understanding of their needs and problems
the Agile transformation is focused on that skillset and department, so it doesn’t include them

As Agile Team members, we move beyond titles to focus on collaboration, so why would leadership be any different?

In Large-Scale Scrum (LeSS) adoptions, everyone lets go of titles and figures out, as a group, what roles need to be played. For many organizations, that is a bit too radical. However, the underlying principle is solid in the case of managers —you don’t need managers as traditionally understood, you need people, who focus on growing the capabilities of the team members.

So what’s the best way for managers to choose new titles for themselves? Ask the team.

How to Ask the Team

There are obviously a few ways you could go about getting input from the team but, to get you started, I suggest running a short workshop. The focus will be on management reflecting on their roles.

(Assumption: you’re already familiar with the idea and mechanics of a Skills Matrix workshop.)

Exercise Goal: Create some form of a shared understanding with all the team members about the role that management is evolving into.

Time: a few hours if only one team. More if there are several teams involved.

Provide Context: Explain that your goal, as a manager, is to redefine your role and title to better support the Team. Remind the Team of the importance of self-organization. Make clear that this exercise needs to be repeated, perhaps annually, so that relationships are renegotiated on a regular basis.

Framing question: “What would it mean if we all had no titles?” Use this, or a question like it, to start a conversation with your team(s). Start with the premise that we’re all equals. What role can each of us play? Do we need titles? If so, what should mine be?

Activities:

Role Responsibilities (similar format to the Cross-skilling workshop)

Using a silent listing style, each team member writes down everything a manager does (Action, Task, Responsibility) today, on PostIts or anything else at hand.
As a team, they sort the items into who does what in a Scrum world. ScrumMaster? Product Owner? Product Development Team? Not needed in Scrum? or Person previously titled as Manager?
As a team, discuss significant differences.

Now that we’ve defined the role, we step back and ask: what title best describes this role?

There you will find your answer to what your new management title should be.

Offer Career Paths

As mentioned, moving beyond titles to focus on collaboration is preferred. If an organization has a formal requirement that titles must continue to exist, then it needs to create career paths that allow senior technical people (coding, testing, usability, analysis etc.) to take on more of a mentorship role without having to become managers. In addition, the people who take on mentorship need to come from diverse backgrounds – both in skill area (BA, QA, U/X) and in ethnicity/gender – to represent from a wide range and not just the majority white male so common in technical fields. Agile has a reputation for being developer-centric when its intention was always to be people-centric.

These available career paths need to emphasize the value of mentorship and the importance of growing team member skills, more than the value of individual contribution.

Ask: What do you need? What’s getting in your way? What can I do as your manager to help? ³

“Titles distinguish the mediocre, embarrass the superior, and are disgraced by the inferior.” - George Bernard Shaw

Stop being a Manager, let go of the title, focus on service to the team and the organization. Then follow through and support the behaviour change with ongoing coaching support.

Whether it’s a formal outside coach or well-trained internal team member isn’t as important as regular, frequent feedback is, to help ingrain this shift to sustainable change ⁴ ⁵ ⁶ ⁷ in how management and team collaborate.

References

“Titles are Toxic” - https://randsinrepose.com/archives/titles-are-toxic/

Image attribution: Agile Pain Relief Consulting

Footnotes

Paraphrasing Pete Berhens on Twitter https://twitter.com/mlevison/status/975448686909100032 ↩
Originally - “How Specialization, Management by Fear, Complexity and Coordination Chaos killed Nokia” - now “Collapse of Tayloristic organizations” by Ari Tikka https://gosei.eu/blog/collapse-of-tayloristic-organizations/ ↩
“The 3 questions managers should ask” by Chris Bailey https://alifeofproductivity.com/the-3-questions-managers-should-ask/ ↩
Why Motivating People Doesn’t Work by Susan Fowler https://www.amazon.ca/Motivating-People-Doesnt-Work-What/dp/1626569452/&tag=notesfromatoo-20 ↩
“Why Leadership Development Isn’t Developing Leaders” by Deborah Rowland https://hbr.org/2016/10/why-leadership-development-isnt-developing-leaders ↩
“Leadership Development Should Focus on Experiments” by Ron Ashkenas and Robert Hausmann https://hbr.org/2016/04/leadership-development-should-focus-on-experiments ↩
“Executive Coaching and its outcomes: What the research actually says” (PDF) by Dr. David Wilkinson, The Oxford Review https://oxford-review.com/executive-coaching-outcomes-research-actually-says/ ↩

The Spotify Model of Scaling - Spotify Doesn’t Use It, Neither Should You

Tue, 24 Oct 2023 00:00:00 GMT

The “Spotify Model” probably isn’t a model and definitely isn’t what is currently practiced at Spotify today. (Some suggest it never was.) The below image was made famous in a video by Henrik Kniberg, where he explains how work was organized into Squads, Tribes, and Guilds. Many people see the structure and try to mimic it in their organization. Worse, many attempt to get the supposed benefit by renaming existing organizational structures with the same labels. As a result, most attempts at the Spotify Model are in fact Cargo Cult.

Spotify Scaling model image, credit Henrik Kniberg and Anders Ivarsson

Figure 1 - The famous picture from: https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

Structure isn’t the most important. Culture will eat any structure. (Hint: that’s why renaming your Teams as “Squads” and calling Departmental Managers “Chapter Leads” didn’t help.) That said, if I don’t summarize those labels, you will look elsewhere anyway, so here we go:

Squad: effectively a Scrum team with a new name. When the original paper was published, each squad owned a small chunk of the UI or behaviour of the system. They own this slice of the product and can run experiments without depending on other teams. People who are familiar with LeSS will notice that squads are feature teams. The research on why stable teams matter applies directly: squad membership should remain consistent over time.
Tribe: a collection of squads that work in a related area. They’re designed to have collaboration across squads with few dependencies, on other tribes. Tribes are capped at 100 people to minimize “restrictive rules, bureaucracy, politics, extra layers of management, and other waste”.
Chapter: people of a single skill area inside one tribe, e.g. testers or developers who work with a certain technology. Chapters meet regularly to discuss problems and share learnings in their field.
Guild: a larger community of interest. Guilds usually include the chapters, however anyone who is interested in a topic can join a guild. When the original paper was written, they had guilds for Web Technology and Agile Coaches Guild.

Structurally, this is a perfectly sound way of organizing teams. The pitfall is that it changes labels without the cultural and mindset change to go with it. And education alone won’t make that change.

Is this just another matrix model, the sort of thing that Agile coaches have been undoing for years? Yes, it is, but it’s a different kind of matrix. In other matrix models, the horizontal relationship is the primary one. E.g. A developer reports to a dev manager; a tester to test manager, etc. Affiliation with the team(s) they work with is more loose. Spotify reversed this. The primary relationship is as a member of a stable, cross-functional team. The chapter lead (not a great choice of name) is a coach, focusing on skill and technical excellence. In theory, this is great. In practice, this is the first place many organizations make a mistake. Your chapter leads aren’t former managers who got a new job title.

There are a myriad of other mistakes people make from reading a whitepaper and watching a video. The list would be longer than the original paper. So popular is this problem, it’s even got its own meme:

spotify model meme

Figure 2 from: https://medium.com/serious-scrum/you-want-to-adopt-the-spotify-model-i-dont-think-it-means-what-you-think-it-means-7df4316081f

You can’t copy and paste someone else’s approach to Agile. Their approach grew from their people and their culture. In addition, all attempts to document a culture are simplifications that are missing details that were important. Instead of copying the Spotify model, or model from another random company (e.g. FitBit, John Deere), grow your own Agile model. It is the only long-term path to success.

Instead, focus on the things that Spotify had going underneath the hood (many of which are also characteristics of effective Scrum teams):

Delivering Value - all improvements to the system should be tested by asking: Does this improvement/experiment, help us deliver value?
Delivering Product Value – requires running experiments and seeing what works for real end users.
Autonomy over Command and Control - without autonomy there is no learning, improvement, innovation or ability to adapt to changing circumstance.
Alignment - instead of telling people what to do for both product features and product architecture, focus on getting teams to align to a common product goal. Consider having multiple teams working from a common Product Goal.
Cross-Functional Product Oriented Teams (aka Feature Teams) – rather than building teams according to their functional layer (e.g. Database, Business Logic, UI). If you’re building a team from scratch, cross-functionality is one of the first things to get right.
Engineering Culture that focuses on building Quality and Simplicity - build a Continuous Delivery pipeline that allows teams to deliver value independently of one another. Versus a pipeline that requires waiting for the DevOps team to deploy for them. Hint: in many organizations, DevOps is a team downstream from the feature team, who deploy the application. This is a well-known anti pattern.
Psychological Safety - the original paper called this “experiment friendly”. The key element of experiment friendly is creating an environment where we can acknowledge taking risks and learning from the process. The fancy name for that is “psychological safety”.
Continuous Improvement as a feature of the system – teams are never done improving. We need to create cultures that promote this mindset.
Morale - originally referred to as happiness, this is the willingness and the persistence of team members to work towards a common good.
Improving the Flow of Work through the system - tools include Limit Work In Progress (aka WIP), Cross-Skilling, and Eliminating Bottlenecks. You can measure the success of this with both Cycle Time and Lead Time.

Agile Pain Relief is committed to helping new Agile professionals who want to learn the language of Scrum and become confident knowing what’s what, so you can focus on helping teams become the most effective they can be. Join us for our Certified ScrumMaster training courses and discover how true Agility actually works.

Impact Mapping – What It is, in Depth, with Examples

Mon, 18 Dec 2023 00:00:00 GMT

Work is humming along nicely when your Marketing VP stops by your desk and says, “We need to double monthly sales.”

That’s it. That their entire instruction.

After you recover from this bombshell, you will need to decide what tool you will use and who you will grab to help you start to tackle this problem.

Do you use Story Maps? (A great tool when you have an idea of where you’re going.) A Journey Map? (Also requires that you have an idea of where you’re going.) A Traditional Roadmap?

I’m going to suggest that you create Impact Maps in situations like this, where you have a vague goal but haven’t yet done a good exploration of how to get there. Impact Mapping is a tool to help you figure out where you will likely get the most bang for your buck. You map out some options to achieve a goal. Once you’ve got a rough idea, you stop mapping and execute.

What is Impact Mapping?

Impact Mapping is a strategic tool to help teams and businesses focus their work on a product feature that will give the most bang for their buck. I’ve used Impact Maps for teams seeking to figure out what/where to build next, and I’ve also used them outside of software development. It is a tool to help the Team and the Stakeholders visualize the outcome they want, the people who can help them achieve it and the deliverable. By visualizing the choices, the team are better able to decide what to create first.

Why Impact Maps Help the Product Owner and Product Manager

Many organizations struggle trying to use Traditional Roadmaps in an Agile environment. They don’t work because there is an implied linear flow and promised timeline for delivery. Linear plans of this nature aren’t suitable in our current world, where change can happen at a rapid pace and history often isn’t a predictable indicator (e.g. COVID, or when once-in-a-hundred-year floods occur twice in three years). Impact Maps replace Roadmaps, making it clear that we have choices in deliverables, while still achieving the original goal.

Traditional road-mapping approaches:

Assume that everything will go well.
Don’t put limits on the number of goals that will be achieved. This lack of bounds puts undue pressure on the team for things that might not even remain relevant.
Don’t ensure the Team and the Product Owner have the same understanding of the strategic goals.

Impact Maps, on the other hand, are about finding the features/work that will have the biggest impact for the customer.

How do you know which strategic options to tackle first? As humans, we tend to jump from a goal to the actions that we think will help us achieve it. Impacting Mapping works by forcing us to consider who is involved in achieving our goal and how they can help us. Using this approach, we find a broader set of possible options –including some that we might not have considered– before narrowing down on which option is most likely to help achieve our goal.

When faced with a variety of options, mapping makes clear which option will have the largest impact and therefore which one to tackle first.

Impact Mapping is a tool to help you figure out where you will likely get the most bang for your buck. You map out some options to achieve a goal. Once you’ve got a rough idea, you stop mapping and execute.

How to Use Impact Maps

Identify the Goal first, then Who (Actor), How (Impact), and What (Deliverable).¹

1. What is the Goal in an Impact Map?

The Goal answers: Why are we doing this? What are we attempting to achieve? The map will be focused on finding options or ways of accomplishing that objective.

2. What is the Actor/Who in an Impact Map?

Who are the consumers or users of our product? Who can produce the desired effect toward our Goal? Who can obstruct it? In describing the Who or the “Actor”, the order of preferred usage is: specific individual, persona, role, job title, group/department – from most specific to least specific. Consider users of the system first, stakeholders second. By focusing on specific people or personas, it makes it more likely the deliverable will meet a real person’s need.

3. What is the Impact/How in an Impact Map?

What Impact can the Actor have? How can they help achieve our Goal? How can they obstruct progress towards the Goal? These are the Impacts that we’re trying to create or prevent. Don’t list everything an Actor might do – just the key things. List business activities, not process features. Be specific and consider negative outcomes as well as positive. When used in an Agile environment, the Impact/How can be tied back to the value statement in a User Story. Check to ensure that both are aligned.

4. What is the Deliverable/What in an Impact Map?

What can we do as a team to deliver the Goal? These become the product features. These Deliverables are the least important end of the spectrum and, on the first pass, will be unrefined. Much of software development is done when someone powerful wants a feature because they think it’s a good idea, but they haven’t really proven the idea will deliver value. By placing Deliverables after the Impact, wasted resources are avoided. So evolution here is a good thing. We don’t need to find all the Deliverables, just enough to find a deliverable that will, for lower cost, deliver the highest Impact. If an early attempt at delivering value fails, we can always return to the map with new information and try again.

Example of an Impact Map:

Impact Mapping example

Figure 1 - Creative Commons 4.0 as per: https://www.impactmapping.org/drawing.html. Credit: http://impactmapping.org/

Tips for Drawing an Impact Map

Impact Maps are intended to be drawn and not just written in words. Visualizing them helps make conversations more concrete. It makes it easier to understand the relationship between a deliverable and the Actor who it is for. If you’re not yet familiar with them, creating an Impact Map from scratch can be intimidating, but it doesn’t have to be. This simple process helps move you through it, and often works well when done over two separate sessions by a collaborative group that includes stakeholders, the Product Owner, leadership and the people who will be doing the work:

Session One: define expected business Goals and measurements Session Two: build the map

Session One: This is the preparation session.

1. Identify the core business objective. Do this by listing possible business Goals, and discussing which one is the current priority. Goals often tie back to money (how to save money, make money, or protect money). However, Goals may tie back to other tangible benefits such as number of readers for a book; improvement in the team’s morale, etc. All of these are measurable in a meaningful way and, if achieved, would make a positive difference in their context. To find real Goals, ask: Why is this feature important? Or: How would it be useful? Keep iterating until you find the underlying Goal. ²

Using the fictional company of our Scrum by Example team, our Impact Map example Goal is: Increase Monthly Book Sales and Profitability for the World Smallest Online Bookstore

2. Define good measurements.³

- what we’ll measure (aka the ‘scale’)
  - how we’ll measure it (aka the ‘meter’)
  - what the current situation is (aka the ‘benchmark’)
  - the minimum acceptable value (e.g. the break-even point)
  - for investment (aka the ‘constraint’)
  - and the desired value (aka the ‘target’)

Our example: ● Measure - Monthly Sales, Monthly Profit ● Current Situation – $100,000, Monthly Profit $20,000 ● Minimum Acceptable Value - $125,000, Monthly Profit $30,000 ● Investment: $200,000 (e.g. one month of expenses for one team) ● Desired Value: $200,000, Monthly Profit $70,000

3. Plan the first milestone. Effectively, you’re picking a Goal/target combination.

Our example: One month after the team complete this work they have increased sales to $150,000/month and profit to $40,000/month. Since the investment is also one month of working time, we’re looking for payoff in two months’ time.

Session Two: This is the mapping session.

1. Draw the map skeleton. Start with one Actor (Who), Impact (How), and Deliverable (What). Use tools that promotes collaboration – whiteboard, sticky notes, etc.

- Put the milestone (Goal/target combination) in the center.
  - Find the Actors who could have a positive or negative effect on the milestone.
  - If people already have ideas or features, put them around the outside. Then ask some questions: Does the feature contribute towards the Goal? Is the Impact valid for the Actor it is ascribed to? Gojko offers a user story-like technique for testing: “<someone> can help us achieve our <objective> by doing <something differently>”

impact mapping example

Then we ask ourselves: What “Impact” can the Actor have? Or: How can the Actor help us?

What Deliverable could we build to achieve this?

impact mapping example

2. Find alternatives. What else could these people do for us? Who else can help? Who can obstruct? If you find that you’re struggling, try Hohmann Innovation Games⁴ or Gray Gamestorming⁵. Also try asking which of the following factors to consider: New Business, Upsell, Retainment, Operational Efficiency⁶

impact mapping example

3. Identify key priorities. Look for obstructions. What can stop us before we start? Is there high-value, low-hanging fruit? What key assumptions should be tested? These questions should all be focused on business activities, impacts, and outcomes, not software features.

In our example, questions we might ask: Are we currently getting bad reviews or negative comments through support? If so, is there a common theme? Do these issues harm our relationships with our current customer. (Retainment)

Assuming our customer relationships are in a good place, will we have happier customers if we sell them more books? (Upsell) Or will we have happier customers if we offer them a referral bonus for referring friends? (New Business)

Alternative: Prioritization. Select which Actor to satisfy first. Consider modified dot voting (red dots for critical features, green dots for low hanging fruit). Given the limited number of options, you can use a Kano model⁷ to categorize more effectively. The Actor with the fewest red dots gets prioritized.

4. Earn or learn. Set a budget to learn whether or not a Deliverable will have the expected Impact. Use simple tools (often not software) to test the value or assumption. The sample questions will be very similar to those used in Lean Startup.

- What is the simplest way to support this work?
  - What alternatives are there?
  - What is the simplest way to test this assumption?
  - Could we start earning money with a manual process?

If you’re struggling to find testable slices, try story mapping or Gojko’s Hamburger method.⁸

Our example: Can we test any of these ideas without implementing a feature in software? For example, can we offer hassle free returns simply by adding a note on the site or in every order saying if you need to do a return call support? This is an experiment – if no one uses the offering maybe it’s not valued.

“Offer similar books” requires a lot of work as we require some algorithm to guess which books are similar. Is there a simple version of this feature that we could try to start? Maybe we could look at our ten bestsellers, manually find books that are close to them, then when a top seller is purchased, offer the companion book. This experiment still requires software development work, however the cost has been reduced from several Sprints of work for one team, to a version that could be built in one Sprint.

Fit the Measures to the Impact Map

Risks

It’s important to make sure that the Impact Map itself doesn’t becomes the target, where we might risk missing things that matter but that are outside the picture.

Typical challenges and mistakes

Too many people involved in creating the map – too large a group will reduce the diversity of the opinions and ideas shared, as the quieter people are drowned out
Wrong people (e.g. no decision makers, no technical people)
Projector or one person doing the drawing. Impact Mapping is a collaborative technique. If you meet in person, consider using sticky notes or index cards and move items around on a table. In a virtual context, consider an electronic whiteboarding tool that invites contributions from everyone versus a tool that only one person can update.
Early criticism (we want more ideas while still in the divergent phase[9] , not an attempt to prune)
Leaders with outsized influence (leaders should always speak last)
Reverse engineering of the entire shopping list. Your existing list of preferred Deliverables may not map well to Actors/Impacts.
Drilling down to detail too early
Skipping levels in the Goal, Actor, Impact, Deliverable layout
Building a map without metrics to guide

Impact Mapping and User Stories

Many Agile Teams use User Stories as dumping ground for ideas, such as when someone has a technical need or a pet feature that they would like to see delivered. They express the idea in the format “As a <role>, I want <to do> so that <value>” and dump it the Product Backlog. Impact Maps can be used to keep these User Stories honest. If the User Story doesn’t map to a branch of the Impact that we’re prioritizing, then it can be dumped.

Impact Mapping and Scrum

As we’ve seen, mapping is a strategic tool to help your team decide where to put its development efforts. Since Impact Mapping is about deciding what work to consider doing, with past clients I have used it prior to putting any effort into creating the Product Backlog, and I would even consider doing it before Story or Journey Mapping – both of which involve exploring the journey of a user through the system the team is building.

Summary

Impact Mapping ensures that when we discuss a piece of work, it always remains in context of our overall Goal, and it can also help us see that there are many paths to it.

Never implement the whole map – instead, run experiments to see which path will get you to the Goal the soonest/with the least amount of effort.

Finally, you can use Impact Maps for more than just product development work; they also help when undertaking organizational change.

Impact Mapping – Glossary and Additional References

Want to learn more about Impact Mapping and other strategies to help your team identify the best way to get more bang for the buck? Our Certified Scrum Product Owner training uses real-life examples and hands-on practice to help you and your team understand how to create ideal customer and organization outcomes, not just produce widgets and complete tasks.

Image attributes: Agile Pain Relief Consulting, except Figure 1: Creative Commons 4.0 as per: https://www.impactmapping.org/drawing.html. (Updated November 2023)

Footnotes

The original book used “Who” for Actor; How for “Impact” and “What” for Deliverable – I find the newer versions far more clear ↩
From Chris Matts https://theitriskmanager.wordpress.com/ ↩
Gojko offers this list as a simplified version of the advice from Competitive Engineering by Tom Gilb ↩
Innovation Games by Luke Hohmann https://www.innovationgames.com/resources/innovation-games-book/ ↩
Gamestorming by Dave Gray https://gamestorming.com/ ↩
From the Business Value Game by Andrea Tomasini https://www.agile42.com/en/business-value-game/ ↩
Kano Model http://en.wikipedia.org/wiki/Kano_model ↩
“Splitting user stories — the hamburger method” by Gojko Adzic https://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/ ↩

Tools, Tools, Tools

Fri, 11 Jan 2008 00:00:00 GMT

Scrum Agile Lean Sticky Notes - image licensed from Photodune

As software developers we have this innate belief that another tool will solve all our problems. To that end many agile practitioners search for a tool to track their projects for them.

However in using a tool we miss the benefits of cards posted on a whiteboard/corkboard in a public place.

Let’s compare the options

Comparison: Physical vs Electronic Agile Boards

Whiteboard/Corkboard	Electronic tool
Daily Standup in front of a board keeps the team focused by reminding team members what the stories and tasks are.	No screen is large enough for team members to stand around and read during the standup. Team members interact with a tool not each other.
Team members can update their progress by moving a card or changing an estimate.	You must login in to the tool and find the task/story to make changes.
Anyone walking past the team area can instantly tell the status of the sprint and project. Since team members see the board frequently road blocks will be quickly spotted.	You must login to see the status of the sprint/project.

In short the whiteboard/corkboard promote conversations and collaboration among team members. If your management insists on seeing pretty reports and charts on their computer then challenge your management.

These reports are waste - they don’t get shipped to the customer.
Invite management to visit the team room on a regular basis and see the progress themselves.
Have daily Scrum of Scrums that management attends so they can get their status fix that way.

If all else fails then treat these reports as an impediment that can’t be removed. Insulate the team from it - don’t force them to use a tool just because someone else wants a report. Instead as ScrumMaster/Facilitator generate the report from the taskboard.

Distributed/Dispersed teams (ie no shared physical environment) are the only time where I see a good argument for the use of tools. Even then I would try the simplest possible solution first: Google spreadsheets. It allows everyone on a team to collaborate on editing a spreadsheet at the same time.

Update: I should’ve stated my conclusion more clearly. Electronic tools work can be made to work, however I believe that you’re giving up an opportunity to foster interaction and collaboration among your team members.

Image via: https://photodune.net/

Two Key Things for Sprint Retrospective Facilitation

Tue, 10 May 2022 00:00:00 GMT

You Got This sign by Prateek Katyal courtesy of Unsplash

Retrospectives are a critical element in Scrum but they won’t work well if your team hates them. A Sprint Retrospective needs someone to facilitate and keep it on track to encourage effective discussion. It’s more of an art than a science, but these key things will help.

1. Remain Neutral

From the Cambridge Dictionary, facilitation is “the act of helping other people to deal with a process or reach an agreement or solution without getting directly involved in the process, discussion, etc. yourself.”¹

This is often the hardest thing to do in the role of facilitator. It’s natural that you have ideas and opinions on what the team could try to improve, but the moment you move to advocacy, the team loses trust in their facilitator. The team needs to know that your goal in the retrospective is simply that they have a successful event and make their own discoveries. If they feel their facilitator has a personal position or opinion involved, they’ll question whether the event is being run to help them, or to steer where the facilitator thinks they should go.

This doesn’t stop you from being a facilitator and a ScrumMaster or Developer, if that’s the case – it merely means that, during the retrospective, you must set aside your personal agenda. Step back from advocacy (which does have a small place outside of the retrospective) to neutrality. Neutrality requires that you don’t advocate for viewpoints, positions, or ideas during the retrospective and, instead, seek to ensure that viewpoints are understood and ideas are heard.

But what about those times when you have ideas/issues that you feel are important to be discussed in the retrospective? You have four viable options:

Don’t share the idea at all. If it is valuable for the team, someone else will come up with it.
Invite another team member or an outsider to be the facilitator in a retrospective when you intend to discuss your idea.
Write your idea down and give it to another team member prior to the retrospective. It becomes their job to advocate on behalf of your idea and, during the event itself, you don’t speak to it.
Have a hat with a “team member” sign that you wear when presenting and speaking to your idea. There are several caveats with this idea: it can only work when the team already trusts that you’re a good facilitator, it can only be used sparingly and, when used, it really should be for only a short fraction of the retrospective.

While it’s challenging when the facilitator is an active team member, having the team’s manager or executive as the facilitator is far worse. Managers have power and, because of that power, participants won’t feel safe being candid and honest when difficult subjects are discussed. Managers cannot facilitate retrospectives and, under most circumstances, they shouldn’t even be in the room.

2. Own the Retrospective Plan, Keep it Interesting

To be effective, you should have a plan but also change up your retrospectives so they don’t get boring and predictable. If they’re always the same old song and nothing improves as a result of the conversations, team members will become disengaged and miss out on the benefits of a well-run sprint retrospective.

As the facilitator, you own the design of the retrospective. You decide which activities fit the team’s circumstances and mood, so be mindful of your choices. For example, if your team had trust issues last Sprint, then don’t plan an activity like Story Oscars² that focuses on why a User Story went wrong, or there’s a good chance it will turn into a blame-and-shame session. In a situation like that, you’d be far better off to pick an exercise that is likely to promote a Systems Thinking mindset, so that the wider context becomes visible before you try to deal with trust issues.

Even with the best plans, you still must be prepared to adapt. I’ve facilitated a retrospective where I could just sense the energy of the room dying and the existing activity wasn’t working for them, so I flipped to a Sailboat Retrospective exercise, which felt a little more lighthearted and interactive. Likewise, if the conversation seems to be going in a different direction than you anticipated but it’s still productive, consider allowing it to unfold and adapt your plan based on the team’s need.

Facilitation Tips

Cover the meeting outline before beginning by giving the team a short outline of your agenda.
Don’t solve problems. Help your team communicate effectively so they solve it.
Allow silence. If the dialogue pauses naturally, don’t seek to fill the void. Silence often prompts someone new to speak up.
Ask open-ended, probing questions that seek to clarify, and test to see if your understanding of a statement is correct by rephrasing it back to the original person.
Direct questions to the quieter members of the group to help bring them into the discussion.
Monitor the energy of the group by observing body language, fidgeting, tone of voice, etc.
Pay attention to your own body language and reactions. What signals are you sending? Are you favouring anyone? Signalling irritation?
Don’t do all the writing. When writing summaries is necessary, consider inviting a team member to do it. You may find that their interpretation of events is different than yours would have been, which is valuable to learn from.
When you must be the scribe and you paraphrase, ask the audience if your rephrasing matches their original intention.
Encourage people to use “I” language if there are difficult situations. That is when the person describes the effect it had on them and their feelings, rather than makes statements that start with “You did … x.”
Refocus the group if they jump ahead segments. For example, if in the data-gathering phase, people start to solve the problem, gently guide them back to the task at hand.
Use a Parking Lot to set aside questions or issues that can’t be handled right now. It acknowledges that there is something that needs to be addressed but prevents the retrospective from being stalled as a result of it.
When you have team members who are more expressive than others, consider exercises where their opinions come later, after quieter team members.
Bring in an outside facilitator from time to time – someone from another team (not just the ScrumMaster), an Agile Coach etc. – so they can observe and offer objective feedback and suggestions for improvement.

This is just a quick post about one of the most essential parts of Scrum. For the fundamentals of effective retrospective structure, see Agile Retrospectives. Learn much more in our free Guide to Effective Agile Retrospectives.

Image credit: Prateek Katyal

Footnotes

Unpacking Interruptions- Why Your Team Struggles to Get Things Done

Mon, 01 Dec 2025 00:00:00 GMT

We’ve all seen a team that is busy and yet is hardly moving forward. A big issue? Interruptions. Some reports suggest most people don’t even get two hours daily to do their work.¹,² Good news, on the difficulty front, is one of the easier one problems to improve.

“It’s all Scrum’s fault…” I recently had someone tell me this in a pub after a long hike. Interruptions are a huge problem for any team, although maybe not commonly discussed over a pint of beer.

I asked a simple question, “Did you have any interruptions before you started Scrum?”. Yes.

“Did Scrum cause those interruptions?” No.

Instead of blaming Scrum, let’s look at the real sources.

Where Interruptions Come From

Self Interruptions

Multitasking and/or boredom - Working on several different items at the same time, we interrupt ourselves by switching between tasks. As someone with ADHD, boredom often leads me to multitask. I don’t even need teammates to interrupt me.
Long running task finishes - Working with Generative AI or a slow build, many tools that we use take time to do their process, so we interrupt ourselves by switching to another task while we wait.

Team Interactions

Requests for help from a teammate
Friends at work stopping by your desk to socialize
Scrum Events - Planning, Daily Scrum, Review, Retrospective and Backlog Refinement
Non Scrum meetings within the team
Unplanned work introduced as new features mid-Sprint

External Interruptions

Notifications, like Slack or email
Meetings outside of the team
Defects/Production support issues
External Dependencies - Needing to ask other teams for help, giving other teams your help
Non Sprint work - Classic example: a manager stops by your desk and says the familiar phrase, “Pssst, could you do me a favour? It will only take an hour.” Famously, no such request has ever taken only an hour.

A Team Member bombarded by interruptions, Non Sprint Work, Slack, Unplanned Work, Dependencies

Interruptions Come at a Cost

The human brain doesn’t handle task switching well (see multitasking to dig deeper for why). It takes 25-30 minutes to recover from an interruption. Worse, when we restart the task, we sometimes forget where we were and end up making mistakes. With scheduled interruptions like a meeting, we know it is coming up and can take time to make notes to get back on track faster. Unscheduled interruptions just derail us.

The customer cares most about whether or not the team delivered something of value, not whether any one person on the team was productive, so disrupting flow affects the health and effectiveness of the whole team. Fortunately, not all interruptions are equal in pain or importance. And they’re all fixable.

Solving for Each Type

Self Interruptions - I’m not going to repeat all of the popular productivity advice (e.g. time blocking, Pomodoro technique, etc.), I will just point out that when you’re pair programming, it’s harder to get lost in the land of multitasking.

Remember

Daily Scrum is especially important as it is expected to replace all other meetings within the team during the day. This should mean that the team doesn’t need any other regularly scheduled meetings during the day.

Team Interactions - Most of the time, if it’s a team mate who is asking for help, it’s a valuable interruption. Even then, Scrum has Daily Scrum to reduce the number of times someone needs to ask for help. The Scrum meetings (properly called Scrum Events) are designed to improve the team’s ability to collaborate and so be productive.

The remaining team interruptions are more complicated. Urgent interruptions (e.g. Production support issues or Bugs) should be taken care of right away. The goal will be to keep the impact to a minimum by reducing the frequency and cost. Scrum by Example – How to Handle Production Support Issues in Scrum covers many strategies.

External Interruptions - When it comes to meetings outside the team, ask “What value does the team gain from this? Does it help the team improve flow?” For example, a regular meeting to review a multi-team Kanban board could be very valuable because it helps the team see the impact of their work and ensures that the team stays unblocked. (See: Kanban Portfolio View and Portfolio Management with Upstream and Downstream Teams)

On the other hand, there are many meetings that provide almost no value to the team. In these cases, either don’t attend or send only one person, minimizing the cost of the interruption.

Most other interruptions are harmful, and we want to reduce/eliminate them. For example, new features mid-Sprint? It suggests that the Product Owner and team need to do better Product Backlog Refinement, Product Strategy Work or Stakeholder Management.

Instead of accepting interruptions as normal, study the sources and help your team. Ask who it helps? What is the cost? Could it be avoided or at least scheduled in advance?

See also the Scrum by Example episodes on this theme: More Interruptions covers core hours and making the cost visible, Unplanned Work Disrupting the Sprint explores what happens when a Product Owner forces new work mid-Sprint, and Overtime on a Scrum Team shows how pressure to be “busy” destroys flow.

At the end of long hike, let’s not talk about Scrum. It’s far more fun to talk about the hike we just had. 🙂

Footnotes

Using GenAI to Code? Not So Fast

Wed, 23 Jul 2025 00:00:00 GMT

AI coding agents have been sold to us, making big promises of how much faster we will work using them. In our “The Real Cost of AI-Generated Code: It’s Not All It’s Cracked Up To Be” article, we showed that this speed is coming at a cost with increased Technical Debt and decreased maintainability. The Agile community has witnessed this many times over the years.

Aside from sharpening our skills, most things that promise to help us go faster come at cost. Now there is new research that calls into question even the speed-up of writing code with GenAI.

Read for Yourself and Decide

Summary and the full paper: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.

Caveats: this is a single research paper which studied senior developers who contributed to open source projects. The codebases for the projects were large (over 1,000,000 lines of code), and the developers were familiar with their projects. Some effort was made to ensure that the projects had good-quality code in the first place. So the paper is studying a narrow slice of work, and the results might not generalize.

The researchers paid the participants to address outstanding issues in their projects. For each issue, they were told to use AI or no-AI. They were also asked to forecast how long the issue would take to fix. When allowed to use AI, the developers predicted they would go 25% faster than an unaided human. That’s not what happened. The AI-enabled developers took, on average, 19% longer to complete the task. Interestingly, even though they were notably slower than their non-AI aided colleagues, they perceived that they had worked 20% faster.

These results are contrary to what we see reported elsewhere.

Some research has been done using either simple tasks like implementing a basic HTTP server (“The Impact of AI on Developer Productivity: Evidence from GitHub Copilot”) or synthetic tasks (“Significant Productivity Gains through Programming with Large Language Models”) - neither of which necessarily generalizes to the real world tasks.
Other studies report on the number of lines of code generated UGH!! (“Sea Change in Software Development: Economic and Productivity Analysis of the AI-Powered Developer Lifecycle”), commits, or pull requests (“The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers’). Of course, none of this is correlated with high-quality code that meets the business needs.
SWE and other benchmarks often make it seem like AI tools are good at solving a wide range of problems. However, these benchmarks have flaws. The only metric that matters to them is: Did the code pass the test? But the projects used for the benchmark have incomplete test cases. The generated code might fix the original issue but introduce a new bug. Worse, the code isn’t examined to see if it is readable or fits the established patterns of the code base.
Much of what we’re seeing to support the value of GenAI tool is self-report data. As the above research study illustrates, the self-report data doesn’t necessarily correspond to reality! As an example, I perceived my last bike ride was 20% faster than the previous one, but the data sadly shows it was merely average.
DORA report (State of DevOps) - The DORA 2024 report has missed the boat, measuring developers’ perceptions about AI. It found that they feel more productive and believe they have reduced complexity. But, as seen above, self-report data isn’t the most reliable when it comes to performance.

More caveats on the research paper:

There is a risk that the paper’s methodology missed something important about real work (although this paper already has a better methodology than previous papers).
Many of the developers hadn’t used Cursor before. Maybe with more practice they would have been faster.
The study used senior developers. Maybe junior developers would gain more benefit from AI assistance. But then that leaves the question of how do junior developers grow and become senior? Will junior developers spend enough time reviewing the generated code, understand it, and verify that it’s a good fit?
This is a single paper. Maybe a larger sample size or a diffent mix of people might have found a different result.

What this paper does is give me pause in accepting the statements that claim AI is magically improving developer productivity. For a concrete example of how AI coding tools struggle with real tasks, see the results of our AI Code Generation and the Tennis Kata experiment.

sketch of GenAI promises vs reality

What would I like to see? I would like papers to look at additional questions not covered in this study:

Was the code change a sensible size? Generally, we don’t want bug fixes to be large changes. When bug fixes are large, it introduces new risks.
Did the AI generated code fit the idioms used in the project?
Was the AI generated code readable?
Did the AI avoid adding any new dependencies?

It is early days in our use of GenAI and software development. The models themselves will likely improve (example: context windows), and tool vendors will find ways to improve their tools so the LLM has more information about the codebase. I also know of some developers who are using a BDD style of development coupled with code generation, which might well pay off.

I hope we all learn to be more skeptical of promises about productivity increases without first examining the methodology underneath. (I, for one, have written off the DORA Reports as unreliable.) In our Certified ScrumMaster workshops, we focus on what actually helps teams deliver value, not promises of faster output.

Related Blog Entries

AI-Generated Code Quality and the Challenges we all face

Vision to User Stories - What is the Best Flow?

Mon, 13 Jul 2015 00:00:00 GMT

In a recent Product Owner Course I was asked to provide a picture of the flow from Vision to User Stories, with all the steps in between.

I think the attendee was hoping for something like:

Vision to User Stories - What is the Best Flow - image by Agile Pain Relief Consulting

There are a couple of challenges. Scrum, being a framework, doesn’t tell the Product Owner or the Dev Team (aka Doers) how to do their work. As a result, none of these particular tools are required and some excellent ones such as Personas and Impact Mapping are missing from this simple picture.

The deeper problem is that a picture like this implies a strict linear flow. But there is no standard flow or right order. Each tool is independent of one another.

A picture, were we to draw it, would be more like an interconnected web. Each tool leading to every other and, just as important, gaining feedback from the tool that comes after it.

Some examples to help:

In the first Sprint, the Team might decide to go from a Vision straight to a few User Stories with Acceptance Criteria. In the same sprint, they build out and deploy two of these stories, finally testing them with their target market (aka Lean Startup and Lean UX). Once they get some initial feedback, they hold a Product Backlog Refinement meeting and start populating their initial Story Map backbone. They use the early version of their Story Map to explore the flow from the key persona’s viewpoint. Next, they create the first few User Stories for each item in the Story Map to make sure they understand it well. By now the Team have created thirty Stories and the Product Owner wants to make sure she is prioritizing the stories that will have the greatest effect for the key personas. She turns to Impact Mapping (effectively Mind Maps for User Stories that explore the Why, Who, How and finally What – only exploring the What after we understand the context).

All the while the Team is building software and validating it with market as they go.

In a separate but parallel universe…

Our Team might start by building a vision using a collaborative game like Product Box with their stakeholders (including actual customers). They move from this to designing Personas that represent their core constituencies and then create a Story Map backbone. They take a couple of extra days to create the initial User Stories and initial acceptance criteria. Then, like the first example, they start building their application and validating in the marketplace. As they gain feedback, they update their existing Vision, Personas, and Story Map(s) to reflect their new understanding of the world.

Aside from my personal preference to the first version of the Team, which is wasting the minimum extra time before testing whether their ideas meet actual customer needs, there is no correct version. All approaches are valid.

Instead what matters:

Continuous Collaboration between the Product Owner, Dev Team, and Stakeholders
Frequently updating their artifacts (Vision, Personas, Story Maps) as they discover meaningful change. Since we don’t want to reinvent waterfall, this implies that all artifacts are kept small and light.
We don’t assume that our Personas, Story Maps, etc. are true versions of reality and we’re always trying to test them with working software validated in the marketplace.

So instead of trying to visualize the “flow” to write User Stories, which suggests something linear without feedback, maybe it would be more helpful to imagine it as a mesh or interconnected web.

Image by Agile Pain Relief Consulting.

Welcome to the High-Performance Teams Game

Mon, 12 Jan 2015 00:00:00 GMT

High Performance Teams Game Banner

Your team is working on the World’s Smallest Online Bookstore, a site that provides the best results (just a few) for every search, not every result on earth. We’re a vulture capital funded company, so if we don’t deliver, our funding will be cut.

So begins the opening of the High-Performance Teams Game.

My goal is to help you see the effects of choices/tradeoffs on productivity and team cohesion. While some of the benefits of Agile happen at the individual level, there are many things that affect the relationships between team members, and therefore the overall cohesion and productivity of the team.

The game is played by a team of 5-9 people, in a series of 5-6 rounds. During each round there is a little bit of teamwork, a little bit of discussion of the science, and some game play. Each round represents 6 weeks, or three 2-week sprints. In each round you have budget for the amount of work/stuff you can do based on your team’s capacity. Some of that budget must be spent on delivering features, otherwise the business will threaten to let you go. Some of it should be spent on growing the team and their engineering skills, otherwise you don’t get more budget capacity.

Some of the leading research ¹² suggests that a key requirement for high performance teams is Cohesion. Cohesion is a measure of the strengths of the relationships between individual team members.

In this session we will use this research to discover:

Simple communication patterns we can monitor to spot the health of the team.
Simple tools we can use to measure and track those patterns.
What effect does the location of the watercooler have? What effect do lunch tables have?
Can cohesive teams get you into trouble?
The importance of dissent and diversity within teams.
Bonuses - the negative effects of individual bonuses are well understood by the Agile community. However, we’re left with the question: Are there good bonuses?

Downloads Available

Game Material (Dropbox folder):

Team Actions Worksheet (1 per team)

Facilitators Material:

Teams Game
Sample Games – four possible paths through the game played out
Slides

Magic and Science of Teams Game Edition from Mark Levison

In addition to the game material, I’ve written a paper on the “5 Steps Towards High-Performance Teams”.

Creative Commons License Icon

High-Performance Teams Game by Mark Levison - Agile Pain Relief Consulting is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Feedback from GOAT (Gatineau Ottawa Agile Tour 2015): During game play at the conference, only the facilitator knew the benefit/effects of each action while the game progressed. As a result, in the 90 minute session some teams had a difficult time keeping track of the calculations. Future editions will reveal all the calculation details on paper to the attendees in the round after they’ve played.

The research underpinning this game aligns with the characteristics of effective Scrum teams and the evidence for why stable teams outperform frequently reshuffled groups. For a practical guide on growing the cross-functional skills that high-performance teams need, see How to Cross-Skill and Grow T-Shaped Team Members.

Image by Agile Pain Relief Consulting. Elements of image by Juancho10 and Canva.

Footnotes

Sandy Pentland - The New Science of Building Great Teams https://hbr.org/2012/04/the-new-science-of-building-great-teams ↩
Ben Waber - People Analytics https://www.amazon.ca/People-Analytics-Technology-Transform-Business/dp/0133158314/&tag=notesfromatoo-20 ↩

What Are the Limits of the Scrum Framework?

Wed, 30 Jan 2019 00:00:00 GMT

What Are the Limits of the Scrum Framework?

Where is Scrum Applicable?

Scrum is a tool for building autonomous, self-organizing, high-performing teams and organizations which can successfully respond to changing business circumstances. People often choose to use Scrum because they want higher quality or greater speed, not understanding that these are outcomes of high-performing teams and not of Scrum itself.

Scrum has been used effectively with teams in a diverse array of industries, including Software Development (where it grew up), Hardware Development, Manufacturing¹, Marketing², HR… even Fighter Planes³ and Gas Plant Design⁴! What these very different industries have in common is they rely on a form of knowledge work, which can be understood as work that primarily involves non-routine problem-solving that often needs creative thinking. Knowledge work benefits from collaboration, which is the primary focus of Scrum Teams, so it’s no surprise that Scrum is well-suited for these industries.

Since teams are the core work unit of Scrum, many of the limits of Scrum come from the focus on how an organization’s teams are structured.

Key Conditions for Scrum to Work Well

Understanding now where Scrum is effective, we can consider what structural foundations are needed for it to function well in a given work environment.

Knowledge Work – It may seem obvious but it’s worth stating: organizations (including most retail and service industries) based around the performance of routine tasks that do not require complex problem-solving or creative thinking will not benefit from using the Scrum framework.

Common Goal – A group of people only becomes a “team” when there is a common goal or target that they’re attempting to achieve. In Software Development, the common goal comes from the Product Vision and Strategy. In a Marketing team, this might come in the form of a brand strategy or marketing campaign plan. Whatever the industry, the goal must unite the work of all team members to something greater than their individual contributions. Without a common goal, there isn’t really a cohesive team, and cohesion is key.

Sufficient Challenge – In tandem with a Common Goal, the problem must be challenging enough that people can’t get the job done if they work alone. If people can work without interacting with others and still achieve their goal, they will often choose to do that. The difficulty of the problem must warrant the use of teams, otherwise Scrum is just unnecessary overhead.

Dedicated Team Membership – The costs of multi-tasking have been documented on numerous occasions and it’s no longer considered a desirable skill like it once was thought to be.⁵ Assigning people to work on more than one team forces them to multi-task, making them less productive. Any form of multi-tasking causes people to lose capacity. Assigning them to multiple teams is just the worst case. Their capacity is reduced due to the delays and costs to focus as they switch gears from one context to another and the teams suffer bottlenecks as they wait for their turn with that person. Ultimately, the number of errors will increase, in part because these individuals switching context will forget key details. Evidence shows that dedicating people to one team, and only one team, doubles the throughput of all teams involved.⁶ Without Dedicated Team Membership, all groups are destined to a lower level of productivity and true teams – certainly not high-performing ones – never form. Scrum would be significantly shackled in this environment.

Stable Team Membership – Effective teams take time to form. It takes 6-8 months before a new team develops the cohesion necessary to be truly effective. Furthermore, every time there is a change in membership the team takes a temporary drop in productivity. After a few months, they may regain strength, and may even eventually improve, however some teams never recover. In situations where there is frequent changeover in team members, the team will always be stuck at a lower level of performance. In addition, Stable Teams are a requirement for predictability.

Tuckman's stages of team formation in Unstable Teams

Low Cost of Change – Agile came of age as the cost of making changes in software was being drastically reduced. Much of the work in the years since has been focused on further reducing the cost of making change – from Continuous Integration and Test Driven Development to DevOps and Behaviour Driven Development. The cost of change in modern software development work isn’t zero, but it is considerably lower than the green screens⁷⁸ and mainframes. For any flavour of Agile to succeed in a new environment, reducing the cost of change (even late in the game) needs to be a priority. In work that incurs a significant cost if changes are made, Agile/Scrum isn’t going to be as practical.

Plannable – Scrum Teams normally work in two-week Sprints, so they need to be able to plan their work at least that far in advance and allow for accommodating small changes. For example, a software development team gives itself enough flexibility that it can fix a production support issue mid-sprint without derailing the main work of the Sprint. A marketing team could adapt their campaign in response to new data it received about customer behaviour. The practical limit is that at least half of the teams’ work needs to be plannable. Companies whose entire business model is to respond to unpredictable client needs won’t benefit from using Scrum to organize future work. Caveat: outside the repair industry there are few businesses that survive in the long run on a purely reactionary basis.

Empowered – Teams can only form when team members feel that they have autonomy. Scrum makes this explicit by establishing the team as self-organizing. Hopefully, this is never a key condition that is lacking but, if it is, trying to apply Scrum wouldn’t help the team become self-organizing and efficient, but it may expose the problem, so it can be resolved before continuing further.

Cross-Skilling is Possible – Scrum (and Kanban teams) eliminate bottlenecks by sharing skills until delays can always be addressed by multiple team members. Bottlenecks are such a fundamentally important barrier to high performance that organizations eventually must address them. Toyota’s approach is to pay people more to be able to handle multiple stations. In healthcare, there are some jurisdictions starting to address the issue by allowing some work previously only done by doctors to now be done by nurses or nurse practitioners. At the same time, there are some work environments where, due to regulation, law, or radically different skill areas (e.g. artist and metal worker), cross-skilling may be limited in its applicability or value, limiting the value of Scrum as well.

Early Delivery and Testing – In Scrum, we don’t assume our expectation of the User needs are correct. Instead, we prefer to deliver products early and gather feedback. We operate in a mode of Product discovery rather than creation. In an environment where we fail to deliver a working product at the end of every Sprint, we are unable to gather feedback. The solution is to find something to show and gain feedback on at the end of every Sprint.

Co-location – Having all team members in the same room continues to be the best choice. Humans have evolved over millions of years for face-to-face interaction, so this is still the best way to build collaborative teams. While remote work and distributed teams are currently trendy in many businesses, the challenges these create are significant and result in high-performance taking longer to grow in the Team. If distributed teams are absolutely unavoidable, applying Scrum practices (e.g. daily stand-up) will be more challenging and require adaptations. It’s still possible to practice Scrum effectively in distributed teams – it’s just much harder.

Examples of Where Scrum Isn’t Ideal

So now that we understand why Scrum works and its conditions for success, these are in order from teams where Scrum is the least likely to help, to where it will be challenging but may still offer some benefits.

Construction - When a team is tasked with pouring concrete or paving a road, the cost of change is effectively the cost of the work. Agile approaches, in general, can still work, but it comes with an increased cost. Consider Lean Construction and both the Empire State Building⁹ and the London Shard¹⁰ of examples of this approach.

Help Desk and Repair Services – When people in an organization provide digital or phone-based support services, their work does involve the Knowledge Work key condition, but it’s entirely driven by interruptions. They can start the day working on one issue, but when a call comes in with a more important issue then they must switch. This pattern can repeat itself several times during the day. This violates the Plannable condition, so Scrum won’t be effective in this context. Consider a different tool that improves the flow through any system, such as Kanban. This may also apply to other organizations and services – essentially anywhere that knowledge is the primary requirement, but the work is not plannable.

Back-Office Operations – Many organizations have groups that do all the background work such as finance and other related departments. Most of this work – invoices, expense tracking, and other bookkeeping – is done effectively by individuals working on their own. While the work is knowledge-based, it is often repetitive and so wouldn’t be Challenging. These groups often lack a coherent vision or Common Goal. Consider Kanban instead of Scrum again, as a tool to better understand the flow of work inside these groups.

Infrastructure and Technology – Most organizations also have people who configure laptops, servers, security, networks, firewalls, and other technical infrastructure. This knowledge work is less repetitive and more Challenging than back-office work, and it benefits from collaboration because problems often require more than one skillset to solve. These groups also typically have a Common Goal (e.g. keeping internal users productive and safe). But in many cases, their unplanned work exceeds their Plannable work. However, Scrum might help by bringing into focus the volume of the unplanned work for the team, helping them put effort into reducing it.

COTS Apps¹¹ – Organizations often outsource a lot of their backend software (think: Gmail, QuickBooks, Expensify) to cloud vendors. This is fantastic, but eventually, there are enough applications each that requires occasional changes (new user, new accounting rule, etc.). None of these applications requires one person maintaining them as a full-time job, so you might end up with 6-7 people maintaining 10-15 individual applications. Lacking a clear Common Goal, this group is unlikely to become a Team. Scrum could work but the value might be limited. The challenge for both the infrastructure and teams is that their knowledge is likely to stay fragmented since there is little reason for people to learn another team member’s area. Whether the team chooses Scrum, Kanban, or some other framework, this will likely remain an issue. Consider asking if the group could be reorganized to create a space where a Common Goal is possible. An alternative option is the team could work to create a goal that is possible in their circumstances. These notes are inspired by a conversation with Petri Heiramo:

Given the “product” they work on is clearly not sufficient to rally them, the discussion would need to be shifted to something greater than the work they are doing. Would they want to become the best support team ever? Would they want to do whatever they are doing in half the time? Would they want to NOT do their work and try to automate as much of it as possible? Do they know whose lives they are making better and could they possibly derive some worthy goal from that end?

One possibility would be to ask them how happy they are at work. If they’re not happy, the next question could be are they willing to put effort into making themselves happy. After all, their three main choices are 1) keep doing what they are doing and stay unhappy, 2) do something to make themselves happier and proud of their work, or 3) leave the company for something else. Obviously, 3 is not desirable and not a great starting point, so the choice should really be between 1 and 2. Then the next step could be to ask them what makes them happy and proud at work, and/or what makes them unhappy and ashamed. This could help them establish a shared goal of becoming happier and discover a starting point for corrective action. There could be a discussion of how to measure happiness and pride (i.e. how to know they’re making progress toward their goal). There could be an agreement of some self-reward (like beer on Friday) whenever they’ve achieved some concrete improvement in their work that they are proud of such as:

removing the deepest information bottlenecks that prevent them from taking holidays without stressing about work.

clearing up their worst technical problems.

making a grumpy customer happy or even delighted with their team/service.

establishing some new practice to improve productivity, or reduce feedback cycles.

Individual Work – any business problem where there is no prospect for collaboration (company of one or everyone works in isolation), won’t benefit from Scrum directly. After all, there is no team to grow. In that circumstance, consider Personal Agility and Personal Kanban.

Team Members Matrixed onto multiple teams and no Stable Membership – I can’t imagine a business circumstance where this is desirable. If this is the scenario, Scrum will work quite effectively to highlight the organizational impediment, but not to help manage the problem. In every workshop, we discuss the fact that Scrum is a tool for finding problems. Scrum succeeds in the long run when the organization takes seriously the need to resolve issues like this that Scrum finds, not just manage them.

There are limits to what we can use Scrum for, but they’re much wider than most would imagine.

Thanks to Petri Heiramo for suggestions and the visioning exercise for the COTS team.

Want to Learn and Become a More Effective ScrumMaster?

Practicing Scrum in the real world is challenging. Questions like whether Scrum is the best choice for a given project or organization is something most of us learn from spending years working in the field… and failing.

We understand that desire to gain a deeper understanding of Scrum: why we choose Scrum and how to apply it effectively. If you share that desire, we invite you to join us for one of our Advanced Certified ScrumMaster workshops – a collaborative, hands-on experience with Certified Scrum Trainer Mark Levison, who will coach you through the most complex aspects of using Scrum, on how to spark real change in your organization, and on what to do to advance your career as a Scrum coach.

Image attribution: Agile Pain Relief Consulting Updated: April 2025

Footnotes

What United Can Teach Us About Building Systems

Tue, 18 Apr 2017 00:00:00 GMT

By InSapphoWeTrust from Los Angeles, California, USA (United Airlines - N797UA Uploaded by Altair78) [CC BY-SA 2.0 (https://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons

In April 2017, United Airlines made global headlines when they forcibly removed one passenger (David Dao) who had already boarded the flight, to accommodate crew flying to another destination. The flight staff called the airport police and Dao was hurt as he was dragged off the plane, suffering a concussion, loss of teeth and other injuries.

In the same week, another United passenger flying from Hawaii to Los Angeles was forced off a plane despite having paid full fare for a first class ticket. “That’s when they told me they needed the seat for somebody more important who came at the last minute,” Geoff Fearns said. “They said they have a priority list and this other person was higher on the list than me. They said they’d put me in cuffs if they had to.”

Neither of these cases should have ever happened. In both cases, crew on the ground and then customer service handled the situation badly. However, I don’t think that the real issue is the airline staff.

There are at least three major issues at play:

Working at 100% of Capacity
Too many conflicting rules
Culture

Working at 100% of Capacity

David Dao was removed from his flight because four crew showed up after the passengers had already boarded. The crew were required in Kentucky the next day, and their absence would have delayed several hundred passengers on other flights. United offered up to $800 to get people to leave the flight, and then when that didn’t work, they simply selected four passengers at random to be removed.

There are two significant problems here:

Stochastic Queueing, by David Levinson. CC BY-SA 3.0

By attempting to have every flight 100% full, there is no capacity to respond to small things going wrong in the system. E.g. extra people showing up at the last minute and creating a shortage of seats. This shows up time and time again, when utilization of capacity in a system exceeds a certain point and the system becomes fragile or breaks completely. In highways and road systems, it happens at around 65-70% of the designed capacity of the road.
By having only enough crew in each city to survive that day’s flights, United is again running at 100% capacity with respect to crew. There is additional risk in that a small problem in Chicago would escalate and become a big problem in Kentucky 24 hours later.

The issue in both cases is the attempt to squeeze every last dollar out of a situation. When we design organizations or systems (e.g. highways, hospitals, airlines) we need to build in enough slack to deal elegantly with small problems.

United could avoid this problem in the future. On all flights to key destinations, set aside 3-4 seats for deadheading crew, and offer these seats to standby passengers only when it can be guaranteed no crew will show up. Another alternative would be to establish backup crews in each city the airline services – the challenge there would be ensuring the backup crews have sufficient cross-skilling to deal with the variety of aircraft that United fly from that airport.

When we’re building teams for knowledge work (e.g. Software Development, Marketing, etc.) that slack time can be used for learning and growing skill.

Too Many Conflicting Rules

The more rules that a system has, the more unanticipated effects, and the less freedom the people doing the work have to make sensible decisions. Between the two incidents, we can see that United has some complicated rules about what it actually means to have bought a fare on the airline:

more important First Class passengers trump other First Class passengers
disabled people, children travelling alone and high status passengers trump deadheading crew
deadheading crew¹ have priority over Economy passengers
United Ground Staff are authorized to offer $400 and then $800 to get passengers to disembark, and cannot deviate from that

This list of United’s policies is, of course, incomplete as it’s just gleaned from news reports following the incident. The complete list is undoubtedly much longer.

With all these rules in place, the ground staff didn’t have enough room to explore other options. Perhaps if they had offered $1000 out of the gate, they would have got volunteers more quickly. Strangely, having to offer $400 – an insultingly low sum for many travellers – made it less likely that people would accept any subsequent offer.

As we learned in Simplicity, when we design systems with complicated rules, they will break down. When we build systems with simple heuristics, people have more capacity to make better decisions in their current situation. In most cases, they use the heuristic as expected, and only occasionally do they break it where local circumstance justifies.

Culture

Under the control of Jeff Smisek, United went from an airline with some customer focus to one totally focused on costs and the bottom line.² Companies that focus on reduction of cost might do well in the stock market for a few quarters. They do well because profits increase, but in the long run the focus on trying to save pennies hurts because it leaves an organization that has no flexibility.

Build an organization that is focused on delighting the customer³, and give the team real decision-making capacity. Then even if we’ve made mistakes, those people still have the ability to identify a problem as it happens and make the situation right.

By all accounts Oscar Munoz, United’s CEO, is attempting to turn the culture around. He has only been CEO for 20 months, which is not enough time to make a significant impact on a company employing nearly 90,000 people.

The real question: is Munoz attempting to make significant changes to affect the culture, or will the cost focus of his predecessor live on?

Footnotes

Deadheading crew – flight staff who aren’t working on the flight but are instead flying to the destination in a passenger seat, to work a flight from there. ↩
The Root Cause Of United’s Denied Boarding Fiasco https://onemileatatime.com/united-denied-boarding-fiasco/ ↩
Is Delighting The Customer Profitable? https://www.forbes.com/sites/stevedenning/2011/04/01/is-delighting-the-customer-profitable/ ↩

When to stop holding retrospectives?

Wed, 23 Nov 2011 00:00:00 GMT

This question often comes up. Usually because a team has become bored with their retrospectives. I suggest you don’t use the same style or format more three times running. The question came up again today with a person saying that their team was doing well and had achieved a steady state. To my mind steady state isn’t the point of Scrum. Scrum is a tool to help you be the best in your industry. Scrum should be a tool you use to disrupt an industry. To that end the next time you tell me that I hear that you’re team is a good as it gets my reply will be: “Ask the team what it would take for them to be the best in their industry, worthy of a case study on Infoq or a major conference presentation. Everything between the team and that case study is an impediment. Go forth and remove the impediments”.

Update I posted this in a bit of hurry - it wasn’t really a full fledged post. To make up I’m adding a section on why people want to stop holding retrospectives:

Complacency

Many teams reach a plateau and assume that they’re done since they can’t make any more improvements right now. It was this belief that I was pushing back against. Sometimes we can’t see where to go from here, but undoubtedly we can all afford to get better. It was to these teams I offered the challenge - what would it take to become a case study in your space?

Boredom

A far bigger problem is boredom. Once the team has experienced the same retrospective style three times in a row, they will become bored. If you’re facilitating watch for people fidgeting, playing with their phones or having side conversations. That’s a good indication that they’re not engaged. If you keep on running the same retrospective read: Agile Retrospectives: Making Good Teams Great (Esther Derby and Diana Larsen) and Collaboration Explained: Facilitation Skills for Software Project Leaders (Jean Tabaka). Google Agile Retrospectives. Read This blog. Whatever you do seek out new styles.

Ineffective

My favorite is the ineffective retrospective. The team walks through the meeting comes up with some SMART goals, they sit on the shelf for the next two weeks and no one acts on them. This is really no better than traditional post mortems. How to make them more effective?

Ensure your SMART actions are achievable in the next two sprint
Post the SMART actions on the top of your Story/Task wall - in BIG WRITING
After a few days start calling attention to the actions at the start of Daily standup, calling more and more attention to them as the Sprint goes on

What other problems do you see with your retrospectives?

Related Blog Entries

Why are we so easily influenced? Weapons of Influence

Thu, 09 Nov 2006 00:00:00 GMT

Influence- Science and Practice book cover

](https://www.amazon.com/gp/product/0321011473/&tag=notesfromatoo-20)

Do you ever walk into a clothing store just to buy a suit and walk out having bought the suit, tie, belt and several shirts? This chapter will explain what just happened.

This is the third posting in an ongoing series of notes from Robert Caildini’s ” Influence: Science and Practice”. This posting covers Chapter 2 “Weapons of Influence” Other postings in this series: Introduction, Other Sources coming soon: Reciprocation, Commitment/Consistency, Authority, Social Validation, Scarcity, Liking/Friendship

“Weapons of Influence” introduces the concept of fixed-action patterns or automatic responses.

What are automatic responses? They’re preprogrammed behaviours that are fired in response to one or more triggers. For example a mother turkey will nurture anything in its nest that makes the “cheep, cheep” noise of a chick (even a mortal enemy as demonstrated with a stuffed polecat and tape recorder). However as soon as the cheep sound goes away the mother turkey will recognize the intruder for what it is (attacking the polecat). Cialdini explains how and why these responses work and why they’re necessary for our day to day sanity.

For example one jewelry store owner (a friend of Cialdini’s) was having trouble moving some turquoise jewelry in her store. Frustrated she with the sales she left a note to the sales staff to reduce the price by 1/2. However the staff misread the note and doubled the price. Over the weekend the jewelry sold out. What happened? The buyers assumed Expensive = good. Why does an automatic response work like this? Short-cuts: automatic stereotyped responses that help us navigate through the thousands of choices we have to make every day. We have so many decisions to make that we can’t afford to do a proper analysis of each one. Instead we really on shortcuts like expensive = good or an experts opinion.

Even an experts opinion can be dangerous, do we listen with a critical ear or just accept it without question. As aircraft accident investigators have found too often we listen to the voice of authority (captain) even when the instructions are clearly wrong and might have fatal results. In another example (drawn from the book Crucial Conversations) in one hospital a patient showed up for a tonsillectomy and had a foot operated on instead. At least seven other people in the operating room wondered why the doctor was working on the foot but didn’t question his authority.

The chapter also introduces the contrast principle, a favourite of profiteers everywhere. The idea: sell or show the customer the most expensive item first and afterwards everything will seem cheap by comparison. For example when a customer comes in to buy a suit, sell them the thousand dollar suit first. After that even a two hundred dollars in accessories will seem cheap by comparison. In another example Cialdini mentions a real estate firm that maintained several rough properties that realtors could show clients first. Once the client had seen the rough property, normal properties seemed good by comparison.

This post introduced the importance and use of automatic triggers, the next post will discuss the Reciprocity principle. Or why we return automatically return favours.

Other reading Marshall Soules Media studies 205: promotion, persuasion and propaganda. Janin’s Surrounded by Weapons of influence

Image via Amazon

Why AI Doesn't Replace Your ScrumMaster (and probably never will)

Wed, 21 May 2025 00:00:00 GMT

AI’s superpower is speed—its ability to churn out text faster than any human. But there’s a catch: it sounds too confident for what it actually “knows”. ScrumMasters, Product Owners and Developers frequently ask me how they can use GenAI effectively, and they wonder if it’s going to automate their job out of existence. Most questions come from misunderstandings of how the current generation of tools work.

GenAI Doesn’t Think

Marketing hype for the current generation of tools that we call AIs makes it seem like these tools are on the verge of replacing people at work, implying that you won’t need a ScrumMaster because the AI will be your coach, and there’s no need for a Product Owner when User Stories write themselves.

The hype claims that Generative AIs (or GenAI), such as Google Gemini, Claude Sonnet, and ChatGPT, can think and reason, but don’t be fooled by the marketing language. Here’s the reality:

Learning - They don’t learn, they’re limited to the data they were trained on.
Reasoning and Thinking - Even when asked to think step-by-step, it’s just faking the process. It doesn’t actually understand.
Context Window - The models we use today have limited memory for the current conversation. Once that memory is exceeded, they forget the beginning of the conversation.
Training Data - AIs have been trained on all of the text on the internet. So their output is just the average of the internet which, of course, is unregulated.

GenAI (properly called Large Language Models) takes the text you give it in the prompt and predicts the next word that should come in the conversation. That word is added to the text after your original prompt, and the revised text is fed back to the model to predict the next word. This continues, building responses one word at a time, until it predicts that enough words have been generated.

This is not how a human works. We consider what we want to express and then find the best way to say it. By giving GenAI human attributes—reason, thinking, conversation—we build a model in our heads that implies they’re like humans. Except they’re not, so we must keep clear in mind their strengths and weaknesses.

GenAI Strengths and Weaknesses

Their core strength is dealing quickly with a large amount of information. Their weaknesses centre around errors. The greatest danger is that, as demonstrated in “The Impact of Generative AI on Critical Thinking”¹, the more confident the AI sounds, the more likely we are to believe it² even though there is no correlation between that and whether or not the information is good.

Strengths

Sifting through a large quantity of information quickly
Finding patterns in data
Generating a large number of different ideas quickly in response to a question (also a weakness if done too early in our work process, as it will bias our creative thinking and the likelihood of spotting missed cases)
Summarization
Analyzing our existing work for what we might have missed

Weaknesses

Patterns - false positives, it will find a signal in noise even when there is no signal
Sounds confident even when providing inaccurate information
Sycophantic – The tool’s response to a prompt often starts with “That’s a great idea”
Risk of errors (from misinterpretations) and hallucination (completely false information) with new models may worsen as new models are increasingly trained with limited supervision on “synthetic data” (generated by other models)

GenAI can be beneficial, however, we need guardrails.

Guidelines for GenAI Use

Key considerations:

Collaboration - Much of Scrum’s success is getting team members to collaborate
Bottlenecks - The theory of constraints shows that improvements that aren’t at a system’s bottleneck are waste (usually making the bottleneck worse).

Scrum and Agile teams can use the following questions to help distinguish between healthy and harmful uses of GenAI.

Before using GenAI in your Scrum team, evaluate:

Collaboration: Does this enhance team collaboration?
Bottlenecks/Value: Is it addressing the team’s bottleneck or significantly speeding up a time-consuming task? (Hint: shaving 5 minutes off a 10-minute task is not a win.)
Risk Tolerance: Can we afford the errors the tool will make? Do we know the subject area well enough to sufficiently review and identify errors in the generated work?
Complexity & Sustainability: Can we manage the added complexity from adopting the tool? Does the time savings account for error detection, correction, and long-term maintenance?
Enabling: Does it make it possible to do something new and novel

Evaluating Tools Using Our Questions

I’ve surveyed many tools across the internet to find a representative sample of the promises the tool vendors make about helping your team. But there’s an inherent problem as I offer my opinions. No website or marketing copy captures what a product actually does behind the scenes. I interpret content and then share the information with you, and you will in turn interpret what you think I’m saying. Think of the child’s game of “Telephone”. Communication, no matter how careful and responsible, leaves room for error.

AI for a Sprint Retrospectives

Many GenAI models promise to connect with tools like Jira, Slack, GitHub, and calendars to automatically gather and analyze sprint data (e.g. completed tasks, communication patterns, roadblocks). They pitch:

AI-Suggested Talking Points: Generates relevant discussion topics based on the analyzed data, helping teams focus on impactful issues.
AI Grouping and AI generated Action Items: Help you easily streamline your retrospective.
Sentiment Analysis: Analyzes team communications and feedback to gauge sentiment and identify underlying emotions or concerns.
Facilitation Assistance: The AI can act as a co-facilitator, guiding the conversation and covering all key areas.
Team Members Accountability: Helps identify, assign, and track action items that arise from the retrospective.

My Take

This is a bit of a mix.

The good: Automated data collection makes it more likely that valuable data comes to the Retrospective.

Only ‘okay’: Analysis, if used to augment and not replace human thinking, might spot hidden patterns. Sentiment Analysis of the team’s conversations might spot overlooked patterns. However, the harm caused to Psychological Safety, knowing that an AI overlord always looks over our shoulders, exceeds the value.

Outright bad: Grouping exercises in Retrospectives are designed to start a conversation among team members about how problems are related. So AI Grouping and, worse, AI generated Action Items are replacing human insight, which is ironic since the humans still need to understand and solve the problem.

Baked into the tools, I looked at? The assumption that all of the meaningful interactions occur inside a JIRA, Asana or KanbanZone. Email, Slack, or real-world conversations are far more important in most teams.

sketch of GenAI assigning tasks to team members

AI Daily Scrum

You just can’t make this up. One vendor promises to replace Daily Scrum with text, voice and video messages, then run reports on a schedule and share the reports with multiple Admins.

My Take

A Daily Scrum is an event to give the team time to understand what their peers are working on, hear about impediments others face, and to spark collaboration. None of this is served by an automated tool. This tool has nothing to do with Scrum, except that it stole the language. I can only imagine that a team using a tool like this will have low psychological safety and also be micromanaged to the brink of extinction.

Not surprisingly, this same vendor, who completely misses the point of Scrum, pitched the ability of the tool to also run Retrospectives on autopilot by gathering notes and feedback from individual team member submissions and “Replace retrospective meetings with scheduled team surveys. …. Run retrospectives consistently on schedule”. Is replacing human interaction with writing to an AI the way to build effective teams and positive work environments? Is keeping to a schedule the most important thing in a Retrospective?

Generate Meeting Agendas and Take Notes

Several tools are offered to generate meeting agendas (planning, reviewing, and retrospectives) based on the current sprint’s needs, and claim to make meetings more purposeful, efficient, and less time-consuming.

An AI meeting assistant auto joins, auto shares, and auto summarizes meetings. AI-powered meeting assistants help save professionals and teams an average of 4 hours a week and increase productivity by automatically generating action items, summaries, and follow-up emails.

Feel stuck for ideas?

FWIW, if you want more creative ideas for retrospectives, see the Retromat: http://retromat.org/en

My Take

How much time do we spend writing agendas? Minutes? Speed-ups in creating agendas seem to be of low value.
Meeting summary and action items might be useful. It saves time, and the risk of errors seems low as long as the participants review the notes/actions immediately afterwards.

Conclusion

So many tools out there promise to provide AI, making promises to solve all of your team’s problems. I could write another five pages reviewing tools. Like any other Scrum-related improvement, take the time to breathe. Before we rush to adopt AI, take the time to look:

Where is your team bottlenecked?
Where would applying a GenAI help make the lives of all team members easier?
Have we considered all the consequences, not just the hype the tool vendor is selling us?

GenAI is a valuable tool. However, it is not the only tool in a ScrumMaster’s tool chest. In our Certified ScrumMaster workshops, we practice the collaboration, facilitation, and critical thinking skills that no AI can replace.

Good tools help you better understand your team and current circumstance. The real work of understanding a team and their work can’t be automated.

Where have you found GenAI helping or harming your team?

Your Pain is Real

Knowing how and when to use AI for your team’s benefit is just one of many issues for Scrum teams today. Use Effective Scrum to help improve your team, in a world that is increasingly challenging.

Agile Pain Relief Blog Entries

Footnotes

Why are Group Decision-making Techniques Important?

Thu, 04 Aug 2022 00:00:00 GMT

decision-making techniques and tools matter

Whether we’re facilitating Retrospectives, Sprint Planning, or a Strategy session, there are always decisions needed. How you approach those decisions should vary depending on the degree of cost and whether the decision is easily reversible or not.

Given the speed at which Agile moves, we can’t afford a lot of time spent waiting for simple decisions to be made. So for low cost, simple, or reversible decisions, we need mechanisms to make decisions quickly and with a minimum of overhead. For more expensive, complex, or risky decisions, we need approaches that explore the problem in more depth and then create experiments that we can run to quickly see which path is a clearer choice before too much investment is made.

Another reason good techniques are needed is because of cognitive biases.¹ Hopefully we’re all aware of them and we’ve started to spot them throughout our lives. Decision making, like everything else, is made more difficult because of these biases, so we’ll also address how those should be factored into your choice of technique.

Establish Decision-making Policies

The first thing to decide is how your group is going to handle decisions. Once that’s determined, add it to your Working Agreements. A defined policy will help people feel that their ideas got the same reception as anyone else’s ideas. When a team doesn’t have an agreement on their decision-making rule, then a team member might feel blindsided if, for example, a majority vote is called for and they were not expecting that. There should be no surprises.

Techniques for Low Cost or Reversible Decisions

With low cost or reversible decisions the cost of minimizing cognitive biases may be more expensive than the decision itself. There are several options for techniques in these situations, but be warned that some of the most common methods have unexpected traps.

In evaluating different tools, I want to know: Does this help the group decide quickly? Does it help ensure quieter voices are heard? Does it avoid endless rounds of debate? If the proposer’s idea loses, will they feel that it got a fair hearing?

Here are some popular tools and how they work.

Majority vote

This can be used as a group decision-making technique and it’s probably the default of most teams, however, there is a significant risk. When we have quieter people on the team and they take the risk to vote against the group, they may easily see a majority vote against them as silencing their opinion. Also, when someone who is powerful votes early, other people may fall into line, either because they assume they know best or because they feel the safest following authority. I strongly recommend against using this in Agile teams; it tends to disenfranchise the voices we need to hear more from.

Consensus

This approach seeks to ensure the support of all members of the group for the decision. This doesn’t require complete agreement, only no disagreement. Usually when seeking consensus, the facilitator asks a question like “Can we all live with and support this decision?”²

Consensus decision-making is remarkably inclusive and does a good a job of inviting participation from all. With this approach, there are still a couple of risks:

Endless debate – a team can get stuck revisiting the same options over and over from different angles³
False consensus – a team member may disagree with a decision, but not voice it to avoid rocking the boat

After reaching consensus, the facilitator might ask the group to commit to helping to implement it.

Fist-to-Five rapid voting technique

This should be done blind – everyone makes their decision and votes are revealed simultaneously using one hand per person. This improves on majority voting because it invites more subtle opinions than just yes/no from a majority vote. It also invites further discussion where it is warranted. Where it would save time, it also signals an idea that has rough agreement.

A “no” vote, will block consensus
No support, but won’t block.
Will discuss and suggest changes
Moderately comfortable, Discuss minor issues
Not in total agreement but comfortable to let the decision pass
Good idea, will work for it

Fist of Five - from Hard No to Great Idea

Decider Protocol

From the Core Protocols – a set of Protocols to help teams go about their work, minimizing the time wasted in meetings. The protocols are designed to help focus discussion and decision making.

One actionable idea is proposed.

Participants ask questions to gain clarity.

A vote is performed using hands again, but this time just a thumb, to indicate a choice.

Thumb up = yes: full support
Thumb sideways = yes: support the idea but may still have to think it through
Thumb down = no: do not support, provide a counter-proposal

The proposer counts the number of votes. If the number of yes votes (either thumbs up or sideways) is too low (usually below 70%) it is a weak proposal and should be withdrawn.

If there are a small number of “no” votes, use the Resolution Protocol to see what it would take to get them on board with a question like: “What will it take to get you in?”

(This is a brief summary – see all the Core Protocols⁴ including the Decider section⁵ and Resolution sections⁶ for more depth.)

Dot Voting

This is a tool for selecting the top few options among many.

Before using dot voting, take a few minutes to group or eliminate similar items. Then each voter gets the same number of dots to vote with. The dots can be stickers or simply a dot written in pen.

A voter places all dots on one idea or spreads them out – it’s their choice.
The idea, or ideas, with the most dots wins.
How many votes per person? Five to seven has worked well for me in the past, but it’s up to you.
In remote teams, some of the tools build dot voting in. In others, I’ve seen attendees edit the titles of sticky notes to add a ”#” per vote.

dot 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 but it, too, has some 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, i.e. voting decisions are made without seeing the votes of others.

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.

It’s worth noting that dot voting is a popular tool for online interactions and distributed teams. The online tools typically cost money, but whiteboard tools such as https://www.mural.co/, https://miro.com and https://stormboard.com/ all allow the facilitator to create a dot voting session. They also have the advantage of being blind. Tools like https://www.groupmap.com/, https://consider.it/ and https://stormz.me/en have a richer set of tools to generate, organize, and vote on ideas. While these aren’t designed for retrospectives, they might be useful.

Techniques for Expensive or Irreversible Decisions

When the cost of the decision is higher or there is an element of risk or uncertainty, then we want to find decision-making tools that mitigate against those, as well as against cognitive bias, and take more time and ask better questions so we can have better information to make decisions with stronger odds of success.

When the cost and/or uncertainty is high, we should not look for an immediate decision. Rather, we should be looking for an experiment that we can run that will get us closer to a clear choice later. In designing our experiments we need to combat cognitive biases such as the following.

We often start our problem by thinking in too narrow of a frame of choices. This is often coupled with Blind Spot Bias, where we can see other people’s biases more easily than our own.
Confirmation Bias leads us to look for information that reinforces our existing thinking, and Motivated Reasoning causes us to see new information in a way that supports our existing beliefs.
Short-term emotions can paralyze us or shut down good choices via fear, sunk cost fallacy⁷ and more
Overconfidence when we are certain about our guesses for the future is often coupled with Hindsight Bias where, once something happens, we see it as if it was the only thing that could have happened.

No single magic technique will overcome all of these biases, but we can take steps to minimize their effect.

Use Systems Thinking tools like change perspective (What happen if we take another person’s point of view?) or change time frame (What will the effects be in 5 days? 5 months? 5 years? This is also known as 10/10/10 Analysis – 10 days, months and years.) This ties back to the Future Perspective approach⁸ of stepping mentally into the future and imagining afresh where we want to arrive.
Explore other sources of data or information. (From outside the team? From outside our organization? Who else has made similar decisions before?)
Use the Rule of Three.⁹ If you don’t have at least three options, you don’t have enough.
Ask what assumptions are being made and test if those assumptions are valid.
Discuss the longer term unintended consequences of this decision. (How could someone game the system to exploit this decision?)
Ask whether there are any time-delayed effects that might show up down the road. This is an especially important question, as a lot of solutions that seem good on the surface cause deeper problems down the road.
Ask for someone to take a dissenting position and treat the dissenting view as important and not just an empty gesture. Getting an opinion from someone who would make a different decision forces us to consider our own approach from another angle. If you can’t find a dissenting view within your team, ask outside your team.
Admit uncertainty.
Consider what would happen if you made the opposite decision. This broadens thinking and can uncover advantages or pitfalls that help make the choice easier.

After the Decision

Whatever the outcome, we need to be careful of “Resulting”¹⁰, where we judge the quality of the decision based on the results. Luck plays a big role in work. Sometimes good decisions result in bad outcomes and sometimes bad decisions still get the result we wanted. The common example used comes from poker where, despite using logic and weighing odds, sometimes luck tips the scales. It’s important to acknowledge that good decisions can have bad outcomes despite a team’s best efforts, otherwise fear will make future decision-making even more difficult.

Good decision-making practices are just one facet of team effectiveness. For a broader look at what makes Scrum teams work well together, see Characteristics of Effective Scrum Teams. And when the team is ready to move beyond cooperation into true joint work, Collaboration Over Work in Isolation explores what that shift looks like in practice.

For additional practical tips and strategies on how you can help your team be more effective, we’d love to have you join one of our Advanced Certified ScrumMaster programs, where instead of dying from boredom sitting in a 2-3 day theory class, you will learn new material and be coached over an extended period how to build a sustainable improvement process.

Footnotes

There are several book length treatments of this subject. Decisive: How to Make Better Choices in Life and Work by Chip and Dan Heath. ↩
Consensus Decision Making ↩
Curiously, Planning Poker was originally invented as a tool to cut through endless debate in estimation meetings. ↩
Core Protocols ↩
Decider Protocol ↩
Resolution Protocol ↩
Sunk Cost Fallacy commonly known as “throwing good money after bad” ↩
Future Perspective ↩
Attributed to Gerald Weinberg: ↩
Courtesy of Thinking in Bets - Annie Duke ↩

Why Having a Tech Lead or Manager as Scrum Master is a Bad Idea

Tue, 05 Sep 2023 00:00:00 GMT

Have you ever had friends or family ask, “I know you’re called a scrum master, but what does that mean? What do you actually do?” Go ahead. Tell them that the role of ScrumMaster is as a servant-leader, coach, and facilitator, navigating the dynamics of the team to ensure Scrum practices are followed and value is delivered effectively.

Then watch their eyes glaze over.

Being a ScrumMaster is an incredibly rewarding job, but it’s not likely to be accused of being thrilling or sexy. Since educating is in my blood, my party answer to “What is a ScrumMaster?” is considerably more dry than yours will hopefully be.

Servant Leadership: prioritizing the needs of the team and helping others to perform as highly as possible. The ScrumMaster doesn’t command or control but serves by removing impediments to progress, facilitating meetings, and helping the team measure their progress. This aspect of servant leadership also entails fostering an environment where the team can be self-organizing and efficient.
Coaching: helps the team improve by ensuring that Scrum principles, values and practices are understood and enacted. This involves mentoring the team, promoting continuous learning and improvement, and addressing any issues that hinder team collaboration and productivity. The ScrumMaster also assists the Product Owner with effective backlog management, and helps them learn in any other areas that help them deliver better quality products (ex. Pair Programming, Behaviour Driven Development, Lean U/X, Example Mapping and many more).
Facilitation: of all Scrum events, such as Daily Scrum, Sprint Planning, Sprint Review, and Sprint Retrospective. This involves ensuring that discussions are effective and decisions are made, without taking a dominant role in the conversation. This also includes fostering an environment where all voices can be heard and creating a safe space for open and transparent communication.

The ScrumMaster’s role is crucially performed without authority. There are several reasons for this:

When the ScrumMaster works without authority, it empowers the development team to take ownership of their work, which is key to self-organization and promotes a sense of responsibility and commitment.
A non-authoritative role fosters a more collaborative atmosphere, where each team member’s opinion is valued. It encourages open communication and transparency.
Scrum embraces a flat team structure (no hierarchy) where everyone has an equal say in decision-making. A ScrumMaster wielding authority would contradict this principle.
When the ScrumMaster does not dictate solutions, it enables the team to problem-solve and learn from their experiences, thereby fostering growth and improvement.

By being a servant leader, facilitator, and coach, without exercising authority, the ScrumMaster plays the role of creating an environment where the team thrives and delivers values. Their primary focus should be on helping them grow their skills at doing the work.

Contrary to popular belief, the ScrumMaster is no more overhead than the coach of the Toronto Maple Leafs or Manchester United (that one was hard to type :-)). In our workshops, we emphasize that the job of ScrumMaster is to coach the team to better performance. For example, if you achieve 3% better per Sprint, you get 2.03 times better in a year. Even if it’s only 3% better per month, that’s still ~42% better year over year. If that’s overhead, then it’s a good overhead worth more than one salary. (Massive hint: there are no meaningful measures of team productivity.)

So what about having a Tech Lead or Manager fill the role of ScrumMaster?

As we test this question, let’s make some core statements:

Scrum/Agile only matter to helping teams do better work.
Scrum specifically works by building high-performance teams.
High-performance teams require psychological safety and self-organization.

Therefore we should reject, or at least acknowledge, things that get in the way of teams doing their best work. The more power a team member has, the harder it is to achieve psychological safety.

Tech Lead or Manager as ScrumMaster is a bad idea

Tech Lead as ScrumMaster

Tech Leads are a more traditional hierarchical role. They have authority and decision-making power. Ideally in a Scrum Team, we wouldn’t have one person with this kind of authority as it undermines the collaborative, self-organizing aspects of Scrum.

Having a Tech Lead as ScrumMaster is a much bigger problem. Over a few months, it will hollow out the Scrum process. While the Scrum practices are still followed, the greater sense of the team will be lost along the way.

Specifically, the following problems will occur:

Role Conflict. The Tech Lead is expected to make decisions related to technical aspects of the product. The ScrumMaster is attempting to coach the team to be more effective.
Different Skills: Tech Leads need to be deeply immersed in the technical side of the project, with most of their growth oriented towards technical work. The ScrumMaster is focused on understanding and coaching human behaviour. Much of their personal growth should be focused on areas like understanding behaviour, and facilitation skills. So the ScrumMaster focuses on allegedly soft skills and the Tech Lead on hard skills.
Decision Making: When the ScrumMaster is also a key decision maker in the Scrum team, it makes it harder for them to facilitate from a position of neutrality. In many cases where Scrum would expect an effective ScrumMaster to facilitate, they will instead need to advocate.
Team Improvement: With Team Lead/ScrumMaster as a shared role, where will the individual put their energy? On technical improvements or team improvements? Scrum expects the ScrumMaster to be putting in continuous effort on Team improvement. At best this will be diluted. From bitter past experiences, this will get lost.
Team Dynamics: With someone of power as the ScrumMaster, this will lead to a power imbalance. Some team members, usually the quiet ones, will be reluctant to speak up. As a result, the team will be diminished because it is getting fewer perspectives.

As we can see, Tech Lead as ScrumMaster is a poor choice. Even worse, I think that we just demonstrated that Tech Leads harm self-organizing teams. Instead of making Tech Leads power players, why not consider the opposite possibility? Scrum teams are intended to be self-organizing - they don’t need formal tech leads. At any moment, different people on the team can step up and provide technical leadership. This is called Shared Leadership. When a team works this way, the product is generally of higher quality because diverse technical perspectives were brought to bear. As soon as we appoint someone the “Tech Lead”, we destroyed the ebb and flow, and we’ve said that someone else (management?), knows what is best for the team.

Scrum teams are intended to be self-organizing, they don’t need formal tech leads.

In addition, the ScrumMaster need not be a full-time role. While a full-time ScrumMaster is often more effective at coaching the team, what matters is that we have someone playing that role who team members consider a peer.

Manager as ScrumMaster

If it was a bad idea for the Technical Lead to be a ScrumMaster, a line manager faces even bigger challenges. The line manager has power over the team. This power inevitably affects team dynamics and self-organization. When the Manager becomes the ScrumMaster, the essence of Scrum will rapidly disappear.

The many problems this creates:

Psychological Safety: Nearly 10 years ago, Google discovered that the single biggest factor affecting team performance wasn’t the quality of the manager, nor the skill level of individual team members. Instead, it was psychological safety. Psychological safety is about being part of a team and knowing that you can share ideas and information without fear. It isn’t the avoidance of conflict, rather it is knowing that we can share information inside a team instead of focusing on protecting ourselves. When the Manager is the team’s ScrumMaster, it is much more challenging to create safety.
Performance Reviews: The Manager owns individual team members’ performance reviews. This power changes their relationship and would harm self-organization. Self-organization in Scrum is intended to allow Team members to have the freedom to make the best decisions they can for the team, product, and organization. When a Manager is the team’s ScrumMaster, team members will self-organize, in part, to ensure that they get a good performance review.
Individual over Team Performance: A manager handling individual performance reviews naturally leads the manager to focus on individual performance. Scrum (and therefore the ScrumMaster) is focused on the performance of the team as a whole. In a good team, some of the best performers aren’t focusing on their contribution, but helping raise the performance of the group. Traditional performance reviews rarely focus on efforts to help the team.
Impediment to Self-organization: In addition to performance reviews, if a line manager is also the ScrumMaster, the team may become overly reliant on their direction and less likely to self-organize.
Protect the Team: The ScrumMaster is expected to protect the team from pressure and outside interference. I can tell you from personal experience, much of the pressure they need to protect the team from comes directly from their line manager (who themselves are being pressured from elsewhere). Pressure on a team to go faster, or meet a deadline, never has the positive benefits people expect. When the ScrumMaster is the team’s manager, one safety mechanism gets removed.
Power Dynamics: The ScrumMaster has no authority over the team. They’re there to coach, not to manage. If the ScrumMaster is also a line manager, the power dynamic changes, stifling open communication, creativity, and risk-taking within the team. Team members may feel they cannot express disagreements or concerns for fear of retribution during performance reviews. Further, it takes all coaching advice and turns it into orders for the
Focus on Team Growth: The ScrumMaster’s core focus is, helping the team become more effective. Most managers don’t have the time to spend on fostering team growth.
Micro Management: A manager acting as the team’s ScrumMaster will see the day-to-day details of the work. They will get sucked into the action. As a result, they will naturally start making decisions about the low-level Sprint work. This is the wrong focus for a manager.
Decision Making: A ScrumMaster is a facilitator and coach. Even when a manager is attempting to act in the facilitator role, the team will see a decision maker, not a neutral party.
Facilitation Skills: Most managers are not trained in facilitation skills. When the manager attempts to facilitate, their efforts will often be viewed with the question of whether they are attempting to advance their own agenda.
Conflict Resolution: The ScrumMaster resolves conflicts by creating an environment where we learn to have open dialogue around problems without judgment. When the ScrumMaster has worked on improving psychological safety, teams are better able to deal with and resolve conflict. Having the Manager as ScrumMaster will impede that, for all the above reasons.

When organizations talk about merging the ScrumMaster and Manager/Tech Lead roles, it often stems from a fundamental misunderstanding of Scrum itself and the role of the ScrumMaster. Scrum isn’t a traditional project management tool, instead, it is a human and team-oriented work system. The ScrumMaster isn’t a manager or leader with authority, they’re the team’s coach. Scrum works by building teams. By giving the team’s coach power, it inhibits psychological safety, damages self-organization, and eliminates most of the benefits of Scrum. Please don’t make tech leads, line managers and other people with power the team’s ScrumMaster. Instead, why not help the team understand the role (especially the human aspects) and then allow them to select their own ScrumMaster, possibly from within their ranks?

Scrum isn’t a traditional project management tool, instead, it is a human and team-oriented work system.

P.s. There will always be exceptions to the rule, as people are quick to point out. On occasion some tech leads and even line managers manage to create the environment for psychological safety and a high-performing team. But contrary to what you might think, doing so may have set their team up for a future failure. Using their influence to create that, rather than allowing the team the autonomy to build it themselves, risks that when the lead or manager is no longer present, the team won’t continue with the same principles and behaviours that made it work.

Why Scrum Works??

Wed, 04 Jul 2007 00:00:00 GMT

Rugby match - image licensed from Photodune

In the previous two posts in this series we examined how Scrum provides value to business and why. This post continues the second theme examining the remaining elements of Scrum.

Artifacts

Product Backlog

Basics:

The product backlog is a prioritized list of features of everything needed and wanted in the finished product. To minimize waste only the next few iterations worth of stories are provided in any detail. The list is maintained by the product owner.

Values Supported:

Visible Long Term Goal

Sprint Backlog

Basics:

The sprint backlog is the list of stories that team committed to for the iteration. It is broken down into small tasks with estimates. It is a closed list, once the team has committed no new tasks are added. Only tasks that the discovers are missing will be added.

Values Supported:

A closed list gives the team an achievable target for the sprint. In the typical environment the team has an open ended list of features and bugs which is always. This is demoralizing since you never really know when your going to be finished. The sprint backlog is just the opposite. Since it’s a closed list the team can see their progress through the sprint as the tasks remaining grow fewer. (Do It Tomorrow and Other Secrets of Time Management by Forster Chapter 7 Closed Lists.)

People

Scrum Master/Facilitator

Basics:

Coaches (but doesn’t lead) the team and removes roadblocks. Acts in the role of servant Leader.

Values Supported:

Shortens the learning curve of adoption of Scrum both for individuals and the team
Provides monitoring and feedback so that the agreed upon process is adhered to
Handles process activity communication with Product Owner and organization so team focus entirely on value delivery - Running interference for the team the ScrumMaster reduces the Random Factor (Do It Tomorrow and Other Secrets of Time Management by Forster Chapter 6 Emergency, What Emergency) so that team members are able to stay focused on their tasks instead of flitting between tasks (one of the worst drains on productivity).

Self Managing Team

Basics:

Perhaps the most important aspect of Scrum that often gets overlooked. The team is self managing. Once they’ve agreed on the iteration’s commitments with the product owner, the team is entirely responsible for delivering the product. Team members choose their own tasks; this often means that several team members will work on a single story.

Values Supported:

More than one team member familiar with every aspect of the product
Freedom to select tasks to work improves personal commitment
Teams perform work load balancing better than any one person with a plan and MS project. In all of the Scrum teams that I’ve worked with, the constant open interaction creates a great sense of personal commitment as we pitch in to help each other solve problems.

Scrum provides the framework to create high performance teams, by supporting many of characteristics necessary for their formation. However nothing can guarantee their formation.

Does every Scrum project succeed - of course not (projects can fail using any methodology). Is it the Silver Bullet (aka Fred Brooks The Mythical Man Month)? of course not - but none the less it works and helps many teams focus on delivering value to the customer every day.

Thanks to Larissa Berger, Norbert Winklareth and Mishkin Bertieg for their feedback and guidance in writing this.

Image via: https://photodune.net/

Why Scrum Works?

Mon, 25 Jun 2007 00:00:00 GMT

Rugby match - image licensed from Photodune

The first of my three part series “Why Scrum Works?” has been posted on Miskin Berteig’s blog: Agile Advice. The last two parts will be published here on Wednesday and next Tuesday (Monday’s a holiday in Canada).

Why Does Scrum work? Why do any of the Agile methodologies work? How does Scrum help teams deliver value? How does it help high performance teams form?

This series of posts that will look at why Scrum works on three levels:

Scrum delivers value to the business
Scrum helps form high performing teams
Scrum helps motivate and focus team members

Continue on Agile Advice…

Part Two: Does Scrum Work? Hell Yes!!! Why? has been posted

Image via: https://photodune.net/

Will AI Make the Federal Government More Efficient or Just More Busy?

Fri, 15 Aug 2025 00:00:00 GMT

The Prime Minister of Canada told federal government to become more efficient and cut their budgets, and it’s suggested that artificial intelligence can play a key role.¹

I know AI, I have seen the inside workings of many government departments, and I know something about efficiency. All politics aside (no, really), I have concerns. Using AI isn’t a bad idea, but it needs to be approached in a responsible way. Especially if you’re the federal government.

Oxford English Dictionary: efficiency (-shensi) n. State or quality of being efficient; (Mech. & Phys.) ratio of useful work done to total energy expended or heat taken in;

Be careful, a focus on efficiency can make systems worse. We save a few dollars, but slow down the whole system. “Do more with less” reduces quality and eventually costs more.

There are two major kinds of “AI” in use today. GenerativeAI and PredictiveAI. Generative AI is the tool most of us are familiar with (ChatGPT, Claude, etc). We write some text, and the model generates a response. PredictiveAI attempts to predict future events based on past data — for example, in an emergency department, deciding who needs hospital admission for pneumonia and who can recover at home.

Can either of these tools help make the federal government more efficient?

GenAI is excellent at creating a large body of text or other content quickly. GenAI promises that it will speed up many tasks, allowing each worker to get more stuff done.
PredictiveAI makes many promises, including automating decision-making.

Will either of these make departments more efficient? Assuming GenAI made everyone faster (it doesn’t) and that it didn’t make mistakes (it does), we expect GenAI to speed up departments magically so they can generate more “stuff”. Lots of stuff makes it seem like people are busy. Busy might appear to be efficient, but those aren’t synonymous.

The problem is the bottlenecks. You know them from the daily commute, that place on the highway where it always slows down. The only place to improve is the bottleneck itself (see Theory of Constraints for more details). So even if GenAI does speed up individual workers, unless that person is the bottleneck, the most likely outcome is that it will make the logjam worse.

sketch of GenAI making stuff faster, but with a bottleneck

Even if we magically fixed one bottleneck (example: issuing passports), there might be consequences (e.g. issuing emergency travel documents for Canadians stuck overseas). Without a clear set of priorities, we might make the whole system worse.

I’ve seen inside many federal government departments, agencies, and crown corporations. I’ve seen departments where the work has already been approved. The work item should take 15-20 days of working time, and it spends 75-90 days waiting for additional management decision-making. In this case, the bottleneck is the speed of decision-making and the lack of autonomy. All but the smallest decisions need to get approval from a senior manager; this is a side effect of a risk-averse culture. The manager demands more information to make each decision, so team members are pulled off their current work to find that information. The number of decisions managers are expected to make is overwhelming, so many vital decisions wait on their desks for weeks or months. If people use GenAI simply to create more quantity rather than quality, it will increase the number of decisions that managers need to make, snowballing the problem.

If decisions are waiting for months, can we responsibly use PredictiveAI to speed the process? In theory, maybe. But in practice, PredictiveAI makes decisions based on past data, and that can lead to poor predictions when the training data was incomplete, or it was biased, or future conditions don’t match the past. Even if PredictiveAI was good at making forecasts of what will happen in thousands of cases (it isn’t), that predictive value is useless at making each single decision (e.g. Should we send this specific patient home?) In these cases, it’s no better than flipping a coin.²

Finally, the focus on efficiency creates other problems. When everything is about efficiency, the focus is primarily on the cost of the work. Missing from the equation: are we doing the right job? Is the work being done well? Efficiency creates systems that are fragile, with many handoffs that are slower at delivering results.

Over years of making mistakes, I’ve learned what does work:

Define what results matter and have clear priorities. Most groups can sustain only three priorities, max, at one time. Overall priorities matter, so when there is a conflict it needs to be clear which item(s) must be finished first.
Study the flow of the system. The easiest way is to build a Kanban board and see where work gets stuck or spends time waiting. Find the bottleneck and consider how to improve throughput there.
Push decision-making down to people doing the work. Most decisions are reversible, and so are lower cost. Reversible choices can be made with less information and less authority… and, therefore, less delays.

Can GenAI help? Perhaps once we’ve found the bottleneck. Some work can be sped up with GenAI but most valuable work still requires a thoughtful person. Instead of chasing magic promises, bottlenecks are most often solved by asking people to help out with the work.

This isn’t a one-time fix. No team or organization stays the same forever, and that is particularly true in government departments. For the best chance of success, they will need to keep measuring the flow and running experiments. Only then can they find opportunities to use GenAI to legitimately improve efficiency. These principles of flow, bottleneck identification, and team-level decision-making are central to what we teach in our Certified ScrumMaster workshops.

Related Blog Entries

Image attribution: Agile Pain Relief Consulting (August 2025)

Footnotes

Working at a Distance is Hard

Mon, 22 Oct 2007 00:00:00 GMT

Working at a distance is hard. There is a reason all the Agile methodologies recommend co-location.

You miss:

A sense of presence
Hallway conversations
Rich shared environment (whiteboards, flipcharts, …)
Personal cues – you can’t tell when someone is focused or would welcome interruption.
It’s very difficult to build trust.
You don’t share the same hours

In short, don’t do it. The best anyone can offer is mitigation strategies.

Tools we use

Plane tickets – this is the most important – you can’t build trust with people you don’t know.
Instant Messaging – requirements: support for multi-user chat with History. History is important so that you can see what was said while you were away from work. We use Jabber with the Spark as our client.
Conference calls
Webex (NetMeeting, et al) – it can be slow and only person can contribute at a time. Works well for demos but poorly for collaboration. Instead we look at the same web page.
Real VNC – we’ve adopted it as our pair programming tool. It allows the remote developer to access and use the local machine at the same time as the owner. Weaknesses: needs to punched through your firewall when working from home, and your still transmitting pixels. Tight VNC also has a good reputation.

Other tools

GoogleDocs Spreadsheet – everyone can see and edit the same spreadsheet at the same time over the web.
Mind Meister - collaborative mind mapping over the web. The free edition allows you to maintain 4 mindmaps at a time.
Card Meeting (free for up to four users) - collaborative Index cards for the web. In theory this should great for retrospectives and planning meetings. In fact this never gelled for my team. The cards aren’t resizable and we found far too big for what we wanted to write. As a result we had to zoom out to see the all the cards - but then we couldn’t see the writing.
Open Meeting (free) Demo Portal: https://inno02.fh-pforzheim.de:8080/xmlcrm/
GotoMeeting, Yugma - effectively replacements for Webex. I’ve not tried them as we already have webex accounts.
Agile Planner (free) I’ve only see a short demo – but it looks like a very promising tool.
XPlanner - some teams love it and others (mine included) don’t.
Campfire (a chat room with support for history. We tried and didn’t like it because it was stuck inside a web page. As a result it didn’t get used).
PlanningPoker.com – supports planning poker (aka wide band Delphi) estimates for distributed teams. Thanks to Mike Cohn and co at Mountain Goat
TracWiki (insert your other favorite wiki)

Techniques

Post Ground Rules (for Meetings et al) at each location. Check for revisions each sprint.
Starting and ending iterations mid week:
Not just for teams working at a distance: Friday afternoons – everyone wants to be home; Monday mornings are very low energy. As a result it’s better to avoid both.
Teams spread across countries also face the problem that each country has different holidays – which for the most part fall on a Monday or Friday.
Team ambassadors who move between teams
Coach/Facilitator per meeting location – if each location has more than a few meetings then additional facilitators in each location can help the meetings run more smoothly.
During Daily Scrum even remote team members should standup – helps keep everyone focused.

These tools and techniques are just a starting point. Please help by adding to the list in the comments. You’re also welcome to suggest improvements in grouping etc.

Yahoo Bans Work from Home – an Alternative Perspective

Sat, 02 Mar 2013 00:00:00 GMT

telephone - image licensed from Photodune

In the past week, Yahoo has said that its employees must work in a Yahoo office by June. The stated goal is to bring people together to increase collaboration. In addition, comments on Quora suggest that current and former employees feel the old work from home policy was badly abused – with Fridays being known as a “no work day”.

Please appreciate that as I and others write, we have no special insight into what is happening at Yahoo. In addition, sometimes when you’re trying to change an entrenched organizational culture, it’s necessary to deliver a shock to overcome inertia.

Reaction in the press castigates Yahoo, (e.g.: “A Giant Leap Backwards”, Jason Perlow says: “Yahoo Fix Your Culture and get Better Telecommuting Tools”) saying, that remote work is the wave of the future, and knocking Yahoo for not embracing it.

From the Principles page of the Agile Manifesto: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Even though it’s already 12 years old, the statement still holds true. Electronic tools are still a long way from sharing body language and emotion that face-to-face interaction provides.

For effective Agile teams, remote work shouldn’t be the norm. Remote work increases the productivity of one team member but reduces the productivity of the whole team due to limited collaboration opportunities and increased communication costs. In addition, telecommuting disconnects people from the team. The key point: remember the goal isn’t to optimize the productivity of the individual but the productivity of the team(s).

On the face of it, asking employees to work in the office is a good thing. What’s missing is that it’s unclear whether people who are moved into offices will be integrated into team spaces that will help face-to-face conversations to happen. Or will they be jammed into productivity-draining cube farms?

Human Impact

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Another Agile Manifesto Principle.

As described in the press, there is no flexibility; starting in June all remote work will cease. For some, this will involve changing their childcare arrangements, while others apparently will have to relocate. Some of these people joined Yahoo on the understanding that they would be working from home; for these people, their job has just changed quite radically.

All of these things would be seen to be de-motivating and so weaken engagement.

Implementation

Based on the leaks to AllThingsD (“Physically Together”) this change appears to be have been handed down from the top. I suspect the reality is more complex. Rather than suggest what should have happened at Yahoo, it’s interesting to consider other ways of having made a change like this.

Taking away choices and options that people have had for a while can be demotivating. What strategies are there for engaging them in making a change?

Option #1

State the Goal: Increase collaboration and face-to-face time. Make clear the constraints; electronic tools (Skype et al) aren’t classed as face-to-face time.

Make a rule that all new hires are expected to work in a Yahoo office. Ask existing employees to commit to coming into the office 2-3 times a week, the days can be determined by each team to meet their needs.

Experiment: Run this as an experiment; after 3-4 months you ask teams to evaluate how the experiment is going. They’re expected to improve their team approach and working agreement to continue to improve on the goal.

Option #2

State the goal and constraints (as in Option #1).

With smaller organizations let the teams experiment on their own and let them decide how to meet the goal. Every six weeks engage the teams to find out what approaches are helping to improve face-to-face time. Share the information with other teams.

With a larger organization it’s not practical to let the teams self-organize to find the solution. In this case the teams should be provided with options and some degree of flexibility.

People have greater engagement when they can choose. They also gain from knowing there is flexibility; even if they never make use of it.

These options would be messier and bit a slower to implement but they would go a long way to making people feel like they’re part of team as a opposed to being simply told what to do.

Summary

If the goal was to shock the system and move it, make it clear that the status quo can’t continue and the policy will probably have the desired effect.

If the goal is an increase in productivity through co-location, I wonder if it might have the opposite effect in the short term.

Image licensed from Photodune

Agile Pain Relief | Blog

$50 Million Phoenix Fix – Avoiding Disaster With Scrum

Early and Incremental Delivery

What has your experience been with Early and Incremental Delivery?

A Rebuttal of Groupthink

Agile Bonuses - The Damage They Do

Individual Bonuses

Team Bonuses

Thank You or Spot Bonuses

Fairness

Conclusion

Research That Doesn’t Suck

Footnotes

Agile Change or Adoption Always Starts with Why

Agile Change or Adoption: Create a Vision

Case Study

Footnotes

Agile Change or Adoption: Define Small Organizational Changes

Improvement Story Templates

Case Study

Agile Change or Adoption: Sense Your Current Culture

Sense Your Current Culture

Case Study

Footnotes

Agile Change or Adoption: the Steps to Go from “Why” to “How”

Sense Your Current Culture

Create a Vision for Change

Go from Vision to Strategy

Define Small Organizational Changes

Recheck the Strategy and the Vision

Agile Change or Adoption: Turn Vision into Strategy

Case Study

Agile Games for Making Retrospectives Interesting

Games

Agile Gurus or Thought Leaders?

Agile in a Tweet

Agile Metrics

Agile Retrospectives: How to Run Effective Sprint Retros

Common Misunderstandings

It’s Not a Post-Mortem

It’s Not a Sprint Review

It Doesn’t Have to Be the Same Agenda Every Time

What is an Effective Retrospective?

What Good Does It Do

Elements of an Effective Retrospective

Don’t Blame the Player, Fix the Game

Simple Ground Rules

Well-Structured

Send me The Guide to Effective Agile Retrospectives

Who Attends a Team-Level Retrospective

Remote and Hybrid Retrospectives

Summary

Send me The Guide to Effective Agile Retrospectives

Related Blog Entries

Footnotes

Agile Tools for Job Search - An Evolving Post

Other sources

Agile Voices Finally

Agile and Scrum Smells

Nothing Ever Gets Better Around Here

1. Smells

2. Discussion

3. Causes

4. Consequences

5. Prevention

6. Example Remedies

7. Case Studies

AI Chatbots for Agile Coaches: Why They Fail

Fine Tuning, RLHF and RAG

Problems with RAG Chatbots and Agile Coaching

Evaluating Chatbots in the Context of Agile Coaching

Other Risks to be aware of with AI Chatbots

But I still want to build an AI Chatbot

Related Blog Entries

AI Code Generation and the Tennis Kata

Footnotes

AI-Generated Code Quality and the Challenges we all face

Key Findings from 5 Studies

Building the wrong thing faster with AI is not a superpower

Engineering in the Age of AI 2026 Benchmark Report1

Engineering in the Age of AI 2026 Benchmark Report¹

State of AI vs. Human Code Generation Report²

AI IDEs or Autonomous Agents? Measuring the Impact of Coding Agents on Software Development³

Complexity Debt Trap⁵

How I Built a Production App with Claude Code⁶