11 ms·

Cargo Cult Agile (2008)

111 points by ekzy 10y ago

zer0tonin 10y ago
I should explain that to my boss, we're literally doing waterfall but with standup meetings...
- techterrier 10y ago
  "wagile"
- flukus 10y ago
  "Agile waterfall" may be a meme but I have seen job listings use that exact term to describe the company. Out of everywhere I've ever interviewed though, no company that has described themselves as Agile have been remotely Agile, ones that don't spend so much time thinking about process generally are Agile to a degree.
- adrianmsmith 10y ago
  Great stuff. I asked one Agile coach about how and when one should do software architecture decisions for a larger project, he said you can take an extra sprint/spike at the start to do software architecture if necessary. At another place, the testing members of the team always tested the previous sprint's work (otherwise they'd be doing nothing for the first 80% of the sprint, if they tested that sprint's software). So if you had a requirements sprint, a software architecture sprint, a development sprint, then that gets tested on the next sprint, what process does that remind you of? :)
  - Sharlin 10y ago
    That is still iteration. Agile doesn't say you can't do things in phases, it just says those phases need to be short enough that you can iterate on them.
    - valuearb 10y ago
      Yea but how done is your sprint if your work isn't tested? It's the old, "done" vs. "done done" debates we had end of every sprint. I wrote the code, it mostly works, it has bugs. Am I done? Should I move on? Technical debt creeping higher and higher.
    - adrianmsmith 10y ago
      Agile does say the results of sprints should be something the customer can understand and use: a software architecture document, or untested code from the development sprint, isn't that.
- liamt 10y ago
  I've been there. Now we do scrum and do standup meetings but it's a lot less strict. Most of the team talks constantly anyway as we're all in the same room. Our old boss is long gone.
- overgard 10y ago
  Is waterfall even a thing? I feel like the software industry is constantly coming up with solutions to cultural problems that were more relevant in 1977 than 2017 Ive worked at places that werent "agile" and it wasnt the strawman experience of waterfall.. it was just people doing work. They just didnt make a big deal about squeezing everything in a two week window and avoided uncomfortable/useless planning and retrospective meetings.
flukus 10y ago
I'd argue stand up meetings are the opposite of agile, the insistence on them is literally breaking the first rule of the agile manifesto: > Individuals and interactions over processes and tools Probably breaking the fourth too: > Responding to change over following a plan How many companies have done a retrospective on whether the daily recitation of Kanban board movements is providing any value?
- jwdunne 10y ago
  To me, a lot of Agile breaks the first rule. A Certified SCRUM Master comes in and overhauls your processes. That is, in effect, processes and tools straight up, from the minute that scrum master goes on a course. It wouldn't be much of a course if it didn't teach some process for implementing SCRUM. It wouldn't be much of a consultation if the consultant tells you to go speak to your customers and find out what is really bothering them and how you can deliver working software quickly to alleviate that. So you have daily standup a, weekly retrospectives, a designated master, product owner, a process for estimation, a n-week sprint. Those are must haves. That's all process.
  - Underqualified 10y ago
    One of the reasons SCRUM wasn't very popular in our team was that we realized it meant having a lot more meetings than we were having before. I think if you go by the numbers, standard scrum has you spending nearly 20% in your time in developer meetings. Stand ups didn't really work for us either as we are doing our own thing most of the time, so there is little to coordinate, and when there is a need, we usually just work closely together.
    - dasmoth 10y ago
      Capital-A-Agile puts a lot of emphasis on very fine-grained collaboration and reducing the amount of time people are "doing their own thing". Some advocates are pretty open about this being a form of micromanagement[1]. Some people thrive in high-visibility, fine-grained-collaboration environments. On the other hand, if you've got people who are already doing good work without many meetings, it's hard to see Scrum-flavoured setups being anything other than intrusive. [1] https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...
struppi 10y ago
I have been thinking about this a lot, ever since I first read this article, some years ago. Most of my freelance projects and technical coaching gigs in the last few years where at companies that were in or after their "Agile transition". And most got "Agile" horribly wrong. I think cargo cult is an issue, but the problem goes deeper. I wrote a conference talk titled "Your Company Will Never Be Agile" around that topic. The gist is: Many C-level executives want "true business agility" for their company: They want to be able to react quickly when circumstances change. Many "workers in the trenches" (developers, testers, ...) want to be able to do good work and provide value to the customer. But in established companies, the organizational structure, processes and policies, annual budgets, KPI and bonus systems and middle management prevent the company from becoming truly agile. So, young, small companies are more agile, because (among other things) they did not become a bureaucracy yet, they are mostly run by engineers with not much middle management, and because of survivor bias (they do not have a war chest yet, so those that were not able to react quickly do not exist anymore). Unfortunately, there is no English recording (but the slides are here: https://speakerdeck.com/dtanzer/your-company-will-never-be-agile https://speakerdeck.com/dtanzer/your-company-will-never-be-a... ).
- isoos 10y ago
  This matches my experience, although I was lucky that I stopped doing "Agile transitions" gigs early enough. My question is: how do you discuss this with a customer? At one point I had a talk with a director of a smaller bank, and he was enthusiastic to bring me on board, even wanted to pay me just to spend my workday in the office doing nothing specifically. I declined, because it was a lost cause: their team was too fragmented, their processes were too convoluted, their estimate for a very minor change added up to several months... Yet, I felt bad about it, because I wanted to help them, but in that environment, I was not able to do anything. How do you approach such situations?
  - struppi 10y ago
    Well, this is very hard. It is more frustrating with bigger companies. In one occasion, where they officially brought me in as an agile coach, I tried to at least achieve some local optimum with the team, because some big improvements were plain impossible. I occasionally talked to managers about all the walls we were constantly hitting, but the answer was always "we can never change that in this company". This did not stop me from mentioning the problems, though. Most company actually hire me as a technical coach or as a developer. There it is easier: When changing the way the team works is not officially my responsibility, I will still mention things that could be done better. But when the company does not listen to me, it is easier to let go: Then I'll just focus again on helping the team dealing with their legacy code monster (or whatever else I was hired to do). So, in short, my strategy of dealing with it: Never give up mentioning problems and trying to establish a culture of continuous improvement with small experiments. But don't get too frustrated when they don't listen. Also, often they do listen, and things get a little bit better ;) How do you deal with those situations? Do you have a different strategy? What could I try to do differently?
deleted 10y ago
[deleted]
RiffyRiffy 10y ago
All managers not only engage in waterfall, but covet all of the privileges of waterfall. The ability to tell lessers what to program down to the line of code is the ultimate expression of power for people who will never, ever be C-level. And to top it off, they use their powers to force you to compel you to agree that their practices are agile. Agile has never, and will never exist when micromanagement is a good enough drug for those who will never reach actual influence.
- 9gunpi 10y ago
  This is very true, but Agile isn't the only un-achievable property in this case. Even basic healthy atmosphere and efficiency barely have a chance in these situations, so expecting someone in a wheelchair to run feels a bit naive.
danpalmer 10y ago
Agile is the only word I know that inverts its meaning when you capitalise it. The team I work in is fairly agile, in that we communicate well, react to changing priorities very quickly, and ship things regularly. We're not perfect by any means, but whenever we consider adding more of the typical "Agile" process we always realise it would slow us down, and we see other companies with more set "Agile" processes being much slower.
- theprotocol 10y ago
  I enjoyed your comment. The rush to formally define and implement "agile" is pretty hysterical on a fundamental level.
- _betty_ 10y ago
  I typically find the same about Software Architect vs software architect - eg the Job Title vs the activity that decent developers do.
- mpweiher 10y ago
  Yes. The funny thing is that at a company I worked for in the 90ies, we were very agile, before that became a thing, and it was GREAT. Empowering, fun, engineering-driven, effective, efficient. The things we did with our tiny team were amazing. When I read about XP, what I read very much resonated with what we were doing, without ever having a name for it other than "what we do and like that works well". However, whenever I've seen Agile applied at other companies, it was horrible. And yet they refer to the same words. Someone recently told me "Agile/XP/etc. sound like slaves trying to figure out better ways to please their masters". And when I take that frame of reference, yep, that is exactly what it sounds like. So something weird is going on with those words.
  - theprotocol 10y ago
    The issue is that "agile" was a descriptive word, used relatively loosely. Then some people tried to capture its essence and artificially engineer it into their process, and it became prescriptive. Some things are better left to occur organically. If you want to be "agile," then reevaluate your corporate culture and create an environment where it might occur. It needs to be you, you can't fake it, much to the chagrin of some of the more uncharismatic business types.
9gunpi 10y ago
Another kind of cult is religious adherence to methodology while ruining the very value the methodology is supposed to enhance. When you think something is stupid (like adopting only standups), frequently it's because you don't understand the motivation behind it. Standups are one of the first obvious changes any team, no matter how oldschool and rigid, can adopt and see the results behind it quickly, to encourage further transformation. When you're changing something big (like a development process that is stable, consistent and filled with people, resources, operational and deployment plans, etc.), you want to change it either radically, or chunk by chunk. Radical changes are easy to decide yet hard to pull off while preserving business continuity, it's a bit of a gamble not everybody is willing to take. So, many executives want the "transformation" to actually be "step by step evolution". And one of the first steps are standups and enhancing the planning. All of the above doesn't debate the fact that there are companies which get Agile terribly wrong, and companies which can't get Agile right due to extremely rigid structure. However, not all companies who fail to visibly transform into Agile in a few easy steps are like that: sometimes they're stuck on early iterations, slowly working their ways further while preserving continuity and market momentum, and there's nothing wrong with it.
- douche 10y ago
  Standups are a complete waste of time. Whoever floated that idea and made it popular should be ashamed of themselves. I was sick of "circle time" and "show and tell" when I was in kindergarten. I don't need to deal with that as an adult when I have work to do.
tomelders 10y ago
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.
Nursie 10y ago
To echo another comment on here - Daily standups have been the most useful development I've seen in my 17 year career so far, I'm not sure why there's the hate for them. It's a small time allotment where everyone gets just a couple of minutes to sum up where they were yesterday, where they're going today and what's holding them up. I've seen them go wrong, when managers decide that they need to attend and use part of the meeting for "management announcements". I've seen it go wrong when one team member cannot shut up and regularly took over the whole meeting (yes, the scrum master was ineffectual). But in general I've found the daily rapid-fire catchup a thing of beauty. The rest I can take or leave. One of the worst projects I've ever observed had a highly paid SCRUM Master/Consultant/Trainer and that team seemed to spend several hours each day on process. They failed to deliver anything, ever, the product was scrapped and everyone was laid off, including the development manager.
- flukus 10y ago
  > It's a small time allotment where everyone gets just a couple of minutes to sum up where they were yesterday, where they're going today and what's holding them up. Don't you have a kanban board or equivalent where you can see what everyone's been up to and what their upcoming tasks are? Do you need to know what's holding them up if it's not you? For those of us complaining, it's not that we don't see the value, we just see other, arguably better ways to get the same value.
  - Nursie 10y ago
    >>Don't you have a kanban board or equivalent where you can see what everyone's been up to and what their upcoming tasks are? Not where I am now, and in places where we have had various boards it was still useful to have the quick verbal communication - "Oh, I have a script that deals with some of that, it might be a useful guide, let's talk afterwards" >> Do you need to know what's holding them up if it's not you? The same thing may bite me soon so I need to know, or I may have a simple workaround and can offer to help them out. I find the line in the article about it being unnecessary if the team is functioning and communicating well quite weird - the stand-up, in my experience, has been a part of that and has also been a way of saving other communication time.
cvs268 10y ago
Based on my personal experience, most projects are doomed from the start due to these 2 MAJOR problems: 1. Not prioritizing the task of gathering, decomposing and documenting use-cases at the project kick-off. 2. Chronically under-estimating effort required. [1] http://thecodeartist.blogspot.com/2015/04/use-case-is-everything.html http://thecodeartist.blogspot.com/2015/04/use-case-is-everyt... [2] http://thecodeartist.blogspot.com/2017/04/effort-estimation.html http://thecodeartist.blogspot.com/2017/04/effort-estimation....
- fiftyacorn 10y ago
  I dont think its "under-estimating" as much as to get buy-in in a corporate environment means promising to over-deliver Architects/Developers can also be their own worst enemy - chosing a new stack over the existing stack
  - cvs268 10y ago
    That too. However most of us tend to be overtly optimistic about the possibility that something will work as expected. Also we tend to forget the secondary tasks involved[3]. Also the fact that there is usually an expected schedule/due-date that are presented before being asked for estimates, people tend to invariably try to fit the effort-estimate into the pre-determined schedule subconsciously neglecting the secondary tasks. Its like when asked if i can cook a turkey-dinner in 2hours, i say - "looks do-able, i can try...". Completely forgetting the fact that i am being expected to raise it from an egg, and take care of it for a few months first. [3] Slide 8 - https://www.slideshare.net/cvs26/effort-estimation-73647698/8 https://www.slideshare.net/cvs26/effort-estimation-73647698/...
  - humanrebar 10y ago
    > Architects/Developers can also be their own worst enemy - chosing a new stack over the existing stack Or doubling down on existing tech (and technical debt) instead of keeping their options open. One of the problems with agile development processes is that they're not paired with agile design principles.
- BaronSamedi 10y ago
_pmf_ 10y ago
Also nice: the joke by Rich Hickey that Agile solving software development via sprints is like someone revolutionizing the marathon by firing a starter pistol every 100 meters.
- joncampbelldev 10y ago
  Thats a good one, from his "Simple made easy" talk[0] [0] https://www.youtube.com/watch?v=zPT-DuG0UjU https://www.youtube.com/watch?v=zPT-DuG0UjU
seanwilson 10y ago
I don't see value in stand ups most of the time and usually they just get in the way of your work e.g. "I'll start this feature in 30 mins because we've got a standup in 10 mins". I already know what most people are doing from either group chat or the planning board, and a lot of details won't have much relevance to everyone so you end up zoning out just like you would in typical bad meetings. The "what did you do yesterday?" part can also encourage people to scramble to justify they worked hard enough yesterday when it's tricky to condense why a task isn't as trivial as it sounds. What did you do yesterday? What are you doing today? What is getting in your way? That's exactly what planning boards are for! Create a Slack bot which automatically summarises and posts this for each team member every day if you really must. Planning boards are great though. They give you an overview of what everyone is up to, what progress is being made and they're little effort to keep up-to-date compared to having to reply to lots of emails about "what's going on?".
partycoder 10y ago
I think the article is correct. Agile has valid motivations and solves concrete problems. But in practice, you will eventually see confirmation bias and cargo cult. The motto of delivering customer value has been used as an excuse to emphasize the surfaces exposed to the customer (e.g: features) and neglect non-features (non-functional requirements, e.g: maintainability, security, performance, scalability, configuration, testing).
tempodox 10y ago
I have yet to see an implementation of "Agile" that's not a cargo cult pretext for micromanagement.
- dasmoth 10y ago
  Some advocates are pretty open about this: https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging Interesting question is -- why is micromanagement by "the team" more palatable to some (many?) people?
  - overgard 10y ago
    It is an interesting question. I suspect its palatable because it evens the playing field. The game changes from skills based to politics based, and that suits some people better.
codingmyway 10y ago
Microservices seems to be the latest cargo cult technique being pushing without really considering whether the benefits outweigh the costs. Some consultants always need another thing to push that a particular company's problems for them so therefore it must be applied everywhere.
rhapsodic 10y ago
I think the most critical factor in the success or failure of a software development project is the skill and dedication of the developers. Yet I never seem to hear or "Agile Coaches" mention that. I guess clients would not be receptive if someone were to tell them that their best course of action was to replace half of their team.
- huherto 10y ago
  > I think the most critical factor in the success or failure of a software development project is the skill and dedication of the developers. And yet. It is part of the agile principles. #9 Continuous attention to technical excellence and good design enhances agility. I am shocked to see how the agile principles are ignored by "Agile Coaches". https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/ https://www.agilealliance.org/agile101/12-principles-behind-...
- overgard 10y ago
  I think this is why agile is, frankly, so insulting. I went to a good university for four years to learn computer science, a field that is legitimately hard. I produce real business value daily. And yet this methodology places about as much trust in me as a mcdonalds worker.
overgard 10y ago
This is anecdotal, but I've found that the more "agile" a place is, the more underworked I am. In most non-agile places, if im out of work its up to me to find a way to make myself useful (agency!), but in agile environments I usually am told not to take something on because "it wont fit in the sprint". I generally think agiles main benefit is bringing the low performers up to average, but at the cost of handcuffing your top performers.
- shanemhansen 10y ago
  > bringing the low performers up to average, but at the cost of handcuffing your top performers. Sounds about right. If you view humans as interchangeable resources then predictable performance is good. Most businesses don't need or benefit from a Linus Torvalds to build their CRUD app.
  - overgard 10y ago
    Sadly true, although weirdly given most companies hiring practices they apparently think they need Linus to build their facebook for cats app.
- pdelbarba 10y ago
  When I worked with a bigger agile group one of the things I liked was having a task list put together and then divided up among everyone but also having an 'on-deck' group for stuff we didn't think we'd have time for. Anyone who got things done faster would have their pick of the on deck work and was some extra freedom and recognition for doing so.
  - overgard 10y ago
    Its a nice idea in theory, but generally ive found these reserve backlogs are full of things nobody actually wants to do, they just think itd be vaguely nice if someone else did it. Its either stuff with no direct business value (refactor the flargenstock), or high-risk/low reward work

111 points by ekzy 10y ago

zer0tonin 10y ago

I should explain that to my boss, we're literally doing waterfall but with standup meetings...

techterrier 10y ago
"wagile"
flukus 10y ago
"Agile waterfall" may be a meme but I have seen job listings use that exact term to describe the company. Out of everywhere I've ever interviewed though, no company that has described themselves as Agile have been remotely Agile, ones that don't spend so much time thinking about process generally are Agile to a degree.
adrianmsmith 10y ago
Great stuff. I asked one Agile coach about how and when one should do software architecture decisions for a larger project, he said you can take an extra sprint/spike at the start to do software architecture if necessary. At another place, the testing members of the team always tested the previous sprint's work (otherwise they'd be doing nothing for the first 80% of the sprint, if they tested that sprint's software). So if you had a requirements sprint, a software architecture sprint, a development sprint, then that gets tested on the next sprint, what process does that remind you of? :)
- Sharlin 10y ago
  That is still iteration. Agile doesn't say you can't do things in phases, it just says those phases need to be short enough that you can iterate on them.
  - valuearb 10y ago
    Yea but how done is your sprint if your work isn't tested? It's the old, "done" vs. "done done" debates we had end of every sprint. I wrote the code, it mostly works, it has bugs. Am I done? Should I move on? Technical debt creeping higher and higher.
  - adrianmsmith 10y ago
    Agile does say the results of sprints should be something the customer can understand and use: a software architecture document, or untested code from the development sprint, isn't that.
liamt 10y ago
I've been there. Now we do scrum and do standup meetings but it's a lot less strict. Most of the team talks constantly anyway as we're all in the same room. Our old boss is long gone.
overgard 10y ago
Is waterfall even a thing? I feel like the software industry is constantly coming up with solutions to cultural problems that were more relevant in 1977 than 2017 Ive worked at places that werent "agile" and it wasnt the strawman experience of waterfall.. it was just people doing work. They just didnt make a big deal about squeezing everything in a two week window and avoided uncomfortable/useless planning and retrospective meetings.

flukus 10y ago

I'd argue stand up meetings are the opposite of agile, the insistence on them is literally breaking the first rule of the agile manifesto: > Individuals and interactions over processes and tools Probably breaking the fourth too: > Responding to change over following a plan How many companies have done a retrospective on whether the daily recitation of Kanban board movements is providing any value?

jwdunne 10y ago
To me, a lot of Agile breaks the first rule. A Certified SCRUM Master comes in and overhauls your processes. That is, in effect, processes and tools straight up, from the minute that scrum master goes on a course. It wouldn't be much of a course if it didn't teach some process for implementing SCRUM. It wouldn't be much of a consultation if the consultant tells you to go speak to your customers and find out what is really bothering them and how you can deliver working software quickly to alleviate that. So you have daily standup a, weekly retrospectives, a designated master, product owner, a process for estimation, a n-week sprint. Those are must haves. That's all process.
- Underqualified 10y ago
  One of the reasons SCRUM wasn't very popular in our team was that we realized it meant having a lot more meetings than we were having before. I think if you go by the numbers, standard scrum has you spending nearly 20% in your time in developer meetings. Stand ups didn't really work for us either as we are doing our own thing most of the time, so there is little to coordinate, and when there is a need, we usually just work closely together.
  - dasmoth 10y ago
    Capital-A-Agile puts a lot of emphasis on very fine-grained collaboration and reducing the amount of time people are "doing their own thing". Some advocates are pretty open about this being a form of micromanagement[1]. Some people thrive in high-visibility, fine-grained-collaboration environments. On the other hand, if you've got people who are already doing good work without many meetings, it's hard to see Scrum-flavoured setups being anything other than intrusive. [1] https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...

struppi 10y ago

I have been thinking about this a lot, ever since I first read this article, some years ago. Most of my freelance projects and technical coaching gigs in the last few years where at companies that were in or after their "Agile transition". And most got "Agile" horribly wrong. I think cargo cult is an issue, but the problem goes deeper. I wrote a conference talk titled "Your Company Will Never Be Agile" around that topic. The gist is: Many C-level executives want "true business agility" for their company: They want to be able to react quickly when circumstances change. Many "workers in the trenches" (developers, testers, ...) want to be able to do good work and provide value to the customer. But in established companies, the organizational structure, processes and policies, annual budgets, KPI and bonus systems and middle management prevent the company from becoming truly agile. So, young, small companies are more agile, because (among other things) they did not become a bureaucracy yet, they are mostly run by engineers with not much middle management, and because of survivor bias (they do not have a war chest yet, so those that were not able to react quickly do not exist anymore). Unfortunately, there is no English recording (but the slides are here: https://speakerdeck.com/dtanzer/your-company-will-never-be-agile https://speakerdeck.com/dtanzer/your-company-will-never-be-a... ).

isoos 10y ago
This matches my experience, although I was lucky that I stopped doing "Agile transitions" gigs early enough. My question is: how do you discuss this with a customer? At one point I had a talk with a director of a smaller bank, and he was enthusiastic to bring me on board, even wanted to pay me just to spend my workday in the office doing nothing specifically. I declined, because it was a lost cause: their team was too fragmented, their processes were too convoluted, their estimate for a very minor change added up to several months... Yet, I felt bad about it, because I wanted to help them, but in that environment, I was not able to do anything. How do you approach such situations?
- struppi 10y ago
  Well, this is very hard. It is more frustrating with bigger companies. In one occasion, where they officially brought me in as an agile coach, I tried to at least achieve some local optimum with the team, because some big improvements were plain impossible. I occasionally talked to managers about all the walls we were constantly hitting, but the answer was always "we can never change that in this company". This did not stop me from mentioning the problems, though. Most company actually hire me as a technical coach or as a developer. There it is easier: When changing the way the team works is not officially my responsibility, I will still mention things that could be done better. But when the company does not listen to me, it is easier to let go: Then I'll just focus again on helping the team dealing with their legacy code monster (or whatever else I was hired to do). So, in short, my strategy of dealing with it: Never give up mentioning problems and trying to establish a culture of continuous improvement with small experiments. But don't get too frustrated when they don't listen. Also, often they do listen, and things get a little bit better ;) How do you deal with those situations? Do you have a different strategy? What could I try to do differently?

deleted 10y ago

[deleted]

RiffyRiffy 10y ago

All managers not only engage in waterfall, but covet all of the privileges of waterfall. The ability to tell lessers what to program down to the line of code is the ultimate expression of power for people who will never, ever be C-level. And to top it off, they use their powers to force you to compel you to agree that their practices are agile. Agile has never, and will never exist when micromanagement is a good enough drug for those who will never reach actual influence.

9gunpi 10y ago
This is very true, but Agile isn't the only un-achievable property in this case. Even basic healthy atmosphere and efficiency barely have a chance in these situations, so expecting someone in a wheelchair to run feels a bit naive.

danpalmer 10y ago

Agile is the only word I know that inverts its meaning when you capitalise it. The team I work in is fairly agile, in that we communicate well, react to changing priorities very quickly, and ship things regularly. We're not perfect by any means, but whenever we consider adding more of the typical "Agile" process we always realise it would slow us down, and we see other companies with more set "Agile" processes being much slower.

theprotocol 10y ago
I enjoyed your comment. The rush to formally define and implement "agile" is pretty hysterical on a fundamental level.
_betty_ 10y ago
I typically find the same about Software Architect vs software architect - eg the Job Title vs the activity that decent developers do.
mpweiher 10y ago
Yes. The funny thing is that at a company I worked for in the 90ies, we were very agile, before that became a thing, and it was GREAT. Empowering, fun, engineering-driven, effective, efficient. The things we did with our tiny team were amazing. When I read about XP, what I read very much resonated with what we were doing, without ever having a name for it other than "what we do and like that works well". However, whenever I've seen Agile applied at other companies, it was horrible. And yet they refer to the same words. Someone recently told me "Agile/XP/etc. sound like slaves trying to figure out better ways to please their masters". And when I take that frame of reference, yep, that is exactly what it sounds like. So something weird is going on with those words.
- theprotocol 10y ago
  The issue is that "agile" was a descriptive word, used relatively loosely. Then some people tried to capture its essence and artificially engineer it into their process, and it became prescriptive. Some things are better left to occur organically. If you want to be "agile," then reevaluate your corporate culture and create an environment where it might occur. It needs to be you, you can't fake it, much to the chagrin of some of the more uncharismatic business types.

9gunpi 10y ago

Another kind of cult is religious adherence to methodology while ruining the very value the methodology is supposed to enhance. When you think something is stupid (like adopting only standups), frequently it's because you don't understand the motivation behind it. Standups are one of the first obvious changes any team, no matter how oldschool and rigid, can adopt and see the results behind it quickly, to encourage further transformation. When you're changing something big (like a development process that is stable, consistent and filled with people, resources, operational and deployment plans, etc.), you want to change it either radically, or chunk by chunk. Radical changes are easy to decide yet hard to pull off while preserving business continuity, it's a bit of a gamble not everybody is willing to take. So, many executives want the "transformation" to actually be "step by step evolution". And one of the first steps are standups and enhancing the planning. All of the above doesn't debate the fact that there are companies which get Agile terribly wrong, and companies which can't get Agile right due to extremely rigid structure. However, not all companies who fail to visibly transform into Agile in a few easy steps are like that: sometimes they're stuck on early iterations, slowly working their ways further while preserving continuity and market momentum, and there's nothing wrong with it.

douche 10y ago
Standups are a complete waste of time. Whoever floated that idea and made it popular should be ashamed of themselves. I was sick of "circle time" and "show and tell" when I was in kindergarten. I don't need to deal with that as an adult when I have work to do.

tomelders 10y ago

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.

Nursie 10y ago

To echo another comment on here - Daily standups have been the most useful development I've seen in my 17 year career so far, I'm not sure why there's the hate for them. It's a small time allotment where everyone gets just a couple of minutes to sum up where they were yesterday, where they're going today and what's holding them up. I've seen them go wrong, when managers decide that they need to attend and use part of the meeting for "management announcements". I've seen it go wrong when one team member cannot shut up and regularly took over the whole meeting (yes, the scrum master was ineffectual). But in general I've found the daily rapid-fire catchup a thing of beauty. The rest I can take or leave. One of the worst projects I've ever observed had a highly paid SCRUM Master/Consultant/Trainer and that team seemed to spend several hours each day on process. They failed to deliver anything, ever, the product was scrapped and everyone was laid off, including the development manager.

flukus 10y ago
> It's a small time allotment where everyone gets just a couple of minutes to sum up where they were yesterday, where they're going today and what's holding them up. Don't you have a kanban board or equivalent where you can see what everyone's been up to and what their upcoming tasks are? Do you need to know what's holding them up if it's not you? For those of us complaining, it's not that we don't see the value, we just see other, arguably better ways to get the same value.
- Nursie 10y ago
  >>Don't you have a kanban board or equivalent where you can see what everyone's been up to and what their upcoming tasks are? Not where I am now, and in places where we have had various boards it was still useful to have the quick verbal communication - "Oh, I have a script that deals with some of that, it might be a useful guide, let's talk afterwards" >> Do you need to know what's holding them up if it's not you? The same thing may bite me soon so I need to know, or I may have a simple workaround and can offer to help them out. I find the line in the article about it being unnecessary if the team is functioning and communicating well quite weird - the stand-up, in my experience, has been a part of that and has also been a way of saving other communication time.

cvs268 10y ago

Based on my personal experience, most projects are doomed from the start due to these 2 MAJOR problems: 1. Not prioritizing the task of gathering, decomposing and documenting use-cases at the project kick-off. 2. Chronically under-estimating effort required. [1] http://thecodeartist.blogspot.com/2015/04/use-case-is-everything.html http://thecodeartist.blogspot.com/2015/04/use-case-is-everyt... [2] http://thecodeartist.blogspot.com/2017/04/effort-estimation.html http://thecodeartist.blogspot.com/2017/04/effort-estimation....

fiftyacorn 10y ago
I dont think its "under-estimating" as much as to get buy-in in a corporate environment means promising to over-deliver Architects/Developers can also be their own worst enemy - chosing a new stack over the existing stack
- cvs268 10y ago
  That too. However most of us tend to be overtly optimistic about the possibility that something will work as expected. Also we tend to forget the secondary tasks involved[3]. Also the fact that there is usually an expected schedule/due-date that are presented before being asked for estimates, people tend to invariably try to fit the effort-estimate into the pre-determined schedule subconsciously neglecting the secondary tasks. Its like when asked if i can cook a turkey-dinner in 2hours, i say - "looks do-able, i can try...". Completely forgetting the fact that i am being expected to raise it from an egg, and take care of it for a few months first. [3] Slide 8 - https://www.slideshare.net/cvs26/effort-estimation-73647698/8 https://www.slideshare.net/cvs26/effort-estimation-73647698/...
- humanrebar 10y ago
  > Architects/Developers can also be their own worst enemy - chosing a new stack over the existing stack Or doubling down on existing tech (and technical debt) instead of keeping their options open. One of the problems with agile development processes is that they're not paired with agile design principles.
BaronSamedi 10y ago

_pmf_ 10y ago

Also nice: the joke by Rich Hickey that Agile solving software development via sprints is like someone revolutionizing the marathon by firing a starter pistol every 100 meters.

joncampbelldev 10y ago
Thats a good one, from his "Simple made easy" talk[0] [0] https://www.youtube.com/watch?v=zPT-DuG0UjU https://www.youtube.com/watch?v=zPT-DuG0UjU

seanwilson 10y ago

I don't see value in stand ups most of the time and usually they just get in the way of your work e.g. "I'll start this feature in 30 mins because we've got a standup in 10 mins". I already know what most people are doing from either group chat or the planning board, and a lot of details won't have much relevance to everyone so you end up zoning out just like you would in typical bad meetings. The "what did you do yesterday?" part can also encourage people to scramble to justify they worked hard enough yesterday when it's tricky to condense why a task isn't as trivial as it sounds. What did you do yesterday? What are you doing today? What is getting in your way? That's exactly what planning boards are for! Create a Slack bot which automatically summarises and posts this for each team member every day if you really must. Planning boards are great though. They give you an overview of what everyone is up to, what progress is being made and they're little effort to keep up-to-date compared to having to reply to lots of emails about "what's going on?".

partycoder 10y ago

I think the article is correct. Agile has valid motivations and solves concrete problems. But in practice, you will eventually see confirmation bias and cargo cult. The motto of delivering customer value has been used as an excuse to emphasize the surfaces exposed to the customer (e.g: features) and neglect non-features (non-functional requirements, e.g: maintainability, security, performance, scalability, configuration, testing).

tempodox 10y ago

I have yet to see an implementation of "Agile" that's not a cargo cult pretext for micromanagement.

dasmoth 10y ago
Some advocates are pretty open about this: https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging Interesting question is -- why is micromanagement by "the team" more palatable to some (many?) people?
- overgard 10y ago
  It is an interesting question. I suspect its palatable because it evens the playing field. The game changes from skills based to politics based, and that suits some people better.

codingmyway 10y ago

Microservices seems to be the latest cargo cult technique being pushing without really considering whether the benefits outweigh the costs. Some consultants always need another thing to push that a particular company's problems for them so therefore it must be applied everywhere.

rhapsodic 10y ago

I think the most critical factor in the success or failure of a software development project is the skill and dedication of the developers. Yet I never seem to hear or "Agile Coaches" mention that. I guess clients would not be receptive if someone were to tell them that their best course of action was to replace half of their team.

huherto 10y ago
> I think the most critical factor in the success or failure of a software development project is the skill and dedication of the developers. And yet. It is part of the agile principles. #9 Continuous attention to technical excellence and good design enhances agility. I am shocked to see how the agile principles are ignored by "Agile Coaches". https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/ https://www.agilealliance.org/agile101/12-principles-behind-...
overgard 10y ago
I think this is why agile is, frankly, so insulting. I went to a good university for four years to learn computer science, a field that is legitimately hard. I produce real business value daily. And yet this methodology places about as much trust in me as a mcdonalds worker.

overgard 10y ago

This is anecdotal, but I've found that the more "agile" a place is, the more underworked I am. In most non-agile places, if im out of work its up to me to find a way to make myself useful (agency!), but in agile environments I usually am told not to take something on because "it wont fit in the sprint". I generally think agiles main benefit is bringing the low performers up to average, but at the cost of handcuffing your top performers.

shanemhansen 10y ago
> bringing the low performers up to average, but at the cost of handcuffing your top performers. Sounds about right. If you view humans as interchangeable resources then predictable performance is good. Most businesses don't need or benefit from a Linus Torvalds to build their CRUD app.
- overgard 10y ago
  Sadly true, although weirdly given most companies hiring practices they apparently think they need Linus to build their facebook for cats app.
pdelbarba 10y ago
When I worked with a bigger agile group one of the things I liked was having a task list put together and then divided up among everyone but also having an 'on-deck' group for stuff we didn't think we'd have time for. Anyone who got things done faster would have their pick of the on deck work and was some extra freedom and recognition for doing so.
- overgard 10y ago
  Its a nice idea in theory, but generally ive found these reserve backlogs are full of things nobody actually wants to do, they just think itd be vaguely nice if someone else did it. Its either stuff with no direct business value (refactor the flargenstock), or high-risk/low reward work