New Teams Can Avoid Common Errors by Understanding Cost of Delay

In an earlier post, I discussed how attending to the cost of delay helps us focus on removing delays in workflow, feedback, communication, and error detection. This involves a focus on finishing (not starting a new story if you can help somebody else with an existing story), working on small stories, and using test-first methods.


Note: This is a continuation of the post, Using Cost of Delay to Improve Scrum

Teams new to Scrum face many common challenges.

  • Not finishing stories at the end of a sprint because too many have been opened
  • Too many untested stories at the end of a sprint
  • Doing an analysis sprint, design sprint, coding sprint, testing sprint (“Scrumerfall”)
  • Separation of coding and testing responsibilities
  • After the demo, realizing there were misunderstood requirements

In an earlier post, I discussed how attending to the cost of delay helps us focus on removing delays in workflow, feedback, communication, and error detection. This involves a focus on finishing (not starting a new story if you can help somebody else with an existing story), working on small stories, and using test-first methods.

Review that list of challenges. Each of these challenges show up as impediments at the end of a sprint. Each can be avoided, or at least mitigated, by following the guidance of removing delays by focusing on lowering the cost of delay.

No longer will you be removing impediments after they’ve been discovered. Now, you will remove them before you even hit them!

The Future of Agile

Here are some of the things Agile has demonstrated to be of value.

  • Having self-organizing small teams
  • Building incrementally
  • Taking an iterative approach

However, an organization is not merely a collection of small teams, it must also do the following:

  • Have a vision to guide what is built
  • Have collaboration across teams

All this means we need an ecosystem that illuminates the vision and allows teams to self-organize to achieve it. Continue reading “The Future of Agile”

The Third Leg of Emergent Design: Acceptance Test-Driven Development (ATDD)

In previous posts, I discussed that the first leg of emergent design is TDD, which provides code quality and sustainability. The second leg is design patterns, which provides insights into handling variation. The third leg is ATDD, which provides us a way of discovering and clarifying the value we will get. Continue reading “The Third Leg of Emergent Design: Acceptance Test-Driven Development (ATDD)”

Design Patterns: The Second Leg of Emergent Design

TDD is the first leg of emergent design or what could be called Agile Design. Design patterns are the second. They’re often described as “solutions to recurring problems in a context.” In this way they can be thought of as recipes that have been learned. But patterns open the door to much more; they are examples of ways to think. Patterns hide varying behavior, structure or which objects to use. Continue reading “Design Patterns: The Second Leg of Emergent Design”

Test-Driven Development (TDD): The First Leg of Emergent Design

I am heartened by the surge in TDD training. To me, TDD is the second most important thing for devs to learn. ATDD is the first.

TDD is not just the automation of unit testing. It’s also intended to improve design and sustainability.

TDD’s formulation of tests, prior to code, drives design. High quality code is easy to test. The reverse is also true. Code that is easy to test is higher quality than code that isn’t. I labeled this quality, “testability,” in my book Design Patterns Explained. Test-First is a process where deciding on your tests before writing your code improves your design. Continue reading “Test-Driven Development (TDD): The First Leg of Emergent Design”

An Open Letter to Participants When We Go In To Train

Among the things needed in the Agile space are better training methods and a better way to use frameworks. This pertains to all organizations coming to Agile:  They are rightfully concerned about what the kind of Agile training they’ll get. They want improvements, not frameworks. At best, frameworks are a means to an end.

Recently, I wrote to such an organization with these concerns. It had a proposal for a small-scale adoption of Lean-Agile involving 3-10 teams with associated Product Owners. Continue reading “An Open Letter to Participants When We Go In To Train”

Seeing Challenges in the Value Stream

In the same way that looking at the value stream helps you observe how value moves, looking at the value stream helps you discover challenges you are facing. Here are some of the most common challenges.

  • It takes too long to get anything done
  • Work is not properly prioritized
  • Chunks of work are too big
  • Too many things are in work
  • There are unclear requirements
  • Teams don’t understand the needs of the business
  • Some people have too much to do and are constraints on multiple teams
  • There is high technical debt
  • There are many integration errors
  • There is insufficient collaboration
  • Ops is blindsided and pulled in many directions
  • There is a lack of visibility of what is taking place

Often, these challenges are apparent when work is stuck in large queues just before the step where the problem is. Lean suggests that instead of focusing on how people can work faster, you should take steps to keep queue size down. Usually, this involves working on small batches, how you do work, and how you organize talent.

Why Agile Coaches Need to Know Both Scrum and Kanban



Scrum and Kanban are the two most popular Agile team-level methods available. While the difference between them is mostly thought to be sprint-based or flow-based, that is just one way in which they differ. Other significant differences include how to start, how to improve, and how people should be organized. They are based on different theories of how to manage software development work and whether you need to change your roles. And this creates other differences such include the amount of discipline to use them and the cultures in which they fit. Continue reading “Why Agile Coaches Need to Know Both Scrum and Kanban”

The Common Aspects of Almost-Instant Agile Success

We hear so much about how adopting Agile is hard. It is worth looking at the exceptions in order to learn why it doesn’t have to be that way.

Let’s consider the case of a dev group of 75-300 people. This is a good example of a common situation. The organization was looking at improvements, focusing on product management, and organizing how people work together. Specifically, here was what they paid attention to. Continue reading “The Common Aspects of Almost-Instant Agile Success”