Kent Beck is behind much of what is associated with agile software development, including the JUnit testing framework and Extreme Programming. Kent was also one of the initial driving forces behind the use of design patterns in object-oriented programming. Kurt Christensen of InfoQ recently had the opportunity to ask Kent some questions about the current state and future direction of agile software development.
InfoQ: What are you currently working on?
Kent Beck (KB): I have just finished a book called Implementation Patterns about how to communicate through code. It will be out in the first quarter of 2007. I am working on new releases of JUnit. And I spend much of my time on remote pair programming with paying clients, working on a variety of projects.
InfoQ: Sometimes when working with an agile team, the transparency of the process will expose problems within the organization which are then blamed on the agile process. Are we beginning to see something like this on an industry-wide scale? Is agile increasing visibility of weaknesses in our industry in such a way as to create something of a backlash against agile in general?
KB: Most of the backlash I have seen is from individual programmers who don't want to be accountable to other members of their organization, rather than from organizations or the industry as a whole. I think that the backlash against the industry is to the vague use of the term agile rather than to any particular process.
Customers don't seem to mind fewer defects and more predictable schedules and programmers who are willing to have conversations and follow through with their commitments. The problems come when customers start to expect those things and programmers don't want to provide them. Calling yourselves agile without a commitment to the values and principles of agile development can lead to some uncomfortable relationships.
InfoQ: I'm concerned that - as a community - when agile works, we all pat ourselves on the back, but that when agile doesn't work we simply punt and say that it wasn't done "right." If agile is more about values than specific, prescriptive practices, then how is an organization supposed to know when they're really doing agile? What does it mean to do agile correctly?
KB: The response you are describing ignores the opportunity for learning from experience when you are uncomfortable with outcomes. I think that we are missing many opportunities to share and learn because we are embarrassed.
Somehow we think, "If I was a perfect programmer, the project would have been a roaring success." If the project isn't a runaway success, I must be a failure. In this mindset running and hiding becomes a reasonable response.
And yes, people in the agile community jump on you as a failure when you admit that things went wrong. This fear reaction keeps us from a lot of useful learning.
There are many factors and some synergy required for a successful project that cannot happen by the technical skill or willpower of a single individual regardless of how smart or heroic that individual is. However there are lessons to learn about communication, team-building, timing, working with other areas of your company and even coding tricks that can be learned from failed projects and applied to future ones. If we were willing to share our learning (rather than our sense of failure) we, as a community, could be much more responsive.
The vagueness of the term agile can be a deterrent. Asking "Are we doing it right?" (or the more likely scenario - telling someone else "You're not doing it right!") is not a very valuable question. "Are we learning all we can?" and "What do we need to change to most benefit our company's goals?" have a lot more impact. If agility is a mindset, then measures of correctness don't really apply. Are you working with an agile mindset? Are you trying to see from more than one perspective? Are you thinking outside the cubicle? Are you communicating with a team working together towards a valued goal? Are you working transparently, honestly, accountably toward your shared goals? What an agile expert would think of the process is far less important than how your process is working for your organization.
InfoQ: In your experience helping organizations grow towards agility, are there recognizable patterns for problems? How do organizations commonly fail to do agile correctly?
KB: Common patterns we have seen are a lack of communication, isolationism both of the team and individuals, silence in the workroom, a person with specialized knowledge the team needs who no one wants to work with, or an inability to articulate the value to the company of their immediate work.
Failure at an organizational level seems to come from the inability to customize processes and make them their own. Trying to apply someone else's template to your organization directly doesn't work well. It leaves out too many important details of the previous successes and ignores your company's specific situation. Rubber-stamping agile processes is not agile. The value of having a principle-based process is that you can apply the principles for an individualized process for your situation and, as an extra bonus, one that has been designed to adapt from your learning as you adopt changes into your organization. It is always "custom."
The biggest problem I see from an individual perspective is that programmers aren't comfortable in their own skins. I talked about this in a piece called "Ease at Work" which is available through Google Video. Until programmers are able to maintain a realistic self-image, the search for the next technical fix will fail to bear fruit in the long term. I'm sure there are big organizational issues too, but change starts at home.
InfoQ: When introducing agility into an organization, do you first introduce practices and then use this as a vehicle to discuss values, or vice versa? Or are the two inseparable, even from the beginning? What are the ways in which you go about trying to change the value system of an organization?
KB: I start with positive experiences people have had already (a style called Appreciative Inquiry) and see how they apply to the current situation. This leads to discussions at all three levels--values, principles, and practices.
To change the value system of an organization requires powerful support, usually from someone high in the organization who wants change. My tendency is to try to manipulate organizations into change, but that doesn't work well. Instead, it works best when I first show my respect for the people I'm working with by doing a good job working in their style. In doing so I can still live my values, principles, and practices. Over time, we learn from each other.
InfoQ: The Scrum community is creating something of a brand name by way of their certification process. Do you see this as a helpful way of making agile more palatable for large organizations? What are the pros and cons of taking agile down this path?KB: I think it makes sense for practitioners to be accountable for their own skills and results. I don't think traditional certification processes - take a test, get a piece of paper - do this. On the other hand, other professions have meaningful certifications. If you are a board certified physician, it means something. The process is very different from the certifications in computing, though. It takes a long time, it's expensive, the examiners are experts, it requires a significant amount of study and a demonstration of the precise use of your knowledge in real situations.
Name recognition can get you in the door, especially at large organizations, but it still has all the problems of cookie-cutter application. If it is seen as accepted practice it will be easier to begin, but once in the door significant adaptation is necessary or credibility will be lost and the value of the name will disappear.
InfoQ: Martin Fowler recently wrote a piece titled "Semantic Diffusion," in which he describes the trajectory for "agile" as a descriptive word. What happens to agile when "agile" becomes just another buzzword? Is there a way to prevent this, to keep the ideas and the language fresh?
KB: When agile becomes a buzzword, then people look for simplistic measures to judge agility. The problem of the metaphor of diffusion is that the idea that meaning decreases over time ignores the specific and successful uses of the term that are occurring in order to maintain the metaphor. I have always been concerned that the term "agile" is such a generically attractive word, it would be used by people who had no intention of accepting the substance of the ideas. Who wouldn't want to be agile? Words are easy; ideas that have value usually have responsibilities attached. That's why we talk about "Responsible Development". The idea of responsibility in English has the connotation of attached burdens, requirements, or obligations. It is not quite so free and easy, but it means more.
When you put ideas out there, you can't control what people do with them. What I do with my ideas is do my best to live them and to report honestly how that is going to my community.
InfoQ: In the time since you've written the second edition of Extreme Programming Explained, have you identified any new values, principles, or practices that you would include were you to write a third edition?
KB: I have not identified any new values for XP. But I have been relying on some other principles for decision-making in my work.
I've begun referring to several principles that aren't listed in the second edition, especially accountability and transparency. I talk about the twin principles of specifying later and testing sooner that come together in test-driven development. Finally, I find the principle of reducing in-process inventory very helpful.
As far as practices go, the most important one I've been using lately is tracking and analyzing the actual usage of software. I am working on a project right now where we implemented usage tracking and it is like turning on the lights in a dark room to see which features users actually use.
About the author
Kurt Christensen has been building software for twelve years. He's worked as a coach, trainer and computer programmer on a variety of different projects, with big and small teams at big and small companies. Kurt currently lives in St. Paul, Minnesota with his wife and two children.