
Agile is Dead - dsego
https://www.linkedin.com/pulse/agile-dead-matthew-kern
======
woah
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?

~~~
jenkinsj
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)

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

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

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

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

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

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

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

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

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

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

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

~~~
mindcrime
_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.

~~~
UK-AL
Sprints aren't sprints.

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

~~~
mindcrime
_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.

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

~~~
halhen
One answer is by Simon Bennet. See
[https://vimeo.com/138060217](https://vimeo.com/138060217) , in particular
13:10-16:00

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

------
swagtricker
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...](http://allankelly.blogspot.com/2015/10/software-has-diseconomies-
of-scale-not.html)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
shockzzz
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?

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

------
PhilWright
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?

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

------
hbcondo714
We ended up implementing Scrumban [1]

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

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

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

------
spalt
hurray!

------
paulddraper
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...](https://www.linkedin.com/pulse/lie-has-beguiled-generation-
developers-richard-eng)), and now there's this.

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

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

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

~~~
jonathankoren
They are one in the same.

