5 ms·

The Agile Labour Union

39 points by rmcna 13y ago

loomio 13y ago
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 13y ago
  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-programmer/ http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...
lhnz 13y ago
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 13y ago
  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.
- seivan 13y ago
  I prefer designers who are engineers on that specific platform. Instead if you're working on user interface alone, you better be damn sure to code that implementation of the interface you designed. 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.
oceanplexian 13y ago
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 13y ago
  The article says that Agile was a way to get what amounts to a contract of work rules, without the labor unions.
dalke 13y ago
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-practices-of-successful-teams/ 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.
marcus_holmes 13y ago
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 13y ago
  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.
  - wildgift 13y ago
    Not all unions are for factory workers. We all have to get beyond that stereotype. There are unions for journalists, social workers, teacher, police officers, college instructors, and nurses. What the union represents in these fields is generally resistance to becoming "factory workers", or more specifically easily replaced workers. 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.
pegas1 13y ago
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 13y ago
  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.
tunesmith 13y ago
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 13y ago
  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.
Aloha 13y ago
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 13y ago
  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.
cateye 13y ago
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.
rjknight 13y ago
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?
- rmcna 13y ago
  You might try the personal site of the author of this piece, Mike Bulajewski: http://www.mrteacup.org/ http://www.mrteacup.org/
- mrxd 13y ago
  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_mehri_author_of_notes_from_toyotaland.html http://www.gembapantarei.com/2006/05/interview_with_darius_m... I also recommend reading The Management Myth which is about management theory in general: http://www.theatlantic.com/magazine/archive/2006/06/the-management-myth/304883/?single_page=true 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 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
asgard1024 13y ago
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 13y ago
  http://brainslink.com/2010/12/be-agile-build-a-house-iteratively/ http://brainslink.com/2010/12/be-agile-build-a-house-iterati... 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-who-built-worlds-tallest-log-cabin.html http://www.telegraph.co.uk/news/worldnews/1544827/Gangster-w... http://gizmodo.com/10-incredible-diy-castles-built-by-just-one-single-pers-1452608410 http://gizmodo.com/10-incredible-diy-castles-built-by-just-o...
- pegas1 13y ago
  Agile is not about letting the customer to run the development process. It is about continuous communication with the customer to hammer on details and for better understanding of the subject domain. 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.
dreamfactory 13y ago
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).

39 points by rmcna 13y ago

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 13y ago
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-programmer/ http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...

lhnz 13y ago

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 13y ago
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.
seivan 13y ago
I prefer designers who are engineers on that specific platform. Instead if you're working on user interface alone, you better be damn sure to code that implementation of the interface you designed. 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.

oceanplexian 13y ago

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 13y ago
The article says that Agile was a way to get what amounts to a contract of work rules, without the labor unions.

dalke 13y ago

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-practices-of-successful-teams/ 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.

marcus_holmes 13y ago

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 13y ago
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.
- wildgift 13y ago
  Not all unions are for factory workers. We all have to get beyond that stereotype. There are unions for journalists, social workers, teacher, police officers, college instructors, and nurses. What the union represents in these fields is generally resistance to becoming "factory workers", or more specifically easily replaced workers. 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.

pegas1 13y ago

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 13y ago
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.

tunesmith 13y ago

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 13y ago
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.

Aloha 13y ago

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 13y ago
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.

cateye 13y ago

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.

rjknight 13y ago

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?

rmcna 13y ago
You might try the personal site of the author of this piece, Mike Bulajewski: http://www.mrteacup.org/ http://www.mrteacup.org/
mrxd 13y ago
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_mehri_author_of_notes_from_toyotaland.html http://www.gembapantarei.com/2006/05/interview_with_darius_m... I also recommend reading The Management Myth which is about management theory in general: http://www.theatlantic.com/magazine/archive/2006/06/the-management-myth/304883/?single_page=true 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 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

asgard1024 13y ago

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 13y ago
http://brainslink.com/2010/12/be-agile-build-a-house-iteratively/ http://brainslink.com/2010/12/be-agile-build-a-house-iterati... 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-who-built-worlds-tallest-log-cabin.html http://www.telegraph.co.uk/news/worldnews/1544827/Gangster-w... http://gizmodo.com/10-incredible-diy-castles-built-by-just-one-single-pers-1452608410 http://gizmodo.com/10-incredible-diy-castles-built-by-just-o...
pegas1 13y ago
Agile is not about letting the customer to run the development process. It is about continuous communication with the customer to hammer on details and for better understanding of the subject domain. 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.

dreamfactory 13y ago

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