Many people in the United States are broke–and the rest of us are tense. One in four mortgages is underwater[1]. 2008 was the worst year on record for household net worth[2]. Over 20% of households under age 35 have a negative net worth [3].
Adopting agile, however, requires not tension, but slack[4]. I mean psychological slack, emotional slack, resource slack, time slack, and financial slack. Under stress, one’s capacity to change shrinks. A person living paycheck to paycheck may find taking career risks difficult. He or she cannot risk the chance that transitioning to agile will bring about job loss.
It’s hard to try things that might fail when so many people are really anxious about their security. Who will announce during a standup meeting that a task is taking longer than expected because they don’t know how to do something? Who will report that the key impediment to successful agile adoption is their boss’s ignorance of agile?
In a recent interview[5], David Chilcott of Outformations noted that there are three topics that are difficult to discuss in the workplace: sex, money, and power. When it comes to money, Chilcott says, the people at Outformations have open discussions about how much each person should be paid. These discussions can be emotionally difficult. (What? I’m not worth $150 an hour?) Yet in the end, people at Outformations know how much everyone else is paid and why. Difficult or not, these discussions eliminate a key impediment people experience when working together on a team.
In a large corporation, talking about pay is usually impossible because it’s often specifically prohibited by the human resources department. As a result, people feeling anxious about finances cannot discuss this impediment openly. On an agile team, this could lead to a loss of transparency and confusion about why velocity is not as high as it might be.
How might this problem be addressed? I do not have a good answer. Maybe a first step is for large organizations to confront the fact that they are not going to transition to agility quickly. Certain parts of the organization and some teams may be agile and the organization as a whole may be said to be agile in a mechanistic, cargo-cult sense, but “full” agility requires a radical change in corporate DNA, and it won’t happen fast. The good news is that even partial agility (getting to done, iterating, etc.) will lead to radical improvements.
The financial fear that people are now experiencing in their daily lives is rarely discussed in the agile community. Recognizing its existence, and the harm that it does, may be first step in neutralizing it.
[1] http://online.wsj.com/article/SB125903489722661849.html
[2] http://www.nowpublic.com/world/household-net-worth-continues-fall
[3] http://6aa7f5c4a9901a3e1a1682793cd11f5a6b732d29.gripelements.com/pdf/vol-710.pdf
[4] Slack by Tom DeMarco
[5] http://www.vimeo.com/9293844
0 Comments Click here to read/write comments
Tags: essay
Make Love, Not Money
Posted by Michael de la Maza on Mon, Feb 08, 2010 @ 09:51 AM
Email This Email Article | Share on Twitter Twitter | Share on Facebook Facebook | Submit to Digg digg it | Add to delicious delicious | Submit to StumbleUpon StumbleUpon | Share on LinkedIn LinkedIn | Share On Technorati Technorati | Submit to Reddit reddit
Some folks in business are pursuing a strategy that is not taught in business school: The best way to maximize profit is to stop thinking about maximizing profit and, instead, to focus on treating people right. That is to say, the best way to make money is to focus on loving people.
Joel Spolsky of Fogbugz fame says it so: “Best Working Conditions -> Best Programmers -> Best Software -> Profit!” [1]
Tony Hsieh of Zappos puts it this way: “Culture is our number one priority…Our whole belief is that if we get the culture right then a whole bunch of other stuff like building a brand…will happen naturally on its own.”[2]
I want to distinguish this view from two similar perspectives: The first is ’60s style hippie collectivism which holds that capitalism is evil because it is inherently coercive and manipulative, that labor and capital should benefit all members of an organization, and that, really, money is a nuisance and what matters is love. The Make Love, Not Money perspective in contrast, says nothing about whether money is a nuisance or how capital should be organized. This is not to say that it is inconsistent with the hippie view.
The second perspective is the standard Scrum mantra: “The goal of a team is to maximize business value by delivering working software.”[3] Under the Make Love, Not Money view this might be re-written to read: “The goal of a team is to optimize its work environment and, as a beneficial side effect, it will radically increase the business value it delivers.” The fact that optimizing the work environment has often led to significant increases in financial success is an empirical finding. It’s consistent with common sense but doesn’t by necessity follow from the “optimize the work environment” premise.
A good question to ask is: Why don’t profit maximizers do this? The typical middle manager, when asked to increase profit, responds by laying off workers or skimping on office furniture-not by creating a great work environment. I do not know why. I suspect, though, that it has to do with human cognitive limitations. It’s hard for us to understand the nth order effects of our actions. Buying cheap office chairs is a simple thing to do-the other, more complicated.
If he adopted it, a profit maximizer might view the Make Love, Not Money perspective as a useful cognitive crutch which helps him make better decisions, just as coaching a chess novice to develop his pieces (instead of telling him to mate the opposing king) is a useful cognitive crutch.
Bottom line: focus on creating extraordinary work environments and get extraordinary profits for free.
[1] See http://www.fogcreek.com/About.html for an eloquent description of the Fogbugz philosophy.
[2] http://blip.tv/file/1696310
[3] See, for example, http://codebetter.com/blogs/darrell.norton/articles/50339.aspx: “Scrum is a process for the empirical control of software
development. It enables teams to deliver working software in an iterative manner in order to maximize business value.”