
Agile Is Dead (2015) [pdf] - ivanche
https://www.youtube.com/watch?v=a-BOSpxYJ9M
======
bane
Whenever we hire a new Agile practitioner, as part of the interview I ask them
to discuss the Agile Manifesto [1]. And then we run through some basic program
design and I ask them what tools they bring to help support various program
needs. They usually bring out various ceremonies and processes and what not.

I then ask them to justify what they've offered against the Manifesto. If
they're thoughtful about it (the Manifesto isn't always correct, and if you
read it carefully leaves open the need for some of this stuff). If they simply
insist it's correct they're cargo culting and we can move on.

What I've found is that the ceremonies are appropriately named in that many of
the practitioners seem to not know what they're for or why they're done. The
teams that seem to really excel are the ones that seem to have thoughtful
managers that shape the practices of their dev group to the specifics of their
work. The ones that seem to always be bogged down and require huge numbers of
staff to get even small amounts of work done seem to be the ones that follow a
checklist of getting as many of the agile practice "things" jammed into their
work processes as possible.

I don't think Agile is dead, but I think it requires smarter team leads who
look at what's come out of it as a set of tools to be employed against
specific development challenges rather than a religion that needs worshiping.

1 - [http://agilemanifesto.org/](http://agilemanifesto.org/)

~~~
borplk
I've noticed the same thing.

I think it comes from a lack of experience which further creates fear and lack
of self-confidence to challenge the practices of the cult.

It's also similar to the "nobody got fired for buying IBM" issue.

It's "nobody got fired for sticking to the established cult ceremonies".

They are people who are afraid and don't care about the team or the company.
They are only concerned about their own job security and paycheck. So they
never risk trying something that is not in the book.

The only way to get them to do something else is to make that thing the "new
best practice".

Give it a tacky name. Send them to some conferences and get them a "Senior
Lingo Bingo Dingo master practitioner" certificate for the new cult ceremony
and they will do it with their eyes closed.

Or maybe ... just fire them.

------
maxxxxx
Agile is a good case study for how good ideas get perverted quickly by
consultants and companies. Object orientation also got changed from message
passing to elaborate inheritance schemes. People always get confused when I
tell that you can do OOP without inheritance besides a few cases.

~~~
ythn
How do you write polymorphic code without inheritance?

~~~
frou_dh
Interfaces give polymorphism. Implementation inheritance gives method reuse.

If you think about the term polymorph ("many shapes"), that describes the
world of differing objects that have the opportunity to satisfy an interface.

~~~
ahartmetz
That's a nice way to think about it.

One of the things that still slow me down sometimes when designing something
in C++ is its somewhat muddled concepts. The overlapping concepts make it
harder to divide and conquer the problem to solve.

Rust is quite different regarding interfaces and benefits from many more years
of research and experience, so I have reason to assume it does better.

~~~
sanderjd
FWIW: Java is a language that is more of a contemporary of C++ but gets this
much more right. While earlier Java code I've seen seems more like most C++ in
the muddiness of the lines between polymorphism and code re-use, most newer
Java code I see these days has very flat inheritance hierarchies (if any at
all), and makes far more broad use of interfaces and composition.

My point is just that it's not only "modern" languages like Rust that have
better support than C++ for this distinction.

~~~
marcosdumay
Java is a decade younger than C++.

Also, I haven't ever seen deep C++ hierarchies. That seems to be invented for
Java.

~~~
HelloNurse
Probably you have only seen good and/or recent C++ code.

Deep inheritance hierarchies are _easy and cheap_ in Java (in fact, Java is
deliberately designed to be good at them), but their popularity is older and
wider; historically the early development of complicated OOP took place mostly
in C++, with Java attempting to facilitate further complication with more
modern tools.

For a well-known (and not too unreasonable) example of C++ deep class
hierarchy, see the streams in the standard library of 20 years ago. The Java
standard library copies them as closely as possible.

~~~
marcosdumay
In retrospect, it's indeed very likely that I have only seen good C++
hierarchies.

------
curtis
In the software development field (and I'm sure other fields as well), we have
this notion of "ownership" that means something more specific than lay people
would expect. If someone "owns" a subsystem, they are not just responsible for
it, they also have the _authority_ to modify it, and they _understand_ it well
enough that they can modify it. Most often (at least in startups) the owner of
a subsystem either implemented it or implemented substantial portions of it.

OK, this is on topic, I swear. This notion of ownership can apply not just
just to individual contributors but scales up to teams and even larger
organizations. A team can _own_ an entire major system for example.

Software organizations of any size at all need a process in order to ship
usable software. Well-run software organizations don't just _have_ a process,
they _own_ that process as in the sense above. The organization has the
_responsibility_ for the process, they have the _authority_ to change it, and
they _understand_ it well enough that they can. Obviously such an organization
can respond to deficiencies in the process and adjust it to work better. They
can even revamp it completely if they need to.

Your Agile software development process isn't going to work well if you
organization doesn't fully own it.

~~~
greenrd
Sometimes code ownership means something slightly stronger, i.e. that no-one
else has the authority to change the code. It's fine for a team to own code in
this sense, but it's really bad news if an individual owns code. This is one
of the things that Scrum tries to prevent, by not pre-assigning tickets/cards.

~~~
closeparen
This kind of dilution of respnsibility essentially guarantees mediocrity and
low satisfaction. It’s bad news if an individual doesn’t own code and/or large
projects over that code. Treating engineers as interchangeable cogs who can be
reallocated between bite-sized tasks on a whim misunderstands the nature of
software development and is employee-hostile in a way that you’re unlikely to
get away with in this labor market.

