Second Generation Agile Software Development
The agile software development community is at a crossroads. On one hand, we have been told to use some very simple techniques to create customer value quickly and they have worked! Interact with your customer, use the simplest thing that might possibly work, deliver value. This is all good. The processes that we have used to come to this point have names like SCRUM and XP (version 1). These processes are terrific.
However, if you have been to one of agile conferences recently (or even one of the major software development conferences), you are aware that there is an ever growing array of techniques available to agile developers to incorporate things that were missing from these agile processes such as the use of testers to test. The agile community has not stood still; it is evolving.
In fact, if you read Kent's latest XP Explained book (the green and white book), you get a slightly different view of XP than you do if you read his earlier white book. In the chapter called "The Whole XP Team" (chapter 10), he talks about the role of the Tester, Interaction Designer, and Architect among others (don't just read the first section of the chapter unless you want to get the wrong idea of what he is trying to say). Whoa! What kind of agile blasphemy is this?
The truth is, the agile community has been moving toward perhaps a more centrist (pardon the pun) position for years. Those who are involved in the community are acutely aware that architecture is required especially for larger projects. Not Big Design Up Front (BDUF) architecture but shadow architecture, one that leads and trails the actual inner workings of the project code. The fact that each role often worked as disconnected units had to be broken. For this, we needed to go to the extremes. Kent calls the early versions of XP etudes or lessons (hard lessons) in building functional teams.
The "new" XP is a second generation agile software development process. So is our own MSF for Agile Software Development (a lot of the patterns within it are based on XP). Both processes have techniques for allowing testers to test the software and architects to help with large scale refactorings. Both are directly driven by customers (more on this in a future blog) and this is a critical success factor. They both are also a little more complex than the first generation processes.
The number of people using first generation agile processes is increasing. It is also true that many companies are using a "Chinese menu" (to quote Uncle Bob Martin) approach to creating their own second generation agile processes. Some would argue about the "agileness" of these processes. The truth is, it is all about delivery. If you deliver as rapidly as possible, don't let anyone tell you to stop. It is when things are breaking down or your competition is outrunning you that you have problems.
It isn't surprising to me that many have grown comfortable with the first generation agile processes. If these work for you, continue. What is surprising is the number of people who are advocating these processes that think that a greater number of roles cannot participate and maintain the agility. The agile world is changing. Embrace change.