It's summer and I've been thinking about sailing. I didn't get to do any this summer, but I can still think about it. Thinking about sailing reminded me of the 1995 America's Cup race between the US and New Zealand. That race is a great illustration of the importance of both getting close to our customers and of rapid feedback.

To design their boat, Team New Zealand made…

Continue Reading

One element of agile project management that is difficult for teams to master is how to overlap their work. If a team doesn’t learn effective ways to do this, team members may settle on a less desirable approach: activity-specific sprints. An activity-specific sprint is as bad a practice as it would be an acronym. In this approach, the team decides to use one sprint for…

Continue Reading

Even before the ascendancy of agile methodologies like Scrum, we knew we should automate our tests. But we didn’t. Automated tests were considered expensive to write and were often written months, or in some cases years, after a feature had been programmed. One reason teams found it difficult to write tests sooner was because they were automating at the wrong level. An…

Continue Reading

Agile project management approaches favor an incremental, just-in-time approach to design. As such, Scrum projects do not have an upfront analysis or design phase; all work occurs within the repeated cycle of sprints. This does not mean, however, that design on a Scrum project is not intentional. An intentional design process is one in which the design is guided through…

Continue Reading

As you may now, I am working on a new book, which will be called Succeeding with Agile. I recently finished writing a chapter for it on the impact of the human resources and facilities groups on an organization that is transitioning to an Agile project management approach. While writing that chapter, I put together a list of all the things that I think should be visible within…

Continue Reading

This week I want to address the question of whether a team should work on one product backlog item at a time or whether it's OK to work on multiple items. In general, a team should feel comfortable working on multiple product backlog items at the same time during an iteration. A typical seven person team will plan between five and ten items into an iteration. They'll usually…

Continue Reading

A question I get frequently is what to do with tasks that do not belong to a particular user story or product backlog item. Common examples I’m asked about include tasks like “update the build server to use the latest version of FitNesse.” Fixing bugs from prior iterations are another common example. I’ve sometimes heard of these tasks that don't belong to a particular…

Continue Reading

In the discussion that ensued from another post here, Brian Bailey asked a great set of questions. The questions were big enough that I've moved them here. I'm going to intersperse Brian's questions and comments with my responses. Brian started with:

If the product owner is onsite and part of the same company, what role should she have in prioritizing tasks within a sprint?…

Continue Reading

A common misperception is that testers cannot do any work during an iteration until the programmers finish a user story or product backlog item. However, the unit of transfer between programmer and tester can be smaller than the user story. Let’s see how this could work through an example: Suppose a tester and I are working on the story about auto-incrementing the next check…

Continue Reading

With no land in sight to guide them, it would have been all too easy for early sailors to get lost in a seemingly endless sea. All too often, software projects also lose sight of when and if they'll reach their destination. This article explores what ancient mariners knew about navigation that we can apply to charting software project progress.

Continue Reading