8 ms·
Agile Failure Patterns in Organizations
- kraftman 11y agoDoes anyone else find this hard to read? Small grey type on a white background makes it look more like terms and conditions than an article.
- m0nty 11y agoI clicked out as soon as that blue rectangle completely obscured my view of the page, which I was already struggling to read anyway (not just because of the contrast - it was a very listy article). Why do so many publishers think a popup is acceptable just because it's now called an interstitial, not a popup?
- kelvin0 11y agoDude, at least pretend to comment on the content and as a side note, comment on the form. How would you feel if someone commented that way on a matter you wrote about concerning an issue you consider important?
- dean 11y agoHave you never come across a site that looked so shitty, that you just left, thinking there could be nothing valuable there? This site is like that. And having to click through the popup, after first scanning it for the extremely non-obvious link, well that just makes the site sleazy. These things lend credibility or take it away.
- jboons 11y agoThe way in which you communicate your important issue is probably equally important.
- kraftman 11y agoI'd appreciate the feedback and I'd try and make it more comfortable to read.
- gvb 11y agoGood, but giving feedback in an unrelated forum that the author probably doesn't read is not useful. The page has a "Leave A Comment" box. Give feedback there.
- zoner 11y agoYes, one of the sites I have to use an user css. Otherwise painfully high number of failure points are true in the place I'm working, so a good article to show the management on the next scrum meeting (some point in the next two months) :)
- kraftman 11y agoProbably a dumb question but how do you apply your own css? With a browser plugin?
- Symbiote 11y agoI have a bookmarklet, which I've shared here: http://codepen.io/anon/pen/wKpewj http://codepen.io/anon/pen/wKpewj (there are lots if you search bookmarklet + {something}). It makes the text 1em, not bold/thin, black on tan. Something a bit better could preserve headings, bold words etc. Firefox's Reader Mode sometimes works, although not on this site.
- Silhouette 11y agoYes, you can use plug-ins like Stylish. It works well for tweaking sites you read regularly, HN say, though personally I find it too much messing around for a site I'm just visiting quickly. I'm more likely to just open the developer tools in whichever browser I'm using and look for rules that set a tiny font-size, a font-weight of 300, a faded color, etc. Often just disabling a couple of those will make a page dramatically easier to read, so I do recommend spending five or ten minutes figuring out how it works in your preferred browser. Even then, I sometimes have to admit defeat. I hate the idea of criticising style rather than substance, but with a site as awful as this one you can spend several minutes trying to make it comfortable to read and still fail.
- squeaky-clean 11y agoOne my phone I thought it was tough to read. Now that I've opened it on my PC, it's practically impossible to read.
- demian 11y ago"Culture of Failure" Good luck selling that to upper management. On the contrary, quick iterations are about reducing the risk of building the wrong thing. Of course in the normal "blaming" corporate culture this won't work, because departments are always competing over budget and deliverables that are not "perfect" will be used as ammunition against the department where the product came from.
- mathgeek 11y agoI usually prefer to call it "culture of learning to get back up again after falling."
- techterrier 11y agoOn the other hand those types do love them a bit of darwinian language. Call it 'Aggressive pursuit of fitness" or something.
- demian 11y agoNot really into using darwinian language, but I like the focus on fitness. It may work better for customer-facing products ("Market Fit" is a thing), but It may be harder to sell it for internal products ("Functional Fit"?)
- noarchy 11y agoMore of the "No True Scotsman" apologia for why Agile fails so often. I especially liked this gem: >Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones. I can't say I'd feel bad if a failed, Agile approach was not in my comfort zone.
- DanielBMarkham 11y agoAs somebody who uses this argument, and somebody who cares about reasoned debate, I must disagree. Agile is not a standard. There is no class, there are no tests, and there is no governing body to determine whether you are agile or not. As such, it's just a marketing term around best practices in iterative and incremental development. Along with XP and the latest hotness in CI/CD/DevOps/etc, it's where you go to see how the cool kids are doing it. Since it's "cool stuff that works most of the time in hi-tech teams", the real question here is this: are you trying new stuff? If so, are you trying stuff that seems to work for a lot of people? If you are not, then, by definition, you are not "doing agile" (or however you want to phrase it). If you are, good for you! You still might suck, but at least you'll suck in different and interesting ways. So in this case the writer is correct. The "No True Scotsman" label does not apply. There are no Scotsmen to begin with. ADD: And of course the flip-side to my argument is also true. Don't get me started with the folks who think that simply because you're doing various Agile practices you should automatically be succeeding -- or the folks that think "if we were only doing Scrum the right way". I've had a lot of headaches there. Tools exist to get work done. If the work is not getting done, use a different tool. "Agile" is simply the sign over the place in the hardware store we go to get certain kinds of tools. We understand and apply tools expertly, but we do not do work by spending all of our time and energy being focused on tools. Instead, good tools allow us to focus our time and energy on the problem.
- noarchy 11y agoOf course it is a marketing term. There are enough people billing themselves out as Agile "coaches", or Scrum "consultants", that the marketing seems to be working. But if they aren't Scotsmen, they've done some great marketing to make people think that they are. So if you or your organization failed, it is because the wrong people were implementing it and/or you did it wrong.
- lojack 11y ago> Agile processes are either bent or ignored whenever it seems appropriate. There is a lack of process discipline. This one I don't understand. Isn't it sort of the antithesis of the first core principle of the Agile manifesto? Shouldn't it be a _good_ thing that the processes are bent or ignored when appropriate.
- err4nt 11y agoWhenever I meet people hiring for tech in Toronto They say things like: 'We practice XP, We apply agile to agile!", I hear "We have no idea what we're doing, and no idea how we're going about it but we will change it whether it's working or not and expect you to jump through a lot of hoops in addition to getting your work done" I've seen offices with Gold stars for employees and these huge whiteboards filled with different milestones and benchmarks for projects. It looks great, but the difference is the work isn't getting finished. I feel like agile can create a smoke screen (if you're not careful) where you're too busy seeing how successfully you're on track with agile and miss the opportunities or failures that are happening in the real world to your product, instead of inside your process. You can be in great shape as far as agile goes, and still be losing customers because your work comes months too late. To me, process should never be more important than product. I come from a graphic design background where process is very important to ensuring consistent results, but you can never fetishize the design process over the results it produces or else you end up with mediocre, commoditized design that is indistinguishable from the worst stuff coming out. You couldn't pay me enough to deal with agile in the workplace, I feel like you'd have to toss an extra 50k on the top nd I doubt anybody would pay me an extra 50k just to deal with it, so I'll continue working with non-agile folks who manage to get stuff done, like professionals! Opportunity doesn't wait for standups, timeboxing (telling people when they are allowed to talk or not), and micromanagement.
- jacques_chester 11y agoI feel like you're rejecting a strawman, rather than basing it on an honest "suspension of disbelief" experience at a well-regarded agile shop. I joined Pivotal Labs a skeptic. Now I'm a proselyte.
- 11y ago
- r0naa 11y ago> Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones. I love how this equates critical thinking and complacency. See? I can do it too.
- incepted 11y ago> Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones Or maybe they have identified Agile for what it is: a snake oil methodology that's completely unproven, which sometimes works, sometimes doesn't and, regardless of the outcome is never blamed if the project fails. Bit like a religion.
- pkaye 11y agoIn your experience, what kind of methodology do you think works?
- ThomaszKrueger 11y agoM'fcking programming. Never failed me.
- joesmo 11y agoThis is likely the number one reason for rejecting agile: it has already failed. I've worked at over a dozen places claiming to do agile and have found exactly zero that actually do. What's worse, the process degrades into 30-60 minute "stand-ups" or "scrums" or whatever, eating into a good chunk of the day for absolutely negative gain (as it's mostly people talking about shit that's irrelevant to 90% of the team and wasting everyone's time because the "process" says they should). I've also seen it degrade into another reason for management to enforce deadlines in all places, including places that only employ deadlines when development is really behind schedule (as is all software development I've ever seen in the business world). And what are the advantages? Little Joe over there in the corner can feel brave enough to speak up about his problem once a day? Seriously? Is this a process for the socially inept? Is that what we're trying to solve here? Disrupting the coding flow? Allowing the manager to be even more lazy in his contact with the team by limiting it to a few minutes a day (closer to 30 than 5)? Having it replace those couple of hours you could have spent designing your app with a few months of 16 hour bug-tracking right before release? Oh, please ... I think it's time to acknowledge the process doesn't work, that anyone can come up with hundreds of points showing why it doesn't, and that it's time to ditch this resource-wasting process altogether.
- UK-AL 11y agoI think trying to do a big bang deployment of scrum in a slow organisation bureaucratic organisation is probably a bad idea. Probably best idea is something using kanban. Map the existing process using kanban. Find bottle necks, and fix the process. Start changing bits to it. Start using TDD, maybe user stories, maybe add "sprint" planning meetings. You might not be implementing "true agile", but its better than complete disaster trying to enforce everything suddenly. Also this comment he stated in the comments makes me uncomfortable. "being uncomfortable committing to an outcome that’s time-boxed" " sticking to a 5-to-9 mentality " You shouldn't really being "commiting" to a time box. Its a guess, not a commitment. You use velocity to get better at the guess. If you miss, oh well lets get better at it next time by adjusting the story points in a sprint. He makes sound like he expecting people to work overtime to meet a commitment. This is not recommended in scrum. You should have a normal work time mentality and work requirements should fit into normal hours. If you miss the "guess", you should adjust the next sprint to not include as much. If you work overtime to meet the commitment, you re-enforce the idea that it is ok to commit a overloaded amount of work to a sprint. Bad. Bad. Bad. That can be abused.
- jahaja 11y agoWhy would one adopt a methodology with so many pitfalls?
- noxToken 11y agoOther methodologies have their pitfalls as well, but agile is the methodology that many are adopting from the get-go or changing to. As such, it's head is on the chopping block. Developers are scrutinizing it to evaluate the trade-offs. You'll see people celebrating agile as if its the messiah to save all projects, and you'll see others decrying it as smoke and mirrors. I think it's important that people are openly (not overly) critical of trends. It can help people make more informed decisions. The problem then lies with others trying to wade through vocal idiots masquerading as experts and legitimate information hidden in the cruft.
- jahaja 11y agoYupp, it's indeed the thing of the day. Reading that list I just wondered if using no apparent methodology would be any worse. I have a hard time rationalizing the almost theological adherence to software development methodologies in general.
- canthonytucci 11y agoI see a lot of people using "agile" and Scrum™ interchangeably. Am I just a deluded fool, or is the agile manifesto completely ignored in practice? People talk about "agile methodology" and I wonder "doesn't the manifesto explicitly reject all 'methodologies'?". I thought that was the point. The manifesto is pretty short already but more or less I understand it as " do what makes sense to you". It's open to interpretation, but that's the whole reason for its existence. If companies think there's a magic book or a system to rigidly define "what makes sense" for all teams on all projects, and that such a system can/should be purchased if only the idiots working for them would just follow the rules, they're doomed anyway.
- pcurve 11y agoI agree 100%. I work in a big corporate environment. The problem with Agile is, it doesn't seem to work in a big corporate environment that loves the followings: 1. Ability to plug and play bodies (PM, Dev, BA, offshore/outsource) 2. Having those bodies held accountable individually 3. Predictable process over progress or quality. 4. Layers of management.
- VLM 11y agoWith the minor correction that #1 also applies to divisions (east coast office vs west coast office) and cross shift (3rd shift ops has the same written procedures and instincts or whatever as 2nd or 1st shift ops). Programming is a young profession. On the other hand, design and engineering and automation are old, and the giants got that way by following pcurve's list, more or less, not by inventing or implementing Agile. Therefore the higher people go in management and therefore the more abstracted they get get from the front line, the more likely they are to completely uninterested in Agile, as that's just not how big companies are run, even if it works for a ten person startup. So there's going to be a push from the top to call it whatever you want but when you interface with the exec suite you'll talk in terms of micromanaged waterfall because that's how we build jet engines here, or mining machines, or run a worldwide communications system, or whatever.
- gregmac 11y agoI think you're bang-on. The trouble is approaching it as if it is some prescriptive methodology, where you can implement the processes and magically you're "agile". It doesn't help that several books, blogs and consultants try to convince you this is the case. The reality is that agile is a philosophy, and there are some processes (like Scrum describes) that happen work well with it: but if you don't embrace the philosophy, the processes won't do anything. This sounds a bit hand-wavey, but it has parallels to software itself: if you fix bugs without understanding their cause, you're doomed to keep "fixing" the same bugs over and over (since you're just fixing the symptoms). Likewise, if someone makes a feature request "I need a button here", and you just put a button where they ask without first asking "why?" and understanding the need, you end up building the wrong things and wasting everyone's time and money. Personally, I'd say the most important things about implementing an agile process that seem to me to be the cause of many people's problems with agile are: * Implement retrospectives, with the power granted to the team to change the process in whatever way makes sense * Stop building systems or components, and start thinking about everything as user stories Retrospectives are where you define YOUR agile process. When we started at my company, I think we did some fairly significant changes to our process at every retro for the few months, and often when someone new joins the team, process changes start coming up at retros again. Building User stories is what really breaks out agile from waterfall. You still have to define the system to some degree (to have a sane architecture), but you don't have to actually build it. "As an administrator, I need to be able to create a new user" can be fully implemented before any code to edit or delete the user is written. Like most things, this is of course not black and white: if you don't define the system as a whole enough, you'll rewrite every feature over and over, or have an un-maintainable mess. However, do it properly, and you get working (if incomplete, from a market perspective) software faster. The real benefit comes from doing the most risky things first, getting user feedback, and failing fast. You don't want to find out that the data model you built can't support the insertion speed you need and needs to be changed after you've already started to build the reporting UI.
- VLM 11y agoSome common pathological beliefs I've seen, some logical fallacies, some worse: The rationalization drive implies failure needs an excuse. Sometimes Agile is the least strongly defended possible victim. Therefore Agile is bad. Agile is complicated. The simplest components to explain are also the most trivial. Something that's only trivial is invariably foolish. Therefore Agile is bad. "Most people" are experimenting with Agile. Half of managers / devs are below median by definition. Its a very realistic prediction that half the time, Agile will result in below median performance. Therefore Agile is bad. Every other silver bullet for the past 50+ years has been a scam. Agile is a silver bullet. No one can explain why this silver bullet is any more likely to be real than the last couple dozen fads. Therefore Agile is bad. Agile only seems to scale to a narrow range of team size. Things that don't scale up, or down, are stereotypically seen as bad by programmers, no matter if the stereotype is applicable or not to the situation under discussion (that's why its called a stereotype or bias). Therefore Agile is bad. Sometimes Agile is implemented as a sub-scheme where the overarching style remains micromanagement or seagull management or simple chaos. If the cake is a lie, a thin layer of Agile flavored frosting isn't going to make the overall dish taste good. Coverups are inherently bad. Therefore Agile is bad. Agile is impossible to define and really popular. Grok that. At least some of the bottom half of the median will simply use the word as a checkbox without ever implementing it. Essentially managers who "have no idea whats going on" will sometimes describe themselves as Agile as false advertising. Therefore Agile is bad. Related to most of the above, the odds of finding a shop actually successfully implementing true Agile are low. Therefore statistically if an employer says they're agile that's a sign for applicants to avoid them. And that means the best people will successfully avoid agile, with all kinds of secondary effects. Therefore Agile is bad.
- mosdave 11y agoif (sentence.BeginsWith("But fact is also,")) throw new GrammarException("Learn how to fucking write.");
- dang 11y agoHN has many non-native English speakers. Insulting anyone for that reason is mean. Your comments have been breaking the HN guidelines by being uncivil and unsubstantive. We ban accounts that do this repeatedly. Please read the rules and post civilly and substantively, or not at all: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- s73v3r 11y agoWait, why would people think that Agile is a substitute for hiring senior people?