A Higher Purpose

When agilists talk about the reasons to adopt an Agile approach, whether Scrum, XP, Kanban, or any of several others, we typically focus on benefits to products, customers, and the bottom line. We also talk a lot about the benefits of working at a sustainable pace, working in self-organizing, collaborative teams, and building a culture of change and improvement. Sometimes we talk about creating a work environment that builds and maintains high morale and, to the extent that such a thing exists in the 21st century, bilateral loyalty between individuals and the organization.

These are all important considerations. Most of them contribute directly or indirectly to improving the working lives of everyone in the organization, which is one of the primary reasons that I am such a strong advocate of Agile. But I think there is a higher purpose  Agile fulfills that we, as agilists need to recognize and promote.

It’s neither trendy nor popular to talk about what used to be widely known as the “social contract”* in a capitalist economy. The idea was that there existed a mutual commitment between corporations and society at large. Society made the commitment to support and encourage corporate success by a) supplying the brain power and labor that corporations used to build products, and b) constructing a regulatory environment (in democratic societies at least) that did not unduly constrain the corporations’ ability to innovate and make a profit. The corporate commitment was to enhance society by providing stable employment at a rate of compensation that would allow the entire economy and society at large to thrive. This is Adam Smith’s “invisible hand.” Henry Ford, for all his other glaring faults, understood this concept instinctively. He recognized that stable employment and good pay for his workers was good for business.

Yes, I know this is a huge simplification of the concept and reality of the social contract, but for me this is its essence.

So what does the social contract have to do with Agile? That’s where the higher purpose comes into play. A long time ago, W. Edwards Deming formulated what came to be called the Deming Chain Reaction. Basically, the Deming Chain Reaction states that as a company increases the quality of its products, costs drop and productivity increases due to reduced rework, market share increases, the company stays in business, and – here’s the key – provides more jobs to produce yet more high-quality product in a never-ending cycle.

The Deming Chain Reaction is a manufacturing model, but it works equally well, with a few tweaks, for Agile software development.

DemingAgileChainReaction

The point is that as organizations apply Agile frameworks, practices, and techniques to improve quality, to implement continuous improvement within the organization, the Deming Chain Reaction comes into play. Companies that adopt Agile conscientiously, comprehensively, from end-to-end of the value stream, do far more than simply stay in business – they thrive. And in thriving, they help the communities in which they operate to thrive as well – or at least that’s the Deming Chain Reaction model. Making a profit is simply not the point. Profitability is necessary, but it’s a means to an end, not the end in itself anymore than agility is an end in itself.

Agile offers the path to success for companies large and small. The higher purpose of that success – and by extension of Agile itself – is for organizations to create employment that is challenging, interesting, dignified, fairly compensated, and widespread, and in so doing to reflect back on their communities and society as a whole the values and principles that produced that success in the first place. To my mind, that is the higher purpose of Agile.

*Note that this is an economic social contract, not the political Social Contract of Locke or Rousseau.

All for now….

…_._

Learning to coach while training

Winter has put in an early appearance on the Front Range of the Rocky Mountains this year. After almost two decades of very late arriving winters, this year is shaping up to be much more like those I remember growing up, with winter firmly ensconced by Halloween. The weather pattern could certainly change, but this has been a nice reminder that Colorado’s weather is, if nothing else, highly variable.

The low overcast today seems to have put me in a contemplative mood. A thought that has been rolling around in my head for some time now concerns the nature of communication in the Agile training sessions I conduct. We tend to think of training as a one-way street, with the instructor delivering the curriculum and answering questions along the way and the participants in the class absorbing the information presented. I have noticed, however, that by the end of a two- or three-day training course, I know far more about the working lives of the people taking the course than I would ever have expected. For example, I know if they constitute a working team, regardless of whether they claim to be such. I also know a great deal about their frustrations, impediments, and constraints. I have a solid grasp of the role each participant plays on the team or pseudo-team* and even some sense of how they work together — if indeed they do.

Given that in any training session, during the presentation portion (as opposed to labs and workshops), I am the one doing the talking at least 80% of the time, I am always surprised to realize just how much I have learned about the participants in the room. I try to answer all questions in-line and make full use of the Parking Lot to capture topics that are either tangential, more advanced than we can discuss as a class at a given moment, or simply beyond the scope of the current course. The Parking Lot then becomes the basis for a moderated discussion at the end of the formal presentation. But even before that point, I have learned much of what I need to know about a particular group of people to begin coaching them in their use of Agile or Scrum.

My employer typically uses various workshops or other discovery sessions to prepare for hands-on team coaching. While I find these types of activities useful for filling in the blanks, I also find, to my great surprise, that most of the information I gather using such tools simply reinforces the picture I was able to construct essentially unconsciously during the initial training. Given the often challenging and difficult nature of coaching agile teams, having learned so much during the initial training is a welcome head start.

All for now.

…-.-

* A pseudo-team is a group of individuals who just happen to be working on the same project at the same time, but without engaging in any actual teamwork.