3 ms·

I could wax lyrical about Agile all day long. If you google 'Agile Bullshit', a comment I wrote on HN a few years ago is usually in the top three results, and b

I could wax lyrical about Agile all day long. If you google 'Agile Bullshit', a comment I wrote on HN a few years ago is usually in the top three results, and because of that I get an email once a month from someone driven to despair by said 'Agile Bullshit' who feels compelled to get in touch with me and vent a little. I enjoy the emails, and I think they've given me a much broader perspective on agile than my own experience alone could offer. I've been writing an article about Agile for years now, that I can never finish. But here's what I consider to the be the two biggest problems with Agile. 1. Agile can never work in an agency, where the client has control over budgets, deadlines, and features. There is simply no incentive for the client to compromise when your agency has made some pretty ridiculous promises and put themselves on the hook to deliver. 2. There are some teams that deliver well under agile (as per the metrics that the business has defined), and some that don't. In my experience, the ones that deliver well produce the worst work because they won't push back on a design or a feature that's incomplete, nonsensical, or plain impossible. They do what they're told and add no value to the overall output. This is especially true of offshore development teams. The teams that produce the better software do push back, but the Agile process as implemented everywhere on earth does not support them. Instead, animosity grows between the developers who push back, and the product-owners|BA's|designers who can't or wont understand the problems with their own work. But! Some process is better than no process. And I've worked in some companies that take Agile very seriously and are willing to put in the hard work to make it work. And I suppose that' the secret sauce that's missing from most organisations that are "Agile", they think it's a trick, a hack, a cheat, a short cut. It's not. Like everything else worth doing, it's hard work.

misja111 10y ago
Well said. The funny thing about point 1. is that the Agile Manifesto implies already that it could never work: "Customer collaboration over contract negotiation" Nevertheless it doesn't stop many agencies from claiming that their fixed price projects are agile.
jaggederest 10y ago
> Agile can never work in an agency, where the client has control over budgets, deadlines, and features. There is simply no incentive for the client to compromise when your agency has made some pretty ridiculous promises and put themselves on the hook to deliver. There's an interesting triad that I've been talking to people about a lot recently. 1. Authority (the ability to make decisions of importance) 2. Accountability (a way of telling if you are doing better or worse) 3. Responsibility (pride and reward proportional to the results you deliver) Essentially when you lack any of those three, you cannot operate effectively. Without accountability, you have no way of knowing what success is. Without authority, you have no power to recruit help or make the necessary changes to be successful, and without responsibility, no amount of accountability or authority matters. This is especially true in asymmetrical relationships like customer-vendor and employee-employer.
- Chris2048 10y ago
  I'd change the labels a little, since I think those terms are overloaded: I think 'authority' is 'agency', or 'self-determination', 'accountability' is 'direction'/'awareness'/'sensitivity'/'comprehension', 'Responsibility' is actually 'motivation': It also might matter if this is 'pride', or 'avoiding blame', and to what degree it is 'reactive' and 'proactive'. Obviously, knowing what you are responsible for, and having every are have a point of responsibility is important too; 'accountability' seems similar to this to me.
  - tomelders 10y ago
    You just invented Semantic-Agile.
  - jaggederest 10y ago
    I wouldn't change those labels, actually, the responsibility-accountability-authority triad is pretty well known if you google. It's just not familiar to most folks in programming I guess.
flukus 10y ago
I'd go a step further and say that agencies can never work, at least past the small project or website level. The customer is oblivious to the maintenance required for a software project (even if it's just maintaining developer familiarity with the code base) and the agency can only ever get them to pay for features.
seanwilson 10y ago
> 1. Agile can never work in an agency, where the client has control over budgets, deadlines, and features. There is simply no incentive for the client to compromise when your agency has made some pretty ridiculous promises and put themselves on the hook to deliver. Yes, I've worked at places where they'd accept fixed budget and short timescale projects while also preaching about the benefits of agile to the client. This meant there was minimal upfront design and the customer was given a chance to change their mind often. This lead to crunch time and having to make changes that could have easily been predicted if planning had been done from the start. If you suggested the latter advice though, you'd be accused of being a "waterfall" practitioner and ignored so it felt very cargo cult. My view is that projects with short time scales where it's predictable early on what all the functionality should be, you should plan out as much as you can from the start and get the client to OK as much as you can early on (e.g. with mockups, interactive prototypes). Agile is more suitable for larger projects with flexible budgets where there are so many unknowns that planning ahead isn't productive.
chrisan 10y ago
I have definitely lived through #1. I started out at a "web agency for marketing agencies". Most of the time the actual client never knew we existed. Budget and features were set up front and the deadline was immovable as other forms of media would be directing to our apps/webpages starting on a specific date. Despite all of that we called ourselves agile. This amounted to pretending to be agile for 90% of the project and then as the deadline approached just staying up late/working weekends to make sure it was complete and out the door. Naturally it was worse when we had competing deadlines between different projects. And when do different clients ever have deadlines that fit nicely in between other clients? Being at a "product company", it is much easier to be agile about stuff where features and/or deadlines can be shifted
parasubvert 10y ago
For #1, I'd say a dedication to Agile requires significant business commitment on the contractual side to ensuring there basically ARE no commitments beyond the backlog/stories. Needless to say, some clients can't handle this and you need to to turn business away. There are agencies that act this way like Tribalscale or Pivotal Labs, both of which are pretty dedicated XP shops but also with significant design and product capabilities.

misja111 10y ago

Well said. The funny thing about point 1. is that the Agile Manifesto implies already that it could never work: "Customer collaboration over contract negotiation" Nevertheless it doesn't stop many agencies from claiming that their fixed price projects are agile.

jaggederest 10y ago

> Agile can never work in an agency, where the client has control over budgets, deadlines, and features. There is simply no incentive for the client to compromise when your agency has made some pretty ridiculous promises and put themselves on the hook to deliver. There's an interesting triad that I've been talking to people about a lot recently. 1. Authority (the ability to make decisions of importance) 2. Accountability (a way of telling if you are doing better or worse) 3. Responsibility (pride and reward proportional to the results you deliver) Essentially when you lack any of those three, you cannot operate effectively. Without accountability, you have no way of knowing what success is. Without authority, you have no power to recruit help or make the necessary changes to be successful, and without responsibility, no amount of accountability or authority matters. This is especially true in asymmetrical relationships like customer-vendor and employee-employer.

Chris2048 10y ago
I'd change the labels a little, since I think those terms are overloaded: I think 'authority' is 'agency', or 'self-determination', 'accountability' is 'direction'/'awareness'/'sensitivity'/'comprehension', 'Responsibility' is actually 'motivation': It also might matter if this is 'pride', or 'avoiding blame', and to what degree it is 'reactive' and 'proactive'. Obviously, knowing what you are responsible for, and having every are have a point of responsibility is important too; 'accountability' seems similar to this to me.
- tomelders 10y ago
  You just invented Semantic-Agile.
- jaggederest 10y ago
  I wouldn't change those labels, actually, the responsibility-accountability-authority triad is pretty well known if you google. It's just not familiar to most folks in programming I guess.

flukus 10y ago

I'd go a step further and say that agencies can never work, at least past the small project or website level. The customer is oblivious to the maintenance required for a software project (even if it's just maintaining developer familiarity with the code base) and the agency can only ever get them to pay for features.

seanwilson 10y ago

> 1. Agile can never work in an agency, where the client has control over budgets, deadlines, and features. There is simply no incentive for the client to compromise when your agency has made some pretty ridiculous promises and put themselves on the hook to deliver. Yes, I've worked at places where they'd accept fixed budget and short timescale projects while also preaching about the benefits of agile to the client. This meant there was minimal upfront design and the customer was given a chance to change their mind often. This lead to crunch time and having to make changes that could have easily been predicted if planning had been done from the start. If you suggested the latter advice though, you'd be accused of being a "waterfall" practitioner and ignored so it felt very cargo cult. My view is that projects with short time scales where it's predictable early on what all the functionality should be, you should plan out as much as you can from the start and get the client to OK as much as you can early on (e.g. with mockups, interactive prototypes). Agile is more suitable for larger projects with flexible budgets where there are so many unknowns that planning ahead isn't productive.

chrisan 10y ago

I have definitely lived through #1. I started out at a "web agency for marketing agencies". Most of the time the actual client never knew we existed. Budget and features were set up front and the deadline was immovable as other forms of media would be directing to our apps/webpages starting on a specific date. Despite all of that we called ourselves agile. This amounted to pretending to be agile for 90% of the project and then as the deadline approached just staying up late/working weekends to make sure it was complete and out the door. Naturally it was worse when we had competing deadlines between different projects. And when do different clients ever have deadlines that fit nicely in between other clients? Being at a "product company", it is much easier to be agile about stuff where features and/or deadlines can be shifted

parasubvert 10y ago

For #1, I'd say a dedication to Agile requires significant business commitment on the contractual side to ensuring there basically ARE no commitments beyond the backlog/stories. Needless to say, some clients can't handle this and you need to to turn business away. There are agencies that act this way like Tribalscale or Pivotal Labs, both of which are pretty dedicated XP shops but also with significant design and product capabilities.