As Agile becomes better known, many troubled teams are deciding to adopt Agile practices to help fix their problems. Most clients seeking our help in Agile adoption first pursue process and tools. The more dysfunctional their teams, the less tolerance they have for focusing on individuals and their interactions.

We have found that the most effective teams– those that show a tremendous improvement in productivity and value to their organizations – have individual team members who take ownership, act responsibly, and are disciplined in recognizing and responding to change at a personal level. These individuals adopt Agile practices because they have made a conscious decision to do so.

Within the software development community, one of the biggest movements over the past decade has been Agile Development whereby teams adopt practices and attitudes consistent with the now famous Agile Manifesto. Additionally, there has been much discussion over the past four to five years about applying principles from the Theory of Constraints (ToC) and Lean Product Development (Lean) to software development. This has had a tendency to muddy the surrounding waters as teams question whether they should apply Agile, ToC, or Lean concepts. Are these three approaches mutually exclusive? Is there some hidden magic that can be unlocked by careful application of all three? Isn't it hard enough just trying to be Agile, without also trying to be Lean and ToC-ish? In this article we give an overview of Lean and ToC and show how they can be used in conjunction with Agile practices to focus on an organization's business value. By using elements of Lean, ToC, and Agile together more business value can be delivered with less effort.

This is an article that John Mufarrige and I wrote about our experience with the BabyCenter development team as they are building a new system and adopting agile development practices to do so. The InfoQ article describes a business-focused approach to choosing the agile practices to adopt can deliver more value than a full methodology adoption.

As more and more people move towards adoption of Agile practices, they are looking to the Agile community for guidance and advice on how to adopt Agile successfully. Unfortunately many of the questions they have such as "Where do I start?" "What specific practices should I adopt?" "How can I adopt incrementally?" and "Where can I expect pitfalls?" are not adequately answered despite the fact that many of us know the answers to these questions. There are currently three types of answers to these questions: 1) read so-and-so's methodology book that refers to an entire process (usually a cohesive set of practices); 2) read articles A, B, and C which are ‘war stories' of companies who have successfully adopted; or 3) a very honest "Well it really depends on your team's specific circumstances, you might want to hire some consultants to help you out (usually this is said by a consultant)." We can do better than that as a community!

A healthy agile project has several typical rhythms such as releases, iterations, stand-up meetings, builds kicked off by continuous integration, and the red-green-red test cycle of a developer. These rhythms have healthy ranges (such as a stand up meeting lasting less than 15 minutes) and characteristics (such as that same stand up meeting not containing design discussions). When they fall out of these ranges or do not display the appropriate characteristics, they indicate that something is wrong with the agile process. As a doctor takes a patient's pulse or blood pressure reading to determine if the patient is ill, we take readings of our rhythms to let us know if something is wrong with our agile process. The rhythms, when off, sometimes need to be addressed directly, and in other cases point us towards areas of the process where we need to dig more deeply to find and correct the root cause of the problem.

Large software development projects are not agile by nature. Large projects are not easy to implement, they are even harder to implement using an agile methodology. Based on over 6 years of experience building software systems using agile methodologies we found that we can modify agile methodologies to be successfully applied to large projects. In this paper, we will introduce a development practice, which we call Divide After You Conquer to reduce some of the challenges during the development of large agile projects. By solving the base problem first with a smaller development team (Conquer p

This paper I co-wrote with my colleague Greg Schalliol - who is one of the best business analysts I have ever worked with (and also has a PhD in philosophy I believe.) We try here to give a 'lessons learned' paper to advise others who are just starting out with XP. It is probably the most cited of my papers so far and has been used to attack XP - I guess I should always try to put in BOLD LETTERS that XP WORKS!!! We were merely giving a word to the wise about what possible mistakes can be made.

This is my first paper on the topic of Agile Development that was published. It is a simple experience report about applying XP on a large project at ThoughtWorks. At ThoughtWorks we (well it is 'they' now since I am no longer a member) have been at the forefront of agile development and were one of the first companies to expand XP to a significant project. At the time of writing this paper we had been practicing XP for almost a year and had molded the XP practices to support a large 80 man development team.

Another 'lessons learned' paper - about XP and the database and the relationship between developers and dba's. Ahmed Hassan was a dba on this project and I had become the tech lead by this time (same 80 man project). This caused quite a bit of internal strife about perceptions of how well (or not well) our development team and dba team were working together in an agile fashion. I can't help it - I just love to take things apart and find their faults - to make them better. Unfortunately my criticism is not always seen as constructive. Sigh....

Originally accepted at XP2003 - but then dropped because neither me nor any of my co-authors could make it to the conference. This has been a near-and-dear idea to me over the past 4 years with XP. The idea is simply that YAGNI is great - and works most of the time - but hey! Many of us are experienced developers and when we've come across something we've solved a few times before we should leverage that experience and not put on blinders. I've had numerous heated discussions on the extremeProgramming Yahoo group with other developers and the idea still seems solid. Here my colleagues and I ta