Why do we work?

Draft

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 
goes unmentioned. 

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 
through self-management. 

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 
self-management alone!

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.

Some History

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. 
Completely 'bought-in'.

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 Breakdown

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

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

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
efficiently?

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

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.

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

Without this, don't expect much genuine innovation emerging from your
environment. 

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

The brain

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.



Greg Bryant