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….

…_._

A Heuristic for Task Work

My rule of thumb for Task work – and one I highly recommend Teams adopt as a part of their Team Working Agreement – is as follows: Every Team Member’s name appears on one and only one in-progress, unblocked Task at a time.

This rule does not preclude multiple Team Members from working on the same Task. It does preclude any Team Member from signing up for or attempting to work on more than one Task at time. And that’s the point. Single-item flow is the most effective, most efficient way known to develop a product.

<

This example (partial) task board shows the task heuristic in operation

The result of this simple rule is that no one is working on more than one Task at once, meaning no one is attempting to engage in multitasking. Another result of this simple rule is that Tasks not yet in progress are available, by virtue of the fact that they live in the To Do column on the Task Board, for any Team Member to work on, until one or more Team Members sign up for the Task. This simple visual cue helps the Team see what needs to be worked on and also helps drive cross-functional behavior on the Team by making it physically possible for anyone to sign up for any available Task.

Excerpt from The Agile Team Handbook, page 139.

All for now….

…_._

Got a Morale Problem? Get Quality!

The connection between product quality and morale isn’t a big mystery, but it seems to be one that is frequently overlooked. W. Edwards Deming and, somewhat later, Frederick Herzberg famously linked the sense of accomplishment people experience when doing good work on projects over which they are able to control how the work is done with high morale. Scrum’s emphasis on delivering a working product increment at the end of each Sprint fits into the morale equation perfectly.

So what’s the problem?

We don’t always do as we should. When teams are pushed to take on more work than they can competently deliver, quality is the inevitable casualty. Teams that find more and more of their capacity sucked away by bug-fixing rapidly experience significant, sometimes catastrophic, declines in morale. With morale goes innovation, productivity, and continuity as people seek to flee the bug storm.

An even worse situation occurred in one company’s misguided attempt to focus on its defect backlog while at the same time delivering new features at their accustomed pace. The solution they settled on was to create a bug-fixing “team” — actually a large work group — that would, in essence, clean up the messes left by the over-worked feature group. Freed from the responsibility for the quality of their work, the feature group delivered a large number of features. Unfortunately, the feature group’s freedom from responsibility produced a product strangled by defects which the poor souls on the bug-fixing work group couldn’t hope to save. Both sides blamed the other for the rotten product quality and morale throughout the company hit absolute rock-bottom. An attempt to introduce Scrum into this situation failed because of the maelstrom of blame, mistrust, horrible morale, and fear of change.

The highest morale I have had the privilege to share in occurred on Scrum teams that were allowed to play by the rules of Scrum: only pulling in the work that the team members could commit to, failing tests were simply an indication of “not done,” and nothing that was “not done” ever saw the light of day. The company provided adequate support for continuous integration, TDD, refactoring, and other good engineering practices, which allowed the teams to work without fear of unintended consequences. When a bug did surface, as bugs inevitably will, the team that produced it was responsible both for the fix and the tests to prove the fix. The teams in this organization felt the same degree of ownership and satisfaction when fixing bugs as when developing new features. In short, their morale was in the stratosphere. Their quality was also spectacular.

So the next time you notice one or more teams suffering from poor morale, work on quality. Fix the quality problem and the response to an inquiry about morale will almost certainly be “what morale problem?”

All for now….

…-.-