Rapid Feedback and the America’s Cup

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…

How To Fail With Agile

Not everyone involved in an agile transition wants the change to be successful. This tongue-in-cheek article details twenty things you can do to sabotage an agile transition. Of course, the twenty things also serve as reminders of things to avoid or watch out for.

The Chivalrous Team Member

In seeking to improve how we develop software, we continually inspect and adapt. While thinking recently about the characteristics of the ideal team member, we found similarities between the best-performing soft- ware teams of today and the Knights of the Round Table. This article considers the Code of Chivalry as applied to team members.

Writing Contracts for Agile Development

User stories are a great way to get people talking about requirements. However, there's a reason why we invented the written word: to make sure that nothing we've said is forgotten or misunderstood. This article explains why contracts are a good way to capture not only the user stories themselves but also to spell out what constitutes the successful implementation of each story.

The Certainty of Uncertainty

If the only certain things in life are death and taxes, why do so many teams think that if they plan well enough they're somehow going to add software to that short list? This article deals with the mistakes team make when they try to account for every potential need and how best to plan for those things that users don't even know they want (or don't want).

Incorporating Learning and Expected Cost of Change

An experience report presented at XP2006 covering why it is not as simple as telling product owners to "prioritize on business value." This experience report presents additional factors to consider when prioritizing.

I Didn’t Know I Needed That!

Products that do everything they're supposed to do and offer consumers something they like, but didn't know they wanted, make customers happy. And that is what most of us in software development ultimately need to accomplish. But how do you separate the must-haves from the bells and whistles? And how do you make sure you're including the right bells and whistles? This article gives you clear advice on how to determine which features to include in order to meet and exceed your end users' expectations.

Distance Remaining Is More Important than Distance Covered

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.

Stop Listening to Your Users

Users are often kept at arm's length. We ask them for their input on the design, but then we, as the experts, take it from there. This article asks you to bring users into the design process as participants rather than simply as founts of information. You might be surprised at where it takes you.

Introducing An Agile Process to an Organization

The transition from a plan-driven to an agile process affects not only the development team members, but also other teams, departments, and management. In this article we describe common pitfalls and effective approaches to making this change.