This week we begin Section 1of Kent Beck’s Extreme Programing Explained, Second Edition (2005), titled Exploring XP, by tackling Chapters two and three. The first two chapters in section One provide us with an overview of the conceptual framework that underpins XP.
Chapter 2: Learning to Drive. In this chapter, Beck challenges us to consider that developing a product or writing code is like driving. The metaphor of driving is used because driving is not a one-time event where you start the car and point it in the right direction then take a nap. Rather, driving is a process of constantly paying attention, gathering feedback and making a series of small changes so that you arrive at your goal healthy and whole. As noted in the preface, the core XP paradigm is “stay aware, adapt, change.” Tying the driving metaphor and XP together is the common problem of mushy requirements. In XP customers drive the content of the system and steer by getting feedback and adapting based on short iterations.
As a veteran of the quality movement of the 1990’s, XP with its “stay aware, adapt, change” empirical model is easily recognizable to me as continuous improvement model that improves effectiveness, communication, competence, and productivity.
Chapter 3: Values, Principles, and Practices. XP, a methodology, represents a very different approach to software development. In order to effectively use the practices that make up XP requires adopting a set of values that are implemented based on a set of principles. Practices are the things we do, and therefore, are clear and objective. They are done or they are not done. For example, a stand-up meeting is a practice; anyone can easily confirm whether a standup meeting is being held. In the book, Beck used the difference between a person who putters around the garden and a master gardener to illustrate the reasons why learning techniques and practices do not yield mastery. Values allow the practitioner to understand the environment, apply and evolve practices when the context demands. No framework stands as merely a set of rote practices even it might seem like just doing practices leads to a useful outcome. This why there are arguments about the ideas of “being Agile” rather than just “doing Agile.” The lure of just learning and applying practices without a framework of values and principles is not limited to software development. On my bookshelf there is a book titled, You Can’t Teach A Kid To Ride A Bike At A Seminar. The book is on sales (I believe everyone should have sales training). Like most how-to books it is full of practices and techniques, with one big difference. The book makes the point that without a set of values and principles we are just robots that don’t have the level of knowledge and understanding needed to apply those practices when the context changes. Values, principles, and principles are necessary to be a gardener, salesperson, or developer.
Values are an overarching set of rules define the boundaries of behavior. Values define what we believe in and are used to judge what we see, think, and do. Most cognitive biases are driven by the values a person or team holds. A team that values being a process more than people will act much differently than a team with the opposite set of values. Defining explicit values provide humans with purpose and direction.
Principles act as the connecting tissue between practices and values. Principles provide the context-specific guidelines for implementing practices based on the values the team holds. Beck uses the metaphor of a bridge between values and practices.
I often talk to people that begin a transformation by adopting practices before thinking about values and principles. Perhaps a small group of true believers have drunk the Koolaid and have institutionalized the values and principles that are at the core of the framework. However, that belief structure does not extend very away from that core group. This approach yields highly variable results and rarely delivers long-term change. This variability occurs whether discussing Agile, the CMMI or a new sales approach. The rationale often seems to be that by adopting practices it is clear that “change” has occurred because it easy to see actions. However because practices are situational, without the guidance of internalized values and principles it is difficult for practices to mold to situations. When practice doesn’t seem to fit, domain specific guidelines are needed or they will be abandoned.
Previous installment of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday: