Confessions of an Agile Purist

It's sunny down in Texas today and the late, great Stevie Ray Vaughan is cranking from my Mac's tiny speakers. It all seems appropriate somehow, Texas blues and the recent accusation that I am an "Agile Purist." My initial thought was that that label was somehow derogatory, a slap in the face, a put-down. A few sweet licks from SRV's guitar has helped me see the light, however. Now I'm ready to embrace the Agile Purist tag rather than trying to wash it off.

So here's the deal, I train and coach Agile teams and have been extremely successful at both of these related endeavors. My philosophy is a simple one: present the rules of the product development game, primarily Scrum, but drawing also on the best that XP has to offer, with a little Lean thrown in for leavening, so that my trainees both know the rules of the game and have the beginnings of a sense of how to take the field and begin to play. Experienced Agilists know all too well that the framework is very simple and lightweight, but that does not make it easy to put into practice. Indeed, simple most certainly does not equate to easy in this context. So my guiding principle is to make sure that everyone in my training classes emerges knowing what to do when they hit the ground, whether with me there to coach them or not.

When I'm coaching, I follow the same principle. Everyone knows exactly what to do -- or at least what to expect -- every single day that I'm on the ground with a client, whether it's an ordinary day with a daily Scrum, a Sprint planning day, or a Review/Demo and Retrospective day. What happens, specifically, during each day is highly variable and hence where the difficulty lies in putting this simple framework into practice. Starting with that Agile Purist approach, which in reality means making sure that everyone knows what to do/expect coming into each day on the job, has served my clients very, very well indeed.

What this means is that I train and coach client teams to play by the rules so that they have confidence in what they are doing and in their individual and collective ability to do it from day one. I want them to learn good habits so that when the unexpected happens -- or when the entirely predictable challenges arise -- they are in the best possible position to make adjustments and continue moving forward with their Agile practice.

Aside from the purely practical, experiential basis for following the rules of the game, there is this one other thing that informs my work as a trainer and coach: I actually believe in the value of the core Agile principles captured in the Agile Manifesto. I believe that putting those principles into practice -- playing by the rules -- has a proven record of success, not just in getting the right product to market, at the right time, and for the right price, but that those principles translated into practices create a healthy, productive, and adaptive work environment that none of the prepackaged methodologies can ever hope to touch.

My devotion to Agile principles and practices, those rules of the game, is therefore not based on a pedantic need to follow some arbitrary formula. Once a team I am coaching learns how to play at a basic level, which typically happens very quickly, I help them learn how to adapt their practices as needed, all the while keeping the principles in the forefront of everyone's mind. We're just not going to start there, on the highly adaptive end of the time line.

So yes, I admit it: I am an Agile Purist.

All for now....

...-.-

Is it a Group or a Team?

This question often occurs to me when I'm on training or coaching assignments. The provocation is usually a statement similar to the following: "We have a development team of 250 highly skilled engineers...." or "Our QA team just can't seem to keep up with development...." or "The business analysis team writes all of our requirements...." or "Our middleware team serves multiple simultaneous projects."

It is common usage to apply the term "team" to mean any collection of individuals who perform some related function, regardless of how those individuals actually work. To me, a team is a very specific type of human organizational unit, defined by how it works, rather than by what it works on. Simply put, teams are distinguished by teamwork. I have even, very occasionally, encountered fair approximations of cross-functional Scrum "teams" that fail to meet this most basic definition.

Teamwork describes a particular way of working toward a shared goal. I have distilled the essential characteristics of teamwork into the following (incomplete) list:

• sublimation of individual ego and need for recognition to the needs of the team
  
• sharing and balancing workload dynamically at daily or finer granularity
  
• individuals offering and requesting help in an environment of trust
• willingness to make personal sacrifices in support of the team
• recognition that the team's goal outweighs (but does not exclude) individual goals
  

I'm certain there are many more traits that one could apply to describe teamwork, but this works for me as a starting point for the discussion. The key distinction I see between a team and a group is the collaborative effort a team engages in to meet its collective goal, for example, a Sprint commitment. A group, on the other hand, may indeed consist of skilled, well-intentioned individuals, but without a collaborative framework and a collective goal, teamwork is absent. The common example is the group of developers, each individually working on their assigned tasks, head down, blinders on, either unable or unwilling to share the load with their fellow group members. Sure, they're all working toward the same end point, but on parallel tracks that by their very nature cannot converge. Group work results in the standard array of dysfunctions and failures that characterize traditional software projects.

Implied in my list of teamwork traits is a self-organizing, empowered team that has the authority to set its own commitments and determine how best to meet those commitments. Another implication is that a team is small. The standard Scrum guideline for team size (seven plus/minus two) has always worked brilliantly in my coaching experience.

So the next time you hear a client or colleague talking about a "team," make sure you know what they really mean: Is it a Team or a Group?

All for now....

...-.-

The Law of Unintended Consequences

This is big topic, but today I want to talk about just one small aspect: the unintended consequence of command-and-control work environments. There is a persistent myth in the software business that runs something like this: if we plan every detail of our product, assign the details to individuals, monitor and track each individual's progress on each task, make sure the load is balanced across individuals and always at the maximum (or just a little more) that each individual can deliver, and if we put in place sufficient incentives and penalties to make sure that individuals follow the plan exactly, the end result will be a perfectly executed project.

Aside from the obvious difficulties of planning a future over which we mere mortals have neither control nor even foreknowledge, there is a massive gotcha lurking in the shadows of this defined, command-and-control approach that is the result of the Law of Unintended Consequences: malicious obedience.

Malicious obedience is a common behavioral response to situations in which individuals know that they have no control over what they work on, how they work, or the outcome they produce. When the incentive/penalty structure emphasizes obedience over all else, people learn very quickly to do precisely what they are told and nothing more, even if they know perfectly well that what they are doing is not the best way to achieve the end goal, which in the software industry is a working, valuable product. A common example, and one that I have experienced on more than one occasion, is when developers write code exactly as specified even when they know that what they're coding is incompatible with some other part of the system, either because of an initial design failure or a requirements change that did not propagate to their part of the system in time. Since command-and-control values obedience over all else, the developers in question had no choice but to follow the plan, write the code as specified, generate waste, and damage the overall project. "We were just following orders, sir."

Since a successful project is (or should be) the actual goal, the cure is to apply Agile principles and practices throughout. When people choose their own daily tasks, freely commit as members of a team to deliver a Sprint backlog, and have control over how they implement a solution, malicious obedience is no longer an issue. To put it another way, removing the compulsion to follow arbitrary orders from the equation eliminates the possibility of malicious obedience. When people are empowered to take ownership of their work, the Law of Unintended Consequences breaks down, resulting in innovative solutions, sterling quality, and timely feature delivery.

All for now....

...-.-