Why do we work?

On the surface, this essay is about Agile and Scrum, two names for a 
family of approaches to group work, based on principles that are 
derived, more-or-less, from human instinct.

As used in modern computer engineering, these two approaches, when
done well by their own criteria, have contributed one very important 
benefit to its practitioners, a benefit that is typically unspoken. 

It has also unwittingly perpetrated a real problem among its practitioners, 
a harm that is equally unspoken.

Now, certainly there are many minor problems with particular implementations 
of Scrum and Agile. But I think the ways it can be done badly are well known, 
are even a part of the process, and well-studied. I will leave those issues
aside here. 

I want to focus on what is most important, which is also what is most ignored.

My aim is to point the way to something much better. This 'attack' comes 
from a radical humanitarian perspective, the one that generated scrum in
the first place.

The Big Benefit

The best things about Agile and Scrum are NOT that they increases 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 able to
judge, or even study, as to their positive or negative effect on the world. 
So the effect of the agility and productivity of Scrum done well is, in most 
cases, not even evaluated. It is almost never optimized for public benefit.
The focus is very narrow.

No, the best thing about Agile and 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 through self-management. These approaches
can allow you to do things well, because a cooperative of free minds can 
be creative and effective in a way that a top-down manager can never 
hope to match. It allows a team to fly in the face of human 'intutions' about 
command-and-control, dictatorial notions of management that have been repeatedly
demonstrated to be ineffective by every measure. We are not automata.

The power 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 a top-down mindset, occasionally remember that they need to respect 
their active experts, and that they should facilitate their cooperation so that 
they can be even more creative and productive. Self-management is mutual support,
and it allows computer people to cooperate to remind those in power of the true 
power of people.

Because of this collaborative 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-demontration of self-management's

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.

It 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 
self-management alone. 

Autonomy is more effective for the same reasons self-management is more 
effective: freedom, creativity, motivation, expertise, buy-in, retention, etc.

We do not 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 it, 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. 
They make it impossible to focus upon using technology to further 
meaningful self-determination and collective action.

In other words: we get a lot done, but what are we working on? Why do we work?

Because of this gap, Agile processes don't even reflect the primary 
lessons of innovation taught by the original dotcom boom, whose most 
enlightening principles have been completely misread, willfully or not, 
by the techno-magnates who survived the dotcom crash.

Some History

When scrum started to become prominent in software development, more or 
less in parallel to the dotcom boom (which needed it to speed iterations), 
I was experimenting with a larger iterative process, in the heart of boom,
in 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". I think it points to the future 
we should be aspiring to, as people in computing.

I'm in my fifth decade of programming. I do it 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 sensitivity 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 those 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 symphony -- 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, we need to take the next step.

Having autonomy means real collaboration, in the broadest possible way. And that 
would reflected in "good scrum". To be clear, I need to provide a sense of what 
that looks like. It was during a 1997 project called Gatemaker, and was the basis 
of the 1998 experiment.

Now I'd been writing about partipatory processes for years, and in 1996 I started 
a software project with my friend Christopher Alexander. He's the architect, urbanist,
philosopher who inspired the software patterns movement -- and much else in
computong -- without being directly involved.

We had just raised funds to give us the freedom to develop the most important
software that we could. Our collegues threw many ideas at us, but we needed to 
get away from this, and get it done, whatever 'it' was. We knew that if we pre-defined 
the application in any way, it wouldn't do anything significant. We needed to 
meet an important need. And we were quite agreed on the needs involved: making the
world better, empowering people, allowing people to make their life better, to in
fact make their environment have life, etc.
We would meet in the morning to discuss what to do next. We did not look at a "to do" 
list. Instead, we asked ourselves, of all the things we could do, what would get us 
closer to our largest goal, the goal we were both 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 nailed the "best next step", I'd go away for 10 hours 
and build it. We did that every day, with breaks, for a few months. And the result 
was unique and heart-wrenchingly beautiful. Which is something one almost never says 
about a computer program, but that was among our "acceptance criteria" every day. 
So, of course we could achieve it, improving it in small-effort steps, focussing on the
most important things first.

That project ended in 1997. At the end of 1998 I launched a startup in downtown 
Palo Alto, which has been called, a bit preciously, one of the "most innovative" 
times-and-places in human history.

We didn't have a conference room: we couldn't afford it. Neither did Google or Paypal, 
and so 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 co-workers. We would stay in this pleasant, crowded 
establishment, filled with enthusiastic boom-town energy and discussion, and 
try to find the next 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. 
When we all knew we were on the right track, we'd leave, and get to work. Completely 
fired up. Completely able to justify our own enthusiasm to outsiders. Completely

But this had to come 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.

We managed to keep this 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'.

In a way, this 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 it.

The Breakdown

The dotcom boom was a pretty special moment, a kind of pinnacle of an actually 
innovative environment which the Bay Area is often marketed as having. On reflection, 
if we want to know where the innovation and enthusiasm of the first dotcom boom 
came from, where disappeared to, and how to rekindle it, then we should consider 
these issues:

Universal opportunity

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 hunched "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 basically one: 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.

This is one of the most important things about finding the product and market that 
excites you: visibility to the needs of an actual community of people. Theoretical
discussion of what people need doesn't mean much, unless you have people you can talk
with and discuss real problems with. A cafeé is perfect for that. A company
really could be, but typically isn't, because most companies are tyrannical and 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.

Public Interest

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 feel 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 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 stuff 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? Aren't there priorities that you 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.

Being free

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

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.

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 

the brain

what we do with computers, and how we do it, is simply not understood.

if people claim to understand it, you should be able to defend yourself.

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 wage-slavery tolerable.

Greg Bryant