Hacker News new | comments | ask | show | jobs | submit login
In a nutshell, why do a lot of developers dislike Agile? (quora.com)
68 points by vatotemking on July 9, 2016 | hide | past | web | favorite | 86 comments



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.


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 )


I'd say that if any of that is happening, then yes, you're doing agile wrong. :)

Most importantly, a product where that happens is missing a definition of done. Done includes, among other things, automated tests, good code quality, and a product owner looking at it and saying, "yes, this will actually meet the business requirements." If it doesn't get done within the 2 weeks, then it rolls over to the next two weeks. If not enough shit gets done in a 2 week sprint (and yes, I hate sprint as a concept), then you schedule less work.

That two weeks are efforts to work in small chunks (something good developers do anyway) and give a general sense of when the project will be done. That means that everyone is aware earlier that a project's scope or timeline is unrealistic. You're doing this rewrite because shit is slow to change; it's the developers' fucking job to point out that repeating the same problem again is a waste of money.

(Agile means pointing out unicorn fantasies as early as possible as to make the hard decisions before the project is 3 months late.)

Now, personally, I prefer continuous flow boards and cycle time to measure that. Then, you can skip the sprint bullshit, but that's a detail.

Finally, the problem you describe is a rewrite. If the problem is that nobody wants to touch that code with a ten foot pole, then you are "fucking empowered" to spend that same time to clean that shit up. Unless business requirements have changed and the software is no longer the right thing to do (see: implements the actual business requirements) then the right, sane thing to do is get a copy of Michael Feathers' Working With Legacy Code and dig in.

Using an agile methodology to do a dumb thing doesn't make it any more or less dumb.


As I said: "Every good idea is turned into a bad one by the relentless management quest to Taylorise clue."


I think you're onto something here. I like to refer to them as "little-a" agile (iterative delivery, accept change, basically the original manifesto) and "big-A" agile: scrum masters, stand-ups, all that.

Devs have to act like adult professionals though, and keep their issues updated, otherwise they deserve the long, boring meetings they so loathe :)


This means that we must have a standup, everyday. we must have a retro, we must have planning.

Every single one of those ritutuals has value.

Just because you're happy coding quietly, alone, in a darkened room with the door shut, doesn't mean everyone is.

I have yet to see an agile shop that doesn't benefit from stand-up to keep the team coordinated and on track. And retros are the forum for self-management and process refinement/iteration.

Moreover, some of those rituals (like sprint planning) are also needed by stakeholders other than the developers themselves in order to get their jobs done. Because, believe it or not, coders are not in fact the center of the universe.

almost half a day a week is lost to pointless meetings. I just want to get on with my job.

Woah, wait, wut? 90% of your time is apparently spent coding and that's a problem for you? You know, at some point this starts to sound a lot like an excessive sense of entitlement...


Nice, jump to the asperger stereotype.

Every single one of those rituals has value. For you/your company. why? because Agile is empiric. Every company is different.

The whole point of Agile, is to be nimble, and respond to evidence. I know what my customer wants, because I talk to them. Funnily enough I like my customers. I want to know how they are using my services. I like talking to people because I am human.

Because my stakeholders are different to my customers, I have to actively fight "Agile" to get my job done. I have to do the TCO calcs, I have to fight for my resources. The feedback loop is looping on the wrong part. But because the agile book says its ok, it must not be changed. But its ok "People not process".

I have once been in a company where agile was done "right". It was refined to the point where we had one meeting a week(effectively a retro).

Feedback was done through jira, which provides rich metrics. Collaboration was expected to happen as and when it was needed. If you couldn't figure it out, then you were in the wrong job. you needed to be able to talk human.

Why is that agile? because the process was mapped to the company, and tweaked until it produced measurable results. Not the other way round.

Everywhere else it feels like agile is a religion that must be observed, never questioned. Woe betide anyone that dares question the knowledge of the vicar as they mumble the softly spoken spells during stand up.


> Every single one of those rituals has value. Just because you're happy coding quietly, alone, in a darkened room with the door shut, doesn't mean everyone is.

The reverse is also true. Just because a daily standup has value for some doesn't mean it has value for everyone.


When I was at (unnamed-giant-online-retailer) we had a big project for a while that resulted in having standups that had about a dozen people in them and lasted about 45 minutes to an hour typically. Every day.

My mind still boggles how nobody else questioned such a misuse of resources.


At (unnamed-giant-bank) for our standups, our scrum master would open the Jira agile board, go through every single ticket in the entire sprint and have the assigned developer give an update. This included tickets still in the to-do category. The developer would literally have to say "no progress" on 20+ tickets every day.

The entire team including PMs, design, business dev, etc. would be present everyday for that absolutely excruciating 1 hour long meeting.


A standup's supposed to be a time for everyone to give a very brief status update, and not much more than that.

If your standup has a dozen people and takes 45 minutes, that implies that either everyone's taking about four minutes to say what they should be able to cover in 2 or 3 sentences. That or someone's missed the point and your standup has turned into the kind of meeting that standups are explicitly not supposed to be, only without the chairs.


To me this is a major problem with agile. No one actually agrees on what it actually is. Any criticism is met with "your not doing it right".


No, the definition of a stand-up meeting is literally a quick meeting that you stand up for because it's so fast.

A 45 minute meeting is by definition not a stand-up... physically it just makes no sense.


Can you point me to an official definition of a stand up meeting? Or is this just another case of "your doing it wrong"?


Well, there's no governing standards committee on the English language, so I can't really provide you with an official definition. But here's the Wikipedia article - based on my skimming, its description seems about right to me:

https://en.wikipedia.org/wiki/Stand-up_meeting

I'm not wild about people trying to be pedantic about rigidly adhering to some idealized Agile-with-a-capital-A. But it's not rules lawyering to say that someone's completely missed the boat. And it sounds like whoever implemented the process at your former employer completely missed the boat.


I was at (unnamed-giant-online-retailer) and a team of 12 too. Our rule is to speak with one foot standing so you have to speak fast... It takes 90 seconds per person usually, sometimes ending with "hey Dave, I need your help in X, let's talk it afterwards".

Same process run by different group will feel different.


> sometimes ending with "hey Dave, I need your help in X, let's talk it afterwards"

Which means, given a 8 hours working day, that you've been needing the help of Dave since the previous day, for an average of 4 hours, and you didn't ask him yet?


Strawman.

It's very possible the guy thought he could figure it out, but discovered he was wrong and mentioned it in the stand-up because it was the first opportunity that day to bring it up (remember, in a lot of places stand-up happens fairly early in the morning in order to give coders the largest block of contiguous time for development).


> but discovered he was wrong and mentioned it in the stand-up because it was the first opportunity that day

Exactly. Which means that he's saying that at the standup not because of any special advantage given by it, but just because it's the very first appointment of the day. Had there been no standup, he would have asked for help anyway.

So either: 1) the standup covers up a fundamental malfunctioning of the team, namely that people can't communicate freely during the day, or 2) useful stuff that people say at the standup is stuff they would have said anyway at that time of the day.


What about jumping up and down while giving your update? That could literally become an Amazon version of "how high" meme.


Oh really? And, tell me, do you agree to speak with your foot standing for 90 seconds? What about, I don't know, with someone pinching you or kicking your arse? Would that further reduce the time? Seriously - if I need to talk, I do, for as long as I think it's necessary. If I don't need to talk, and I don't need to hear other people's updates, this is just, how can I put it? Humiliating.


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.


I thought Toyota got some of their ideas of continuous improvement from Deming, who failed to find a receptive audience who'd implement hid ideas in the US.


This is really intriguing. Do you have a book or other source you can recommend where I can learn more?


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.


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.


In rare circumstances everything must go right beforehand, e.g. the New Horizons probe to Pluto.


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.


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.


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.


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


And devops turns into "end user is QA"?


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!"


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.


'Hate your team' is a little too strong, I think. I may dislike some of their working habits, and I think our code quality would be higher if we took code review seriously (I've been told to not hold back PR approval even on issues like not putting braces on single line if statements - if it runs, it's "good enough"; I'm also the only one to ever write tests). Implementing less isn't an option because we have a hard deadline

I see what you're saying in your last point, but on that particular sprint, someone didn't want to do something they had assigned to themselves and pulled in a different story/ticket. I have no issues picking up anything that is still unassigned, and I had mentioned during the daily that I was available if anyone needed help with anything. No one got back to me and I honestly didn't know until later that day that the other story/ticket hadn't even been started. I don't think I should have to talk to individual developers to see if they need help; we're adults and if you can't manage your workload or can't communicate that then I don't have a solution for you


> In my current team, it's followed religiously.

So, not Agile then...


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


I think expecting business to know what they want is a mistake.

I'm not much of an agile true believer, but as a former developer who is now "management" (shudder), I have never-ending frustration when teams expect full, perfect, set-in-stone requirements from day 1. When you're developing a new product in a new field, that's not how it works. We have to build something that minimally works, get it in front of real customers, and then make adjustments based on their reaction. Lather, rinse, repeat. This isn't "management can't make up their minds." This is "management are not clairvoyant."

To those who hate requirements changes, I'd love to know how you are able to determine with 100% certainty the exact product the market wants before you build it. If you can do that consistently, you should be a billionaire.

If you do understand that we don't know for sure what needs to be built from the beginning, you have two options. First, I can give you my current best guess at what we need to build, and we can work together to figure out what the right starting point (mvp) is, with the understanding that the rest may change later. Or I can figure out the mvp myself, and only tell you that, preventing the situation in which I told you about something that later has to change, but also robbing you of the opportunity to see the big picture and contribute to the plan. Which do you prefer?


I think the main issue most devs struggle with is not the changing requirements but that the timelines are not adjusted accordingly and have to be swallowed by the dev with overtime. And in most cases when there is some adjustments it's not nearly enough to cover the actual costs. If that was somehow resolved I think the vast majority of devs would be fine with changing requirements. Problem is I don't think there is an easy way because most non-dev don't truly understand the costs involved.

Fr example can u imagine telling a plumber no the bathroom is now going to be 30 feet to the left. The plumber says ok but that will cost u a week of work. How many people would say no, u have 1 day to do it and u will be held accountable for my estimate and not ur estimate because I don't trust u when u say a week. Now assume the walls are closed and it's only after u open them u learn there are other issues. Doesn't matter, one day. This is what most de s deal with. I assume ur not like this but this is how most devs have to work. It's frustrating. If u would be given the week then u would be fine, but instead ur told the timeline and/or cost. U may even be told no u can't use those tools they r too expensive, but u need to complete the task in the faster then even people who can use the tools.

My whole point is it's often not the change requests that are the issue, it's what it entails, in that the schedule and costs are not adjusted fairly.


Exactly.

That said, I think "give us the perfect requirements up front" is a reasonable defensive reaction. Because the first thing a lot of developers get asked is "When can you have this done?"

In most places, if the (made up, arbitrary) deadline is not hit, it's not managers who say, "Damn, our bad; we should have been clearer about what we were asking for." It's almost always an inquisition into either a) why the estimates were wrong, or b) what's wrong with the developers that they aren't delivering on time.

I now have a bag of tricks for keeping this kind of trouble to a minimum. But I think managers and execs have to stop asking, "When, to the exact hour, will this (hazy and ever-changing) thing be done?" It's not a sensible question, and if we pile blame culture on top of that, it's no wonder most projects quickly go off the rails.


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.


I personally don't tolerate abuse and would GTFO, but I understand that's not always an option. :(


Hopefully others will jump in with answers more relevant to your situation. I work mainly in a startup and small-company context because the customer and business realities are more prominent than the political situation. In my mind's eye, I see companies as opaque spheres of different sizes. The bigger they get, the farther the average person is from the external reality, and so the less that reality matters.

I also think this is tied in with current American managerialist culture. The notion of controlling work by setting arbitrary hurdles and deadlines is so pervasive that many people can't imagine an alternative. This very easily turns into pure fantasy, even on the billion-dollar scale. [1] I expect that there are plenty of companies that would literally go out of business before they would change their ways.

So in your shoes I'd take a hard look at your company and ask what its true values are. If they really value appearance over results, politics over substance, dominance over cooperation, then I don't think that's something you can change on your own. I'd personally try to find someplace better, and if I couldn't then I'd mainly play to survive, not to win.

But if you think the company has its heart mostly in the right place, then in your shoes I'd start with weekly team retrospectives. [2] [3] Each week, you'll make note of problems and possible solutions. Each week you try to make things incrementally better. And gradually you'll build up solid data to say things like, "For the last quarter, the most common thing in team X's weekly top 3 productivity drains has been insufficient contiguous time to focus. If you want us to go faster, please help us to limit meetings and interruptions to the mornings for the next quarter as an experiment."

If possible, I also strongly recommend finding ways to ship early and often. The longer managers go without experiencing actual progress, the crazier they get. If you release new business value at least weekly, then they'll focus much more on picking what's next then on yelling at people. At my last startup, even with a small team, we were releasing a few times a day. That meant that the CEO wanted something urgently, he could always get it soon just by telling us what thing currently in progress was less urgent. He always felt in control. It also meant that he was kept busy looking at new results and thinking about what came next; he didn't have time to fuss much with our work.

Related to that is building cross-functional teams. To me, a team is a group of people that win and lose together, a group that can play the game basically on their own. So I'll try to put a few developers physically together with a designer and a product manager and whoever else is vital. If PMs think of themselves as their own team, then it's hard to counteract those bad incentives. But if the PM only wins when the project and the rest of the team wins, they'll be much more collaborative.

And I'd also encourage you to make good use of every disaster that comes your way. The best luck I've had changing culture and process has always come when there's some mega-fuckup that's fresh in people's minds. That's especially true when you already have a successful small-scale example going. E.g., I remember one retrospective after a team spent 9 months building a big upgrade that was a flop. One of their peer teams was at that point releasing every few days and quickly responding to business data: killing bad ideas quickly, doubling down on the good ones. The pain of failure plus the envy of colleagues doing well was a powerful combination.

Sorry for the ramble in reply, but basically my answer is: as problems present themselves, solve them in ways that move you toward greater agility. By which I mean more frequent releases, faster feedback loops, closer collaboration, less work in process, more responsive to business and customer needs. To it continuously on a small scale and regularly at the large. If you can make a 1% weekly improvement, things will be 68% better by the end of the year, and 181% better at two years.

Does that help? If not, feel free to reply here or email me. Glad to help as I can.

[1] For example, the dumbfounding mess in Mississippi, which we know about because of one stubbornly honest engineer: http://www.nytimes.com/2016/07/05/science/kemper-coal-missis...

[2] A good book is Larsen and Derby's Agile Retrospectives: https://www.amazon.com/Agile-Retrospectives-Making-Teams-Gre...

[3] Also handy is the Retromat: http://plans-for-retrospectives.com/


At the risk of an unproductive comment, that was quite a read (in the most positive sense.) Your advice is very well taken and I can see the logic and experience in it, I really appreciate the time you took to ramble :)

To make the comment more productive and to echo some sort of thoughts on your thoughts:

Would agree re: managerial culture. I've seen a very out-of-wack ratio of deadlines set vs. deadlines that provide productive bottom line or user facing value.

Secondly re: values, I've come to a realization that I love my coworkers but find that what I love in them seems to get diluted the higher you get in the organization. It puts me in a conflicted spot about fit; and in the interim your survive v win advice is likely wise if only from a hedging-risk point of view.

The emphasis on small ship cycles is something I certainly need to improve. I've pushed hard to turn my code/commit style into this manner, so it seems lacking that I would drop that from overall feature delivery.

Cross functional teams however, although appreciating wholeheartedly (had a 4 man dream team at my last job that I really miss) I have very little power to change. The PM org is as you suggest _very separate_ (at least from my perceptions of their incentives and alignment). I can't be entirely pessimistic, there is certainly shared value when the shared feature ships well, but for whatever reason the focus seems often much more on asserting control and less on delivering value, for whatever reason.

Disaster handling as well is something that where I see the value, although pragmatically, you're usually in "put out the fires, damage control" mode and holding ransoms isn't really looked kindly upon. To their credit, the powers that be have been _reasonable_ (although as a grumpy ex-sysop I always like to push harder) in assigning time to postmortem/address issues, but for incentives beyond even THEIR control, it's not a priority.

In short; I've seen some "large company" problems at multiple places I've worked and in the lack of "true power" to oppose it your advice is very valid, if an uphill battle.


Glad to hear it was helpful. And don't beat yourself up for, e.g., release frequency. This stuff is hard enough to do when the context supports it.

I agree with you on some people favoring control over value. That's especially true for people whose primary job function is seen as control. Project managers and middle managers especially are often rewarded for the appearance of action, not the quality of the business result. This is part of why I strongly favor approaches where cross-functional teams mostly self-manage the work and other details normally given to project managers.

As to disaster handling, I should be clear that I'm not talking about asking for big changes during a crisis. Instead, there's this window after trauma where people are open to doing something different. Before the pain, nobody has reason to change the status quo. And eventually, they forget. It's sort of like how when people have a really bad hangover, they might say, "I'm not drinking again for a month." In that moment you can say, "Wow, I've been wanting to do that too. Let's try it together."

Good luck with your efforts! I wish I had a general-case solution for you. But my approach has been to find or create contexts where I can get a relatively independent team focused on value delivery. I think current managerial culture is inimical to that, so I expect that's an uphill battle at most places.


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.


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.


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


Oof, yeah. If what I've experienced is at all indicative, agile and outsourcing mix like nitroglycerin and shaking.


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.


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.


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.


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


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.


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.


Fuck those people. Sales that are that pathological are all kinds of broken.


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.


It sounds like your sales friend needs to be told "no" more often.

Because it turns out everyone is making those same requests and the product owners are putting "we'll put it on the backlog" as a soft no. A backlog needs to be shit that will actually happen.

Alternatively, the wrong things are prioritized. The backlog is not "first in first out." It's a "here are the next 5 most important things. Why is your special snowflake more important than that?"


This is by design and it's a good thing. If every salesperson is allowed to drop high priority "but my client is asking for this NOW" work items on engineering, you'll end up in a tug-of-war of competing priorities from O(n) stakeholders who don't give a shit about planning or roadmap in order to make their sale. Been there, done that. A proper product owner can balance all such requests and figure out what actually is needed to move the product forward. Salespeople need to make a business case for getting their requests done. Potential monetary results alone is often not enough, for good reasons, to force a context switch in an engineering team.


This is how products and companies die.


Having worked at a company with a lot of this that's now circling the drain, I can't disagree.


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.


Perfectly put.

I've been trying to push this kind of thinking recently. Most successful big projects grow out of a successful small project.


> Most successful big projects grow out of a successful small project.

This is probably true, one could even say that forming a big team from day one is cargo-culting others' success.


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


> Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

> Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

http://agilemanifesto.org/principles.html

It sounds like the system started off as agile and the second system lost the plot.


Wow, the numbers (headcount / users / allocated time) speak alone!

Thanks for sharing.


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


But Agile, as I understand it at least, is explicitly designed for cases when requirements aren't fully known.


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.


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


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.


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.


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.


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.


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


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.


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


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


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.


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.


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.


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.


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


The moment the process becomes a goal instead of solution - now you have two problems.

You cannot abstract away the need for common sense.


Listen to one of the authors of the manifesto itself: https://www.youtube.com/watch?v=a-BOSpxYJ9M

(BTW, he is very opposed to the use of Agile as a noun ;).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: