9 ms·

In a nutshell, why do a lot of developers dislike Agile?

68 points by vatotemking 10y ago

Dirlewanger 10y ago
Paraphrasing a comment on /r/programming about this yesterday: If there is a decent set of requirements, then the framework used is irrelevant.
- taneq 10y ago
  But Agile, as I understand it at least, is explicitly designed for cases when requirements aren't fully known.
  - Zigurd 10y ago
    Moreover, Agile is about realizing there is value in reconsidering your requirements as you discover opportunities, or encounter problems. You may think you know all the requirements. But that it often an illusion or a rigidness that prevents a better result.
  - forgottenpass 10y ago
    Agile is designed for that case, but most development methodologies are designed for that case. The idea that requirements are set in stone, or - more specifically - the idea that not setting them in stone is breaking conventional wisdom is just running us in circles. Requirements are just a name for detailed goals. They change as goals change. Diffs can be applied them just as easily as to the codebase. Maybe a team has them over emphasized and too rigid, maybe too undocumented and in flux. But prescriptive development methodology doesn't give teams tools to figure out what works for their projects. Development processes aren't really improving with every new trendy thing that comes out, they're just finding new ways to package and shuffle things around.
    - taneq 10y ago
      > but most development methodologies are designed for that case Modern (ie. post-XP) software methodologies, yes. Traditional engineering? Not at all. Software is unique in that it's essentially free to convert your design into your end product. It's one thing to iterate weekly when your build process costs $0.02 of electricity and half an hour of server time. It's another thing entirely when you have to obtain many different parts (some with long lead times, others custom built, and small batches always cost far more per unit) and then assemble them manually before testing a physical object.
joeblow9999 10y ago
Agile is for managing upward and a lot of developers would rather, you know, develop
pcmaffey 10y ago
What's ironic about this metaphor is that Agile's roots can be found in building construction. We all know the story of Toyota, but where did Toyota come up with the idea? From Japanese stone masons. The nature of building with stone is such that you never truly know what resources you have to work with. The shape, color, texture of stone is all variable. This means too that the way each component fits together is unpredictable. For the eye of a master builder, who constructs edifices with each relationship perfectly balanced, each component placed intentionally, who can see every step of the process and what each choice means for the integrity of the whole, such a craftsman understands that every day brings with it a whole new set of variable inputs, which can never be planned for, spec'ed out, or tasked to laborers who do not see the whole. Modern construction cares nothing for such craft. It will be the domain of robots. Software development too will follow this path, as we humans are suckers for predictability. But such a road will be littered with people suffering in jobs that make them feel like robots, projects that fall flat, and endless repeating boxes of sameness.
- dschiptsov 10y ago
  Construction, it seems, is a "waterfall" by definition, and, it is, probably, from architecture the model took its roots. Agile came from business and finance, where everything is uncertain and even not well understood.
  - ethbro 10y ago
    As someone who studied the field, construction in abstract seems a waterfall model. Construction in practice requires something very similar to agile: too many uncontrolled real world variables, interdependent timelines, and sheer laws of physics. If everything goes right, yes waterfall. Everything never goes right.
    - mixmastamyk 10y ago
      In rare circumstances everything must go right beforehand, e.g. the New Horizons probe to Pluto.
- 10y ago
wpietri 10y ago
Hi! Early Agile person here, but I hate what the term Agile has become. [1] I think there are a lot of good reasons to grumble about Agile, especially when management use it as a stick to beat developers. But I don't think the problem described here is one of them. I think expecting business to know what they want is a mistake. When my dad was making software in the 60s, 70s, and 80s, we were mainly automating existing business process, so we could draft behind all the hard work done working out the right paper forms and reports. But modern software comes from a process of experimentation and discovery, competition and evolution. As the people who understand the technology best, we should be as part of that process from beginning to end. This analogy is misleading because software gives us power that we don't have in the real world. If we start with port-a-potties and want real bathrooms, we just have to change the description of a bathroom and the computer will do the rest. In software, if you are disciplined about automated testing, refactoring, and keeping up with technical debt, an evolving architecture is totally doable. I think where people fall down is that they don't believe that managers will give them enough time to keep things clean as they go. And I agree, they won't. You have to take the time. But if you do it from day one you can do it gradually and incrementally. You can gradually redirect management pressure away from developers and toward making better product choices. So please let's take control of our working conditions back. We're professionals, and we can say, "No, I'm still writing tests. That's a best practice, and it would be negligent for me to leave that out." But we can do that while delivering incrementally, so that no week goes by without the business getting some new benefit in production. [1] http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
- existencebox 10y ago
  Let me give two stories. I am in full agreement with your statement, however want to give supporting evidence as part of a "I'm not sure how to push back well even after all these years without compromising a lot of political capital". 1. Just this week, I watched a manager wait until after I was on vacation, and then publicly chew out my employee for slipping a deadline. I would agree he should have pushed harder, BUT he slipped it due to our peers being very rigorous on his CR (he is a new employee) to bring him up to standards. (I would add we would have had even MORE buffer had the person in question not continued to change the spec 2 months into a 3 month project, which can happen, but should be acknowledged as a cost) . The manager in question found this (the deadline slipping) regardless unacceptable and gave him grief in front of the whole team about it, and this is the second time I've watched the manager place these meetings when I'm going to be gone because otherwise I come down like a bag of bricks on someone going after my employees. But to why I mention that last sentence regarding my nature, NO AMOUNT of this seems to motivate positive change in the long run, _especially_ since I'm "managing up" and having to do this as an engineer myself, any big "push" I make costs a lot of effort and karma, and doesn't seem to stick long term despite my best efforts. 2. More specifically, I had a conversation you summarized above (taking TIME to dev well) just a few weeks ago with my manager. Over the last few years we've repeated a pattern, I take longer than he'd like, he gives me shit for it, I tell him it'll pay dividends long term, he grumbles, but then it does. (bug rates, iteration speed under frameworks I write, reuse due to good modularity/code cleanliness, these are all benefits you see rendered on a very short time scale, even just keeping with the most broad basics.) Now, I will give him credit for saying "you have a point and I'll leave it to your judgement" but that took me _two years_ of very incendiary 1:1's of my trying to put my money where my mouth is against someone who has been at this a lot longer than me and with some very strong opinions about that. I frankly don't see a "shortcut" after that experience, although the conclusion was more positive. So let me tie up this ramble with addressing your conclusion: I'd LOVE to take control of my working conditions back. But when the same people (PMs) who lead to my just throwing my hands up at even TRYING to get work done at work due to constant context switching/interruptions _SCHEDULE MEETINGS_ asking us why we're so slow (and then spend the whole meeting complaining about how WE pull them into meetings they don't need), it seems like there are just massive gaps of understanding or lack of shared incentive between the various powers that be. I don't know how to take control of my working condition back, but I've damn well been trying, and would be curious to hear any anecdotal suggestions from you in working this through more "political" environments.
dschiptsov 10y ago
Because the way you manage an orchestra does not eliminate the necessity of each musician to be able to perform decently?
fatdog 10y ago
Agile, like anything, is perfect when you implement it perfectly. Nobody does, but it's not the method's fault, the method is perfect. What I have seen is it used as a chip on the shoulders that makes product meetings feel like dealing with communist border guards. Working in Agile shops can be a lot like watching lab mice running a maze. You try to say, "hey, so this path you are working on, there is a map for it when it was solved in <discipline x>." and the response was, "this is Agile, we don't take grand designs or waterfall requirements, and we don't need anymore chickens in our standup." Or you say, "hey, so this thing you are building, for someone to buy it, we're going to have to explain to them why it's good and how it meets their expectations, can we create a sequence diagram or a model so I can plug in how it meets standards and regulations and code and such?" and the response is, "we don't need documentation, the code is documented, and if you had provided us with the requirements we could prove it in our unit testing." The trouble I have with a lot of engineering and dev culture is what it lacks, and often irrationally rejects, is balancing the technical understanding with a top down view. The best engineers have or at least appreciate this, and they bring it with them. Unfortunately this gets them immediately promoted to roles where they aren't actually writing code. I've used this house building simile in Agile shops before, where any bunch of carpenters, electricians, plumbers and brick layers can build a fine house that will stand up, but the matter of whether anyone will want to live in it, buy it, insure it, legally sell it, live anywhere near it, or trust that it won't be knocked down by local climate or regulations - is an equally complex problem you need someone with expertise to solve. Everyone has complains, devs about managers, managers about devs, it's an age old problem. A lot of Agile gets used to formalize an adolescent culture. I look forward to the pendulum swinging back to a more balanced equilibrium.
- drumdance 10y ago
  This is a frustration I had in my most recent project. Management did a good job of coming up with interesting features in the abstract, but a terrible one of communicating those features and working them into the app in a way that was intuitive. I often found myself saying, "this is potentially a good feature, but how do we explain it?" We never had a good designer on staff, so that was a huge part of the problem. A couple times we used outside designers but they didn't have a holistic view of the app, so their designs created as many questions as they answered.
taneq 10y ago
People hate Agile now for the same reasons people hated "extreme programming" before it: Mismanagement based on a few misunderstood buzzwords. Extreme programming had the de-emphasis on documentation in favour of verbal communication, which got garbled into "just don't document anything". Agile has sprints, which has been twisted into "crunch time every two weeks for two weeks".
- digi_owl 10y ago
  And devops turns into "end user is QA"?
KaiserPro 10y ago
The whole point of Agile was "people not processes" However because at my company we have professional scrum masters, everything must be religiously Agile. This means that we must have a standup, everyday. we must have a retro, we must have planning. almost half a day a week is lost to pointless meetings. I just want to get on with my job. Trust me to use the ticketing system to figure out what I'm doing and raising blocking issues.
- davidgerard 10y ago
  The free E-meter at every desk is a valuable job perk! The Kool-Aid tasted a bit funny, though. sprint: artificial crisis end of sprint: abandonware Scrum Master: CV credit for my planned escape to a new company stakeholder: someone you can't get away with externalising your costs onto, because they can hammer a wooden spike through your heart Project Manager: a job that no longer needs to exist in the astounding new world of Scrum! (Pay no attention to the project owners, product owners, story-writing users above you in the org chart or Scrum Masters behind the curtain.) simplified: doesn't implement the actual business requirements lightweight: doesn't implement the actual business requirements, but does so much more elegantly than the version that works easy: project was born circling the drain (and doesn't implement the actual business requirements) legacy: the version that works and implements the actual business requirements, though no sane human wants to touch it user story: a valiant attempt to extract coherent requirements and bug reports; ends up being precise specifications for the wing feathers of the desired magical flying unicorn pony velocity: a speed with a direction: skittering about following marketing's random hairpin turns retrospective: blamestorm incoming! stand-up: establishing blamestorm targets early Inspect and Adapt: perhaps bong hits will fix my makefile We'll put that on the backlog: ahaha fuck you doing Agile wrong: noticing any of the above. I do enjoy some of the jargon. empowered: do your own fucking job. "Could you just copy down these log files from these fifteen servers for me and put them on the shared drive? Thanks." "I'm sorry, I'm afraid you're empowered to do that." Every good idea is turned into a bad one by the relentless management quest to Taylorise clue. (originally posted by me at https://reddragdiva.dreamwidth.org/594955.html https://reddragdiva.dreamwidth.org/594955.html )
  - 10y ago
quantumhobbit 10y ago
The problem with modern "Agile" and frankly all other software development methodologies is the mismatch between the knowledge and expectations of the business and tech. Business and tech tend to use Agile to keep each other at arms length and never learn about what the other does. This is a shame because originally agile was about forcing business and tech to work closely and interact regularly. Hence the short sprints and frequent stand ups. In the parent example the management should have known enough about building to realize they were a creating a clusterfuck, and the builders should have had enough knowledge and input to the business to figure out what they were supposed to be building. When both sides assume the other is too stupid to work with and avoids meaningful interaction, it shouldn't be a surprise when the result is a hacked together mess.
- bengale 10y ago
  The problem I've seen is rather than forcing the business and tech to understand and work with each other managers are hired to do 'agile' and basically proxy for the business. They don't know anything more than developers do, and while there is more iterative development, the feedback is coming from the wrong people. It just becomes useless meetings and checkboxes.
vemv 10y ago
Probably an essential mistake is to put multiple people to work on a greenfield project at once, when the requirements are particularly uncertain. Better to allocate a single full-stack dev to experiment for a couple weeks. He also will interact with the business owner daily. Let him focus on the business logic and also the core user interactions. On top of that MVP foundation (i.e. on week 3), you can put the rest of the team to refine backend, frontend, graphic design and so on.
- ninkendo 10y ago
  > Probably an essential mistake is to put multiple people to work on a greenfield project at once, when the requirements are particularly uncertain. This statement rings so true to me that I really hope there exists a fleshed out version of this theory, with examples to prove it and maybe a catchy name, etc. Where I am now, I've literally participated in an identical thing being built in two ways at two different times: - The first time, I was the initial full-stack dev, along with one other guy (we were more of a duo... we paired a lot and worked pretty fluidly, it was kind of a 2-person equivalent of a single-person experiment.) The result was finished in 3 weeks and was flimsy but cohesive. Eventually the team was reduced to just me and I carried out the project for a few more months before a proper "team" was on board. - Then, the company noticed what we had done, decided that a bunch of other people had done similar things (it's a large company, after all), and then a 250-person organization was formed to write an MVP that was largely identical in scope. I wasn't in any leadership position in this new org, so nobody really cared that I had experience in this. I was reduced to writing a tiny insignificant part of the larger whole while our director drove the requirements. We're 10 months in and haven't shipped the first milestone yet. In the first example, we were almost too successful. The resulting product was used by thousands of people, for important things, with a lot of satisfaction and kudos from the users. But the total size of the team never really exceeded 5-10 people, so it got to the point where we were burned out supporting it, and there weren't enough reserves to call in to help because of the "second system" distracting everyone: In the second case, we don't have our first customer yet (although we've only kind of "soft" launched.) We did a massively half-assed attempt at agile that was basically "waterfall, but more vague, and please work harder", where we kinda half-assed came up with requirements, split everything up into 10-15 major "tentpoles", each of which was developed by separate teams. 6 months later we decided to start "integrating" all of it. 4 months after that, things finally kinda sorta work end-to-end. I've gone through a ton of self doubt through the process. In the first case, it worked only because there was almost no communication: we just did what we felt like, explored, and we were lucky that the end result worked. "Clearly, this will never scale, and is no way to run a real software product", I remember thinking. When the org got huge and we did our second system, I thought "Finally, I can learn to do what real software devs do and work for a big team with communication and requirements, etc". And inevitably when the result is a big pile of shit, I can't shake the feeling "this would've been better if I knew how to do real software development and work with a large team." Self loathing ensues. So I witnessed the pendulum swing each way. The first way was massively successful, but I suspect isn't sustainable (the product is withering due to lack of support now.) The second isn't successful at all, and is a complete mess, but maybe it'll be better with time. The only thing I know for sure is that few companies in the world can afford the amount of wasted time and energy we've spent on the second system. I suspect the real world works more like the first case but I don't have enough experience to know. I can't shake the thoughts of "I haven't seen real software development yet", and I don't know how much validity there is behind those doubts.
InclinedPlane 10y ago
Agile is just a collection of stuff that people put together in order to ensure useful productivity from arbitrary teams. Often it's misapplied and misused, usually in order to micromanage. The roots of agile come from the bad old days when the typical software project was a consulting gig with an elaborate negotiated spec and schedule and a huge disconnect between the buyers and the developers, let alone the users. And when the "software crisis" was in full swing, and many software projects failed to deliver anything of use, at all. Back in the days when even using source control wasn't common, and when regular builds and smoke tests were even rarer. Agile ensures a few things: It ensures that you use an incremental development strategy: start with something simple that works, then iteratively add to it over the course of short periods of work to move it closer to the desired state of functionality and capability. Because you routinely have workable builds this means you will always have something to show for your work at the end, because you have a pattern of having something working all the time. It pushes the team toward continuous integration and regular builds with testing. Which avoids building up invisible technical debt due to undone integration work as the project progresses. Agile avoids the "big bang integration" problem. It pushes the team toward visibility and interaction, so they get to know what everyone else is working on and it forces collaboration related to integration ASAP, all of which helps increase team cohesion and leads to higher code quality. People get to see the products of other's work routinely, making it easier to see what they're good at (and not) and aiding team mates in learning from one another. It avoids unnecessary over-complications and the tendency to procrastinate, such as the notorious "second system effect". It ensures that people stay concentrated on real milestones and real work not pie in the sky perfect systems with schedule estimates off by orders of magnitude or not even feasibly possible. It gives the "stakeholders" more visibility into the work. The product itself becomes the ground truth for the product, rather than a spec or a memo or a contract. If those folks have concerns they can be addressed and taken care of before it is extremely costly to fix. And if they want to make changes to the design relative to their initial thoughts, that too can be done fairly easily, resulting in an end product that is more suitable than would be the case otherwise. And it ensures that sprint by sprint, work gets done, the product moves forward. With good teams this isn't a problem, but in the "enterprise trenches" with demotivated teams of average or below average coders this can be a real problem. It can be difficult to get anything done, let alone anything more than just spinning their wheels. All of these things are for the most part good things, and they are the reason why the concept of agile has become so pervasive. The problem is that today a lot of the agile basics just go without saying (continuous integration, routine builds and testing, iterative development, short sprints for work, and so on) while some of the other aspects end up being applied in a cargo cult manner with no comprehension for why they were used as well as when they are warranted and when not. Even if agile practices were being used correctly most of the time, which they aren't, it still would not be a good one size fits all practice for all circumstances. Moreover, the modern perversions of agile have done a lot of damage. Removing opportunities for use of initiative, creativity, and expertise by many coders, taking responsibility for even the tiniest decision out of their hands and transforming them into children. In some ways agile is like a remedial course in software engineering, but a lot of high caliber developers are finding themselves stuck with it even though it is restrictive and harmful, because management is thoughtless.
walkingolof 10y ago
I see the benefits with agile, but I cant help feeling that something is lost in a process that so completely controls the employees ... it is probably great to churn out good software, I doubt however that great software happens in that environment
ajankovic 10y ago
It's not just developers. My friend works in the sales department and he hates it. Every functional request that he make has to go through the usual "agile" process and it's just blocked by the weeks of sprints that are trying to keep up with the increasing backlog. Some of those requests are very important and will benefit with actual real monetary results, but he has to personally escalate it through hierarchy and force dev team to break their sprint rules and force them to work on it. In other words he has to make them be agile by force.
- zzalpha 10y ago
  Some of those requests are very important and will benefit with actual real monetary results That has nothing to do with agile. That's a basic failure in product management, and would happen regardless of the dev methodology. If those features really do have such a large business impact, they should be getting prioritized (hint: the backlog isn't a rigid, time sequenced FIFO). If they're not, either the PO sucks, or the features aren't as important as the sales guy thinks relative to other items in the backlog.
- eldavido 10y ago
  As a developer, it is highly upsetting to me when sales does this. A well-functioning product development org has processes in place to decide what gets done first. These processes take into account tons of inputs including bug feedback, enhancement requests, potential for outages if something isn't fixed, long- and short-term competitive and strategic concerns, customer requests, and internally-sourced architecture requests. Then some selfish jackass comes along (from whatever department) who just can't wait because WE NEED TO GET THIS DEAL, so the entire process is thrown out the window to satisfy the whims of one customer, who may not even be large, high-revenue, or strategically important, and the wrong works gets done. Please, stop the madness. Don't go around the product team, and if you're in eng, please don't tolerate this bad behavior.
  - douche 10y ago
    Fuck those people. Sales that are that pathological are all kinds of broken.
venomsnake 10y ago
The moment the process becomes a goal instead of solution - now you have two problems. You cannot abstract away the need for common sense.
rimantas 10y ago
Listen to one of the authors of the manifesto itself: https://www.youtube.com/watch?v=a-BOSpxYJ9M https://www.youtube.com/watch?v=a-BOSpxYJ9M (BTW, he is very opposed to the use of Agile as a noun ;).
bunderbunder 10y ago
This somewhat mirrors my own experience with trying to practice Scrum: The spot where agile practices fail is invariably in management misunderstanding how it's supposed to work. Techies may get lost in bikeshedding every single user story, but it's management who hires Uncle Bob to come deliver a 1-week mandatory all hands training course and then doesn't bother to show up for it. If they had, or if hey had bothered to read a book or something, then they would probably have seen that nice chart that's invariably somewhere close to slide (or page) 4 that lists all the things that $agile_process is and is not good for, accompanied by warnings about the need to be adaptable. It's part of why I'm uncomfortable with name brand agile practices, because they make it way too easy for folks to interpret the guidelines as rules, or to interpret a useful tool as a silver bullet. For a while it bothered me so much that I was inclined to throw the baby out with the bathwater. I don't like to think that way anymore, though. Incompetent leadership will cause a team to be dysfunctional regardless of how it's organized. Blaming X or Y organizational technique for your boss's bad behavior is a gross misunderstanding of the situation.
- Zigurd 10y ago
  > If they had, or if hey had bothered to read a book or something Agile is simple, but it isn't easy at all. Without management buy-in to sit through the bikeshedding to find the technology gems among their technical talent's ideas (that they did a good job of recruiting and compensating, right?), Agile is going to turn into a swamp where mediocrities fool each other into thinking they are doing something. Doing this while engaging low-bid outsourced implementation resources is 10X harder. Unless you pay through the nose for True Believers like ThoughtWorks, you're going to get fake Agile.
  - bunderbunder 10y ago
    Oof, yeah. If what I've experienced is at all indicative, agile and outsourcing mix like nitroglycerin and shaking.
akkartik 10y ago
This was very entertaining to read, and we all engage in these these analogies between software development and building houses or bridges or whatever. But nobody talks about this implication: the reason construction is so much more reliable and robust is that our forebears tried lots of different houses and bridges before we settled on the ones we see today. That was only able to happen because nobody was insisting that all houses look alike and use the exact same materials. Since bits are easier to copy than atoms, we've made a fetish out of exact copying ("reuse"), and we peer-pressure each other to copy more with the complaint that they're "fragmenting" if they don't submit. I think it's extremely silly. When something like Android starts feeling it's too fragmented, that's just a symptom of deeper issues, and force-upgrading everyone to the newest version just keeps us from better understanding the deeper issues. Tl;dr - if you want software to be more reliable, insist less on reuse, and allow copies to diverge more.
- digi_owl 10y ago
  Nah. buildings are alike because we have measured, tested and documented every damn material for their behaviors under various uses. Thus if you want a wall of a certain size and shape, you have a list of materials to pick from depending on the weight is to carry. The reason people insist on upgrading to the latest and "greatest" software is because there are no rigidity to APIs etc. The Linux kernel gets more use than GNU/Linux user space because the kernel devs are held to a more stringent API rigidity. This makes kernel behavior predictable. Similarly, Windows, for all its warts etc, gets used in business because Microsoft built a reputation for predictable APIs. Only with 64-bit Windows can you no longer run 16-bit binaries (dating back to Windows 3.0!), and that's because the 64 and 16 bit CPU modes are mutually exclusive.
brudgers 10y ago
So we just bought a port-a-potty, and screwed around on the internet for two weeks. It seems to me, the there problem isn't agility, it's a lack of professionalism.
kelvin0 10y ago
It seems like all (pretty) good ideas, this one was meant as a set of guidelines to help teams build better software. That's until agile became a dogma (to some) and a means to an end in itself, with most the focus on getting agile 'right' and the project success being secondary. It's kinda like the idea of unions when they where first started to protect workers that were being exploited like farm animals. Nowadays some big unions could care less about the workers, and care more about their own survival as an entity and get trapped in activities which have nothing to do with their original mission. Of course, please don't see this exmaple as saying all unions are bad.
eldavido 10y ago
I'm a dev manager. We use agile, it works for us, and people are happy. All you have to do is make a giant list of all the things to do, make sure people are working enough, and on the right things, and use the appropriate level of design -- sometimes a little, sometimes more. I think the hardest thing is getting business stakeholders to get out of the "fixed project" mindset, though: here's what we want, here's how much money we have, how long will it take/how much will it cost? When the real question ought to be, what should we do first, given the budget that we have, that will most help the business? Also, devs should be treated as adults. No "planning poker", forced daily stand-ups, or any of that nonsense. Just keep your stories updated in the issue-tracking system, deliver iteratively, and keep on shipping. So much of what gets blamed on agile feels like bad org politics/poor stakeholder management.
arenaninja 10y ago
Alright, here's my Agile rant. It's bigger than my last one because I hadn't experienced it to its full potential. In my current team, it's followed religiously. Stand-ups are daily and people use it as a time to fraternize between talking about actual work, I just want to get back to work. There's no camaraderie, every retro is this one guy bitching about how things aren't done the way they were in his previous job (and usually they aren't because it wouldn't make sense). The time between demo and sprint planning is a full day's of wasted time per developer, because there's nothing to do. Every developer writes hacks and things that shouldn't pass code review get passed because there's not enough time in the sprint to implement the known-good solution. I've caught flak from going beyond the story requirements because I know what the final solution actually looks like. I also catch flak regularly because I run out of work and I take more tickets that are not in the sprint. I've never not finished a task when I did that. Every other meeting I get to hear a spiel from the project manager about how great Agile is. I'm sure there's cases where Agile is the perfect solution. But it's not every time, and the rigidity that people want to apply was never meant to be there. I wish it would go away, but it's the perfect tool for management to be able to submit reports and say "look how consistent we are!"
- pjkundert 10y ago
  > In my current team, it's followed religiously. So, not Agile then...
- ebiester 10y ago
  So, it sounds like you hate your team, and agile just makes it more obvious. So, here are the few quick fixes I see: 1. point out in retro that standups as currently constructed are a waste of time. Tell them you will utilize the law of two feet if they can't be tightened up. 2. Suggest a definition of done. If the product owner doesn't agree it meets requirements, code quality isn't high, and tests aren't there then it's' not fucking done. That means your sprints are implementing too much. 3. Don't pull in more work if other members are struggling to finish something. How can you help them out to make sure their code quality doesn't suffer? If your piece is adjacent to another that is in desperate need of refactoring/code quality improvement, just say that you needed to clean that up to implement your solution. Use that time to de-hackify.
IanDrake 10y ago
I think a lot of commenters here are missing the point being made in the short story. Agile is good for startups building a product where they don't already have a known product/market fit. It's understandable in that situation. A client of mine uses it to unburden itself with upfront design for a 3rd gen system that is well known and could easily be built with waterfall. There have been (what I would call) two false starts already. I don't see why agile is beneficial in this situation.
marssaxman 10y ago
It takes time away from real work without making that work significantly easier to accomplish. It is frequently used as a tool of control by managers who want to be in charge, thereby defeating its own reason for existence. The terms and practices tend to be hokey and faintly demeaning. The problem is not the specific body of techniques used to schedule tasks and manage time; the problem is the way that the hierarchical nature of traditional management structures diminish agency and discourage transparent communication. This leads to misapplication of effort and destroys motivation, crippling productivity. Empower people to act responsibly and they generally will. Exercise empathy and people will trust you. Give people the information they need and they will reciprocate. Agile development was an attempt at doing these things better, but it has been reduced to a collection of code words and empty rituals by managers who don't realize that it is actually their philosophy about the purpose and nature of management itself that needs to change, and not merely their choice of techniques.
robmccoll 10y ago
While well intentioned as an abstract concept, all discussions around agile as a business concept to me inevitably lead me to conclude that agile sits somewhere between a cult and a cargo cult and that anyone drinking that kool-aid will at some point in the discussion run across no true Scotsman fallacies.
snarfy 10y ago
Agile is supposed to be a development process, not a business process, but I've never seen it implemented that way.
aphextron 10y ago
It's kind of like communism. Seems great on paper, but it just never really plays out effectively.
jasim 10y ago
Agile is used to justify both rigidity as well as chaos. The one hour standups and forced sprint metrics are on one side. The utter lack of planning that is waved away by claiming agility is the other. These are two extremes, and the word seems to fit both the bills depending on who is doing the complaining.
bane 10y ago
Agile, IMHO, was meant to be a sort of zen-like "process-less process". After a few decades it became understood that software development wasn't working and doubling down on borrowed traditional engineering practices wasn't resulting in better software, only incredible delays in delivering broken software. Here's the manifesto: "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more." This is deep stuff and an incredible (and rare) set of pragmatic philosophies set down by folks who'd been suffering through the industry for a while. Processes are intended to minimize risk and ensure reproduction of already achieved work. If you aren't making yet another copy of something that already exists, you don't want a process. (sorry if this comes off a little braggardly), I've been known to run incredibly effective teams that produce tons of work very quickly. I use what I call an "Agile-ish" approach based on some personal meditations on getting software done. I call this approach the "Get Shit Done" model. 1) Is this new work or reproduction of old work (should I explore and evolve or reproduce?) 2) If this is new work, the goals are set down as very coarse milestones with exit ramps in case things are working out. 3) If this is new work, work is broken down into a check-list in a pipeline with the following steps: To Do->Doing->Paused->Done Work is first filed as tickets in To Do. When it's being worked on it moves along to Doing. If, during "Doing", new work is identified, it's created and put into "To Do". If necessary the current work that's "blocked" is simply moved into "paused". Once Paused work is unblocked, it moved back into "Doing". It either finished, creates new work tasks or is paused again. Rinse and repeat. Kanban boards work pretty well for this, but you can do it with a spreadsheet in a pinch just fine. 4) If this is new work, work is only considered "Done" if it's checked in, tested and documented (and builds). Everybody hates it when they're doing it, everybody loves it when they need to figure something out later and the customers drool over getting rapid delivery of already documented, tested and validated stuff. This scales pretty well for teams of 1-to-100 (but starts to strain on the larger sizes). Teams are organized into hierarchies each with their own pipelines. Each team has a team-lead. I meet once a week with all the team leads and require all team leads to meet with their teams once a week. During crunches or abnormal events, we meet more often. This creates a cascading "clock" that identifies things that are taking too long and might need extra attention. I give team leads extraordinary autonomy to figure out the details at their level. This also gives people a week to be create and figure out ways around issues and problems. Team members can generally float or matrix if needed. Work moves along a general "discover, productionize, deploy" model. What's amazing about software is that it's almost always new work. If it's not new work, you still don't really need a process to reproduce it. Just copy the code into the new place, configure it and start it up. This is unlike any other engineering endeavor in human history and it takes entirely new ways of thinking to get it done. What I've found is that many many organization simply want to repurpose waterfall models and apply "Agile" sounding names to everything. I once turned down work because the customer had a 500+ page manual on their formal "Agile Software Process Methodology". No, no, no, NO. You don't get it. Here's another protip: Sprints are for engineering, Kanban is for Research. If you know what you are doing, use Sprints to force a development clock. If you don't know what you are doing and need to figure it out, Sprints just make everybody angry and create useless artificial pressure that accomplished nothing. If you're engineering, you already know what to do, Sprints help provide motivational energy.

68 points by vatotemking 10y ago

Paraphrasing a comment on /r/programming about this yesterday: If there is a decent set of requirements, then the framework used is irrelevant.

taneq 10y ago
But Agile, as I understand it at least, is explicitly designed for cases when requirements aren't fully known.
- Zigurd 10y ago
  Moreover, Agile is about realizing there is value in reconsidering your requirements as you discover opportunities, or encounter problems. You may think you know all the requirements. But that it often an illusion or a rigidness that prevents a better result.
- forgottenpass 10y ago
  Agile is designed for that case, but most development methodologies are designed for that case. The idea that requirements are set in stone, or - more specifically - the idea that not setting them in stone is breaking conventional wisdom is just running us in circles. Requirements are just a name for detailed goals. They change as goals change. Diffs can be applied them just as easily as to the codebase. Maybe a team has them over emphasized and too rigid, maybe too undocumented and in flux. But prescriptive development methodology doesn't give teams tools to figure out what works for their projects. Development processes aren't really improving with every new trendy thing that comes out, they're just finding new ways to package and shuffle things around.
  - taneq 10y ago
    > but most development methodologies are designed for that case Modern (ie. post-XP) software methodologies, yes. Traditional engineering? Not at all. Software is unique in that it's essentially free to convert your design into your end product. It's one thing to iterate weekly when your build process costs $0.02 of electricity and half an hour of server time. It's another thing entirely when you have to obtain many different parts (some with long lead times, others custom built, and small batches always cost far more per unit) and then assemble them manually before testing a physical object.

joeblow9999 10y ago

Agile is for managing upward and a lot of developers would rather, you know, develop

pcmaffey 10y ago

What's ironic about this metaphor is that Agile's roots can be found in building construction. We all know the story of Toyota, but where did Toyota come up with the idea? From Japanese stone masons. The nature of building with stone is such that you never truly know what resources you have to work with. The shape, color, texture of stone is all variable. This means too that the way each component fits together is unpredictable. For the eye of a master builder, who constructs edifices with each relationship perfectly balanced, each component placed intentionally, who can see every step of the process and what each choice means for the integrity of the whole, such a craftsman understands that every day brings with it a whole new set of variable inputs, which can never be planned for, spec'ed out, or tasked to laborers who do not see the whole. Modern construction cares nothing for such craft. It will be the domain of robots. Software development too will follow this path, as we humans are suckers for predictability. But such a road will be littered with people suffering in jobs that make them feel like robots, projects that fall flat, and endless repeating boxes of sameness.

dschiptsov 10y ago
Construction, it seems, is a "waterfall" by definition, and, it is, probably, from architecture the model took its roots. Agile came from business and finance, where everything is uncertain and even not well understood.
- ethbro 10y ago
  As someone who studied the field, construction in abstract seems a waterfall model. Construction in practice requires something very similar to agile: too many uncontrolled real world variables, interdependent timelines, and sheer laws of physics. If everything goes right, yes waterfall. Everything never goes right.
  - mixmastamyk 10y ago
    In rare circumstances everything must go right beforehand, e.g. the New Horizons probe to Pluto.
10y ago

wpietri 10y ago

Hi! Early Agile person here, but I hate what the term Agile has become. [1] I think there are a lot of good reasons to grumble about Agile, especially when management use it as a stick to beat developers. But I don't think the problem described here is one of them. I think expecting business to know what they want is a mistake. When my dad was making software in the 60s, 70s, and 80s, we were mainly automating existing business process, so we could draft behind all the hard work done working out the right paper forms and reports. But modern software comes from a process of experimentation and discovery, competition and evolution. As the people who understand the technology best, we should be as part of that process from beginning to end. This analogy is misleading because software gives us power that we don't have in the real world. If we start with port-a-potties and want real bathrooms, we just have to change the description of a bathroom and the computer will do the rest. In software, if you are disciplined about automated testing, refactoring, and keeping up with technical debt, an evolving architecture is totally doable. I think where people fall down is that they don't believe that managers will give them enough time to keep things clean as they go. And I agree, they won't. You have to take the time. But if you do it from day one you can do it gradually and incrementally. You can gradually redirect management pressure away from developers and toward making better product choices. So please let's take control of our working conditions back. We're professionals, and we can say, "No, I'm still writing tests. That's a best practice, and it would be negligent for me to leave that out." But we can do that while delivering incrementally, so that no week goes by without the business getting some new benefit in production. [1] http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...

existencebox 10y ago
Let me give two stories. I am in full agreement with your statement, however want to give supporting evidence as part of a "I'm not sure how to push back well even after all these years without compromising a lot of political capital". 1. Just this week, I watched a manager wait until after I was on vacation, and then publicly chew out my employee for slipping a deadline. I would agree he should have pushed harder, BUT he slipped it due to our peers being very rigorous on his CR (he is a new employee) to bring him up to standards. (I would add we would have had even MORE buffer had the person in question not continued to change the spec 2 months into a 3 month project, which can happen, but should be acknowledged as a cost) . The manager in question found this (the deadline slipping) regardless unacceptable and gave him grief in front of the whole team about it, and this is the second time I've watched the manager place these meetings when I'm going to be gone because otherwise I come down like a bag of bricks on someone going after my employees. But to why I mention that last sentence regarding my nature, NO AMOUNT of this seems to motivate positive change in the long run, _especially_ since I'm "managing up" and having to do this as an engineer myself, any big "push" I make costs a lot of effort and karma, and doesn't seem to stick long term despite my best efforts. 2. More specifically, I had a conversation you summarized above (taking TIME to dev well) just a few weeks ago with my manager. Over the last few years we've repeated a pattern, I take longer than he'd like, he gives me shit for it, I tell him it'll pay dividends long term, he grumbles, but then it does. (bug rates, iteration speed under frameworks I write, reuse due to good modularity/code cleanliness, these are all benefits you see rendered on a very short time scale, even just keeping with the most broad basics.) Now, I will give him credit for saying "you have a point and I'll leave it to your judgement" but that took me _two years_ of very incendiary 1:1's of my trying to put my money where my mouth is against someone who has been at this a lot longer than me and with some very strong opinions about that. I frankly don't see a "shortcut" after that experience, although the conclusion was more positive. So let me tie up this ramble with addressing your conclusion: I'd LOVE to take control of my working conditions back. But when the same people (PMs) who lead to my just throwing my hands up at even TRYING to get work done at work due to constant context switching/interruptions _SCHEDULE MEETINGS_ asking us why we're so slow (and then spend the whole meeting complaining about how WE pull them into meetings they don't need), it seems like there are just massive gaps of understanding or lack of shared incentive between the various powers that be. I don't know how to take control of my working condition back, but I've damn well been trying, and would be curious to hear any anecdotal suggestions from you in working this through more "political" environments.

dschiptsov 10y ago

Because the way you manage an orchestra does not eliminate the necessity of each musician to be able to perform decently?

fatdog 10y ago

Agile, like anything, is perfect when you implement it perfectly. Nobody does, but it's not the method's fault, the method is perfect. What I have seen is it used as a chip on the shoulders that makes product meetings feel like dealing with communist border guards. Working in Agile shops can be a lot like watching lab mice running a maze. You try to say, "hey, so this path you are working on, there is a map for it when it was solved in <discipline x>." and the response was, "this is Agile, we don't take grand designs or waterfall requirements, and we don't need anymore chickens in our standup." Or you say, "hey, so this thing you are building, for someone to buy it, we're going to have to explain to them why it's good and how it meets their expectations, can we create a sequence diagram or a model so I can plug in how it meets standards and regulations and code and such?" and the response is, "we don't need documentation, the code is documented, and if you had provided us with the requirements we could prove it in our unit testing." The trouble I have with a lot of engineering and dev culture is what it lacks, and often irrationally rejects, is balancing the technical understanding with a top down view. The best engineers have or at least appreciate this, and they bring it with them. Unfortunately this gets them immediately promoted to roles where they aren't actually writing code. I've used this house building simile in Agile shops before, where any bunch of carpenters, electricians, plumbers and brick layers can build a fine house that will stand up, but the matter of whether anyone will want to live in it, buy it, insure it, legally sell it, live anywhere near it, or trust that it won't be knocked down by local climate or regulations - is an equally complex problem you need someone with expertise to solve. Everyone has complains, devs about managers, managers about devs, it's an age old problem. A lot of Agile gets used to formalize an adolescent culture. I look forward to the pendulum swinging back to a more balanced equilibrium.

drumdance 10y ago
This is a frustration I had in my most recent project. Management did a good job of coming up with interesting features in the abstract, but a terrible one of communicating those features and working them into the app in a way that was intuitive. I often found myself saying, "this is potentially a good feature, but how do we explain it?" We never had a good designer on staff, so that was a huge part of the problem. A couple times we used outside designers but they didn't have a holistic view of the app, so their designs created as many questions as they answered.

taneq 10y ago

People hate Agile now for the same reasons people hated "extreme programming" before it: Mismanagement based on a few misunderstood buzzwords. Extreme programming had the de-emphasis on documentation in favour of verbal communication, which got garbled into "just don't document anything". Agile has sprints, which has been twisted into "crunch time every two weeks for two weeks".

digi_owl 10y ago
And devops turns into "end user is QA"?

KaiserPro 10y ago

The whole point of Agile was "people not processes" However because at my company we have professional scrum masters, everything must be religiously Agile. This means that we must have a standup, everyday. we must have a retro, we must have planning. almost half a day a week is lost to pointless meetings. I just want to get on with my job. Trust me to use the ticketing system to figure out what I'm doing and raising blocking issues.

davidgerard 10y ago
The free E-meter at every desk is a valuable job perk! The Kool-Aid tasted a bit funny, though. sprint: artificial crisis end of sprint: abandonware Scrum Master: CV credit for my planned escape to a new company stakeholder: someone you can't get away with externalising your costs onto, because they can hammer a wooden spike through your heart Project Manager: a job that no longer needs to exist in the astounding new world of Scrum! (Pay no attention to the project owners, product owners, story-writing users above you in the org chart or Scrum Masters behind the curtain.) simplified: doesn't implement the actual business requirements lightweight: doesn't implement the actual business requirements, but does so much more elegantly than the version that works easy: project was born circling the drain (and doesn't implement the actual business requirements) legacy: the version that works and implements the actual business requirements, though no sane human wants to touch it user story: a valiant attempt to extract coherent requirements and bug reports; ends up being precise specifications for the wing feathers of the desired magical flying unicorn pony velocity: a speed with a direction: skittering about following marketing's random hairpin turns retrospective: blamestorm incoming! stand-up: establishing blamestorm targets early Inspect and Adapt: perhaps bong hits will fix my makefile We'll put that on the backlog: ahaha fuck you doing Agile wrong: noticing any of the above. I do enjoy some of the jargon. empowered: do your own fucking job. "Could you just copy down these log files from these fifteen servers for me and put them on the shared drive? Thanks." "I'm sorry, I'm afraid you're empowered to do that." Every good idea is turned into a bad one by the relentless management quest to Taylorise clue. (originally posted by me at https://reddragdiva.dreamwidth.org/594955.html https://reddragdiva.dreamwidth.org/594955.html )
- 10y ago

quantumhobbit 10y ago

The problem with modern "Agile" and frankly all other software development methodologies is the mismatch between the knowledge and expectations of the business and tech. Business and tech tend to use Agile to keep each other at arms length and never learn about what the other does. This is a shame because originally agile was about forcing business and tech to work closely and interact regularly. Hence the short sprints and frequent stand ups. In the parent example the management should have known enough about building to realize they were a creating a clusterfuck, and the builders should have had enough knowledge and input to the business to figure out what they were supposed to be building. When both sides assume the other is too stupid to work with and avoids meaningful interaction, it shouldn't be a surprise when the result is a hacked together mess.

bengale 10y ago
The problem I've seen is rather than forcing the business and tech to understand and work with each other managers are hired to do 'agile' and basically proxy for the business. They don't know anything more than developers do, and while there is more iterative development, the feedback is coming from the wrong people. It just becomes useless meetings and checkboxes.

vemv 10y ago

Probably an essential mistake is to put multiple people to work on a greenfield project at once, when the requirements are particularly uncertain. Better to allocate a single full-stack dev to experiment for a couple weeks. He also will interact with the business owner daily. Let him focus on the business logic and also the core user interactions. On top of that MVP foundation (i.e. on week 3), you can put the rest of the team to refine backend, frontend, graphic design and so on.

ninkendo 10y ago
> Probably an essential mistake is to put multiple people to work on a greenfield project at once, when the requirements are particularly uncertain. This statement rings so true to me that I really hope there exists a fleshed out version of this theory, with examples to prove it and maybe a catchy name, etc. Where I am now, I've literally participated in an identical thing being built in two ways at two different times: - The first time, I was the initial full-stack dev, along with one other guy (we were more of a duo... we paired a lot and worked pretty fluidly, it was kind of a 2-person equivalent of a single-person experiment.) The result was finished in 3 weeks and was flimsy but cohesive. Eventually the team was reduced to just me and I carried out the project for a few more months before a proper "team" was on board. - Then, the company noticed what we had done, decided that a bunch of other people had done similar things (it's a large company, after all), and then a 250-person organization was formed to write an MVP that was largely identical in scope. I wasn't in any leadership position in this new org, so nobody really cared that I had experience in this. I was reduced to writing a tiny insignificant part of the larger whole while our director drove the requirements. We're 10 months in and haven't shipped the first milestone yet. In the first example, we were almost too successful. The resulting product was used by thousands of people, for important things, with a lot of satisfaction and kudos from the users. But the total size of the team never really exceeded 5-10 people, so it got to the point where we were burned out supporting it, and there weren't enough reserves to call in to help because of the "second system" distracting everyone: In the second case, we don't have our first customer yet (although we've only kind of "soft" launched.) We did a massively half-assed attempt at agile that was basically "waterfall, but more vague, and please work harder", where we kinda half-assed came up with requirements, split everything up into 10-15 major "tentpoles", each of which was developed by separate teams. 6 months later we decided to start "integrating" all of it. 4 months after that, things finally kinda sorta work end-to-end. I've gone through a ton of self doubt through the process. In the first case, it worked only because there was almost no communication: we just did what we felt like, explored, and we were lucky that the end result worked. "Clearly, this will never scale, and is no way to run a real software product", I remember thinking. When the org got huge and we did our second system, I thought "Finally, I can learn to do what real software devs do and work for a big team with communication and requirements, etc". And inevitably when the result is a big pile of shit, I can't shake the feeling "this would've been better if I knew how to do real software development and work with a large team." Self loathing ensues. So I witnessed the pendulum swing each way. The first way was massively successful, but I suspect isn't sustainable (the product is withering due to lack of support now.) The second isn't successful at all, and is a complete mess, but maybe it'll be better with time. The only thing I know for sure is that few companies in the world can afford the amount of wasted time and energy we've spent on the second system. I suspect the real world works more like the first case but I don't have enough experience to know. I can't shake the thoughts of "I haven't seen real software development yet", and I don't know how much validity there is behind those doubts.

InclinedPlane 10y ago

Agile is just a collection of stuff that people put together in order to ensure useful productivity from arbitrary teams. Often it's misapplied and misused, usually in order to micromanage. The roots of agile come from the bad old days when the typical software project was a consulting gig with an elaborate negotiated spec and schedule and a huge disconnect between the buyers and the developers, let alone the users. And when the "software crisis" was in full swing, and many software projects failed to deliver anything of use, at all. Back in the days when even using source control wasn't common, and when regular builds and smoke tests were even rarer. Agile ensures a few things: It ensures that you use an incremental development strategy: start with something simple that works, then iteratively add to it over the course of short periods of work to move it closer to the desired state of functionality and capability. Because you routinely have workable builds this means you will always have something to show for your work at the end, because you have a pattern of having something working all the time. It pushes the team toward continuous integration and regular builds with testing. Which avoids building up invisible technical debt due to undone integration work as the project progresses. Agile avoids the "big bang integration" problem. It pushes the team toward visibility and interaction, so they get to know what everyone else is working on and it forces collaboration related to integration ASAP, all of which helps increase team cohesion and leads to higher code quality. People get to see the products of other's work routinely, making it easier to see what they're good at (and not) and aiding team mates in learning from one another. It avoids unnecessary over-complications and the tendency to procrastinate, such as the notorious "second system effect". It ensures that people stay concentrated on real milestones and real work not pie in the sky perfect systems with schedule estimates off by orders of magnitude or not even feasibly possible. It gives the "stakeholders" more visibility into the work. The product itself becomes the ground truth for the product, rather than a spec or a memo or a contract. If those folks have concerns they can be addressed and taken care of before it is extremely costly to fix. And if they want to make changes to the design relative to their initial thoughts, that too can be done fairly easily, resulting in an end product that is more suitable than would be the case otherwise. And it ensures that sprint by sprint, work gets done, the product moves forward. With good teams this isn't a problem, but in the "enterprise trenches" with demotivated teams of average or below average coders this can be a real problem. It can be difficult to get anything done, let alone anything more than just spinning their wheels. All of these things are for the most part good things, and they are the reason why the concept of agile has become so pervasive. The problem is that today a lot of the agile basics just go without saying (continuous integration, routine builds and testing, iterative development, short sprints for work, and so on) while some of the other aspects end up being applied in a cargo cult manner with no comprehension for why they were used as well as when they are warranted and when not. Even if agile practices were being used correctly most of the time, which they aren't, it still would not be a good one size fits all practice for all circumstances. Moreover, the modern perversions of agile have done a lot of damage. Removing opportunities for use of initiative, creativity, and expertise by many coders, taking responsibility for even the tiniest decision out of their hands and transforming them into children. In some ways agile is like a remedial course in software engineering, but a lot of high caliber developers are finding themselves stuck with it even though it is restrictive and harmful, because management is thoughtless.

walkingolof 10y ago

I see the benefits with agile, but I cant help feeling that something is lost in a process that so completely controls the employees ... it is probably great to churn out good software, I doubt however that great software happens in that environment

ajankovic 10y ago

It's not just developers. My friend works in the sales department and he hates it. Every functional request that he make has to go through the usual "agile" process and it's just blocked by the weeks of sprints that are trying to keep up with the increasing backlog. Some of those requests are very important and will benefit with actual real monetary results, but he has to personally escalate it through hierarchy and force dev team to break their sprint rules and force them to work on it. In other words he has to make them be agile by force.

zzalpha 10y ago
Some of those requests are very important and will benefit with actual real monetary results That has nothing to do with agile. That's a basic failure in product management, and would happen regardless of the dev methodology. If those features really do have such a large business impact, they should be getting prioritized (hint: the backlog isn't a rigid, time sequenced FIFO). If they're not, either the PO sucks, or the features aren't as important as the sales guy thinks relative to other items in the backlog.
eldavido 10y ago
As a developer, it is highly upsetting to me when sales does this. A well-functioning product development org has processes in place to decide what gets done first. These processes take into account tons of inputs including bug feedback, enhancement requests, potential for outages if something isn't fixed, long- and short-term competitive and strategic concerns, customer requests, and internally-sourced architecture requests. Then some selfish jackass comes along (from whatever department) who just can't wait because WE NEED TO GET THIS DEAL, so the entire process is thrown out the window to satisfy the whims of one customer, who may not even be large, high-revenue, or strategically important, and the wrong works gets done. Please, stop the madness. Don't go around the product team, and if you're in eng, please don't tolerate this bad behavior.
- douche 10y ago
  Fuck those people. Sales that are that pathological are all kinds of broken.

venomsnake 10y ago

The moment the process becomes a goal instead of solution - now you have two problems. You cannot abstract away the need for common sense.

rimantas 10y ago

Listen to one of the authors of the manifesto itself: https://www.youtube.com/watch?v=a-BOSpxYJ9M https://www.youtube.com/watch?v=a-BOSpxYJ9M (BTW, he is very opposed to the use of Agile as a noun ;).

bunderbunder 10y ago

This somewhat mirrors my own experience with trying to practice Scrum: The spot where agile practices fail is invariably in management misunderstanding how it's supposed to work. Techies may get lost in bikeshedding every single user story, but it's management who hires Uncle Bob to come deliver a 1-week mandatory all hands training course and then doesn't bother to show up for it. If they had, or if hey had bothered to read a book or something, then they would probably have seen that nice chart that's invariably somewhere close to slide (or page) 4 that lists all the things that $agile_process is and is not good for, accompanied by warnings about the need to be adaptable. It's part of why I'm uncomfortable with name brand agile practices, because they make it way too easy for folks to interpret the guidelines as rules, or to interpret a useful tool as a silver bullet. For a while it bothered me so much that I was inclined to throw the baby out with the bathwater. I don't like to think that way anymore, though. Incompetent leadership will cause a team to be dysfunctional regardless of how it's organized. Blaming X or Y organizational technique for your boss's bad behavior is a gross misunderstanding of the situation.

Zigurd 10y ago
> If they had, or if hey had bothered to read a book or something Agile is simple, but it isn't easy at all. Without management buy-in to sit through the bikeshedding to find the technology gems among their technical talent's ideas (that they did a good job of recruiting and compensating, right?), Agile is going to turn into a swamp where mediocrities fool each other into thinking they are doing something. Doing this while engaging low-bid outsourced implementation resources is 10X harder. Unless you pay through the nose for True Believers like ThoughtWorks, you're going to get fake Agile.
- bunderbunder 10y ago
  Oof, yeah. If what I've experienced is at all indicative, agile and outsourcing mix like nitroglycerin and shaking.

akkartik 10y ago

This was very entertaining to read, and we all engage in these these analogies between software development and building houses or bridges or whatever. But nobody talks about this implication: the reason construction is so much more reliable and robust is that our forebears tried lots of different houses and bridges before we settled on the ones we see today. That was only able to happen because nobody was insisting that all houses look alike and use the exact same materials. Since bits are easier to copy than atoms, we've made a fetish out of exact copying ("reuse"), and we peer-pressure each other to copy more with the complaint that they're "fragmenting" if they don't submit. I think it's extremely silly. When something like Android starts feeling it's too fragmented, that's just a symptom of deeper issues, and force-upgrading everyone to the newest version just keeps us from better understanding the deeper issues. Tl;dr - if you want software to be more reliable, insist less on reuse, and allow copies to diverge more.

digi_owl 10y ago
Nah. buildings are alike because we have measured, tested and documented every damn material for their behaviors under various uses. Thus if you want a wall of a certain size and shape, you have a list of materials to pick from depending on the weight is to carry. The reason people insist on upgrading to the latest and "greatest" software is because there are no rigidity to APIs etc. The Linux kernel gets more use than GNU/Linux user space because the kernel devs are held to a more stringent API rigidity. This makes kernel behavior predictable. Similarly, Windows, for all its warts etc, gets used in business because Microsoft built a reputation for predictable APIs. Only with 64-bit Windows can you no longer run 16-bit binaries (dating back to Windows 3.0!), and that's because the 64 and 16 bit CPU modes are mutually exclusive.

brudgers 10y ago

So we just bought a port-a-potty, and screwed around on the internet for two weeks. It seems to me, the there problem isn't agility, it's a lack of professionalism.

kelvin0 10y ago

It seems like all (pretty) good ideas, this one was meant as a set of guidelines to help teams build better software. That's until agile became a dogma (to some) and a means to an end in itself, with most the focus on getting agile 'right' and the project success being secondary. It's kinda like the idea of unions when they where first started to protect workers that were being exploited like farm animals. Nowadays some big unions could care less about the workers, and care more about their own survival as an entity and get trapped in activities which have nothing to do with their original mission. Of course, please don't see this exmaple as saying all unions are bad.

eldavido 10y ago

I'm a dev manager. We use agile, it works for us, and people are happy. All you have to do is make a giant list of all the things to do, make sure people are working enough, and on the right things, and use the appropriate level of design -- sometimes a little, sometimes more. I think the hardest thing is getting business stakeholders to get out of the "fixed project" mindset, though: here's what we want, here's how much money we have, how long will it take/how much will it cost? When the real question ought to be, what should we do first, given the budget that we have, that will most help the business? Also, devs should be treated as adults. No "planning poker", forced daily stand-ups, or any of that nonsense. Just keep your stories updated in the issue-tracking system, deliver iteratively, and keep on shipping. So much of what gets blamed on agile feels like bad org politics/poor stakeholder management.

arenaninja 10y ago

Alright, here's my Agile rant. It's bigger than my last one because I hadn't experienced it to its full potential. In my current team, it's followed religiously. Stand-ups are daily and people use it as a time to fraternize between talking about actual work, I just want to get back to work. There's no camaraderie, every retro is this one guy bitching about how things aren't done the way they were in his previous job (and usually they aren't because it wouldn't make sense). The time between demo and sprint planning is a full day's of wasted time per developer, because there's nothing to do. Every developer writes hacks and things that shouldn't pass code review get passed because there's not enough time in the sprint to implement the known-good solution. I've caught flak from going beyond the story requirements because I know what the final solution actually looks like. I also catch flak regularly because I run out of work and I take more tickets that are not in the sprint. I've never not finished a task when I did that. Every other meeting I get to hear a spiel from the project manager about how great Agile is. I'm sure there's cases where Agile is the perfect solution. But it's not every time, and the rigidity that people want to apply was never meant to be there. I wish it would go away, but it's the perfect tool for management to be able to submit reports and say "look how consistent we are!"

pjkundert 10y ago
> In my current team, it's followed religiously. So, not Agile then...
ebiester 10y ago
So, it sounds like you hate your team, and agile just makes it more obvious. So, here are the few quick fixes I see: 1. point out in retro that standups as currently constructed are a waste of time. Tell them you will utilize the law of two feet if they can't be tightened up. 2. Suggest a definition of done. If the product owner doesn't agree it meets requirements, code quality isn't high, and tests aren't there then it's' not fucking done. That means your sprints are implementing too much. 3. Don't pull in more work if other members are struggling to finish something. How can you help them out to make sure their code quality doesn't suffer? If your piece is adjacent to another that is in desperate need of refactoring/code quality improvement, just say that you needed to clean that up to implement your solution. Use that time to de-hackify.

IanDrake 10y ago

I think a lot of commenters here are missing the point being made in the short story. Agile is good for startups building a product where they don't already have a known product/market fit. It's understandable in that situation. A client of mine uses it to unburden itself with upfront design for a 3rd gen system that is well known and could easily be built with waterfall. There have been (what I would call) two false starts already. I don't see why agile is beneficial in this situation.

marssaxman 10y ago

It takes time away from real work without making that work significantly easier to accomplish. It is frequently used as a tool of control by managers who want to be in charge, thereby defeating its own reason for existence. The terms and practices tend to be hokey and faintly demeaning. The problem is not the specific body of techniques used to schedule tasks and manage time; the problem is the way that the hierarchical nature of traditional management structures diminish agency and discourage transparent communication. This leads to misapplication of effort and destroys motivation, crippling productivity. Empower people to act responsibly and they generally will. Exercise empathy and people will trust you. Give people the information they need and they will reciprocate. Agile development was an attempt at doing these things better, but it has been reduced to a collection of code words and empty rituals by managers who don't realize that it is actually their philosophy about the purpose and nature of management itself that needs to change, and not merely their choice of techniques.

robmccoll 10y ago

While well intentioned as an abstract concept, all discussions around agile as a business concept to me inevitably lead me to conclude that agile sits somewhere between a cult and a cargo cult and that anyone drinking that kool-aid will at some point in the discussion run across no true Scotsman fallacies.

snarfy 10y ago

Agile is supposed to be a development process, not a business process, but I've never seen it implemented that way.

aphextron 10y ago

It's kind of like communism. Seems great on paper, but it just never really plays out effectively.

jasim 10y ago

Agile is used to justify both rigidity as well as chaos. The one hour standups and forced sprint metrics are on one side. The utter lack of planning that is waved away by claiming agility is the other. These are two extremes, and the word seems to fit both the bills depending on who is doing the complaining.

bane 10y ago

Agile, IMHO, was meant to be a sort of zen-like "process-less process". After a few decades it became understood that software development wasn't working and doubling down on borrowed traditional engineering practices wasn't resulting in better software, only incredible delays in delivering broken software. Here's the manifesto: "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more." This is deep stuff and an incredible (and rare) set of pragmatic philosophies set down by folks who'd been suffering through the industry for a while. Processes are intended to minimize risk and ensure reproduction of already achieved work. If you aren't making yet another copy of something that already exists, you don't want a process. (sorry if this comes off a little braggardly), I've been known to run incredibly effective teams that produce tons of work very quickly. I use what I call an "Agile-ish" approach based on some personal meditations on getting software done. I call this approach the "Get Shit Done" model. 1) Is this new work or reproduction of old work (should I explore and evolve or reproduce?) 2) If this is new work, the goals are set down as very coarse milestones with exit ramps in case things are working out. 3) If this is new work, work is broken down into a check-list in a pipeline with the following steps: To Do->Doing->Paused->Done Work is first filed as tickets in To Do. When it's being worked on it moves along to Doing. If, during "Doing", new work is identified, it's created and put into "To Do". If necessary the current work that's "blocked" is simply moved into "paused". Once Paused work is unblocked, it moved back into "Doing". It either finished, creates new work tasks or is paused again. Rinse and repeat. Kanban boards work pretty well for this, but you can do it with a spreadsheet in a pinch just fine. 4) If this is new work, work is only considered "Done" if it's checked in, tested and documented (and builds). Everybody hates it when they're doing it, everybody loves it when they need to figure something out later and the customers drool over getting rapid delivery of already documented, tested and validated stuff. This scales pretty well for teams of 1-to-100 (but starts to strain on the larger sizes). Teams are organized into hierarchies each with their own pipelines. Each team has a team-lead. I meet once a week with all the team leads and require all team leads to meet with their teams once a week. During crunches or abnormal events, we meet more often. This creates a cascading "clock" that identifies things that are taking too long and might need extra attention. I give team leads extraordinary autonomy to figure out the details at their level. This also gives people a week to be create and figure out ways around issues and problems. Team members can generally float or matrix if needed. Work moves along a general "discover, productionize, deploy" model. What's amazing about software is that it's almost always new work. If it's not new work, you still don't really need a process to reproduce it. Just copy the code into the new place, configure it and start it up. This is unlike any other engineering endeavor in human history and it takes entirely new ways of thinking to get it done. What I've found is that many many organization simply want to repurpose waterfall models and apply "Agile" sounding names to everything. I once turned down work because the customer had a 500+ page manual on their formal "Agile Software Process Methodology". No, no, no, NO. You don't get it. Here's another protip: Sprints are for engineering, Kanban is for Research. If you know what you are doing, use Sprints to force a development clock. If you don't know what you are doing and need to figure it out, Sprints just make everybody angry and create useless artificial pressure that accomplished nothing. If you're engineering, you already know what to do, Sprints help provide motivational energy.