12 ms·

Everyone claims they are following “agile methods” but few do (2018)

156 points by spking 8y ago

mikece 8y ago
A common point of contention is that agile is a list of philosophical guidelines, not a hard-and-fast framework for how to do things. A "true agile" shop should be periodically reviewing and updating their processes in the light of what makes the most sense. If, however, "being agile" is an organizational checkbox then some form of generally accepted agile methodology will be implemented whether it is the best fit for the company, whether the teams truly understand it, and without a built-in plan to reflect and decide if they are even doing agile right or if it's actually benefiting the organization.
linuxftw 8y ago
> Middle managers can also miss the importance of co-locating teams by bringing together designers, engineers, product managers and content specialists in the same physical space. The most highly functioning agile teams aren’t just at the same location or on the same floor: they share the same table. I can't refute this strongly enough. Managers should do their jobs and manage. Doesn't matter where team members are located. Anyway, this agile nonsense gets too much air time. We got it: highly iterative feedback loop development.
- walshemj 8y ago
  Actually no it doesn't referring to "agile nonsense" is a real red flag. Real Agile RAD /DSDM really does work best with collocated teams and experienced developers not lowest bid outsourced talent. I have worked on both RAD and OSI 9000 (BS5750) waterfall projects so I have experience in both types of development. Oh my Second RAD project was featured at the IEEE and when I was younger I worked with the BSI in the early days of BS5750
  - cryptonector 8y ago
    GP said nothing about "lowest bid outsourced talent". "remote work" != "lowest bid outsourced talent".
    - walshemj 8y ago
      Oh I think I could safely assume that from the dismissive tone
- howard941 8y ago
  I couldn't agree with you more. At $CURRENT_PLACE we preach an iterative spiral that I believe is appropriate for the sort of embedded safety tech we work on that has built in time delays for testing at (for ex) UL or whatever NRTL is the NRTL of the day. Whether we're succeeding at differentiating it from serial waterfall is debatable. I think we are because marketing travels to see us every other week and they're meaningful yet we avoid what seem to me like make work bits of agile and scrum. Absent the imposed processes everyone works closely enough together that we can finish each others sentences most of the time and most of us appear look forward to coming into a workplace where the manager is absent half the time but because his most important role is to his bosses from interfering with us and to clear out the obstacles in our way it works pretty well.
abakker 8y ago
This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy. Agile is basically implemented to create an iterative feedback loop in the development process, but it seems totally rational that what works for startups won't work for very large distributed companies, and what works for an app developer won't work for an automotive supplier. Standups can take different shapes, the 'V' in MVP differs wildly by industries, and the cycle time that a product needs to have can be determined by external market forces (e.g. the school year). Agile is meant to adapt to the characteristics of the business it is used in, rather than to be specifically some universal way of everyone trying to everything in the same way.
- ravenstine 8y ago
  > This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy. Maybe so, but you are also describing Agile as if it can be anything a company wants it to be, which effectively makes Agile meaningless. I've worked with clients that have a waterfall-like development process, "standups" that are both status-reporting to management and on the spot planning, adaption to change is very slow and cumbersome, velocity charts serving management more than the team itself, tickets that represent multiple stories at once, management adding tickets(i.e. more story points) without removing less important ones, gigantic release cycles, etc. Is that still "Agile"?
  - AndrewDucker 8y ago
    Are they following the Agile Manifesto? https://agilemanifesto.org/ https://agilemanifesto.org/ If so, then it is. If not, then it isn't.
    - ravenstine 8y ago
      Of course not, and that's really the point. Plenty of organizations will tell you they are Agile when they aren't truly following the Agile manifesto, but that's not going to stop the evangelicals from eating the horse manure("our team has standups 'n stuff") that reassures them that their belief system works. Everyone's bullshitting each other, and I wish it would stop, but I know it won't. Not everyone can be a "true scotsman". I'm not even defending Agile or other related methodologies like Scrum. They have some good ideas, but I haven't seen quantifiable evidence that they are good for businesses. Many of the ideas are good for software engineers, but that doesn't mean they are actually good for teams or companies. Even then, I've management use "responding to change over following a plan" as a license to make more arbitrary changes to what engineers will work on in a given day because they can take it. Planning days and point systems be damned.
jacknews 8y ago
The article presents too many Agile/Scrum "artifacts" for my taste, eg Agile favors so-called T-shaped skills Adam Smith would be turning in his grave Agile is a true democracy LOL The Agile philosophy certainly has something to say, but it's not hard to see the possible negative implications of "self-managing/self-policing teams" when they're owned by capitalist organizations. These kinds of ninja teams can be extremely effective, but they should own a share in what they create, otherwise the whole thing becomes a BS attempt to make people work harder via "transparency"
- andrekandre 8y ago
  i feel very much this gets close to the issue. (for me at least) if agile is supposed to empower the team to self-improve and self-organize, then being placed into a top-down hierarchy where the upper levels are always in charge anyways is a contradiction in itself and is a huge cause of disappointment that it’s “not working”... well of course it’s not working if i it’s being imposed by “the top” and for their own reasons... right from the start it’s not team-centered, so there you go.
ben7799 8y ago
I'm ready for what comes next after Agile. I've been through about 5 Agile shops now. I would say one of the 5 ran Agile well, the rest were a mess that just makes it frustrating for everyone. What we mostly have now is watered down agile.. the worst bits of agile like never actually "designing" anything, but we don't really have any of the good bits of the older management processes left over. I don't really want full waterfall again but I would really love to see some sort of lite versions of Functional specifications & design specifications come back. Agile works best IMO in the Pre-1.0 phase of a product and gets progressively worse the further you get towards maintenance of a product. I also think Agile works better and better the closer you are to the UI, and worse and worse the further you get from the UI. Solid back end design and infrastructure rarely fits well into "Sprints" and solid back end infrastructure is not sexy at all in a demo, so Agile can demote back end design to the point everything gets done in a way that is too MVP. Then later on when scalability, performance, bugginess, and maintainability come into play you're into that "established product" phase where Agile doesn't do as well. So you've got problems in an area of the product Agile has trouble with happening in a phase of development Agile has trouble with. Agile also seems to really require absolutely top notch product management folks, and they are seriously rare. The thing is of the 5 shops: * 3 Were acquired * 1 Went IPO * I work at the 5th currently So the companies always had a successful exit even if the codebase passed onto the acquiring company or to the public investors had major issues.. so at least in my experience there's no feedback loop to correct the issues.
- im_down_w_otp 8y ago
  I regret that I have but only one upvote to give for your comment.
- cwyers 8y ago
  Scrum != agile. You don't need sprints to be agile. If sprints aren't working for you and your team, then stop doing sprints. If your team can't decide to stop doing sprints, then you're not leading your own agile process and you're not really doing agile.
  - cwyers 8y ago
crankylinuxuser 8y ago
Well lets read further in... So the article indicates and blames executives from short-circuiting Agile. And the article says that the best Agile is democratic? That sounds like a worker cooperative, not a private corp, LLC, S or even a C corp.
cwyers 8y ago
I think there's a fundamental misunderstanding of agile. Agile isn't Scrum, agile isn't Kanban, Agile isn't even really the manifesto. Agile is, like lean manufacturing (one of its inspirations), based around one really simple concept: the workers know the most about what they are doing and should be leading the charge on what they are doing. If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments. If agile is just another way for management to exert control over software development, rather than being about ceding control to software developers, it won't "work." This is the same thing you see with lean/TPS, by the way. The joint GM/Toyota venture showed that without committing to these principles, adopting parts of TPS don't really deliver the full benefits.[1] As one UAW team leader said about why working for Toyota was preferable to GM: > The GM system relied on authority. People with rank, the managers, ruled regardless of their competence or the validity of what they were saying. It was basically a military hierarchy. At NUMMI rank doesn't mean a damn thing. Standardized work means we all work the objectively best way to do the job, and everyone does it that way. I might make some minor adjustments because of my height, for example, but I follow the procedure as laid out because it makes sense. We're more like a special forces unit than the regular military hierarchy. Management's delegated responsibility to the people who do the work, and that gives workers a sense of pride in their jobs. If management is asking the developers to adopt agile, but they aren't doing anything to adopt agile themselves, good luck. 1) https://www.researchgate.net/publication/245862516_Democratic_Taylorism_The_Toyota_Production_System_at_NUMMI https://www.researchgate.net/publication/245862516_Democrati...
- throwaway55554 8y ago
  > If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments. If agile is just another way for management to exert control over software development, rather than being about ceding control to software developers, it won't "work." This is exactly what it has become though. It's not about developers, it's about managers and product owners. It's about numbers in a spreadsheet that managers can show upper managers. Management has sucked the life out of agile. It's become this rigid metric producing muck that gets in the way.
drderidder 8y ago
Dave Thomas, one of the original authors of the Agile Manifesto [1] wrote an article called "Time to Kill Agile" [2] a few years ago (which he subsequently re-titled "Agile is Dead"). He has some good insight on how Agile (the methodology) got to be something very different from what they intended. Originally they were trying to break away from a rigid methodology, not introduce a whole new one. Unfortunately, if you don't codify something into a set of rules, it's pretty hard to get people to follow it, and it wasn't long before "experts" were building formal processes out of it. I've never seen it work well, and the more ardent the adherents are, the worse it seems to get. I think every team needs to find the approach that works best for them to itemize, prioritize and communicate progress. In my experience the two most important aspects of moving a project along are simply communicating what needs to be done and recognizing effort. [1] http://agilemanifesto.org/ http://agilemanifesto.org/ [2] https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html
- bostik 8y ago
  > I think every team needs to find the approach that works best for them to itemize, prioritize and communicate progress. This is spot on. And the fact is, this has been known since at least 1980's (!)[0]. I am quite fond of using the version "culture trumps process", because it so well encapsulates the reality. (Also: hits directly against "The Process" ideology.) It often feels like everyone and their dog within the industry are hell-bent on establishing a Good Development Process. But that's a false premise. You can't just introduce a designed process and expect it to magically fix things. Workflow is everything: motivated and talented people will go to lengths to get their actual work done, process be damned. The best thing you can do is to invest in good tooling and actively encourage sane development practices. Get the workflow right, and process will follow. Crucially, as you said above, every company will need to find their own flavour. 0: https://quoteinvestigator.com/2017/05/23/culture-eats/ https://quoteinvestigator.com/2017/05/23/culture-eats/
- wnevets 8y ago
  I've dealt with "agile experts" who appear to never have actually read the agile manifesto. For those "experts" is always about following the rules and process of their version of agile. What gets presented by these "experts" is rarely anything like the original indent if not the anthesis.
ergothus 8y ago
I don't think I've been in a truly Agile shop, though a few times we had truly Agile periods on a given project. That said, some worked. If they: * considered every task to be a mix of features, deadlines, and resources, and realized that if you fall behind, even a little, you have to adjust at least one of those three * iteratively completed tasks and reviewed any adjustments to the overall project * Had dev <=> management be two way communication Then things were pretty smooth, even if they weren't Agile.
legitster 8y ago
I work at a large national software company who shall remain nameless. At some point, they determined that "we are now Agile" and put all work in a tracking software, and everything must now be assigned to sprints. But if you dig any amount of depth down it becomes ridiculous. An example I found, the helpdesk literally has one project every sprint ("Ticket resolution: February Sprint 1", "Ticket resolution: February Sprint 2", etc.) Or tasks that used to take 2 or 3 days now gets split across 2 or 3 sprints, because guy 1 can't allocate it to guy 2 until he finishes it. And it just sits around until the next sprint. Even creative departments are supposed to snap-to. The idea is a recording a video should be a dozen or so tickets in Jira (edits and revisions happen as bugs). These teams are smart and overworked enough to completely ignore the directive. And the amount of PMs has increased by an order of magnitude, because taking things in and out of the tracker has become its own workload because managers want to see more and more detailed 'analytics', so work get broken down into finer and finer pieces. I describe the situation as if someone tried to make their truck lighter and faster by bolting a Lotus onto it.
- sethammons 8y ago
  > Or tasks that used to take 2 or 3 days now gets split across 2 or 3 sprints, because guy 1 can't allocate it to guy 2 until he finishes it. And it just sits around until the next sprint. This so much. Because no PMs want to adhere to "sprint forecast," but insist on "sprint commitments," you literally cannot commit to doing a unit of work that depends on someone else getting theirs done first until they are done. A smooth flow that gets to market quicker now _must_ be lock step gated by sprint start dates. /me sighs
  - iovrthoughtthis 8y ago
    I imagine stuff like this is why kanban was developed.
    - sethammons 8y ago
      I think kanban was primarily for interrupt driven projects, but this works too for pipeline like stuff.
kleiba 8y ago
Does any one have good (as in: known to actually have had a positive effect in the past) insights on how to convince your manager(s) that (at least their version of) "agile" is not helping the company? My wife works in a company where the managements seems to be quite "proud" to apply "agile methods" but in my wife's opinion, it's more BS bingo than producing a measurable boost in productivity, quality, or any other desirable metric. It is her impression that they are forced to adhere to certain routines even when the benefit is questionable. For instance, every morning at 9pm the whole department has a "daily scrum meeting", but most of the time there's nothing important to report from the day before for a lot of people, so it tends to lead to either embarrassment, pressure, or to people making crap up just so they have something to say. Needless to say that this doesn't lead to "team building". That's just one example. So, either the specific way "agile" is executed in my wife's company is just stupid, or the whole methodology is perhaps not applicable to their setup -- or something else. But it seems that the current practice is just a gigantic waste of time, yet the management is so proud of their "agile" way. How could this situation be improved? Any tips?
- soperj 8y ago
  From what I've seen is that Agile doesn't ever end up working when it's driven from Management. They only care because it's supposed to be more productive, but they don't want to actually adopt any of the measures that make it more productive.
  - nielgaard 8y ago
    But it is always driven from management. When was the last time a group of developers decided all by themselves that they needed a development framework to get work done? And isn't it funny how management never uses any agile framework to do their own stuff. Could you imagine the board of directors putting Fibonacci cards on their foreheads when deciding on budgets or earnings forecasts?
- codeflo 8y ago
  I know what you describe is common, but the purpose of the daily really isn’t to boast about your heroic achievements of yesterday, or give a status report to management. That part should be cut out entirely much of the time. A better idea is to plan the current day, identify where someone could use help, where two people need to coordinate more closely or on what issues further discussion is needed and with whom. If there’s nothing to discuss because everyone is already on the same page, that’s great, cut the meeting short and start working. Also, depending on your setup, people who can never usefully work together on anything probably shouldn’t be part of the same daily standup. I’ve seen several cases where this meeting was way, way too large.
peterwwillis 8y ago
Most people who have an opinion about Agile don't understand it, and nobody understands it because the industry doesn't make it mandatory. It's the same with DevOps... A great idea reduced to a buzzword due to confusion.
maxxxxx 8y ago
We should have stopped at the Agile Manifesto. Everything following it made Agile worse. In the end companies will almost always regress to a top down hierarchy. True Agile is bottom up which is against the structure of most companies.
- sequoia 8y ago
  Is the agile manifesto actionable in any clear way?
hnruss 8y ago
I'm working on a project right now that lacks well-specified requirements, yet we're barreling ahead with the implantation. I'm not exactly sure what's going to happen. My guess is that we'll end up with an MVP that meets the known requirements, but then we'll have to rewrite some part of it to meet the as-yet-unspecified requirements.
hota_mazi 8y ago
Companies that don't follow agile and instead, choose to pick only the subset of agile recommendations that make sense for their culture and teams, are actually the real agile companies. It's always struck me how the attitude of agile advocates has always been so rigid to the point of being dogmatic, thereby being the exact opposite of agile.
cirgue 8y ago
I feel like 'agile' has become similar to capitalism or socialism in that it exists to solve a set of problems, and the internal structure of the idea does in fact solve the problems it seeks to solve, but has a whole bunch of real-world failure modes that make it tricky if not impossible to make work successfully over the long term because they're founded on assumptions of how humans work that are close but incomplete. Management always wants more granular control over projects, and agile doesn't encode a way of resisting evolution toward one of the many versions of zombie agile.
tkefauver 8y ago
Where in this article is there any examples of how most people aren't following agile methods? Pointless
tkefauver 8y ago
Where in this article is their any examples of how teams are not adhering to agile methods? Pointless
jaequery 8y ago
Agile is so vague I don’t even know what it is anymore. Can someone show us how an agile should look when creating a simple to-do list project?
mbostleman 8y ago
My current experience with a distorted Agile approach is that it is used as an excuse to not have a big design. The idea is to not block on a big design UP FRONT. Not have no design at all. So the platform I'm working on now has been torn down to the foundations and fundamentally rebuilt at least twice because the lead(s) on the project never looked further than one sprint out. Somehow it is expected that an organic design will spring from nothing. Very unfortunate.
oxfordmale 8y ago
I would recommend for the author of this article to read the original Agile manifesto and point out where the so called Agile methods and resourcing models are described. I am often only resourced 10% to some Agile projects, because my expertise is often only required for a small part of the project. And yes a copy writer can do my job as well, but would you really let an average electrician build the timber structure of your roof while the plumber wires your house ?
sequoia 8y ago
It’s notable that the ratio of “that’s not really agile” to “this _is_ agile” comments in discussions like this is typically about 10:1. Everyone knows what agile isn’t but no one can seem to explain exactly what it _is_. Furthermore, the “you’re holding it wrong” criticism of everyone who gets poor results from agile, which seems to be a majority of people attempting to use agile practices according to articles like this and comments ITT, is a major cop out. If 75% of people attempting to use a tool hurt themselves with it, you should start asking whether this was a well designed tool in the first place. My solution: stop using the term “agile.” It’s so vague and means so many things to different people that it effectively means nothing. Instead, talk about specific practices (sprints, story points, etc) and be able to explain the purpose of each practice. This can clear away the agile fog and get people discussing actual trade offs rather than agile magic dust.
- iovrthoughtthis 8y ago
  That’s the point though, right? There is no one “Agile Methodology”. It’s meant to be a communication protocol you grow within your organisation based on the principals outlined in the manifesto.
  - sequoia 8y ago
    The title of the article “Everyone claims they are following “agile methods” but few actually do” suggests that there is something called “agile methods” that can be followed. I don’t think I understand what you mean about it being a communication protocol. In any event, it seems beyond debate that the term “agile” is extremely widely misunderstood. I’m arguing that instead of tilting at windmills trying to correct everyone who is “understanding it wrong”, we give up, discard the term, and focus the pros and cons of specific, describable practices. Agile seems to be more of a feeling than a practice.
    - iovrthoughtthis 8y ago
      There are some codified system of rules and behaviors that people have developed to help their orgs gain agility e.g. Scrum, SAFe, etc. But there are probably an infinite ways to skin that cat. Doesn’t really matter which one you use just that everyone is using the same one. Which leads me onto why it’s a communication protocol. Human systems/processes/procedures just organise the flow of information, often to help people make decisions. If everyone isn’t following the same set of rules and behaviours then there can be a breakdown in communication. Which usually screws things up (whether top down or bottom up)
tynpeddler 8y ago
I was a late comer to software development so my career is relatively short at this point. I have worked for 2 different shops and had wildly different experiences with agile. The first is a fortune 500 company that is not a techy company. They have a lot crusty old infrastructure and when they decided to do agile, they hired a consultant company that came in and spent a lot of time training everyone in their "agile" methodology. I can say without sarcasm that it worked great. It was painful at first and it took probably a year for everyone to adapt, but I was very pleased with the end result. Agile didn't mean, don't do design. For us, Agile meant to always be designing. We set aside 2 hours every week to sit down as a team and design future features, as well as evaluate current architecture and propose changes. Outside those 2 hours, devs would do additional design as needed. We had one hour every week for a long form meeting for our BA's, product experts and development team to all get on the same page for business requirements and future product direction. In addition, the product team was available for consultation almost every day, and never fewer than 3 times a week. Our retrospectives were rigorous, and by the time I left the company, our estimates were excellent. We had gone from almost never being able to finish our sprint correctly to it being a surprise if every story wasn't finished on time. Occasionally business would throw a curveball at us and we would have to scramble to get our backlog and designs into place, but we were still able to finish almost every sprint as promised. I'm a little over a year into the new place. It's also a Fortune 500 company, but it is know as techy and has a good reputation with the field at large. So far it has been miserable. They're one of those companies that does waterfall with standup. As a result, we have extended periods of torturous drawn out design (one guy went six months without writing a line of code for work), followed by a mad scramble to implement our designs as we realize we're running out of time. As a result, the documentation looks nice, but the code is a mess and doesn't always match the documentation. Since the team can't self organize, tech debt continues to accrue at a terrific rate. Small stories are awkward because the pipeline and commit process is too difficult and slow to justify it. Part of the problem is the lack of business analysts. Without that intermediate group to help manage business complexity, the developers are left doing an extensive amount of basic requirements gathering just to get started on a problem. In addition, there's no real institutional memory, and when business flows change, there's no one around to update old docs with the new changes. There's no real story grooming, so we routinely overshoot our sprints. Without a clear understanding of how product and development are supposed to interact, priorities are changing constantly and I've been shuffled between two projects almost at random. I could go for hours about the two different companies but I think the difference boil down to one simple factor. The first company had a culture of continuous improvement. They had their share of failings, mostly related to not being a very techy company, but everyone in that company was deeply committed to constantly making things better. Pain points were either quarantined so as not to impede work, or they were called out and fixed. If something couldn't be fixed or quarantined, than it was tracked until everyone was so sick of talking about it, we'd find the time to fix it. The second company does not have such a culture. Everyone is very comfortable with the status quo no matter how much it slows things down. Things are starting to get a little better, but not much. I think Agile worked well with the first company because everyone was already interested in constantly improving. Agile gave them a framework to evaluate their performance and improve it. Without that culture of constant improvement the second company just adopted the most cosmetic practices of Agile, without actually changing anything, or evaluating their own behavior.
iovrthoughtthis 8y ago
I see part of the problem being that Agile is seen as a management methodology when it’s actually a development methodology. Management here meaning overseeing people. Development here meaning building things.
akeck 8y ago
We follow "Jira methods".
lochlan 8y ago
IMO the problem is that people want to buy Agile. They want to pay a consultant, or go to a class, implement a dozen scrum rituals, and call it “agile.” Agile is not Scrum, Kanban, or even XP. It is the manifesto. It is shipping all the time at a sustainable development pace. I have had great success implementing agile and I attribute this to continually reindexing on the manifesto and examining the impact of our process. Spoiler: removing processes is a solution as often as it is adding a process. No amount of stand-ups or sprint planning or retrospectives makes your software process a good one.

156 points by spking 8y ago

A common point of contention is that agile is a list of philosophical guidelines, not a hard-and-fast framework for how to do things. A "true agile" shop should be periodically reviewing and updating their processes in the light of what makes the most sense. If, however, "being agile" is an organizational checkbox then some form of generally accepted agile methodology will be implemented whether it is the best fit for the company, whether the teams truly understand it, and without a built-in plan to reflect and decide if they are even doing agile right or if it's actually benefiting the organization.

linuxftw 8y ago

> Middle managers can also miss the importance of co-locating teams by bringing together designers, engineers, product managers and content specialists in the same physical space. The most highly functioning agile teams aren’t just at the same location or on the same floor: they share the same table. I can't refute this strongly enough. Managers should do their jobs and manage. Doesn't matter where team members are located. Anyway, this agile nonsense gets too much air time. We got it: highly iterative feedback loop development.

walshemj 8y ago
Actually no it doesn't referring to "agile nonsense" is a real red flag. Real Agile RAD /DSDM really does work best with collocated teams and experienced developers not lowest bid outsourced talent. I have worked on both RAD and OSI 9000 (BS5750) waterfall projects so I have experience in both types of development. Oh my Second RAD project was featured at the IEEE and when I was younger I worked with the BSI in the early days of BS5750
- cryptonector 8y ago
  GP said nothing about "lowest bid outsourced talent". "remote work" != "lowest bid outsourced talent".
  - walshemj 8y ago
    Oh I think I could safely assume that from the dismissive tone
howard941 8y ago
I couldn't agree with you more. At $CURRENT_PLACE we preach an iterative spiral that I believe is appropriate for the sort of embedded safety tech we work on that has built in time delays for testing at (for ex) UL or whatever NRTL is the NRTL of the day. Whether we're succeeding at differentiating it from serial waterfall is debatable. I think we are because marketing travels to see us every other week and they're meaningful yet we avoid what seem to me like make work bits of agile and scrum. Absent the imposed processes everyone works closely enough together that we can finish each others sentences most of the time and most of us appear look forward to coming into a workplace where the manager is absent half the time but because his most important role is to his bosses from interfering with us and to clear out the obstacles in our way it works pretty well.

abakker 8y ago

This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy. Agile is basically implemented to create an iterative feedback loop in the development process, but it seems totally rational that what works for startups won't work for very large distributed companies, and what works for an app developer won't work for an automotive supplier. Standups can take different shapes, the 'V' in MVP differs wildly by industries, and the cycle time that a product needs to have can be determined by external market forces (e.g. the school year). Agile is meant to adapt to the characteristics of the business it is used in, rather than to be specifically some universal way of everyone trying to everything in the same way.

ravenstine 8y ago
> This feels like "I can't define agile, but I know it when I see it"...or just a wonderful example of the No True Scotsman fallacy. Maybe so, but you are also describing Agile as if it can be anything a company wants it to be, which effectively makes Agile meaningless. I've worked with clients that have a waterfall-like development process, "standups" that are both status-reporting to management and on the spot planning, adaption to change is very slow and cumbersome, velocity charts serving management more than the team itself, tickets that represent multiple stories at once, management adding tickets(i.e. more story points) without removing less important ones, gigantic release cycles, etc. Is that still "Agile"?
- AndrewDucker 8y ago
  Are they following the Agile Manifesto? https://agilemanifesto.org/ https://agilemanifesto.org/ If so, then it is. If not, then it isn't.
  - ravenstine 8y ago
    Of course not, and that's really the point. Plenty of organizations will tell you they are Agile when they aren't truly following the Agile manifesto, but that's not going to stop the evangelicals from eating the horse manure("our team has standups 'n stuff") that reassures them that their belief system works. Everyone's bullshitting each other, and I wish it would stop, but I know it won't. Not everyone can be a "true scotsman". I'm not even defending Agile or other related methodologies like Scrum. They have some good ideas, but I haven't seen quantifiable evidence that they are good for businesses. Many of the ideas are good for software engineers, but that doesn't mean they are actually good for teams or companies. Even then, I've management use "responding to change over following a plan" as a license to make more arbitrary changes to what engineers will work on in a given day because they can take it. Planning days and point systems be damned.

jacknews 8y ago

The article presents too many Agile/Scrum "artifacts" for my taste, eg Agile favors so-called T-shaped skills Adam Smith would be turning in his grave Agile is a true democracy LOL The Agile philosophy certainly has something to say, but it's not hard to see the possible negative implications of "self-managing/self-policing teams" when they're owned by capitalist organizations. These kinds of ninja teams can be extremely effective, but they should own a share in what they create, otherwise the whole thing becomes a BS attempt to make people work harder via "transparency"

andrekandre 8y ago
i feel very much this gets close to the issue. (for me at least) if agile is supposed to empower the team to self-improve and self-organize, then being placed into a top-down hierarchy where the upper levels are always in charge anyways is a contradiction in itself and is a huge cause of disappointment that it’s “not working”... well of course it’s not working if i it’s being imposed by “the top” and for their own reasons... right from the start it’s not team-centered, so there you go.

ben7799 8y ago

I'm ready for what comes next after Agile. I've been through about 5 Agile shops now. I would say one of the 5 ran Agile well, the rest were a mess that just makes it frustrating for everyone. What we mostly have now is watered down agile.. the worst bits of agile like never actually "designing" anything, but we don't really have any of the good bits of the older management processes left over. I don't really want full waterfall again but I would really love to see some sort of lite versions of Functional specifications & design specifications come back. Agile works best IMO in the Pre-1.0 phase of a product and gets progressively worse the further you get towards maintenance of a product. I also think Agile works better and better the closer you are to the UI, and worse and worse the further you get from the UI. Solid back end design and infrastructure rarely fits well into "Sprints" and solid back end infrastructure is not sexy at all in a demo, so Agile can demote back end design to the point everything gets done in a way that is too MVP. Then later on when scalability, performance, bugginess, and maintainability come into play you're into that "established product" phase where Agile doesn't do as well. So you've got problems in an area of the product Agile has trouble with happening in a phase of development Agile has trouble with. Agile also seems to really require absolutely top notch product management folks, and they are seriously rare. The thing is of the 5 shops: * 3 Were acquired * 1 Went IPO * I work at the 5th currently So the companies always had a successful exit even if the codebase passed onto the acquiring company or to the public investors had major issues.. so at least in my experience there's no feedback loop to correct the issues.

im_down_w_otp 8y ago
I regret that I have but only one upvote to give for your comment.
cwyers 8y ago
Scrum != agile. You don't need sprints to be agile. If sprints aren't working for you and your team, then stop doing sprints. If your team can't decide to stop doing sprints, then you're not leading your own agile process and you're not really doing agile.
- cwyers 8y ago

crankylinuxuser 8y ago

Well lets read further in... So the article indicates and blames executives from short-circuiting Agile. And the article says that the best Agile is democratic? That sounds like a worker cooperative, not a private corp, LLC, S or even a C corp.

cwyers 8y ago

I think there's a fundamental misunderstanding of agile. Agile isn't Scrum, agile isn't Kanban, Agile isn't even really the manifesto. Agile is, like lean manufacturing (one of its inspirations), based around one really simple concept: the workers know the most about what they are doing and should be leading the charge on what they are doing. If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments. If agile is just another way for management to exert control over software development, rather than being about ceding control to software developers, it won't "work." This is the same thing you see with lean/TPS, by the way. The joint GM/Toyota venture showed that without committing to these principles, adopting parts of TPS don't really deliver the full benefits.[1] As one UAW team leader said about why working for Toyota was preferable to GM: > The GM system relied on authority. People with rank, the managers, ruled regardless of their competence or the validity of what they were saying. It was basically a military hierarchy. At NUMMI rank doesn't mean a damn thing. Standardized work means we all work the objectively best way to do the job, and everyone does it that way. I might make some minor adjustments because of my height, for example, but I follow the procedure as laid out because it makes sense. We're more like a special forces unit than the regular military hierarchy. Management's delegated responsibility to the people who do the work, and that gives workers a sense of pride in their jobs. If management is asking the developers to adopt agile, but they aren't doing anything to adopt agile themselves, good luck. 1) https://www.researchgate.net/publication/245862516_Democratic_Taylorism_The_Toyota_Production_System_at_NUMMI https://www.researchgate.net/publication/245862516_Democrati...

throwaway55554 8y ago
> If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments. If agile is just another way for management to exert control over software development, rather than being about ceding control to software developers, it won't "work." This is exactly what it has become though. It's not about developers, it's about managers and product owners. It's about numbers in a spreadsheet that managers can show upper managers. Management has sucked the life out of agile. It's become this rigid metric producing muck that gets in the way.

drderidder 8y ago

Dave Thomas, one of the original authors of the Agile Manifesto [1] wrote an article called "Time to Kill Agile" [2] a few years ago (which he subsequently re-titled "Agile is Dead"). He has some good insight on how Agile (the methodology) got to be something very different from what they intended. Originally they were trying to break away from a rigid methodology, not introduce a whole new one. Unfortunately, if you don't codify something into a set of rules, it's pretty hard to get people to follow it, and it wasn't long before "experts" were building formal processes out of it. I've never seen it work well, and the more ardent the adherents are, the worse it seems to get. I think every team needs to find the approach that works best for them to itemize, prioritize and communicate progress. In my experience the two most important aspects of moving a project along are simply communicating what needs to be done and recognizing effort. [1] http://agilemanifesto.org/ http://agilemanifesto.org/ [2] https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html

bostik 8y ago
> I think every team needs to find the approach that works best for them to itemize, prioritize and communicate progress. This is spot on. And the fact is, this has been known since at least 1980's (!)[0]. I am quite fond of using the version "culture trumps process", because it so well encapsulates the reality. (Also: hits directly against "The Process" ideology.) It often feels like everyone and their dog within the industry are hell-bent on establishing a Good Development Process. But that's a false premise. You can't just introduce a designed process and expect it to magically fix things. Workflow is everything: motivated and talented people will go to lengths to get their actual work done, process be damned. The best thing you can do is to invest in good tooling and actively encourage sane development practices. Get the workflow right, and process will follow. Crucially, as you said above, every company will need to find their own flavour. 0: https://quoteinvestigator.com/2017/05/23/culture-eats/ https://quoteinvestigator.com/2017/05/23/culture-eats/
wnevets 8y ago
I've dealt with "agile experts" who appear to never have actually read the agile manifesto. For those "experts" is always about following the rules and process of their version of agile. What gets presented by these "experts" is rarely anything like the original indent if not the anthesis.

ergothus 8y ago

I don't think I've been in a truly Agile shop, though a few times we had truly Agile periods on a given project. That said, some worked. If they: * considered every task to be a mix of features, deadlines, and resources, and realized that if you fall behind, even a little, you have to adjust at least one of those three * iteratively completed tasks and reviewed any adjustments to the overall project * Had dev <=> management be two way communication Then things were pretty smooth, even if they weren't Agile.

legitster 8y ago

I work at a large national software company who shall remain nameless. At some point, they determined that "we are now Agile" and put all work in a tracking software, and everything must now be assigned to sprints. But if you dig any amount of depth down it becomes ridiculous. An example I found, the helpdesk literally has one project every sprint ("Ticket resolution: February Sprint 1", "Ticket resolution: February Sprint 2", etc.) Or tasks that used to take 2 or 3 days now gets split across 2 or 3 sprints, because guy 1 can't allocate it to guy 2 until he finishes it. And it just sits around until the next sprint. Even creative departments are supposed to snap-to. The idea is a recording a video should be a dozen or so tickets in Jira (edits and revisions happen as bugs). These teams are smart and overworked enough to completely ignore the directive. And the amount of PMs has increased by an order of magnitude, because taking things in and out of the tracker has become its own workload because managers want to see more and more detailed 'analytics', so work get broken down into finer and finer pieces. I describe the situation as if someone tried to make their truck lighter and faster by bolting a Lotus onto it.

sethammons 8y ago
> Or tasks that used to take 2 or 3 days now gets split across 2 or 3 sprints, because guy 1 can't allocate it to guy 2 until he finishes it. And it just sits around until the next sprint. This so much. Because no PMs want to adhere to "sprint forecast," but insist on "sprint commitments," you literally cannot commit to doing a unit of work that depends on someone else getting theirs done first until they are done. A smooth flow that gets to market quicker now _must_ be lock step gated by sprint start dates. /me sighs
- iovrthoughtthis 8y ago
  I imagine stuff like this is why kanban was developed.
  - sethammons 8y ago
    I think kanban was primarily for interrupt driven projects, but this works too for pipeline like stuff.

kleiba 8y ago

Does any one have good (as in: known to actually have had a positive effect in the past) insights on how to convince your manager(s) that (at least their version of) "agile" is not helping the company? My wife works in a company where the managements seems to be quite "proud" to apply "agile methods" but in my wife's opinion, it's more BS bingo than producing a measurable boost in productivity, quality, or any other desirable metric. It is her impression that they are forced to adhere to certain routines even when the benefit is questionable. For instance, every morning at 9pm the whole department has a "daily scrum meeting", but most of the time there's nothing important to report from the day before for a lot of people, so it tends to lead to either embarrassment, pressure, or to people making crap up just so they have something to say. Needless to say that this doesn't lead to "team building". That's just one example. So, either the specific way "agile" is executed in my wife's company is just stupid, or the whole methodology is perhaps not applicable to their setup -- or something else. But it seems that the current practice is just a gigantic waste of time, yet the management is so proud of their "agile" way. How could this situation be improved? Any tips?

soperj 8y ago
From what I've seen is that Agile doesn't ever end up working when it's driven from Management. They only care because it's supposed to be more productive, but they don't want to actually adopt any of the measures that make it more productive.
- nielgaard 8y ago
  But it is always driven from management. When was the last time a group of developers decided all by themselves that they needed a development framework to get work done? And isn't it funny how management never uses any agile framework to do their own stuff. Could you imagine the board of directors putting Fibonacci cards on their foreheads when deciding on budgets or earnings forecasts?
codeflo 8y ago
I know what you describe is common, but the purpose of the daily really isn’t to boast about your heroic achievements of yesterday, or give a status report to management. That part should be cut out entirely much of the time. A better idea is to plan the current day, identify where someone could use help, where two people need to coordinate more closely or on what issues further discussion is needed and with whom. If there’s nothing to discuss because everyone is already on the same page, that’s great, cut the meeting short and start working. Also, depending on your setup, people who can never usefully work together on anything probably shouldn’t be part of the same daily standup. I’ve seen several cases where this meeting was way, way too large.

peterwwillis 8y ago

Most people who have an opinion about Agile don't understand it, and nobody understands it because the industry doesn't make it mandatory. It's the same with DevOps... A great idea reduced to a buzzword due to confusion.

maxxxxx 8y ago

We should have stopped at the Agile Manifesto. Everything following it made Agile worse. In the end companies will almost always regress to a top down hierarchy. True Agile is bottom up which is against the structure of most companies.

sequoia 8y ago
Is the agile manifesto actionable in any clear way?

hnruss 8y ago

I'm working on a project right now that lacks well-specified requirements, yet we're barreling ahead with the implantation. I'm not exactly sure what's going to happen. My guess is that we'll end up with an MVP that meets the known requirements, but then we'll have to rewrite some part of it to meet the as-yet-unspecified requirements.

hota_mazi 8y ago

Companies that don't follow agile and instead, choose to pick only the subset of agile recommendations that make sense for their culture and teams, are actually the real agile companies. It's always struck me how the attitude of agile advocates has always been so rigid to the point of being dogmatic, thereby being the exact opposite of agile.

cirgue 8y ago

I feel like 'agile' has become similar to capitalism or socialism in that it exists to solve a set of problems, and the internal structure of the idea does in fact solve the problems it seeks to solve, but has a whole bunch of real-world failure modes that make it tricky if not impossible to make work successfully over the long term because they're founded on assumptions of how humans work that are close but incomplete. Management always wants more granular control over projects, and agile doesn't encode a way of resisting evolution toward one of the many versions of zombie agile.

tkefauver 8y ago

Where in this article is there any examples of how most people aren't following agile methods? Pointless

tkefauver 8y ago

Where in this article is their any examples of how teams are not adhering to agile methods? Pointless

jaequery 8y ago

Agile is so vague I don’t even know what it is anymore. Can someone show us how an agile should look when creating a simple to-do list project?

mbostleman 8y ago

My current experience with a distorted Agile approach is that it is used as an excuse to not have a big design. The idea is to not block on a big design UP FRONT. Not have no design at all. So the platform I'm working on now has been torn down to the foundations and fundamentally rebuilt at least twice because the lead(s) on the project never looked further than one sprint out. Somehow it is expected that an organic design will spring from nothing. Very unfortunate.

oxfordmale 8y ago

I would recommend for the author of this article to read the original Agile manifesto and point out where the so called Agile methods and resourcing models are described. I am often only resourced 10% to some Agile projects, because my expertise is often only required for a small part of the project. And yes a copy writer can do my job as well, but would you really let an average electrician build the timber structure of your roof while the plumber wires your house ?

sequoia 8y ago

It’s notable that the ratio of “that’s not really agile” to “this _is_ agile” comments in discussions like this is typically about 10:1. Everyone knows what agile isn’t but no one can seem to explain exactly what it _is_. Furthermore, the “you’re holding it wrong” criticism of everyone who gets poor results from agile, which seems to be a majority of people attempting to use agile practices according to articles like this and comments ITT, is a major cop out. If 75% of people attempting to use a tool hurt themselves with it, you should start asking whether this was a well designed tool in the first place. My solution: stop using the term “agile.” It’s so vague and means so many things to different people that it effectively means nothing. Instead, talk about specific practices (sprints, story points, etc) and be able to explain the purpose of each practice. This can clear away the agile fog and get people discussing actual trade offs rather than agile magic dust.

iovrthoughtthis 8y ago
That’s the point though, right? There is no one “Agile Methodology”. It’s meant to be a communication protocol you grow within your organisation based on the principals outlined in the manifesto.
- sequoia 8y ago
  The title of the article “Everyone claims they are following “agile methods” but few actually do” suggests that there is something called “agile methods” that can be followed. I don’t think I understand what you mean about it being a communication protocol. In any event, it seems beyond debate that the term “agile” is extremely widely misunderstood. I’m arguing that instead of tilting at windmills trying to correct everyone who is “understanding it wrong”, we give up, discard the term, and focus the pros and cons of specific, describable practices. Agile seems to be more of a feeling than a practice.
  - iovrthoughtthis 8y ago
    There are some codified system of rules and behaviors that people have developed to help their orgs gain agility e.g. Scrum, SAFe, etc. But there are probably an infinite ways to skin that cat. Doesn’t really matter which one you use just that everyone is using the same one. Which leads me onto why it’s a communication protocol. Human systems/processes/procedures just organise the flow of information, often to help people make decisions. If everyone isn’t following the same set of rules and behaviours then there can be a breakdown in communication. Which usually screws things up (whether top down or bottom up)

tynpeddler 8y ago

I was a late comer to software development so my career is relatively short at this point. I have worked for 2 different shops and had wildly different experiences with agile. The first is a fortune 500 company that is not a techy company. They have a lot crusty old infrastructure and when they decided to do agile, they hired a consultant company that came in and spent a lot of time training everyone in their "agile" methodology. I can say without sarcasm that it worked great. It was painful at first and it took probably a year for everyone to adapt, but I was very pleased with the end result. Agile didn't mean, don't do design. For us, Agile meant to always be designing. We set aside 2 hours every week to sit down as a team and design future features, as well as evaluate current architecture and propose changes. Outside those 2 hours, devs would do additional design as needed. We had one hour every week for a long form meeting for our BA's, product experts and development team to all get on the same page for business requirements and future product direction. In addition, the product team was available for consultation almost every day, and never fewer than 3 times a week. Our retrospectives were rigorous, and by the time I left the company, our estimates were excellent. We had gone from almost never being able to finish our sprint correctly to it being a surprise if every story wasn't finished on time. Occasionally business would throw a curveball at us and we would have to scramble to get our backlog and designs into place, but we were still able to finish almost every sprint as promised. I'm a little over a year into the new place. It's also a Fortune 500 company, but it is know as techy and has a good reputation with the field at large. So far it has been miserable. They're one of those companies that does waterfall with standup. As a result, we have extended periods of torturous drawn out design (one guy went six months without writing a line of code for work), followed by a mad scramble to implement our designs as we realize we're running out of time. As a result, the documentation looks nice, but the code is a mess and doesn't always match the documentation. Since the team can't self organize, tech debt continues to accrue at a terrific rate. Small stories are awkward because the pipeline and commit process is too difficult and slow to justify it. Part of the problem is the lack of business analysts. Without that intermediate group to help manage business complexity, the developers are left doing an extensive amount of basic requirements gathering just to get started on a problem. In addition, there's no real institutional memory, and when business flows change, there's no one around to update old docs with the new changes. There's no real story grooming, so we routinely overshoot our sprints. Without a clear understanding of how product and development are supposed to interact, priorities are changing constantly and I've been shuffled between two projects almost at random. I could go for hours about the two different companies but I think the difference boil down to one simple factor. The first company had a culture of continuous improvement. They had their share of failings, mostly related to not being a very techy company, but everyone in that company was deeply committed to constantly making things better. Pain points were either quarantined so as not to impede work, or they were called out and fixed. If something couldn't be fixed or quarantined, than it was tracked until everyone was so sick of talking about it, we'd find the time to fix it. The second company does not have such a culture. Everyone is very comfortable with the status quo no matter how much it slows things down. Things are starting to get a little better, but not much. I think Agile worked well with the first company because everyone was already interested in constantly improving. Agile gave them a framework to evaluate their performance and improve it. Without that culture of constant improvement the second company just adopted the most cosmetic practices of Agile, without actually changing anything, or evaluating their own behavior.

iovrthoughtthis 8y ago

I see part of the problem being that Agile is seen as a management methodology when it’s actually a development methodology. Management here meaning overseeing people. Development here meaning building things.

akeck 8y ago

We follow "Jira methods".

lochlan 8y ago

IMO the problem is that people want to buy Agile. They want to pay a consultant, or go to a class, implement a dozen scrum rituals, and call it “agile.” Agile is not Scrum, Kanban, or even XP. It is the manifesto. It is shipping all the time at a sustainable development pace. I have had great success implementing agile and I attribute this to continually reindexing on the manifesto and examining the impact of our process. Spoiler: removing processes is a solution as often as it is adding a process. No amount of stand-ups or sprint planning or retrospectives makes your software process a good one.