How to Give a Great Sprint Demo

Exciting. Entertaining. Do these words describe your sprint review meetings? Or are boring and unfocused more accurate? Here are tips and best practices for a reliably good sprint review (demo). Read More

The Magic of 1-Day Sprints

How long should your sprints be? Generally, 1-2 weeks, with a preference towards a shorter sprint. But that’s not what I’m writing about today. I want to introduce you to the magic of 1-day sprints. Read More

Change Happens—So Make it Cheaper

Change on software projects is expensive; it leads to wasteful rework. Change is risk. We can deal with risk one of two ways. We can reduce the likelihood of the negative event occurring. Or we can reduce the impact of the negative event when it does occur. (Of course, the two can often be combined.) The traditional approach says, "Let's put more effort and thought in up-front and avoid that expensive change." (That is, let's prevent the negative event from occurring.) The problem, as decades of experience have shown, is we still can't seem to avoid change. Here's why: the kinds of change that plague software development can't be eliminated by thinking harder up front. Read More

Functional Managers in Agile

As an organization transforms to an agile way of working, functional managers (e.g. a dev manager or a test manager) can feel lost. Many of their traditional responsibilities move to other roles or disappear altogether. How can functional managers continue to add value in an agile organization? Here are a few ideas… Read More

Building a Useful Task Board

The task board is a simple, yet powerful, tool for Scrum teams. As a coach, I can tell a lot about a team just by looking at their task board in the middle of a sprint. If your Scrum team is in the same location, I can't think of a good reason why you wouldn't want to build and use a task board. Here's how to build a basic task board, various ways to enhance it to convey more information, and some analysis of the many things you can learn from this simple tool. Read More

Why Longer Sprints Probably Won’t Help

As a coach, I'm frequently told, "Our sprint length is too short. We want to change it from X to Y weeks." The time box—the sprint in Scrum, the iteration in XP and other iterative methods—is one of the most powerful tools in agile software development for revealing problems in a team or organization. Notice I said reveal, not fix. I've seen a few cases where the sprint length really was too short. More often, though, the feeling that the sprint is too short is a sign of deeper problems. Lengthening the sprint might push these problems back under the surface, but it's unlikely to actually solve them. Before you increase your sprint length, ask "Why?" a few times to see if you have any of the following underlying issues, and try to deal with those first. Maybe your sprint really is too short. But don't start there, lest you miss an opportunity to improve. Read More

Growing DONE—How to Make the Definition of Done Work for Your Team

Effective agile teams get things done. They build software day after day that's not just "code complete" but really shippable. And when their product owner says, "ship it," they can get their shippable software into production at the drop of a hat. The Definition of Done can be a powerful tool to make these things happen...If it's used right. Most agile teams I see have one of four relationships with a Definition of Done: They don't have one They have one but don't really use it They have one but can never satisfy it They have one, satisfy it for each story, but still have lots to do at the end of a release I rarely come across teams who use the Definition of Done to good effect day after day, sprint after sprint. Find out why and how to fix it »