
The Agile Labour Union - rmcna
http://westspacejournal.org.au/article/summer-2013/the-agile-union/
======
dalke
I couldn't make heads or tails of it. There's an interesting point about Lean
development coupled to Taylorism, but I saw no ties with how agile is tied to
unionization.

The article says: [Agile] does this by limiting the number of working hours,
demanding autonomy and self-management, rejecting the arbitrary dominating
power of the boss, preventing their jobs from being shipped overseas, and
ensuring that software engineers are involved in their workplace as decision
makers.

1) "limited working hours" \- the essay quotes Beck on prohibiting more than
40 hours of work per week, and says of crunch time that "Agile methodologies
rightly reject this as inhumane and unsustainable." However, waterfall
methodology _also_ rejects this as unsustainable. The reference I have is for
Jones 1991, which says that Voluntary Overtime is effective up to about 44
hours per week, and beyond that effectiveness is likely to get worse.

So, you're doing agile. Your boss wants mandatory overtime, with 50 hour weeks
for the next 3 months, in order to beat some deadline promised to the board.
In a union, you talk with your union rep (who may have been involved in your
contract), and present a united front against the arbitrary and fundamentally
poor decision.

In an agile shop you ... point to a book which says that 40 hours is enough?
Then when your boss points out that the industry average is 48-50 hours, you
say ... ? And you are effective because ... ?

2) "rejecting the arbitrary dominating power of the boss"

I didn't see where that was really developed, other than some specifically
project related decisions. Can agile prevent the boss from firing an employee
any more than waterfall can do so? Can agile fight towards getting the salary
increase you were promised for working 60 hour weeks, but never got? Not that
I'm aware of.

While unionization is supposed to offer that sort of protection, agile only
rejects certain limited forms of boss power.

3) "preventing their jobs from being shipped overseas"

The point here is that outsourcing can't happen with a methodology which
requires co-location with the customer. "The forth and fifth principles
mandate co-location of the engineering team and daily interaction with
business people" where from the Agile Manifesto: "4) The most efficient and
effective method of conveying information to and within a development team is
face-to-face conversation. 5) Business people and developers must work
together daily throughout the project."

Except that those principles don't require on-site work, only say that on-site
is the "most efficient and effective method." There are any number of web page
which talk about "distributed agile", for example.

For example, here's a page talking about how to build an agile off-shore
[http://www.agilebuddha.com/agile/distributed-agile10-good-
pr...](http://www.agilebuddha.com/agile/distributed-agile10-good-practices-of-
successful-teams/) . It argues that frequent travel for in-person contacts is
essential, and still requires daily meetings, only through videoconferences
and other means.

While agile would say this not as effective, it doesn't reject this outright,
so it cannot be anti-offshoring.

~~~
wildgift
Loomio's comment gets the gist of it. The software creation process has been
moving to Agile, which beats waterfall, but there's an emerging practice of
UCD. If programmers cannot find some way to work with and within UCD, a
division of labor between designing the product with the end user, and writing
the code to implement it will develop. This will lead to declines in
programmer autonomy, and will demand changes to Agile. The seed for this
change is already planted within Agile by people advocating for Taylorism.

That's not my thinking - just my interpretation of the text.

~~~
dalke
Thanks for highlighting that. I at first found the UCD reference even less
understandable than the starting thesis comparing agile to unionism.

I agree, btw, with the assessment that Agile is "naïve in assuming that a new
system’s customer ... can adequately represent the goals." Agile seems
designed for the admittedly large number of in-house development efforts,
where end-user and paying customer are very similar. It does not have anything
like persona development from UCD. Indeed, I am annoyed with agile's papering
over of the term "customer."

I agree too that software development methodologies have not, in general, been
influenced much by UCD. I say from reading in 1990s the ideas promoted by
Raskin, Cooper, Norman, Nielsen, and Tognazzini, and watching the jump and
seemingly rapid decline in interaction design over the last 10 years. Based on
that, I don't see UCD as having emerged any more now than it was 10 years ago.

But since I don't see Agile as a sort of unionization which separates
programmers vs. non-programmers (with Waterfall the stand-in for Taylorism),
then the rest of the comparison doesn't hold together. It feels more like
someone who doesn't know what unionization does.

Focusing on the idea that early Agile is a non-Taylorism style, I recall that
even early on, CRC cards were associated with an "IdealTime." People wanted to
turn that into real time, and determined the load factor through XpVelocity.
According to Fowler though, StoryPoints (or StoryCounting) are "easier to
calculate, less likely to be abused, and every bit as accurate."

Quoting c2.com: "Because C3 measures estimated and used IdealProgrammingTime,
as well as elapsed time, I believe that it does have something to do with how
many minutes per day are spent developing on the task. While I may be in
disagreement with Kent on that, I'm not in disagreement on the utility of
what's below. --RonJeffries"; C3 being the project which heavily influenced
early Agile.

Thus, I think time estimate and measurement has _always_ been a part of Agile.

The author made a reference to "Alternatives to Lean Production: Work
Organization in the Swedish Auto Industry". I was curious about that, since I
live in Sweden, and Saab's nearly empty car factories lie on the other side of
town.

That book was written in 1992, which is just a few years before the start of
Saab's gradual decline. Volvo no longer has a plant in Kalmar, nor in
Uddevalla, though they are still strong elsewhere. Searching now, there was a
2012 symposium titled "What have we learnt from Volvo Uddevalla?"
[http://ilpc2012stockholm.wordpress.com/2012/03/25/symposium-...](http://ilpc2012stockholm.wordpress.com/2012/03/25/symposium-
what-have-we-learnt-from-volvo-uddevalla/) . It says:

> Reflective Production, implemented by Volvo in its Uddevalla plant ... [was]
> renounced [in the 1990s]. But some aspects of reflective production were
> adopted by other companies, especially in Japan.

> Do we know better today the reasons for the development and subsequent
> abandonment of Reflective Production? ... Are they specific to the Swedish
> context or is it possible to find them elsewhere?

It's interesting then that while the author proposes that non-lean methods are
possible, and quotes from that source, that non-lean method was abandoned.
Perhaps the alternative approach is actually worse than lean?

FWIW, the author of that 1992 book, in [http://www.akesandberg.se/wp-
content/uploads/downloads/2010/...](http://www.akesandberg.se/wp-
content/uploads/downloads/2010/05/Enriching-Production_Ake-SANDBERG-
ed.-1995-2007.pdf) , "criticizes Volvo’s official justification of the closure
and demonstrates the weaknesses of its calculation of cost savings", by
comparing the Kalmar plant to the lean approach in the Gothenburg plant.

Moreover, the quote from Alistair Cockburn takes place at the Scandinavia
Developer Conference, which is in Gothenburg, the home of Volvo. You would
think that if Reflective Production were still influential then people there
would know about it.

(Hmm, I should ask about it next time I'm in Gothenburg to talk with software
people.)

------
loomio
This quote summed it up for me:

> Agile processes are optimised for constructing technical systems conceived
> and built by programmers, but poorly suited to building socio-technical
> systems that seek an integration between humans and technology—a model that
> requires software engineers to embrace a wider range of disciplines and
> skills as equals, and adopt a more comprehensive vision of what it means to
> successfully build software. Failing to make this transition is very likely
> a death sentence for the Agile movement.

~~~
discreteevent
Reminds me of:

"Instead, the technical talent goes to work on elaborate frameworks, trying to
solve domain problems with technology. Learning about and modelling the domain
is left to others. Complexity in the heart of software has to be tackled head
on. To do otherwise is to risk irrelevance."

\- From Domain Driven Design by Eric Evans.

Also in the original article is this:

"Except for the most senior software engineers, most of the creativity and
innovation in software will move to specialised design and research activities
using techniques that exceed the reductionist thinking that dominates computer
science departments."

I think that part of the problem is that we need very few real computer
scientists (but they are needed). However most people who want to build
software are trained as computer scientists. The people who train them
naturally teach them to value things that are useful to computer science
research but this can cause them to be limited when it comes to solving real
world domain problems holistically.

Or as patio11 says "Don't call yourself a programmer"
[http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-
pro...](http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/)

------
asgard1024
I am not sure if this falls into Agile or not (proponents seem to differ), but
I don't think you can build a house just driven by customer requirements and
_their_ priorities.

Imagine, how it would look like:

\- "Well, my number one priority is to have a shelter from elements.." OK, so
we build the roof first.

\- "OK, now I would also like to stand in there." Uh, then, lift up the roof
and build some walls around it.

\- "How do I get in? The trapdoor in the roof is too high now, I know there is
a ladder, but.." Let's make some door, then.

\- "Right, but the floor inside is a bit dirty. Can you do something about
that?" Sure, let's put some concrete inside.

Etc.

The reason why you can do something like this in programming is a) it's
abstract, there is no extra cost for changing things, b) you do as much as
possible modularly (OOP, FP, TDD...) anyway. But I can't really imagine any
other engineering project without (at least a bit of) waterfall.

~~~
ljf
[http://brainslink.com/2010/12/be-agile-build-a-house-
iterati...](http://brainslink.com/2010/12/be-agile-build-a-house-iteratively/)

Not that I agree that the linked process would be a good process for building
the average house - Agile is only more efficient if there is a high risk of
requirements changing or of being unknown. I (think) many people have a fairly
set idea of what they want from a house, and have a finite amount of funding
for it, where a functioning roof, but missing walls would be a major problem
:)

That said I think these fit the bill for agile buildings:

[http://en.wikipedia.org/wiki/Sutyagin_House](http://en.wikipedia.org/wiki/Sutyagin_House)
[http://www.telegraph.co.uk/news/worldnews/1544827/Gangster-w...](http://www.telegraph.co.uk/news/worldnews/1544827/Gangster-
who-built-worlds-tallest-log-cabin.html)

[http://gizmodo.com/10-incredible-diy-castles-built-by-
just-o...](http://gizmodo.com/10-incredible-diy-castles-built-by-just-one-
single-pers-1452608410)

------
oceanplexian
This article is all over the place...

They cite the transition to a service-based economy a good match for Agile
(Which is a problem in itself). Unfortunately we don't live in that utopian
vision. For example, it would be quite unreasonable for a contractor to change
the design of a home in iterative cycles.

Agile is not a union. It just optimizes management in a specific direction at
the expense of others.

~~~
wildgift
The article says that Agile was a way to get what amounts to a contract of
work rules, without the labor unions.

------
tunesmith
Zooming out, how does UCD protect against the basic risk of paying too much
attention to the customers/users? It's like the old story of Henry Ford saying
if he had asked his customers what they wanted, they would have said faster
horses. It's the programmers/technologists that often have the insight of
knowing what the customers _would_ want if they knew they could have it.

~~~
rjknight
I think this is a very good point, and I think it suggests a resolution to the
"antagonism" between developers and UCD practitioners suggested in the OP.

In designing a system, the developers are the ones with the best grasp of what
is _possible_ , in both the positive ("here's a new way of solving this old
problem") and negative ("that solution would not work because of _X_ ")
senses. If the UCD practitioner is a true specialist, they will by necessity
be unaware of the implementation details and even system architecture, which
might cause them to either fail to spot a potential improvement or to suggest
features which have poor cost-benefit ratios (even if the benefit is
positive).

UCD practitioners don't just ask the users "what do you want?" (I'm a
developer but I have done some user research as part of UCD projects). They
ask "what are your problems?" or "what are your needs?", and then create mock-
up solutions which address those needs, which are then validated with the
customer (think "lean startup", if it helps). It's not that different from
traditional agile, except instead of "the customer" you now have "the
customers" and you do a lot of your early-stage iterating in wireframes and
mock-ups.

This does create risks, of course. The UCD practitioner might propose designs
that are unnecessarily difficult to deliver - yes, "the customer is always
right", but the customer doesn't always want to pay enough to get what they're
asking for, and it's the developers who will evaluate how much the designs are
going to cost to implement. Or the UCDer might over-specify things, mapping
out several months worth of development in wireframes that might imply major
back-end work, with all of the waterfall delivery problems that entails -
supposing that the back-end work takes longer than expected, would the
customer prefer to cut some features or deliver later? If so, which ones? If
the design reaches the developers as a single, cohesive package that cannot be
broken down, we're back in waterfall-land and that's no good for anyone.

To my mind, this can be resolved within the classic agile framework of cross-
functional teams. User research should be a function of the team, and the
decisions about what solutions to propose to the users should be team
decisions. The designer should not be proposing work that will be carried out
by the developers without consulting them first, and the developers should
play an active role in suggesting features and solutions - offering their
knowledge of what's technically possible to inform the designs. This keeps the
design process grounded in technical reality but also allows for the designer
to challenge the developers to come up with a way of achieving something that
customers want.

------
marcus_holmes
Well I loved it. I thought it covered a lot of interesting ground using the
Agile == Union analogy.

There's some points I disagree with (UCD designers are not managers, so
allowing them to design a system is not reverting to management control, and
it seems to me the easiest solution to the proposed quandary is to consider
UCD as part of the engineering process and the designers as part of the
engineering team). But on the whole it says interesting things about the
function of Agile in our workplaces.

~~~
fennecfoxen
I'm uncertain to what extent I can agree that agile and labor unions are
similar. They have some superficial features in common, but I think the
fundamental structure is radically different:

1\. A unionized factory worker performs the same sequence of operations over
and over to achieve a standardized type of output. An agile software developer
is generally combining operations in new ways: if it's the same thing over and
over again, your developer is not very good at figuring out how to reuse code.

2\. The nature of the employer relationship is different, at least in today's
economy. A typical software engineer is reasonably hard to replace and can
apply skills at a variety of alternative employers. The best case for a labor
union is when the opposite is true.

3\. I think the causal relationship is reversed. The reason that agile is
adopted is not to protect programmers from off-shoring or long hours (typical
union pitches). It is adopted because the firm is willing to believe that the
co-located team with decent hours is a better deal. The union/management
relationship may be starkly adversarial; the agile-team/management
relationship far less so.

So if there's a UCD fad going around, I don't see it as capable of disrupting
the "agile" ecosystem's employees' lifestyle the same way that some new
process or external shock could disrupt a unionized manufacturing ecosystem's
employees -- not unless it really fundamentally changes how a coherent piece
of software ends up finding itself structured, and a couple of wireframes and
the like aren't going to do that.

~~~
marcus_holmes
1\. I think you have a strange idea of what unions are and do.

2\. ditto. The 'best case' for a labor union is that their members are highly
skilled and hard to replace, with lots of alternative employers.

3\. The article clearly states that Agile is not implemented in order to
protect developers, but the net effect is the same. Agile team/management
relationships cannot be adversarial because Agile.

The point the article makes is that UCD separates the design of the system
(the bit that needs management and user contact) from the implementation,
which then allows the implementation (as wildgift points out) to be considered
a cost and Taylorised (squeezed) into 'efficient' permanent crunch time.

~~~
fennecfoxen
Ah. My ideas of labor unions presented here are in fact strange, because they
have been narrowed (for the purposes of this discussion) to the perspective of
"the union exists to protect your interests against rampant Taylorism imposed
from the management, in the same way that Agile is posited in The Article to
protect programmers from something analogous." While labor unions' members may
in fact be best off under a scenario such as you describe in yourpost#2,
that's not a grand example of a case where you can say "we need a labor union
to protect our interests from management or our lives will be made miserable
by exploitation" and seems not to relate to the issues raised by the article.

------
cateye
I need to create a autohotkey or something to insert this everywhere where I
see a comparison between Agile and Waterfall:

\- This content contains a false dichotomy between Agile and Waterfall, used
as an argument to justify Agile. Every healthy person can imagine that
iterations are often needed and sometimes even inevitable. In the real world,
there isn't a situation with a sharp distinction between projects that
prohibit iterations and projects that have iterations in all phases.
Iterations are not invented in 2001 by a couple of guys thinking up a
manifesto.

The term Waterfall is an imaginary enemy (maybe once used with good intentions
to make a point clear) and Agile isn't a solution for all (software project)
world problems. In the years before the "Agile enlightenment" successful
products are built with or without iterations.

------
lhnz
So, according to this, User-Centred Design (UCD) is going to decrease the
status of software engineers and make their working conditions closer to that
of blue-collar workers by completely separating conception from execution.

I guess designers will be able to do user research and rapid prototyping with
tools that are provided to them and then once they have a good product it will
be passed to an implementation team to get implemented? Obviously once that's
done it's released to the customer and there will be no need to ever change
the design because by this point it is infallible.

One of the issues I can see here is that the design prototype will need to be
kept in sync with the implementation, and designers will have to rely on
prototypes being an accurate prediction of user's behaviour.

I do think the "interesting/creative work" baseline will probably get worse
for many software engineers but I hope this takes 50+ years. I guess
creativity and innovation is a scary thing for people and it's probably only a
matter of time before the bean counters try to optimise/regulate and
ultimately squash it. (And I believe they will for the non-creative have very
little clue on where ideas come from and will squeeze until the golden goose
stops producing eggs.)

When/if this happens I don't plan to be working. It would be unbearable to do
non-creative work. I'd exit somewhere that I could keep my dignity and write
poetry or programming for people that I met without the meddling of inward-
facing fools.

~~~
wildgift
It's warning that UCD is going in that direction - and that management is
going to use UCD to marginalize programmers. It doesn't have to be that way,
though, if Agile is willing to get in and work with UCD to develop disciplines
that work for both designers and programmers.

I think one place this might happen is the issue of speed. All new programs
are pretty slow, but they get sped up with "optimization" (LOL - more like
caching and clever laziness tricks.) Evaluating speed needs during the design
process brings programming into the design process a lot sooner, opening
channels of communication that can reach to the user.

------
pegas1
Have you ever seen unions concerned in improving work results, quality of the
product and productivity? Accepting Even if workers conditions that could be
more demanding?

the contrast is much more apparent than the analogy.

I worked in waterfall shops long enough to know that those were like unionized
jobs where you could fair better by producing more code lines by copy/paste
than by thinking. And the worst programmers moved the ladder to better paid
non-programming "analyst" or "architect" jobs faster, not wasting their time
on code details.

~~~
wildgift
There's that saying, you can have it done right, fast, and cheap... pick any
two. Generally the construction unions go for right and fast, not cheap.
Often, they won't even do fast, mainly because speed and safety are often at
odds with each other.

Of course, the meaning of cheap here is different. Cheap in the general market
is $10 an hour, and union is $15. Qualified is around $20 to $30 an hour for
the more common things, and a lot more for exotic skills like building
bridges.

The logic is simple, though. Because construction unions aren't involved in
producing product, they aren't interested in increasing speed and
productivity. What they can increase is skills and quality and safety. So
construction unions own training centers - gigantic warehouses and lots with
classrooms and vocational education facilities. They force their members to
get training.

In industrial unions in factories, the dynamic is different. Everything is
based on the assembly line, so it's a different situation, and the unions have
different strategies centered around that.

Likewise, trucker unions and other unions in the supply chain are increasingly
strategizing around the supply chain.

I think you mischaracterize the waterfall shops. What waterfall did wasn't
create union-like conditions. Waterfall rationalized the software production
process, and created a kind of "factory" for software. The union-like behavior
you notice is really factory behavior; when people in a factory resist
management, even individually, it'll end up looking like a factory union's
resistance.

When a union in a factory decides to do a "slow down" or "work to rule", it's
resisting by putting pressure on the factory's workflow.

Unions operating in other sectors have different strategies. In the service
sector, they use public campaigns to gain sympathy in the community. Teacher
unions tend to use the political process (being a public sector that is
popular with the electorate).

Agile's strategy was to improve quality, and give the programmer more
autonomy. A side effect of autonomy (and TDD) is to allow the programmers to
leverage productivity gains of new libraries and even new languages.

We don't associate what agile did with unionization, but that's largely
because the craft-guild style union is moribund. It hasn't really revived and
adapted for the age of data and software. That said, there are things like
FOSS, GNU/FSF, Creative Commons and other organizations that operate in the
space. The PC revolution, and then desktop publishing, and the internet, and
now 3d printing and open hardware have all created a kind of "labor movement"
of individual workers. It just lacks a political voice and a labor strategy.

------
rjknight
I found this article to be very interesting. Does anyone have any pointers to
similar writing about organisational politics in relation to agile
development, lean or UCD?

~~~
mrxd
Author of the article here. On Lean, I'd recommend a book called "Notes from
Toyota-Land: An American Engineer in Japan" that is in part about the dark
side of Lean and its impact on workers. Or just read an interview with the
author:
[http://www.gembapantarei.com/2006/05/interview_with_darius_m...](http://www.gembapantarei.com/2006/05/interview_with_darius_mehri_author_of_notes_from_toyotaland.html)

I also recommend reading The Management Myth which is about management theory
in general: [http://www.theatlantic.com/magazine/archive/2006/06/the-
mana...](http://www.theatlantic.com/magazine/archive/2006/06/the-management-
myth/304883/?single_page=true)

The wikipedia page on participatory design gives a nice overview:
[http://en.wikipedia.org/wiki/Participatory_design](http://en.wikipedia.org/wiki/Participatory_design)

Unfortunately most of the work in these areas is highly academic and assumes a
lot of background knowledge. I thought this article on participatory design
was quite good, but again, it's an academic paper:
[http://peterasaro.org/writing/Asaro%20PD.pdf](http://peterasaro.org/writing/Asaro%20PD.pdf)

------
Aloha
Agile seems to drive longer working hours. Instead of a big release 4 times a
year, its lots of short very intense sprints.

Also, light blue on white is basically unreadable.

~~~
ljf
The intense sprints should only include the work that the team believes they
can complete (and commit to completing) within the sprint period.

So the team shouldn't end up having to work extended hours due to Agile - if
they are then either they are estimating incorrectly, or are being
forced/asked to estimate incorrectly.

------
dreamfactory
The article seems quite confusing on a number of fronts.

Architects of buildings don't actually use waterfall for a start - they
continually adapt and improvise (in response to things like variable materials
supply, soil conditions, weather, unexpected archeological finds etc.)

The UCD practitioner as outlined here is a type of, or proxy for, a product
manager, which would fit in very well with any agile process.

The insight about unionisation is interesting, but the fact that agile turns
out to share some subset of traits with unions doesn't really say much about
agile - as nobody designed agile as a form of unionisation by the backdoor. It
could be entirely coincidental and irrelevant or it might reveal something
about aspects of unions being an emergent property of labour. (We certainly
see unions appear across many industries in most nations.)

The point about lean and agile seems misconceived to me. Agile is essentially
about preserving your options for change by reducing batch sizes and thereby
improving flow of business value delivered. Scrum is just one form of agile,
which reduces the epic cycles of waterfall from 6+ months to 1-4 weeks. More
lean-focussed approaches like Kanban just take that further to a granularity
of individual features. In fact you will have much more measuring and chartism
under Scrum. A major lean argument is that optimal program velocity is
achieved by continuous flow, even where it means that some individual items
move at a slower pace - much like traffic control. This is precisely not an
inhumane 'whip the horses harder' PM approach. It is also easier to visualise
without needing to constantly measure an refine - bottlenecks should be self-
evident from a kanban board for example.

Design thinking isn't something I'd say was at odds with agile at all, but in
my experience is considered part of the wider movement away from 'throw over
the wall' approaches (along with devops and lean UX). It's fundamental to lean
startup for example.

And Taylorism is misapplied by many people to software development. In one way
you can comfortably separate conception from execution with software. You
could call them design and production line. The commonly made mistake is to
think of coding as a production line activity rather than one of design. In
fact the process of software development is one of automation generally - just
as a high level of standardisation allows you to have robots building cars, a
high level of software design allows you to automate execution. Where you have
shoddy design, you end up with an inefficient process with humans doing
production line work - that's a failure of industrialisation and Taylorism,
not an example of it. This is in fact why software projects that attempt to
separate design from technical implementation always run into huge problems.
The technical implementation isn't a separate thing but is the actual design
(and UCD here is closer to discovering the goals than defining
implementation).

