
Three Ways Agile Has Gone Astray - aard
https://medium.com/@ard_adam/three-ways-agile-has-gone-astray-165acf3fd3c0
======
caymanjim
There are legitimate complaints in here, but it sounds more like the author
has had bad experiences than that the practices themselves are at fault.

I've been consulting for the past decade, at a company focused on agile
methodology. Prior to that, I worked at waterfall organizations. As I
consultant, I've seen about ten companies that practice (or pay lip service)
to most aspects of agile.

I agree with many of the concerns expressed in the article, but I'd counter a
few of them.

Sprints are a great learning tool. If you've got to timebox your development
to two weeks, you've got to learn to break features down into bite-sized
chunks. You've got to learn to write flexible code so that it's possible to
accomplish something meaningful in two weeks. Over time, you learn to
effectively estimate work, and your estimates are no longer meaningless and
wrong. You can better predict milestones for the business, which goes a long
way toward building faith and trust, and ultimately reduces stress and
pressure. It also provides a regular cycle of checkpoints for the business, in
the forms of demos, planning meetings, retrospectives, and other opportunities
to give and receive feedback. This all helps both the business and the team to
plan. When teams get into a rhythm, they can consider switching to a looser
workflow, whether another defined practice like Kanban, or something less
formal. Or stick with sprints if everyone is comfortable.

Collective code ownership doesn't preclude having a domain or technical expert
who provides leadership for a component. It doesn't mean everyone's opinion
carries the same weight, or that you shouldn't have a gatekeeper, or that you
can't require sign-off before merging changes to the production branch. It
simply means that everyone feels empowered to work on anything, and that the
team shares knowledge and responsibility. This isn't in opposition to the open
source model cited. It's about teams sharing power and responsibility so that
there aren't silos, sacred cows, or people whose disappearance would be
catastrophic.

Estimation is notoriously difficult, but it's necessary. Free open source
projects outside the scope of a business don't have to estimate because they
don't have paying customers, they don't have requirements, they don't have
business deadlines. There may be reasons to impose some of those things, but
in the end you're talking about projects that are largely staffed by people
volunteering their spare time, with the freedom to do what they want when they
want. A business has competitors it needs to beat to market, has sales and
marketing and supply chain timing to coordinate, has support staffing
decisions to make, and has customers making demands. You can't simply ignore
these business realities and throw up your hands because estimation is hard.
You have to learn to estimate, as a team, to provide predictability. The more
you do it, the better you get at it. This ties into sprints as well; they
provide a timebox within which a team learns over time to get better at
predicting delivery.

There are valid observations and concerns in the article, but no solutions.
You can't simply dismiss the problems that agile methodologies try to solve.
No ritual is a panacea. The true agile philosophy is to constantly evaluate
the situation and try to find a better way of doing things.

I didn't see any suggestions in this article, so I'll stick with the tools
that have worked for me.

