Hacker News new | past | comments | ask | show | jobs | submit login
Agile is Dead (linkedin.com)
121 points by dsego on April 26, 2016 | hide | past | favorite | 99 comments



This guy is decrying a bunch of hucksters selling buzzwords to corporate managers with more money than sense. What's his solution?

> If I were king, I would prefer to see a methodology using the (ISC)2 recommended practices in the SDLC, and the emerging OWASP practices, with more certifications like the CSSLP.

The author apparently calls himself an "Enterprise Architecture Evangelist MSEA BSEE CEA³ CISSP-ISSAP PMP ITIL"

I've got to chuckle. What does any of this even mean? And what does it have to do with writing good software?


He's either a troll or lacks reading comprehension. The first article he links to is well summarized by this paragraph:

"And, unfortunately, I think time has proven me right. The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products." (https://pragdave.me/blog/2014/03/04/time-to-kill-agile/)

"Doing the right thing at any time" is still a perfectly valid principle, though.


Perhaps: MSEA (Master in Science of Engineering Awesome) BSEE (Binomial System Enterprise Engineer) CEA³ (Crack Enterprise Architect -to the 3rd!) CISSP-ISSAP (Calisthenic Infrastructure with Solipsistic System Paradigms - Isomorphic and Soporific System Accreditation Practices) PMP ITIL Pusillanimous Management Practices for Information Technology Inline Languages (or Pmpster IT for short)


Titles by first result on Google

MSEA - Maryland State Education Association BSEE - Bureau of Safety and Environmental Enforcement CEA3 - Clean energy associates CISSP-ISSAP - CISSP-Information Systems Security Architecture Professional PMP - Project Management Professional ITIL -Information Technology Infrastructure Library

Those got less interesting as I went on. :/

His title reads like a shitty craigslist posting

For sale - 92 Toyota Corolla $100000

TOYOTA COROLLA ACURA HONDA FORD CORVETTE CHEVROLET DATSUN...


I think all those letters are meant to test whether you can read letters or not. An eye chart if you will.

It has nothing do with writing good software. I've seen these sprinkled about on titles before and I've just rolled my eyes in the past and will continue to do so in the future.


Well, I'm sure he could explain it all to you. If you take his 4-day course, of course. Seating is limited. Reserve your spot for a paltry fee of $5000.

And the best part is, you can access his slides later. Through an OWASP and OASIS-approved highly-scalable and enterprise-y SOAP API which is extremely easy to consume, as long as you use his Enterprise Scalability Patterns Application Block (it's well-documnented in his 890-page book, which is a must-buy).


What is CEA³?

edit: Perhaps it is a certified enterprise architect "black belt" such and such from:

https://www.feacinstitute.org/feac-courses

Looks like all you need is 11K and 14-16 hours:

http://www.tomsitpro.com/articles/enterprise-architect-certi...


Why would anybody assume they'd be taken seriously on HN when they have _that_ as part of their title? It doesnt even rhyme.


Don't forget TOGAF! No 'Enterprise Architect's" resume is complete without a little TOGAF!


Agile will be dead as long as it's the dominant management methodology and there are page-views to be had. It'll be replaced with essentially the same process but with different terminology. Long before the Agile Manifesto, when I was working at NASA, we talked about the reality that the state of knowledge about a project is at its lowest at the beginning, and that any realistic project planning and management process must acknowledge and accommodate that fact. Subsequent research has confirmed that human beings consistently underestimate complex tasks, and that this bias persists even with experience, so no matter what methodology you adopt, you will always be under unrealistic deadlines. This results in distortions to whatever process you use, and flaws in whatever product you produce, and these distortions and flaws will be blamed on your development process, since no one will accept that it's simply an unfixable feature of human nature.


I've always felt the problem is that we're trying to estimate something unestimatable. My thought's always been that if the management needs of the company are that developer time should be quantifiable and that projects should have a direct ROI, then the most sense would be to only chase ROI in small projects of little risk, and leave business growth to big projects with lots of ambiguity and lots of risk. This is the same for any kind of business venture; why should writing software be any different?

In other words, if your process involves predicting time needed to complete a project, you've already failed.


My father-in-law is a project manager for a gigantic construction company, so it was interesting talking about estimation for him. Estimates are much more predicatble in his field, even when working on multi-million dollar projects with timelines that span several years.

The difference was that in construction, the same subprojects have to be done over and over again, so subcontractors can easily be given and held to realistic deadlines, and your only bloat comes from the usual hiccups. On the other hand software engineers _by definition_ estimate things they've never built before. If they've already built it, they can just port it over and start working on something new.

Combine that with everyone's tendency to underestimate, inability to determine unknown unknowns, and the usual hiccups, and we're left with the usual refrain: accurate software estimation is basically impossible.


The interesting thing is that in software engineering the cost of additional sub components is zero. Copying bytes is effectively free, so we gain no useful information on how much it costs to build a widget.


2 observations from my experience:

1 - You can fix the time or the scope of the project, but not both. I can say, "I will deliver project X in 4 months" but you have to be willing to let me toss out scope, and the earlier the better. This does work. Just like I can say, "I will promise to deliver all the scope in project X, I just can't promise how long it will take." Agile helps break this into smaller chunks, and allows you to get more visibility into what's realistic more quickly. I've seen too many waterfall projects slip by 3-6 months at a time only when the final deadline approaches.

2 - I've seen more projects slip because of "Unplanned work" and "Missed Dependencies" than due to "Misestimated work". It's either scope creep, or "I didn't realize we needed to test integration" or "Person X didn't give me what I needed." The only counter-examples I've seen are when engineers aren't consulted in the estimates.


I would certainly agree on both of these assertions.


I think, Digitalization helps a lot to change the mindset of management by just removing unnecessary management levels and by bringing the remaining levels closer to product development. This happens to a point where management by deadline becomes a weakness, because the now missing management levels cannot hide weak links (from upper management, investors, share holders, customers).


>> "the state of knowledge about a project is at its lowest at the beginning"

Sounds like the Cone of Uncertainty:

https://en.m.wikipedia.org/wiki/Cone_of_Uncertainty


Do you have any references to "subsequent research"? I am truly interested in digging deeper.


Daniel Kahneman's book "Thinking Fast and Slow" is a great overview of the field of cognitive bias. For a more academic treatment of his research, check out "Heuristics and Biases". The part of his work most relevant to project estimation can be found in the "planning fallacy" section. Aside from Kahneman, there are numerous papers on software estimation, many of which note these consistent biases (for example Jørgensen, https://pdfs.semanticscholar.org/fd87/d248dd55f59d8d93742fb3...).


I know that Code Complete 2 has quite a few discussions about the phenomenon of consistently missed estimates and many references about those. I would definitely look there for a starting point about the impossibility of successful estimation in software.


"Agile is Dead" is like saying: Life sucks.

Agile is a phenomenon with lots of different manifestations that try to do their best at embracing the Agile Manifesto. Yes there is hype and people who make money of it. But that hype is justified by many examples of successful Agile manifestations.

Most important to Agile is to get it. To get into the mindset of feedback loops and collaboration. For larger companies with "non-Agile" habits, that is hard by default.


I hope 'Agile', as a product, with the capital A, that sells lots of worthless pulp fiction "how to" books, with dogmatic consultants propagating useless practices they neither understand nor can follow, well I hope that is dead. It was and is a cancer on the industry as a whole.

I however hope 'agile' as a spirit of talking to your users, breaking down tasks into bite size deliverables, testing, and making sure things move in a generally agreeable direction, well, I hope that persists and flourishes.


Those who say "agile is dead" are those that think agile was something you had to buy in the first place. To me agile has always just been a way of thinking about solutions to problems. It can't 'die' because it ideas have already been absorbed into our collective consciousness and affects the way we create solutions. Even if no one calls it agile anymore, the mark has been made.


Let's just call that Quality and make things in good ways.

Go back to W. Edwards Deming—understand your customers, understand your company and your people, manage with respect and based on science and psychology, and base decisions on the reality of your systems and customers, rather than fantasy goals or objectives.


The problem is that agile mindset was sold like a product and those that bought it never took into account the cultural change that organizations have to make to make "agile" work.


Yes! Agile with a small 'a' is something I talk about at work too often. I don't want to be "Agile" but rather "agile" as in the definition of the word, "able to move quickly and easily."


Agreed. It's interesting because we all know branding aside, feedback, frquent builds, communication is something you can't deny is a good thing. But it's not unfortunately hard to decouple enthusiasm for agile from a perception of zealotry.


I think agile is mainly about a common language, contract or understanding between the developer(s) and their customer(s). Before, customers used to negotiate a finished product without taking all the risks involved in specification changing.


But also, agile is dead.


Long live Agile?


Just to illustrate an example of how people are using the term "agile" wrong:

If you ask around, you'll notice that (many|most) people equate "agile" with "two week sprints". But if you actually read the Agile Manifesto you find this:

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

Agile does not dictate that you use two week sprints. In fact, th term "sprint" itself is not even part of agile! The term "sprint" comes from Scrum, which is simply one specific methodology which claims adherence to the agile philosophy. But Scrum != Agile. Agile can also be XP, Crystal Clear, or AUP, etc.


Scrum is the easiest for management to grasp at a surface level so out of all the methodologies under the Agile banner Scrum is most readily and widely adopted.

The problem is that Scrum "sprints" are like treating a marathon as 422 contiguous 100m dashes.


The problem is that Scrum "sprints" are like treating a marathon as 422 contiguous 100m dashes.

Yep. Or to put it another way, too many shops seem to think that you can "sprint" ALL THE TIME. And while it's "only a metaphor", it's a meaningful one in this case. You can't:

    sprint -> sprint -> sprint -> sprint -> sprint -> sprint -> ∞
You have to:

    sprint -> sprint -> breather -> sprint -> breather -> sprint -> sprint -> breather -> ∞
or something like that.


Sprints aren't sprints.

Replace sprint with time segment. And you get more accurate picture.


Sprints aren't sprints.

Except when they are. And just using that term encourages people to treat them like actual sprints, instead of just metaphorical sprints. This is why I advocate for use of the term "iteration" instead. But even then, I think it's important to include "slack" iterations that are for random bug fixes, miscellaneous refactoring, etc., that is developer driven, not business user driven.


> Agile is Dead.

Ok. I listen. What is it wrong with it ? Then there is an endless list of links. I don't even know where to start. Impossible to argue against that. But I still don't understand what the author meant.

So. If we just stick to the agile manifesto. Is there something wrong with it ?

The worst part is that there is no proposed alternative. I kind of get the idea that the author still thinks big upfront design is the way to go. If he believes agile is no better than Waterfall. I can't agree with that. I would hate to go back to that.


One answer is by Simon Bennet. See https://vimeo.com/138060217 , in particular 13:10-16:00


Since no one has posted it,

Manifesto for Agile Software Development

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 interaction over process 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 items on the right, we value the items on the left more.


Agile and was indeed the OOP Design Patterns of the late 2000s. Sure, there's many smart things in it, and many of those will survive, but when consultants started selling cargocultish dance moves you have to do to succeed, and where all failures happened because you were just not pure enough, it became as awkward as AbstractsSingletonFactories.


Oh, look. Another PMP proponent who didn't _WANT_ any agile practice success rushing to quote everyone who has reflected on the fact that it isn't perfect. This guy kills his credibility with the "let's hold a rave on the grave of Agile, I'll bring the Molly" attitude.

Also, he clearly never learned the secret sauce of "agile" that Scrum and modern proponents only pay lip service to because it doesn't "sell well": Fucking. Technical. Practices. I've spent over a dozen years now on teams that focused on a.) pair programming b.) test coverage and testability c.) CI (actual CI on one branch - not GitFlow B.S.) and d.) Close customer involvement. We shipped high quality, low bug software that made money for the businesses. Teams that fail to learn technical excellence leave 75% of the value of "agile" on the table, and 9 times out of 10 it's the fools in suits that won't 'let' them do it.

As far as I'm concerned, big organizations can go to hell & keep failing over and over. As software becomes more powerful, 'we' don't need them: http://allankelly.blogspot.com/2015/10/software-has-disecono...


Good Riddance. While applying for jobs last year, I have seen huge difference between companies that demonstrate great pride in using Scrum and Agile and (insert any other buzzword here) and others that really understand how software gets developed.

Software is and ever was product of art and skill. There are great ways to improve productivity, for instance I really like how kanban fits software development. On the other hand, using Scrum and sprints and what not is how non-tech HR person explains to the non-tech management how software should be developed.


Seems to me that if you are a decently talented developer one would be able to adjust to whatever work methodology a company uses. It's a pointless thing to involve whether a candidate knows anything of the system currently in place. Every job I've worked has been different, some have even changed, and it's worked out fine enough.


One of my last clients used scrum (I was a contractor). The boss ran a fortune 500 company during the day and decided to take everything she learned to run her own small 20-person company.

Our standups lasted minimum 1 hour every day. Every Thursday we had a show-and-tell meeting, which meant going through everything we worked on and fixed (some of these meetings lasted 3 hours) and we also had a pre-planning and post-planning scrum meeting, each lasting 3 hours.

At one point I was charging the company more for meetings than actual work (it was 70/30 meetings to work).

I finally left when we added another 1-hour meeting on Fridays where we would just tell a joke, funny story, or something about our life. Since the majority of other contractors/developers on the team were from other countries (and didn't speak English very well), it was one of the most awkward situations I've ever encountered at work.


Sad. It looks like the someone going through the motions without understanding the intent.

In contrast, I've been part of agile teams where we were from three different timezones, had short standups (sometimes multiple times a day depending upon the need), and focused on delivering value.


> DevOps is the next wave replacing Agile

DevOps is about eliminating the decades-old division between development staff who control the programs and operations staff who control the data. By having "DevOps" staff who control both programs and data, businesses open themselves up to large-scale employee theft and fraud.


Being "Agile" means being able to respond to change.

For software, that means delivering high value, high quality working software quickly and frequently. One needs the fundamentals of short feedback loops, the ability and willingness to inspect and adapt, and collaboration and teamwork. Everything else - training, release planning, standups, story card walls, iterations - is all just the ceremonies and techniques that support these fundamentals.


You can't kill Agile because Agile doesn't mean anything.

It's a marketing term. It's the place in the bookstore you go to buy books about cool stuff technology teams are doing nowadays.

If I want science fiction, I go to the science fiction aisle. If all the science fiction sucks this week, I either buy something else or wait until next week. I've already established that I like reading science fiction.

If I'm consuming material titled "Agile" that doesn't seem to work, or seems like a scam? I stop consuming that material. More will be along later.

And just like in books, many times you have to take the book home and try it out to see if it works for you.

I think there are some people who really, really, really want a magic bullet. They want an answer to life, the universe, and everything. And in so many fields, that just doesn't exist. These are some of the same people, by the way, who make Agile so terrible for everybody else. You gotta dial back the feverish adopter thing, whether you're for or against Agile, to make any progress in your career.


As with any tool there is a place for it. Daily stand ups sucked but on the big project I was on, it did help with people needing to bring up roadblocks. open floor plans suck but you get used to them and start feel isolated when you go back to a cube. Code quality suffered because of the constant pressure to get things done now.


Stand ups didn't suck at my last company. (My current one doesn't do scrum at all.) But they were okay because I refused to let people screw them up. If anyone got off-topic, I simply asked a pointed question and got them back on track. Everyone appreciated it, and it kept the stand-ups short, like they were supposed to be.

When others ran the stand-ups, they tended to let people ramble more, and they were more painful. I did my best not to step in and corral the situation, but I still often ended up asking the appropriate question.

My meetings went the same way, with a focus on getting things done so we could all go back to our desks. We socialized plenty from our desks and other times, and there was no need to drag out meetings.

I was thanked for my efforts numerous times, and I tried to be aware of any discord that was created, so I'm fairly sure I wasn't making enemies by doing it.

My point is that standups don't have to suck, but someone has to keep them on track. That's what the standup leader is supposed to be doing anyhow.


Heh, on one of the projects I once worked on, we had a problem with the stand-ups getting too longwinded, and so we instituted a 1-minute time limit for each persons' update. And then we were like "Hey, this is working pretty well, let's see if we can shrink the time limit!" We ended up getting it down to 10 seconds/person, with the entire standup over in one minute.

The essential purpose of a standup is to make sure everyone knows what everyone else is working on, to identify any potential blockers early, and to get the right people collaborating offline to work out details. It really doesn't take very long to say this: "ComponentX, componentY; Blocked on componentZ; need to talk to Bob and Sue afterwards" is fine.


There's no reason you need to get everybody in the same physical place at the same time for this. If you are just giving status updates, team chat is a perfectly viable option.

I know I personally can't get started on things right away in the morning because of the psychic weight standups carry. I can't get focused because in the back of my mind I know I'm going to get interrupted soon for a meeting that mostly has little relevance to me.


I had another project (two, actually) where we had a "remote standup", where a couple of the team members were on the opposite coast and dialed in via videochat. You do lose something. It works, but it never felt like those teams "gelled" as well as the ones where everyone was in the same office, and the remote workers were often off doing something tangential rather than something core to the project. One of the points of the standup is to build trust and unity within the team; it's harder to do that when you're not face-to-face.

Also, there's nothing that says that standups have to be in the morning. Most of the teams I've worked on actually had theirs either right after lunch or mid-afternoon. That accommodated those of us who were late-risers, it let the early-risers get some work in in the morning, and it meant that it'd often fall during food coma or when energy levels hit a mid-afternoon nadir.


That's fair, but for groups who are in fact all in the same office, there's plenty of face to face time every day. In every environment I've worked, I've never met a developer who's been gung-ho for standups. They are always attended begrudgingly. And if you need standups to build team camaraderie and trust, there's probably other larger issues that a standup isn't going to solve.


>If anyone got off-topic, I simply asked a pointed question and got them back on track.

I'd love to hear some examples here, maybe a snippet of one of your stand-ups.


open floor plans suck but you get used to them

Open floor plans are not a requirement of "agile". That people think this, is evidence of the real problem here: hucksters have been selling something else, but using the word "agile" to promote it. If one wants to argue that the term "agile" is dead, then maybe one has a point. But I'll argue that the essence of agile is just as sound as it ever was, it's just that we let the term get misappropriated. How to proceed from here is an open question...


The problem with agile is it's not management friendly. And since they cut the checks, they get to dictate how things get done. All they care about is when is it going to be done and how much will it cost. Oh, and make sure all that shit management promised is in there.


Are you redefining "friendly" as, "makes promises that can't be kept and tells you what you want to hear?"


It's an operational definition of "friendly", as implemented by middle managers across the globe.


By more than middle managers. I think some people also use this when seeking relationships.


Well, it does seem like an odd thing to sell your customer on, doesn't it? If you wanted to do some home renovations and somebody told you they had no idea how much it would cost to do until they started working on it, you might be uncomfortable. There are scenarios where this isn't an issue but I wonder if it's as broadly applicable as we've made it out to be.


If you wanted to do some home renovations and somebody told you they had no idea how much it would cost to do until they started working on it, you might be uncomfortable.

Right and this why I say that so many people are (intentionally or not) misunderstanding what "agile" means, and selling something else using that label. Look at what the Agile Manifesto actually says about plans / planning and what not:

    Through this work we have come to value:
    ...
    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
So, all those people out there acting like "being agile" justifies operating with no plan at all, are NOT really in alignment with the core principles of agile. Agile does not prescribe "no planning" and never has. What this was all in reaction to, was the idea of BDUF (Big Design Up Front) and the concept of spending huge amounts of time building models and creating artifacts which, in and of themselves, delivered no value to the customer - and furthermore, were likely to be changed anyway.

If "agile has failed" is really true, then here's the one place where it probably failed: It was never prescriptive enough. Which might seem paradoxical, but the problem is, the AM is subjective enough that people could find justification for whatever bullshit ideas they came up with, in the Manifesto. :-(


Having dealt with US Federal Government customers and multi-year projects, I think the issue is that it gets really hard to provide an accurate cost and time estimate for the whole project without a BDUF, at least once a project gets beyond a certain size. This is especially true when the project is just a piece of a larger product and needs to coordinate with other subprojects.

It may be that agile is just not appropriate for such projects, in which case I wish companies and customers would stop trying to force-fit them.


It's really hard to provide an accurate cost and time estimate even with a BDUF.


True enough, but I guess the question is whether agile processes help or hurt.


The difference, as I see it, is this: In a "BDUF" / "not agile" environment, the customer expects a rigorous change control process, and that serves to protect the developers when the customer starts changing things around. In an environment marketed as "agile" it became received wisdom that you don't do "change control" because it "isn't agile". So while the agile process (Scrum or what have you) was designed to manage the change in requirements from the developers' point of view, we seemed to get away from the thing that forced the customer to update their view of things, when changing requirements midstream.


I guess it depends what people mean by agile, because I've seen some people talking about agile means it's impossible to say roughly how much time work will take without starting out which seems odd.


My favorite variant on this is combining "agile" with no design or requirements up-front with a rigid change request process at the end.


My favorite variant on this is combining "agile" with no design or requirements up-front with a rigid change request process at the end.

The thing is, a certain measure of "change control" was always a good idea, even in an "agile" environment. My (admittedly subjective) take is that getting away from change control contributed to everyone's mindset shifting to where "changes are free".


Well, in the project I saw this happen on they also stopped the requirements gathering process for an agile process where they promised to implement changes when it didn't match the process well, so it was kind of a bait-and-switch technique.


Its almost as if service based economies are not that compatible with property rights based capital markets.


OK... so what do you propose software developers do to usher in the post-capitalist age?


Its almost as if service based economies are not that compatible with property rights based capital markets.

I don't see it quite that way. Services business work in our economy, but if you're doing something on a services basis, you have to understand the implications of that and how to manage them. There are all sorts of services in our economy that work (mostly) fine today.

To illustrate what I mean, let me use an example.. if you take your car in to a shop for repairs, you expect an estimate, and you aren't necessarily pissed if the final tally is off the estimate by a bit. But you will be royally pissed if it's off by an order of magnitude or more.

So, do software projects sometimes cost (in time, money, both, etc.) an order of magnitude more than estimated? Yeah, I'd say so. But here's the rub... are car mechanics better at estimating than software developers? Not necessarily, but their customer doesn't typically come along when the project is half done, and yank the rug out from under them and ask for something that negates half the work they've already done.

"Yeah, about replacing that spun bearing...I don't really want that, just replace the fuel injectors instead".

Nope. Doesn't happen. But I'll argue that the equivalent does happen in our world.

Of course the Agile Manifesto is all about the idea of embracing change, and accepting change even late in the process. So we have to accept that and deal with it. But the rub here is that we have do so in a way that doesn't come across to the customer as an order of magnitude failure.

This is one place where I think we, as an industry, kinda fell on our swords. WE understand agile, but we didn't always educate the customer on what agile meant. And we didn't do a very good job of communicating to the customer what the impact of their change in requirements is. We accept changing requirements, yes... but we haven't always made it absolutely clear to the business customer that "making this change is the equivalent of asking the auto mechanic to replace the fuel injectors instead of fixing the bearing. This is throwing out all the work we've already done, and we need to re-estimate everything now."

Is it because IT people lack the nerve to push back when business users make huge demands? Or something else? I don't know, but over the years I've become convinced this is a big part of the problem. We let the users change things (which they have the right to do), but we don't make damn sure they understand the implications of what they're asking for, and update the estimate/plan/etc. to reflect the new reality.


That's the problem with outsourcing. Most outsourcing companies will let you spin around in circles charging the whole time even if they know a better way.


> How to proceed from here is an open question...

Keep doing the parts of it that work for you. If parts of it don't work for you, change them or drop them. (Part of the agile philosophy is that you can hack your process.)

We may need to drop the word "agile". But if the mindset leads to you practices that are helpful, use them.


> open floor plans suck but you get used to them and start feel isolated when you go back to a cube

I felt the same way. And now after a few years of open floor plans, I actually love them. Sure there are some drawbacks: noise can increase, and certainly there are more distractions, but there are many benefits. Communication is easier. That feeling of isolation is gone. The group feels more cohesive. I think the only modification that could be made would be to create more isolated areas off to the side either for individual work or team meetings. And companies are doing that, although the private areas are moreso for meetings. But I hear that some are even making smaller areas just for individuals who need a few hours to focus on one task.

> Code quality suffered because of the constant pressure to get things done now

It takes some wisdom for managers to be able to properly apply Agile principles. Pressuring devs to spit something out without properly designing it is poor management practice. Its common, yes, but its still wrong. That's why Agile suggests a fairly wide range of time to deliver software (from two weeks to two months). Every piece of software is different, and it takes good people to determine the correct balance between release frequency and development time. You should prefer to release frequently, but if you're releasing garbage then what's the point?


Does Agile really not work with large enterprises? Or is it more that "fake agile" doesn't work?


> Does Agile really not work with large enterprises?

It works well when you can control or bound the expectations of your users. Delivering a gradually-expanding customer self-service portal, for example, is a perfect candidate for agile processes.

However, it doesn't work when the requirements are legal or financial compliance. There is seldom an opportunity to iterate and improve, it needs to be done once and fully by the go-live date. You can't release a small part of a compliance project ahead of schedule because, well, it wouldn't be compliant... Date-bounding makes-up a large proportion of enterprise business logic for this reason.

Counter-intuitively a large enterprise actually needs to be more flexible in its project management and methodology than a small, "agile" start-up. Deploy whichever technique is appropriate for the task, which means you have to have adaptable staff.

Source: having worked for a Fortune 100 that was agile-ising.


That makes sense, I think. Though in the spirit of the original authors, it sounds like it's more about collaborating and getting things working bit-by-bit rather than releasing publicly.

In the legal/financial compliance zone, it's probably about "here are the things we need to get done for this aspect of compliance," and then just doing them.

We're saying the same things, yeah?


Yes. Compliance things can be broken down into smaller deliverables just like anything else. You just have to make sure what the feature being delivered is compliant if it is being released to production. Just because something is being "delivered" doesn't mean it's going directly into the hands of clients.


Fake agile does not work. Large enterprises come with all their problems in processes, tools, skills, etc. They hear this new buzz word and latch on to it. They take this new thing to their teams and ask them to implement it. And all this while, the upper management just knows how to pronounce the word "Agile"; they have no clue what it means or the work needed to "implement Agile". So upper management is never in a position to help the teams. Most times, management does not want to change the existing tools, processes or grow people's skills. And so agile fails - because people want the benefits of agile without doing the work.


I've got a coworker (absolutely brilliant fellow) who bristles whenever he hears buzzword-compliant terms like ITIL and Agile brought up anywhere near management.

Not because those terms mean anything even remotely bad (in fact, he agrees with a lot of the philosophies), but because those terms come pre-loaded with a lot of baggage and preconceived notions by management, and saying that we have an agile-like process is just begging for some C-level with not enough work to do, to get involved and begin dictating requirements they don't understand.

I doubted this until I saw it happen personally a couple of times.

The process is completely, totally meaningless (and in many cases actively harmful), unless you also get the culture change to go with it.


Agile isn't binary in the sense that it either "works" or "doesn't work". Do enterprises adopt agile? Yes. Is it not "true" agile? Most likely yes. Can anyone equivocally determine what true agile is? No.

Agile is what you make of it. The biggest thing holding back a "by the book" agile scrum implementation at enterprises is budgetary process. Business people, who own budgets, have an extremely hard time understanding why they can't build X for $Y, because there are few agile processes that help them clarify that.


We are around 200 and it works really well here. We must be doing it wrong because things are going better since we switched to agile 5 years ago.


There is a plague of fake agile out there.

People buy cheap outsourced development written to spec. People say they want all the benefits of agile but that means embracing risk in order to access the potential of their coders in a real agile management environment. In fact they are happier missing out on a great implementation if it is cheap and timely.

So there is a lot of agile bullshit out there, looking agile-ish but really being paranoid micromanagement by cheapskate philistines making crap software, managed on kanban boards by people with certifications.

Real agile is hard. Maybe impossible for most projects. But being fake agile avoids grappling with the hard problem of how to get the most out of your software development with the resources you have.


The biggest problem with agile is it seems to eliminate software planning. It's a stark contrast to waterfall where execs and product managers spent months designing things leaving no time to actually implement them. Agile swings wildly the other way, some product manager writes a few user stories on what he expects the software to do and off you go writing code.

I've never been an an AGILE project where architects and managers followed through with designs or documentations. The halfway through the sprint you'll get clarifications of specs if you're luckly. Something needs to be redesigned? too late, you're doing another sprint next week.


His account is a troll right?

Anyone that lists under certifications...

   'Winter Survival, Civil Air Patrol, Starting 1974'
...is impressed with certifications more than they should be. Or anyone that lists...

    '22% raise in one year, CDC'
...under Honors & Awards is surely making a joke?


It is irrelevant if agile is dead until we have something to replace it with.


We ended up implementing Scrumban [1]

[1] https://en.m.wikipedia.org/wiki/Scrumban


The guy advocates CMMI in other posts which is a bureaucratic nightmare to work under.

I think this guy isn't a developer, and fetishes over planning and really process driven development.


But we're alive. Let's move on.


hurray!


LinkedIn's really on a roll here.

72 hours ago there was "The Lie That Has Beguiled A Generation Of Developers" (https://www.linkedin.com/pulse/lie-has-beguiled-generation-d...), and now there's this.

I can't wait to see what's next. Maybe "The End of Programming".


Bah, as a front-end developer paying attention to my space I hear about "HTML/CSS/Javascript sucks and this is why" articles nearly every day. I'd rather these people tell me what they like and why; it would be far more productive use of time.


I'm a huge fan of the web as it is today, maybe I should write that article. But nothing gets you to click like, "everything you know is a lie."


There are a lot of "purists" (I use that term loosely) who seem to think that the web should stay in the form of "static content delivery", and we're blundering up the future by developing all this front-end software for the browser in these janky frameworks which no one will support in 10 years..

But the web is much more accessible to the average user, there's a reason that there's been so much success with JS front-end apps. Sure they aren't as quick and streamlined as their native counterparts, but where cutting-edge performance isn't required I think it's a pretty good option.


It's not really LinkedIn, it's more their built-in blogging platform, pulse.


Is their Pulse related to, or the same as, that startup called Pulse that was acquired a few years ago, and in the news?


They are one in the same.


Oh I didn't know LinkedIn hosted blogs. That makes me sense.

Now I know what blogs are just sensational twaddle.




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

Search: