XP Explained

This week we continue with the building blocks of Extreme Programming by tackling chapters four and five in Kent Beck’s Extreme Programing Explained, Second Edition (2005). Chapters four and five provide a deep dive into values and principles.  Why, when we talk about frameworks or methodologies, do we spend so much time on values and principles?  Simply put, values and principles provide a rationale for the practices that are the nuts and bolts of a methodology. Without an understanding of why we do something, it will be difficult to hold on to a practice or to understand when and why to tweak a practice when things get tough. (more…)

XP Explained

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.  (more…)

Don't get caught up in these process mistakes.

Don’t get caught up in these process mistakes.

Almost all human endeavors use a process architecture.  Some of those architectures might not be immediately apparent, such as the scrum that often occurs at the beginning of a foot race or software development in a two-person start-up.  Others, such as the product development in the medical device fields, are far more regimented.  A mantra that many leaders in the software field utter is: “that we should only define just enough process.” It is easy to cobble together a process architecture that leads to common problems.  It isn’t that anyone goes out of their way to make a mess out of process architecture, but it happens far more often than anyone would like.  Common process architecture faux pas include: (more…)

20130501-224521.jpg
If you have ever visited a major tourist site you have seen tour guides shepherding groups of camera-touting tourists. It is easy to see the tour guide role as that of a leader. A typical tour guide plans the logistics of the tour, herds the tour group ensuring everyone is moving in the same direction and implements the vision of the tour planner to deliver value. The goal of our tour guide is to make sure the team begins and ends together, that no one gets lost and the goal of the tour is accomplished. The role provides administrative and tactical leadership to the tour group. But, the tour guide is not playing the role of the product owner. In Agile projects the product owner provides visionary leadership. Tactical leadership and administration, the tour guide role, is generally defused across the entire team.

The arrangement of roles is facilitated by the application by two Agile Principles. The first is the principle that directs the business and IT personnel to work together on daily basis. The second principle in play here is that of self-organizing teams. For example, one mechanism that spreads the role of tour guide across the team is the backlog prioritized by the product owner. The backlog respects the vision in bite-sized chunks that the team can then plan and execute. Another example of tactical leadership that the team drives is the standup meeting, in which the whole team acts as cat herders. So, on an Agile project, who is the tour guide that herds the team toward the product owners vision ? The answer is that role is spread across the team and that Agile techniques facilitate making sure that we start and end in the correct place.