Why do we work?
... or 'the scrum café'
On the surface, this essay is about 'agile' and 'scrum', two names for a
family of approaches to collaborative work that make a number of claims
including, more or less explicitly, that its processes better harmonize
with human instincts for cooperation, free association, and creative
As used in modern computer engineering, this family of approaches (I'll
just call them 'scrum' from now on), when reasonably performed by their
own criteria, have contributed one very important benefit to its
practitioners: but it typically goes unmentioned.
Additionally, it has unwittingly done a genuine disservice to its
practitioners, and this harm equally tends to exist without comment.
Before I describe them, I want to make it clear that there are certainly
many minor problems with particular 'implementations' of scrum in real
projects. But I think the many ways it can be done badly are well-known,
discussed widely, part of the process, and well-studied. I'll leave those
issues aside here.
I want to focus on these two most important issues, which are also the most ignored.
My goal is to point the way towards something much better. So, this is not an
attack, but a critique, one that comes from a radical humanitarian perspective,
a perspective that I believe led to scrum in the first place.
The Big Benefit
The most important benefits of scrum are NOT the increase in 'flexibility' and 'productivity'.
Those benefits would only be important if the goals are important. And currently, evaluating
importance is not part of scrum. I'll return to this later.
No, the most important 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
work through self-management.
Scrum can allow a group to work well, because a democratic assembly 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 inhumane fallacies about command-and-control
and dictatorial managerialism, which 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 effectiveness of self-management gives clout to computer workers, and offers a defense
against the general class of retrograde technocrats who rule 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
the active experts and facilitate cooperation and freedom, if they want increased innovation,
adaptation, and production. Effective group self-management increases mutual support, and
makes space for the technicians to self-actualize, reminding those in power of the
true power of people.
Because of this collective defense, the emergence of 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
legitimizing, re-demonstration, and recognition of self-management's superiority,
against the worst practices of management.
Unfortunately, because it sounds radical to say all this, self-management's proven
success and superiority is rarely openly discussed. Which is disempowering. We need to
remind everyone of it, as often as we can.
The Real Problem
Unfortunately, the worst aspect of this form of self-management is also never discussed.
I hinted at it above.
Scrum injects a disempowering illusion of self-determination into the endemic tyranny
of everyday life in the computer industry, or any managerialist technocratic environment.
We've proven that self-management is more effective. But we have no actual autonomy, no power,
no self-direction, not even the opportunity to prove that FURTHER autonomy and agency can
be even MORE effective than self-management alone!
Autonomy is more effective than taking orders, for the same reasons self-management is more
effective: free discussion, individual and group creativity, improved motivation and ownership,
broader inclusion of expertise, wider buy-in, better retention, etc.
But we do not yet decide what needs to be built. So we aren't yet empowered, in that way,
by scrum in a corporate or institutional environment. We are stuck as self-managed teams working
for autocrats, unless we fight for this power or leave our institutions.
Scrum and agile-like initiatives in the industry 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.
So an effect of this kind of 'self-management' is to regularly distract workers from focusing
upon the issues that are most important to themselves, their community, and the world. They've
become cogs in someone else's machine, and they're typically aware of it, but can't say anything.
They are not able to discover or develop any means of even judging whether what they do is helpful
or hurtful for anyone. 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 outside of it.
They cannot be involved in judging what's important, because meretricious executives 'at the top'
need to defend their positions as 'legitimate' decision-makers, even though they are only trained
to represent the interests of the rich and powerful, or those who seek to be.
In other words: we're productive, but what are we working on?
Why do we work?
Because of these chains, the somewhat rigid scrum processes that groups adopt don't even reflect
the primary lessons of innovation and freedom we inherited from the enlightenment, or even those
we learned in the wild west world of the original dotcom boom. The most important lessons of the
boom have been completely misread, willfully or not, by the propagandists and plutocrats of monopoly
capitalism. And we're all suffering as a result.
When scrum started to become a prominent buzzword in software development,
more or less in parallel to the early days of the world wide web -- which needed
better working processes 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 "weak" scrum, i.e. the UNempowered type, which is everywhere,
I'll call this experiment "strong" or "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 cooperating in a positive way in the world. Finding 'like-minded'
people to work with is incredibly important for good work. Rather than playing an instrument
in someone else's supposed orchestra, you become the composer and producer along with your
collegues. This is sorely lacking in the computer industry. So much so that it had to be
faked with the corporate adoption of "agile" and "scrum". People who live in prisons need
to feel some autonomy, or they will simply die. The executives couldn't allow workers
to be THAT unhappy, so we'll allow them to find a way to self-manage their cell-blocks.
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".
Let me provide some examples of what that looks like.
To escape from a day-job consulting to a silicon valley digital mapping company, I embarked
on a 1996 project called Gatemaker. This later became the basis of my 'good scrum' 1998 dotcom
'experiment', which I'll explain in a moment.
I'd been writing about partipatory processes and self-direccted communities for a few years,
and in 1996 I started Gatemaker with my brilliant friend Christopher Alexander. He's the architect,
urbanist, and philosopher who inspired -- among much else in computing -- the software patterns movement
and the wiki, without being directly involved. One of the main aspects 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 from Sun Microsystems to give us the freedom to develop the most important
software that we could imagine. For three months. Our computer-business colleagues threw many
ideas at us, but we needed to get away from this influence, to discover whatever the most important
thing was that we could achieve in that time. We knew that if we went along plans to build ambitious
systems of the sort that already existed, we wouldn't achieve anything significant in so little time.
We needed to make the world better, empower people to make their lives better, to give their environment
more life, and to make them feel more alive.
We'd meet in the morning to discuss what to do next. We never looked at a "to do" list or anything
like it during these discussions. 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. Then I'd come back
the next day and we'd look at it, see if it was the right thing, keep it or discard it, or determine
some modification for it, and again try to work out the next important thing to do. We did that every
day for three 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
That project ended in 1997. In 1998, also on the side of my day-job consulting, 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 was one of the most influential.
My new comrades and I didn't have a conference room: we couldn't afford it. Neither did the people who
had just founded Google and Paypal, who lived within a block away in different directions. We all hung
out in this one particular café, a lot: the terribly named, but quite beautiful,
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 comrades. We would sfind a table 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, and we absorbed humannity. But the
moment 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. Completely 'bought-in'.
This NECESSARILY came from within. You can't fake such a thing through a top-down 'mission' for the
'company leaders'. Autocracy with fake autonomy will provide those poor-quality corporate or institutional
products and services we're all too familiar with: forced, uncreative, uninteresting, improperly motivated,
inauthentic, uninnovative, impoverished, broken, exploitative. The products of nightmare monopolies.
We managed to keep this empowerment going for a few months. It made us famous in this small but
influential scene. But we grew, and brought in new colleagues, who brought with them the destructiveness
of the top-down industry. This screwed up the working environment. We went from being the archetypal start-up
on the corner, with luminaries from the computer industry asking how we created such a genuinely generative
environment, to a battered start-up which (visitors would tell us) seemed 'divided' and 'searching for leadership'.
The old-fashioned managers 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 and others did not want that. People sometimes say they WANT to be ordered around ...
and if their life is difficult that's understandable at first. Typically, though, when given a real opportunity
to determine their own fate, in cooperation with others, they'll love independence. In the feeling of excitment
during the bubble, great comraderie emerged, which helped the cooperation of good scrum to work. The growth and
crisis towards the end, and the 'we-told-you-not-to-be-idealistic' nagging afterwards, led to the re-takeover by
managers and autocrats. Which we're all 'enjoying' today. The revolution was defeated.
The lesson, to me, is pretty straighforward. Once you manage to put human feeling, sensitivity, cooperation, and
the desire to do something wonderful for the world, into the CORE of your design-build decision-making -- then
you need to protect it.
We're very far from doing this today in the industry. Corporations and institutions are more ruthlessly
hierarchical than ever. But for some of us, this is one of the easiest eras to initiate projects and find teams.
In mutual support with our fellow tech people, it is our responsibility to help everybody to find this freedom
to be human. And they in turn, should feel the same responsibility towards the world and their fellow workers.
The Gatemaker project:
A Gatemaker video
Greg Bryant's diary of the Gatemaker presentation to Sun
Greg Bryant's paper presented to Sun
Gatemaker as a window into the computer industry
Christopher Alexander letter to Bill Joy on Gatemaker
More Christopher Alexander memos on Gatemaker
My sketches in the café where it happened
Addendum: Studying the time and place
The spot where I weathered the dotcom boom was pretty special. It was a local pinnacle, an actually
innovative environment, which the Bay Area is often touted as having, but rarely has. 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 these issues:
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
methodological systems are mental constructs, and people will become trapped
within them unless they explicitly say "there is nothing there, let's rethink this".
Repeatedly. But the more infrastructure and credence you give a system,
the harder that is.
The promotion of autonomy and cooperation needs to be the primary goal of scrum.
If it isn't, then it's a bad system, simply making subservience and supplication