Why do we work?

This site is critical of many of the most basic assumptions of Agile
and Scrum. But there would be no point in unraveling Agile, and revealing
its fundamental misconceptions, if my aim wasn't to point the way to 
something better. This is an attack from a humanitarian perspective.

The Real Problem

To some people, the emergence of "Agile" and "Scrum" and "Patterns"
in industrial management may have seemed revolutionary. It has been
pointed out, from the start, by many, that the ideas are not new. 

There is much wrong with these movements, much of which has also
been discussed since they first appeared. But the worst aspect of Agile
is never discussed: on the whole, it has been bad for people. 
It injects a disempowering illusion of self-management and 
self-determination into the endemic tyranny of everyday life 
in the computer industry.

These branded initiatives are riddled with a presumption 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 most important issues, to themselves, their community, and 
the world. They make it impossible to focus upon using technology 
to further meaningful self-determination and collective action.

These 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

At about the time that "scrum" became prominent in software development, 
more or less in parallel to the dotcom boom, I was experimenting with 
a process, also in the heart of boom in Palo Alto ... 

... in a café. 

As opposed to "bad scrum", which is everywhere, I'll call this experiment
"good scrum". I think it points to the future we should be aspiring to.

I'm in my fifth decade of programming-with-guarded enthusiasm, but my 
parallel background is in community-driven social change. I'm a student 
of the kind of sensitivity needed to make the world better from the 
bottom-up, from the grassroots. 

It's this sensibility, this understanding for people's need for 
self-determinismm, for agency, in their work, and the joy of finding
that agency in the world, of finding like-minded people to cooperate with,
rather than as a side-note to someone else's supposed symphony -- 
that is so 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

Having autonomy means real collaboration. And that's reflected in "good scrum".
To be clear, I need to provide a sense of what that looks like. It's the
basis of the later experiment.

Just before dotcom boomed, I'd finished a software project 
with Christopher Alexander, the architect/urbanist who inspired 
the software patterns movement, without being involved in it. 

We would meet in the morning to discuss what to do next. We did not
look at a "to do" list. 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 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 little by little, 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: 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" in this café with my co-workers.
We would stay in this pleasant, crowded establishment, filled
with enthusiastic 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. 

But it had to come from within. You can't fake this through a top-down
mission. Autocracy with fake autonomy will provide poor quality corporate 
or institutional products and services: 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 small institution which visitors said 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 that ... but when given the opportunity
to determine their own fate, in cooperation with others, they love it.

The Breakdown

On reflection, if you want to know where the innovation and
enthusiasm of the first dotcom boom came from, and where it 
disappeared to, then consider these issues:

Universal opportunity

One approach to looking at the engendering of the innovation of
the dotcom boom, was that there is 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. I remember stopping Larry Page on the street,
and I'm sure he remembers this, and I asked him if he thought
the woman I was talking to could 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, that had been cooking inside them for years, 
or who were good at solving problems on their feet, 
the sudden opportunity to not be a 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.

Tools for Cooperation

Table Paper

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, that's not the way the world works at the moment. That
could change, at least in the computer industry, if computer 
people would like it to.

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.

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.

Greg Bryant