The Agile Labour Union
westspacejournal.org.au
westspacejournal.org.au
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... . 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.
That's not my thinking - just my interpretation of the text.
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-... . 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/... , "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.)
> 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.
"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...
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.
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://www.telegraph.co.uk/news/worldnews/1544827/Gangster-w...
http://gizmodo.com/10-incredible-diy-castles-built-by-just-o...
so, in your building example, the project assumes doors will have handles. Decision about the color and shape of door handles is postponed and your wife can have her pick right at the moment the door is ready.
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.
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.
1) It's not always true that users lack insight or imagination into new possibilities. Many of our best futurists aren't technologists - Gene Roddenberry, for example. On the opposite side, programmers can sometimes be resistant to new ideas because they judge the effort to be too high for the benefit. This would be the equivalent something like "If you ask engineers, they'll tell you to buy a faster horse because internal combustion engines are expensive, hard to build and horses are faster anyway (at the beginning they were anyway)." What this misses is that speed isn't the key benefit. If you talked to users, you'd probably discover their needs are lower maintenance costs and improving reliability. Users didn't want to go faster, they wanted to get rid of the horse.
2) UCD is not about asking users to invent new ideas, architect the system or tell us how to implement it (i.e. do you want a horse or an engine?). It's about including the users' perspective in how we assess the benefits and drawbacks of a technology. Engineers tend to want to do this by quantifying aspects of the technical system (megahertz, megapixels, MTBF, softer measures like code quality), excluding a broader perspective of the socio-technical system—the system in a social, human context of use.
3) Developers are often resistant to including the users in the design process because they feel that it impinges on their autonomy, especially when it interferes with their desire to innovate. There's a little bit of... well, hypocrisy is maybe too strong a word, so let's say inconsistency in this. Developers defend their own autonomy and right to direct their own work, and rightly so. But they then argue that it should be taken away (or at least not given) to the users of the technologies they build, technologies which deeply affect the work and lives of those users. As I argue in the article, excluding users has a negative impact on developer autonomy, because UX designers are brought in, reducing and sometimes eliminating developer control, except for the most talented and insightful.
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.
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.
Early factory unions also tried to retain special skills, but automation prevailed... so the union instead went along with the automation, but demanded a greater fraction of the gains from productivity increases.
Agile is adopted because it's a system that works better for some situations. The "deal" is that to get the Agile product, you have to hire Agile programmers, who have a belief that they must work a certain way. Refusing to allow management to control the process is adversarial to management, even if management is happy to go along with it to get the end result.
And speaking of adversarial... what could happen is that UCD will end up being even less adversarial with management than the programmers. After all, they are going to be iterating designs to find the balance between "works for the business" and "works for the user". The programmers will be implementing after all the iteration, and be considered a cost center that can be squeezed for more output for less money.
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.
They will have a conflict if management decides to use those tactics, but there are other ways to increase productivity.
If workers and managers can generally find alignment with, and achieve, the goals of the company, the conflicts are avoided.
- 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.
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.
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.
I've grown tired of photoshop monkeys and UX snake oil salesmen these days. It's not like common sense and designing usability can't be understood by developers of the platforms, especially when the software engineering tools are so close to the design for GUI.
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.
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.
I also recommend reading The Management Myth which is about management theory in general: http://www.theatlantic.com/magazine/archive/2006/06/the-mana...
The wikipedia page on participatory design gives a nice overview: 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
Also, light blue on white is basically unreadable.
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.
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).