Working draft

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

As used in modern computer engineering, this family of approaches (I'll
just call it 'scrum' from now on), when reasonably performed by its
own criteria, has 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, but 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. I think the many ways that scrum can be done badly are well-studied,
discussed widely, and part of the process. 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 towards 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 of any given project were important.
And currently, evaluating the real importance of goals is not part of scrum. I'll return to this later.

No, the most important thing about scrum as a movement is that, no matter how badly your
team is externally managed, in the old-fashioned top-down manner, your team can now 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.
Scrum has allowed teams 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'. Our joint power is greater if we work together as
fully-empowered individuals.

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 become
converted to the top-down mindset, occasionally remember that they need to respect 
the active experts, and need to 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 their people.

Because of this collective defense, the emergence of scrum in industrial management may have 
seemed revolutionary. It's true, as 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 re-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 would 
be even MORE effective than self-management alone!

Group 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. Our joint power is not
increased when one member of an organization controls the actions of the others.

So scrum didn't go far enough. We do not yet decide what needs to be built. 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 power delegated to "product owners", etc.

So the effect of that kind of 'self-management' is to keep workers too busy and distracted
to focus 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 and metrics of performance
make it impossible to focus upon the use of technology to further meaningful self-determination
and collective action -- in the public interest -- 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 typically
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.

Some History

When scrum started to become a buzzword in software development, it was more or less in parallel to
the early days of the world wide web -- which needed better working processes to speed iteration
and improvement, as was widely understood at the time. But in this era, I was experimenting
with a larger iterative process, rather publicly, 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 and conductor
along with your collegues. This is sorely lacking in the computer industry. So much so
that it had to be faked, by corporate adoption of unempowered versions 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 they encouraged them to find
a way to self-manage their cell-blocks. As long as they kept following their leaders.

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-directed 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 
was a push for radical democratic decision-making in planning, design, and construction, with an
emphasis on human feeling. By 1996, he'd practiced and studied this for decades.

We had just raised enough 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 their influence, to discover whatever the most important 
thing was that we could achieve in that time. We knew that if we went along with 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 try again to work out the next important thing to do. We did that every
day for three months. And the result was unique, with a potent efffect, 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, focusing on the most important 
things first.

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. As one of the 'innovators', I'd say that's nonsense. But I'll concede that it was one of
the most influential.

My new start-up 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 a block from me, 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 borrow the "good scrum" from my project with Alexander, in this café with many comrades.
We would find 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 were paper tablecloths for us to scribble upon constantly. Different people would join us on
an ad hoc basis.

There was no product owner. Unless one thinks of the 'human race' or the 'public interest' as a product owner. 

Each of us contributed ideas, considered their impact, gave voice to our deepest desires ... it could go on 
for hours, or minutes, while we interacted with onlookers, who came and went, and we absorbed humanity.
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' from the
'company leaders'. Autocracy with autonomy-washing will produce those poor-quality and poorly-considered
corporate or institutional outcomes 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. 
Who knows what the consequences were upon the minds of the onlookers. But our startup grew, and brought in new 
colleagues, who brought with them the destructive habits of the top-down industry. This screwed up our 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 invasion of old-fashioned management had left us terribly vulnerable 
when the dotcom 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. They didn't care how they managed their project imternally. But I and others did not want only 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, people will
love independence. In the feeling of excitment and opportunity in Palo Alto in 1999, 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 a resurrection of managerialism and autocracy. 
Which we're all 'enjoying' today. The revolution was defeated.

The Core

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.

---
---
---
References:

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

Dotcom boom:
My sketches in the café where it happened

---
---
---

Addenda:

Studying the time and place

That spot where I weathered the dotcom boom was pretty special. It was a local pinnacle, an actually 
innovative environment, which Silicon Valley is often touted as having, but rarely has. 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, and improve upon it, we should reflect upon the following observations.

Universal opportunity

There was no "natural entrepreneur" or "entrepreneurial class" that engendered innovation
during the dotcom boom. The demand for workers was so high, and the hierarchy in the computer
industry was so bloated and collapsing in key places, that all kinds of people were recruited
into the role of initiating and organizing. So, really, "anyone could start something" ...
and there was plenty of cash to support them in their endeavor: the very definition of an
empowering environment. This was commonly understood at the time. It was a world turned upside-down.
I was talking to a woman on a sidewalk, about starting her own company. I stopped Larry Page
as he walked by (and I'm sure he remembers this) and asked him: "Why couldn't she be a CEO?" 
He self-deprecated and shrugged "Well, I'm a CEO". People with good ideas and valuable 
experiences -- which might have been cooking inside of them for years, or people who were unsung
but good at solving problems on their feet, were attracted and swept up in 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 their potential.

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, meant as a
disposable tablecloth. So, everyone could take out their pen and scribble ideas and 
contribute to central sketches, lists, etc. That's it. Human minds, discussion, table paper, 
and a café full of people, so you can watch the world go by and chat with it when you 
want another opinion.

This is one of the most important contributions to the finding of a public interest product, 
domain, and population that excites you: visibility into the needs of actual communities of people. 
Theoretical discussions in boardrooms about 'what people need' don't mean much -- you need 
normal people you can talk with, discuss real problems with, and test tech with. A café 
is perfect for that. A company could be, but typically isn't, because most companies are tyrannical; 
they define what you're working on, and they own what you're thinking about.

Any public space, for example an open, public university, is a much better environment.

I must also say that downtown Palo Alto, like San Francisco or Berkeley or any old quarter of
any old city, has qualities that no corporate headquarters or research park can have. Everything
is within walking distance. You bump into hapopy people enough so that you can create a genuine community.
And you are still part of the real world. You meet the public. You are the public. Without the public, 
how can we do things in the public interest? Good work is in the public interest.

And we naturally want to do good work.

Public Interest

Money, fame, and success aren't what is important -- although wouldn't it be nice if we were considered
successful in proportion to the good we do -- but unfortunately that's not the way the 'industry' sees 
things at the moment. That could change, at least in computing, 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 an autocracy, these qualities need to be defined by the group. But, since
people have ideas, but groups do not, the ideas that form a community culture need to come 
from people who are informed and thinking and feeling and have the strength of will 
to ensure they are making good, principled decisions.

That won't happen if decisions are made for them, if other people determine what they do, 
and tell them what they should do.

If you yet don't know what you should do, and how to approach a problem, how can another 
person 'estimate' the time you should be spending on it? What would that mean? 
Why is there such a rush to schedule tasks that are most likely wrong? Is that efficient?

So, putting 'points' on work is obviously harmful. There is no point. If you become good
at these metrics, something must be wrong with either the problems you're tackling or the
invention with which you're solving the problem. You'll end up only scheduling things you know.

Important tasks need to be defined by the individuals and the group. No improvement or pivot 
or innovation, of corporate or institutional strategy or operation or organization, can 
work properly without the consent of empowered individuals. Nothing about us without us.

So, when you fight against 'points', and the product owner (why does this role exist?) 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. The metrics are nonsense for a genuinely
empowered group.

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.

People need to work in a group whose members will celebrate the interesting work you've
done as a result of initiative. You want no surprises? Really? Not even good ones?

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 colleagues. But that's different than looking for 
"support from management". That's our behavior in a tyranny. It's a microsupplication
that disempowers everyone. 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 principles.

Without free application of good principles, for any aspect of the project, don't expect 
genuine innovation to emerge 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 sensitivity to people, and to the world around you. Inside of an 
institution, the more conformist the culture, the less likely you'll
have a diverse enough set of ideas to act as grist for identifying
real-world issues that need technological support.

We also need a developing sense of what's important. One should really avoid
trivial improvements. Systemic, fundamental, recurring problems are the 
ones that people need us to address. Otherwise, consider: you may be polishing 
and calcifying an automation of somebody else's exploitation.

But you also need the freedom to experiment, given this diverse environment. 
UNIX and the Software Tools movement grew out of sufficient freedom, somewhat under
the table, within Bell Labs at the time, to pursue better ideas. Yes, a license 
headache ultimately ensued, but that was fixed by free versions of the software. 
But if Bell Labs had a culture that completely avoided risk and new ideas, 
the application of theory to computing practice would've been set back 20 years. 

Stuck in your own social engineering

When you have an important goal, go ahead and have it. You don't need to stick
to your agreements in all circumstances. If you have some kind of scientific 
management mechanism, it gets continually harder to maintain your attention to
your humanity above and beyond the mechanisms you've agreed to use. They stop 
you from being human just that much more. It make you that much LESS agile, 
that much less inventive, that much less cooperative with your colleagues,
and that much less capable of seeing or doing what's important.

As an example ...

Pulling multiple stories is not necessarily multitasking

The biggest problem with the marketing of agile and scrum, is the 
tacit assumptions of top-down management and the cult of efficiency and 
productivity. It interferres with changes every discussion, reducing 
many to nonsense. 

So, everyone agrees that a certain kind of 'multitasking' is silly and 
ineffective. But, that's the kind of multitasking we mean. Others kinds 
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. 'The 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 interconnected, 
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. 
But it shouldn't be acceptable, 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.

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 group habits, when they don't 
apply, or when they are being used to enforce a top-down distracting 
complexity.

What we do with computers, and how we do what we do, is simply not understood.
How the brain works is not understood. We have only hints, and feelings.

If someone claims to understand these things, 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 build around a system, 
the harder it is to escape from.

The promotion of autonomy and cooperation needs to be the primary goal of scrum. 
If it isn't, then you're using a bad system that simply makes subservience and 
supplication tolerable.

The poverty of centralized decision-making

In a tyrannical system dominated by monopoly capital, the computer industry has,
at moments, been shaken up by circumstances, empowering the crowd to look for
opportunities to work in new ways.

Unfortunately, they often settle into the same old dynamics: looking for their
'leaders', their 'managers', their 'architects'. Occasionally, they may have
dreamed about a more equitable society, but their habits, beliefs, and professional
expertise often fit into a certain centralized model of decision-making. Nothing
else is even tried. They don't even know how to advocate for democracy in the
workplace; they exaggerate the importance of every just-so story and anecdote to 
avoid experimenting with it.

Everyone should know the big picture of the work they do, not just the PR. They 
need to be able to explain it, so they know where and how they can share their 
expertise and local knowledge -- which 'leaders' are invariably ignorant of -- 
so it can improve the organization. This is also the only way they can do their 
work properly, because they need to design and implement their work in a way 
that it contributes to the whole. 

If they don't know the whole, how can they do that?

Every organization you're part of should have a business dashboard for everyone,
with the same information the executives get. After that, we can get rid of the 
executives, and replace them instead with people whose job is to interface with 
the outside world, occasionally empowered to talk about possibilities that would 
need to be approved by the community. This is very easy to facilitate with computer 
interfaces. But, because of entrenched power, these applications are never built.

We have not yet begun the experiment of democracy-at-work in our industry. The small
organizations and sub-units of large organizations -- which are often semi-democratic 
by necessity but the executives don't know it -- offer only a glimpse of the
possibilities of community-driven decision-making.

Instead, we have an industry of consultants and commentators who write books that
might as well be entitled "better habits for autocrats", and hosting seminars that
could be called "24 ways to optimize your technocracy".

We need to pull away from this managerialist, militarist 'great man' view of progress
and 'great captain' view of institutional maintenance, and pull people back into
the collective effort to operate things properly. The current approach is destroying
everything.

The poverty of the whole system

"The establishment" we live in is an imperialist, militarist, extractive capitalism
that pervades every impersonal transaction we're party to. When we get together and
work or play, we are cooperating to entertain ourselves. When we plop down in front
of corporate entertainment, or the infotainment they call news, we are not creating
anything. And that is the nature of extractive imperialism: it drains and destroys
life everywhere. The normal community work that provides food or tools for people
has been destroyed in favor of a weaker, more fragile, more destructive form of
industrial agriculture -- so destructive that a PR campaign to call it the 'green
revolution', the first modern greenwashing, needed to be conducted in order to make
people ignore the starvation and poverty it brought.

That's the system that wants you to believe that it knows what's best. It's the system
that might allow you to work without immediate supervision, but it won't let you decide
what's important to work on. The executives and administrators of the system always 
make the wrong decision from the public-interest point-of-view, and the right decision
from a stay in power and stand on everyone's neck point0-of-view.

This is the system that needs to be turned upside-down, but not in such a way that it's
just going to reconstruct in a different form after the revolution. This time, everyone
needs to know exactly what they're doing. I know, 'good luck with that'. But we have to
find ways to make it possible to run everything with joy and cooperation. That would be
real innovation.