Why do we work?
On the surface, this essay is about Agile and Scrum, two names for a
family of approaches to collaborative work, meant to harmonize with
human instincts for cooperation and intellectual freedom.
As used in modern computer engineering, these two approaches, when
reasonably performed by their own criteria, have contributed one very
important benefit to its practitioners: but it's one that typically
Additionally, it has unwittingly done a genuine disservice to its
practitioners, a harm that equally tends to go unmentioned.
Before I describe them, I want to make it clear that there are certainly
many minor problems with particular implementations of scrum. But I think
the many ways it can be done badly are well-known, are discussed, are a
part of the process, and well-studied. I will leave those issues aside here.
I want to focus on those most important issues, which I believe are also
the most ignored.
My aim is to point the way towards something much better. This is not an
'attack', but a critique, one that comes from a radical humanitarian perspective,
the perspective that I believe generated scrum in the first place.
The Big Benefit
The best things about scrum are NOT the increases in agility and productivity.
If you care about the goals, productivity may be important.
But a good Scrum team can also complete stories that it may not be in the position
to judge, or even study, as to their positive or negative effect on the world.
So the actual outcomes of the vaunted agility and productivity of scrum done well,
are in most cases, not even evaluated. They are almost never optimized for public benefit,
not even for the narrow benefit of the team in question. The focus is very narrowly
upon the goals. Which are not the team's goals, even though they are called "the
team's goals". The team hasn't actually considered what their goals might be.
They are highly constrained by the tyranny they find themselves in.
No, the best thing about scrum is that, no matter how badly your team is externally
managed, in the old-fashioned top-down manner, your team can prove that it does better
Scrum can allow you to do things well, because a cooperative of free minds can
be creative and effective in a way that top-down management can never
hope to match. It allows a team to fly in the face of human fallacies about
command-and-control, dictatorial notions of management that are repeatedly
demonstrated to be ineffective by every measure. We are not automata. We are
not puppets. We are not smart pencils. We are not resources.
The proof of self-management gives clout to computer people, and offers a defense
against the general class of retrograde people who run companies and institutions.
Those executives and administrators who were engineers, although they can easily
get converted to the top-down mindset, occasionally remember that they need to respect
their active experts, and that they should facilitate their cooperation and freedom
so they can be even more creative and productive. Self-management is mutual support,
and it allows computer people to collectively remind those in power of the true
power of people.
Because of this joint defense, the emergence of "Agile" and "Scrum" in
industrial management may have seemed revolutionary. It has been pointed out,
from the start, by many, that the ideas and processes are not new. But that shouldn't
detract from the importance of this widespread re-demonstration of self-management's
success, against the worst practices of management.
Unfortunately, because it sounds radical to say so, this success is rarely
openly discussed. That's disempowering. People should be shouting it!
The Real Problem
Unfortunately, the worst aspect of this form of self-management is also
never discussed. I've hinted at it above.
Scrum injects a disempowering illusion of self-determination into the
endemic tyranny of everyday life in the computer industry.
We've proven that self-management is more effective. But we have no
ACTUAL autonomy, no self-direction, not even the opportunity to prove
that FURTHER autonomy and agency can be even MORE effective than
Autonomy is more effective for the same reasons self-management is more
effective: free discussion, individual and group creativity, improved
motivation and ownership, broader expertise, buy-in, retention, etc.
We do not yet decide what needs to be built. And so we are not
empowered, in that way, by scrum or agile in a corporate or institutional
environment. Unless we fight for this power, or leave our institutions.
Agile/Scrum initiatives are riddled with the presumptions of wage-slavery, as if
everyone should, in one more recent characterization, "do a tour of duty"
within a computer company run by "thought leaders", with delegation to
"product owners", etc.
These processes regularly distract workers from focusing upon the issues
that are most important to themselves, their community, and the world.
Including their users. The focus upon doctrines of performance make it
impossible to focus upon the use of technology to further meaningful
self-determination and collective action, at work or in the world.
In other words: we get lots done, but what are we working on?
Why do we work?
Because of this gap, the somewhat rigid scrum processes that groups adopt
don't even reflect the primary lessons of innovation in the enlightenment,
or even those we learned in the wild world of the original dotcom boom,
whose most improtant principles have been completely misread, willfully
or not, by the techno-magnates who survived the dotcom crash.
When scrum started to become a prominent buzzword in software development,
more or less in parallel to the early days of the dotcom boom -- which needed
a better social process to speed iterations and improvements, as was widely
understood at the time) -- I was experimenting with a larger iterative process,
in the heart of boom, in downtown Palo Alto ...
... in a café.
As opposed to "bad" scrum, i.e. the UNempowered type, which is everywhere,
I'll call this experiment "good scrum", even though I just think of it as "good
work". It points to a future we should be aspiring to, as people in computing
who care about being good citizens.
I'm in my fifth decade of programming. I program with increasingly guarded
enthusiasm, because my parallel background is in community-driven social change.
I'm a student and practictioner of the kind of organizer-sensitivities needed
to make the world better from the bottom-up, from the grassroots.
People need self-determinism and agency in their work, and I experience special
joy when I find people's agencies cooperating in a positive way in the world.
Finding 'like-minded' people to work with is increadibly important for good work.
Rather than playing an instrument in someone else's supposed orchestra, you
become the composer along with your collegues. This is sorely lacking in the
computer industry. So much so that it had to be faked with "agile" and "scrum".
People who live in prisons need to feel some autonomy, or they will simply die.
We can't have workers be THAT unhappy, so we'll tell them to find their own way
to MANAGE their cell-blocks.
Well, everyone, we need to take the next step. Having autonomy means real collaboration,
in the broadest possible way. And that should be reflected in "good scrum".
To be clear, I'll need to provide a sense of what that looks like.
I'll pick the process from a 1996 project called Gatemaker. It was the basis of my
1998 dotcom experiment.
Now, I'd been writing about partipatory processes for a few years, and in 1996 I started
a software project with my friend Christopher Alexander. He's the architect, urbanist,
and philosopher who inspired the software patterns movement, the wiki -- and much else
in computing -- without being directly involved. One of the main domains of his
architectural work were experimental large-scale democratic decision-making projects
in planning, design, and construction. He'd done this for decades.
We had just raised funds to give us the freedom to develop the most important
software that we could imagine. Our collegues threw many ideas at us, but we needed to
get away from this, to work on it ... whatever 'it' was. We knew that if we pre-defined
the application too much, it wouldn't do anything significant. We needed to
meet some important goals: make the world better, empower people to make their life
better, to give their environment life, etc.
We would meet in the morning to discuss what to do next. We never looked at a "to do"
list or anything like it. Instead, we asked ourselves: given where we were now, what,
of ALL the things we COULD do, would get us closer to our greatest goal, the goal we
were passionate about: providing access, for the maximum number of people, to the tools
they needed to build a wonderful and nurturing, living environment for themselves
and their community.
We would discuss this for hours. We were very motivated to actually build something
helpful. When we thought we had nailed the "best next step", I'd go away for 10 hours
and build it. We did that every day, with few breaks, for months. And the result
was unique and heart-wrenchingly beautiful. Which is something we almost never say
about a computer program, but that was among our "acceptance criteria" every day.
So, of course we could achieve it, improving it in small efforts, focussing on the
most important things first.
That project ended in 1997. In 1998 I launched a startup in downtown Palo Alto,
a time-and-place that has been called, a bit preciously, one of the "most innovative"
in human history. I'll concede that it was one of the most influential.
We didn't have a conference room: we couldn't afford it. Neither did the fellows who
had just founded Google and Paypal, who lived a block away in different directions.
We all hung out in one particular café, a lot: the terribly named,
but beautifully designed, University Coffee Café, on University Avenue
in Palo Alto.
I decided to replicate the "good scrum" from my project with Chris Alexander,
in this café with my young co-workers. We would stay in this pleasant, crowded
establishment, filled to the gills with enthusiastic boom-town energy and discussion,
and try to find the next MOST important thing to work on that day.
There was no product owner. Unless one thinks of the human race as a product owner.
Each of us contributed ideas, considered impact, gave voice to our deepest desires ...
it could go on for hours, while we interacted with other people who came and went.
But when we all knew we were on the right track, we'd leave, excited, and get to work.
Completely fired up. Completely able to justify our own enthusiasm to outsiders.
This NECESSARILY came from within. You can't fake such a thing through a top-down
mission. Autocracy with fake autonomy will provide those poor-quality corporate or
institutional products and services we are all familiar with: forced, uncreative,
uninteresting, improperly motivated, inauthentic, uninnovative, impoverished.
No wonder they produce the stuff of nightmare monopolies.
We managed to keep this mood going for a few months, but institutional mistakes eventually
screwed up the working environment. We went from being the archetypal start-up on the
corner, with luminaries from the computer industry wondering how we managed to seem
so 'genuine', to a battered start-up which (visitors would tell us) seemed 'divided'.
It left us terribly vulnerable when the bubble burst.
In a way, this division was 'good scrum' versus 'bad scrum'. Half the company wanted to
tell people what to do, and be followed. I didn't want that. People sometimes say they
WANT to be ordered around ... but when given the opportunity to determine their own
fate, in cooperation with others, they love independence. In the feeling of excitment
during the bubble, great comraderie emerged, which helped the cooperation of good scrum
to work. The crisis towards the end, and afterwards, led to the takeover by managerialism.
Which we're all 'enjoying' today.
The dotcom boom, where I was, was pretty special, a local pinnacle of an actually
innovative environment which the Bay Area is often touted as having. On reflection,
if we want to know where the innovation and enthusiasm of the first dotcom boom
came from, where it disappeared to, and how to rekindle it, then we should consider
One approach to looking at the engendering of the innovation of the dotcom boom,
was that there was no "natural entrepreneur" or "entrepreneurial class". The demand
during the boom was high, and the hierarchy in the industry was collapsing in key
places, so all kinds of people were recruited into the role of initiating and
organizing. So, really, "anyone could start something". This was common coin at the
time. I was talking to a woman about starting her own company. I remember stopping
Larry Page as he walked by, and I'm sure he remembers this, and asked him:
"couldn't she be a CEO?" He self-deprecated and shrugged "Well, I'm a CEO".
This was a world turned upside-down, which gave people with good ideas and valuable
experiences -- which might have been cooking inside of them for years, or who were good
at solving problems on their feet -- the sudden opportunity to not be wage-slaves
anymore, and connect more directly to the public. This was something the World Wide Web
provided technically, and which the computer industry was scrambling to take advantage
of, and so, at this moment, individuals could rise to the top.
An unobscured view of the real world.
We talk a lot about collaboration tools, but at this café, which didn't even
have wifi, there was only one tool: table paper.
The café tables were covered with a sheet of white butcher paper, which means
everyone could take out their pen and scribble ideas and contribute to central sketches.
That's it. Human minds, discussion, table paper, and a café full of people,
so you can watch the world go by and talk to them when you wanted another opinion.
This is one of the most important things about finding the public interest product
and market that excites you: visibility to the needs of an actual community of people.
Theoretical discussions in boardrooms about what people need don't mean much -- you need
normal people you can talk with and discuss real problems with. A café is perfect for that.
A company really could be, but typically isn't, because most companies are tyrannical, define
what you're working on, and own what you're thinking about.
Any public space, for example a public university, is the best environment.
Money, fame, and success aren't what is important -- although you SHOULD be successful
in proportion to the good you're trying to do -- but unfortunately that's not the way
the 'industry' sees things at the moment. That could change, at least in the computer
industry, if computer people would like it to. You CAN do things that are good for the
Success, estimates, and self-determination
What does it mean for the work of a group of people to be successful?
To be great?
If it's not a tyranny, it needs to be defined by the group. But, since
people have ideas, but groups do not, the ideas that form these agreements
need to come from people who are informed and thinking and feeling and have
the will to make good decisions.
That won't happen if decisions are being made for them. If other people
are determining what they do, and telling them what they should do.
If you don't know what you should do, why should another person estimate
what you should do? What would that mean? Scheduling the wrong things
So, putting 'points' on work is considered harmful. There is no point.
Trying to schedule getting things done? Well, what are those things?
You'll end up becoming path-dependent, only scheduling those things
you know, rather than the things that will make you successful, or
the things that help people.
Those things need to be defined by the individuals.
And no change or improvement or pivot or innovation, of corporate or
institutional strategy or operation, can happen without empowered
So, when you fight against 'points', and the product owner says
'how can I schedule without them'? You have to ask them WHY they
are scheduling? Are there priorities that we have all discussed?
No? If not, then why is anything being scheduled? If yes, then you're
already working on them, and you will work on them until they become
done, done enough, or NOT a priority anymore.
When it comes to something that effects no one else, and only your own
time, if you need to ask permission, you're not free. That counts
for a group of people too.
Self-determination in self-management, and workplace democracy, means
that you should be able to start a project with whomever you want. You
can't use all of your time on it, of course, without support of your
collegues. But that's different than "support from your management".
That's tyrannical. It doesn't matter if you agreed to it contractually.
Selling your actual freedom violates everyone's principles -- we are
just in the habit of not defending those.
Without this, don't expect much genuine innovation emerging from your
Engendering sensitivity to opportunity
What is is that allows you to sniff out significant product and service
differentiators, in the search for a good solution, or a better solution?
It's the sensitivity to people, and the world around you. Inside of an
institution, the more conformist the culture, the less likely you'll
have a diverse enough set of people to act as grist for identifying
real-world issues that need technological support.
It's also a developing sense of what's important. One should really avoid
trivial improvements. Systemic, fundamental, recurring problems are the
ones that people need addressed. Otherwise, consider: you may be polishing
and calcifying somebody else's automated wage-slavery.
But you also need the freedom to experiment, given this diverse
environment. UNIX and the software Tools movement grew out of sufficient
freedom, within Bell Labs at the time, to pursue better ideas.
Yes, a license headache ultimately ensued, but if there had been
a culture of risk-and-idea avoidance, the application of theory to
computing practice would have been set back 20 years.
Too much social engineering
When you have a goal, go ahead and have a goal. If you add some
kind of scientific management mechanism, it gets continually
harder to maintain your humanity and attention above and beyond
the mechanisms you've agreed to use. It stops you from being human
just that much more. It make you that much LESS agile, and that
much less capable of seeing or doing what's important.
False arguments used everywhere
The biggest problem with the marketing of agile and scrum, is that
the assumption of top-down management and a cult of efficiency changes
every argument, to the point of nonsense. So, everyone agrees that
a certain kind of 'multitasking' is silly and ineffective. But, that's
the kind of multitasking we mean. Others are completely out of our
control: our brains do many things at once to accomplish things that
appear to us to be 'one thing'. The notion that avoiding multitasking
is universal -- or 'fractally applicable', in one phrase that makes no
sense on close examination -- is just a circular definition. That kind
of multitaking that's ineffective, is inneffective. But if I want to
work on "two tasks", as if there's some kind of absolute division of
tasks, because they are in=terconnected, or they have something in common
that interests me, or are contrasted in some way that interests me,
I'll be damned if anyone can prove that it is more efficient to
force me to work on one to completion, followed by another. It's insane,
and is only acceptable in a top-down industrial environment. Where it
is not appropriate, in the same way that it wouldn't be acceptable in
any kind of exploratory or research environment. We need better ways
of doing things, and dogmas about the number of stories one can consider
at once, justified by our lack of ability to talk and sing at the same
time, will keep us, like any dogma, from finding commonalities and
insights into doing the right thing, and doing it well.
Pulling multiple stories is not necessarily multitasking
We mean by 'multitasking' the attention-stealing switching from
one task to another. Basically, if it reduces the quality and
profundity of something, it's bad.
But, if these are 'multiple stories' that you can see a common thread in,
they are not multiple stories, from that perspective. But from the
team perspective, you wouldn't want to change the stories.
I believe if agile people understood the cognition involved, they'd be
able to defend themselves from some of these bad patterns, when they don't
apply, or when they are being used to enforce top-down distracting
What we do with computers, and how we do it, is simply not understood.
If someone claims to understand it, everyone should be sufficiently-informed
to defend themselves from such dogma.
Trapped in a machine
It's very easy to get simplistic about how scrum should work, because
systems are mental constructs, and people will become trapped with them
unless you explicitly say "there is nothing there". Repeatedly. But the
more infrastructure and credence you give a system, the harder that is.
Autonomy needs to be the primary goal of scrum. If it isn't, then it's
a bad system, simply making subservience tolerable.