Agile Software Development

In the last decade agile methods have moved from being a cult technique to an increasing part of the mainstream. I was lucky enough to be at the beginning of this story, with early experiences on the ‘birth project’ of Extreme Programming and a co-author of the Manifesto for Agile Software Development. ThoughtWorks started using agile methods in 2000 and have highlighted them on their projects world-wide. We’ve learned a huge amount about using agile methods in enterprise settings and are committed to sharing this learning to help foster their intelligent adoption.

The New Methodology

My introductory article on agile methods, focusing on the two key criteria that sets them apart from the traditional view of software process: adaptive planning and a people-centered approach. The original version of this article appeared in 2000 where it influenced the growing interest in agile methods, this updated version is still my favorite introduction.

Is Design Dead?

When Extreme Programming first appeared, many people thought it called for the death of software design. Still today, a common misconception of agile methods is that they eliminate design. Yet from the beginning the advocates of Extreme Programming were people who cared deeply about well-designed software. In this essay I explore what happens to design in the world of agile methods and Extreme Programming, concluding that design is still present, but looks rather different.

It’s Not Just Standing Up

Jason Yip’s definitive guide to running stand-up meetings.

Agile and Offshore

When we were looking into opening an office in India in 2002, people doubted that agile methods could be used in an offshore development project. I spent time talking to ThoughtWorkers in India and the US to determine how we did it.

Evolutionary Database Design

In the early days, databases were seen as something that was not amenable to the evolutionary design process that comes with agile thinking. My colleague Pramod Sadalage and I describe how he overcame this problem.

Continuous Integration

CI is a key practice in agile methods. Many people say they do it, but violate the most important rule: “everyone commits to the mainline every day”. Here’s more on this and the other key practices of CI.

An Appropriate Use of Metrics

As with any style of process, agile software development has bred lots of interest in metrics. The thinking goes something like this, “We need a number to measure how we’re doing. Numbers focus people and help us measure success.” Whilst well intentioned, management by numbers unintuitively leads to problematic behavior and ultimately detracts from broader project and organizational goals. Metrics inherently aren’t a bad thing; just often, inappropriately used. Pat Kua, author of The Retrospective Handbook, demonstrates these issues and offers an alternative approach that uses metrics well.

Planning Extreme Programming

After Kent wrote the initial "white book" on Extreme Programming, he collaborated with me on writing a book concentrating on the planning process in Extreme Programming. While other agile planning books have appeared since, I still like this book for its brief coverage of the essence of planning in XP.


Agile has been a big topic for me on this site. This page shows many highlights, but there’s more to explore, with many entries on the bliki, and other articles to mention. To explore agile topics the best way is to use the tagging system. Good tags to start with are: agile, agile adoption, agile history, continuous integration, evolutionary design, extreme programming, and process theory

The photo at the top of this page (and most agile-oriented pages) comes from the very first agile conference.

Manifesto of Agile Software Development

It may not have started it all, but the manifesto gave the movement a name together with a dollop of initial energy. A decade later it still captures the essence of what agile methods are about.

Agile Fluency

Adopting agile software development is neither a quick nor easy path. Diana Larsen and James Shore (experienced agile coaches) have come up with a way to think about how teams progress through stages of fluency in agile thinking. The path begins by focusing on value and then progresses to delivering and optimizing that value. Diana and James outline the benefits of each stage and the what investments you need to make to get there.


Agile methods are founded upon making change easy, this means that you need to have a code base that's amenable to change and the discipline to make changes safely. Refactoring is the foundational technique to change and improve the design of an existing code base. While my book on refactoring was written a decade ago, the techniques it teaches are just the same today.