
In a nutshell, why do a lot of developers dislike Agile? - vatotemking
https://www.quora.com/In-a-nutshell-why-do-a-lot-of-developers-dislike-Agile/answer/Miles-English?srid=i5M8&amp;share=1
======
KaiserPro
The whole point of Agile was "people not processes" However because at my
company we have professional scrum masters, everything must be religiously
Agile.

This means that we must have a standup, everyday. we must have a retro, we
must have planning.

almost half a day a week is lost to pointless meetings. I just want to get on
with my job. Trust me to use the ticketing system to figure out what I'm doing
and raising blocking issues.

~~~
InclinedPlane
When I was at (unnamed-giant-online-retailer) we had a big project for a while
that resulted in having standups that had about a dozen people in them and
lasted about 45 minutes to an hour typically. Every day.

My mind still boggles how nobody else questioned such a misuse of resources.

~~~
qihqi
I was at (unnamed-giant-online-retailer) and a team of 12 too. Our rule is to
speak with one foot standing so you have to speak fast... It takes 90 seconds
per person usually, sometimes ending with "hey Dave, I need your help in X,
let's talk it afterwards".

Same process run by different group will feel different.

~~~
Udik
> sometimes ending with "hey Dave, I need your help in X, let's talk it
> afterwards"

Which means, given a 8 hours working day, that you've been needing the help of
Dave since the previous day, for an average of 4 hours, and you _didn 't ask
him yet_?

~~~
zzalpha
Strawman.

It's very possible the guy thought he could figure it out, but discovered he
was wrong and mentioned it in the stand-up because it was the first
opportunity that day to bring it up (remember, in a lot of places stand-up
happens fairly early in the morning in order to give coders the largest block
of contiguous time for development).

~~~
Udik
> but discovered he was wrong and mentioned it in the stand-up because it was
> the first opportunity that day

Exactly. Which means that he's saying that at the standup not because of any
special advantage given by it, but just because it's the very first
appointment of the day. Had there been no standup, he would have asked for
help anyway.

So either: 1) the standup covers up a fundamental malfunctioning of the team,
namely that people can't communicate freely during the day, or 2) useful stuff
that people say at the standup is stuff they would have said anyway at that
time of the day.

------
pcmaffey
What's ironic about this metaphor is that Agile's roots can be found in
building construction. We all know the story of Toyota, but where did Toyota
come up with the idea? From Japanese stone masons.

The nature of building with stone is such that you never truly know what
resources you have to work with. The shape, color, texture of stone is all
variable. This means too that the way each component fits together is
unpredictable.

For the eye of a master builder, who constructs edifices with each
relationship perfectly balanced, each component placed intentionally, who can
see every step of the process and what each choice means for the integrity of
the whole, such a craftsman understands that every day brings with it a whole
new set of variable inputs, which can never be planned for, spec'ed out, or
tasked to laborers who do not see the whole.

Modern construction cares nothing for such craft. It will be the domain of
robots. Software development too will follow this path, as we humans are
suckers for predictability. But such a road will be littered with people
suffering in jobs that make them feel like robots, projects that fall flat,
and endless repeating boxes of sameness.

~~~
dschiptsov
Construction, it seems, is a "waterfall" by definition, and, it is, probably,
from architecture the model took its roots.

Agile came from business and finance, where everything is uncertain and even
not well understood.

~~~
ethbro
As someone who studied the field, construction in abstract seems a waterfall
model. Construction in practice requires something very similar to agile: too
many uncontrolled real world variables, interdependent timelines, and sheer
laws of physics.

If everything goes right, yes waterfall. Everything never goes right.

~~~
mixmastamyk
In rare circumstances everything must go right beforehand, e.g. the New
Horizons probe to Pluto.

------
eldavido
I'm a dev manager. We use agile, it works for us, and people are happy.

All you have to do is make a giant list of all the things to do, make sure
people are working enough, and on the right things, and use the appropriate
level of design -- sometimes a little, sometimes more.

I think the hardest thing is getting business stakeholders to get out of the
"fixed project" mindset, though: here's what we want, here's how much money we
have, how long will it take/how much will it cost? When the real question
ought to be, what should we do first, given the budget that we have, that will
most help the business?

Also, devs should be treated as adults. No "planning poker", forced daily
stand-ups, or any of that nonsense. Just keep your stories updated in the
issue-tracking system, deliver iteratively, and keep on shipping.

So much of what gets blamed on agile feels like bad org politics/poor
stakeholder management.

------
taneq
People hate Agile now for the same reasons people hated "extreme programming"
before it: Mismanagement based on a few misunderstood buzzwords.

Extreme programming had the de-emphasis on documentation in favour of verbal
communication, which got garbled into "just don't document anything".

Agile has sprints, which has been twisted into "crunch time every two weeks
for two weeks".

~~~
digi_owl
And devops turns into "end user is QA"?

------
quantumhobbit
The problem with modern "Agile" and frankly all other software development
methodologies is the mismatch between the knowledge and expectations of the
business and tech. Business and tech tend to use Agile to keep each other at
arms length and never learn about what the other does. This is a shame because
originally agile was about forcing business and tech to work closely and
interact regularly. Hence the short sprints and frequent stand ups.

In the parent example the management should have known enough about building
to realize they were a creating a clusterfuck, and the builders should have
had enough knowledge and input to the business to figure out what they were
supposed to be building. When both sides assume the other is too stupid to
work with and avoids meaningful interaction, it shouldn't be a surprise when
the result is a hacked together mess.

~~~
bengale
The problem I've seen is rather than forcing the business and tech to
understand and work with each other managers are hired to do 'agile' and
basically proxy for the business. They don't know anything more than
developers do, and while there is more iterative development, the feedback is
coming from the wrong people. It just becomes useless meetings and checkboxes.

------
arenaninja
Alright, here's my Agile rant. It's bigger than my last one because I hadn't
experienced it to its full potential.

In my current team, it's followed religiously. Stand-ups are daily and people
use it as a time to fraternize between talking about actual work, I just want
to get back to work. There's no camaraderie, every retro is this one guy
bitching about how things aren't done the way they were in his previous job
(and usually they aren't because it wouldn't make sense). The time between
demo and sprint planning is a full day's of wasted time per developer, because
there's nothing to do. Every developer writes hacks and things that shouldn't
pass code review get passed because there's not enough time in the sprint to
implement the known-good solution.

I've caught flak from going beyond the story requirements because I know what
the final solution actually looks like. I also catch flak regularly because I
run out of work and I take more tickets that are not in the sprint. I've never
not finished a task when I did that. Every other meeting I get to hear a spiel
from the project manager about how great Agile is.

I'm sure there's cases where Agile is the perfect solution. But it's not every
time, and the rigidity that people want to apply was never meant to be there.
I wish it would go away, but it's the perfect tool for management to be able
to submit reports and say "look how consistent we are!"

~~~
ebiester
So, it sounds like you hate your team, and agile just makes it more obvious.

So, here are the few quick fixes I see:

1\. point out in retro that standups as currently constructed are a waste of
time. Tell them you will utilize the law of two feet if they can't be
tightened up.

2\. Suggest a definition of done. If the product owner doesn't agree it meets
requirements, code quality isn't high, and tests aren't there then _it 's' not
fucking done._ That means your sprints are implementing too much.

3\. Don't pull in more work if other members are struggling to finish
something. How can you help them out to make sure their code quality doesn't
suffer? If your piece is adjacent to another that is in desperate need of
refactoring/code quality improvement, just say that you needed to clean that
up to implement your solution. Use that time to de-hackify.

~~~
arenaninja
'Hate your team' is a little too strong, I think. I may dislike some of their
working habits, and I think our code quality would be higher if we took code
review seriously (I've been told to not hold back PR approval even on issues
like not putting braces on single line if statements - if it runs, it's "good
enough"; I'm also the only one to ever write tests). Implementing less isn't
an option because we have a hard deadline

I see what you're saying in your last point, but on that particular sprint,
someone didn't want to do something they had assigned to themselves and pulled
in a different story/ticket. I have no issues picking up __anything __that is
still unassigned, and I had mentioned during the daily that I was available if
anyone needed help with anything. No one got back to me and I honestly didn 't
know until later that day that the other story/ticket hadn't even been
started. I don't think I should have to talk to individual developers to see
if they need help; we're adults and if you can't manage your workload or can't
communicate that then I don't have a solution for you

------
wpietri
Hi! Early Agile person here, but I hate what the term Agile has become. [1] I
think there are a lot of good reasons to grumble about Agile, especially when
management use it as a stick to beat developers. But I don't think the problem
described here is one of them.

I think expecting business to know what they want is a mistake. When my dad
was making software in the 60s, 70s, and 80s, we were mainly automating
existing business process, so we could draft behind all the hard work done
working out the right paper forms and reports. But modern software comes from
a process of experimentation and discovery, competition and evolution. As the
people who understand the technology best, we should be as part of that
process from beginning to end.

This analogy is misleading because software gives us power that we don't have
in the real world. If we start with port-a-potties and want real bathrooms, we
just have to change the description of a bathroom and the computer will do the
rest. In software, if you are disciplined about automated testing,
refactoring, and keeping up with technical debt, an evolving architecture is
totally doable.

I think where people fall down is that they don't believe that managers will
give them enough time to keep things clean as they go. And I agree, they
won't. You have to _take_ the time. But if you do it from day one you can do
it gradually and incrementally. You can gradually redirect management pressure
away from developers and toward making better product choices.

So please let's take control of our working conditions back. We're
professionals, and we can say, "No, I'm still writing tests. That's a best
practice, and it would be negligent for me to leave that out." But we can do
that while delivering incrementally, so that no week goes by without the
business getting some new benefit in production.

[1] [http://agilefocus.com/2011/02/21/agiles-second-chasm-and-
how...](http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-
in/)

~~~
zippergz
_I think expecting business to know what they want is a mistake._

I'm not much of an agile true believer, but as a former developer who is now
"management" (shudder), I have never-ending frustration when teams expect
full, perfect, set-in-stone requirements from day 1. When you're developing a
new product in a new field, that's not how it works. We have to build
something that minimally works, get it in front of real customers, and then
make adjustments based on their reaction. Lather, rinse, repeat. This isn't
"management can't make up their minds." This is "management are not
clairvoyant."

To those who hate requirements changes, I'd love to know how you are able to
determine with 100% certainty the exact product the market wants before you
build it. If you can do that consistently, you should be a billionaire.

If you do understand that we don't know for sure what needs to be built from
the beginning, you have two options. First, I can give you my current best
guess at what we need to build, and we can work together to figure out what
the right starting point (mvp) is, with the understanding that the rest may
change later. Or I can figure out the mvp myself, and only tell you that,
preventing the situation in which I told you about something that later has to
change, but also robbing you of the opportunity to see the big picture and
contribute to the plan. Which do you prefer?

~~~
FollowSteph3
I think the main issue most devs struggle with is not the changing
requirements but that the timelines are not adjusted accordingly and have to
be swallowed by the dev with overtime. And in most cases when there is some
adjustments it's not nearly enough to cover the actual costs. If that was
somehow resolved I think the vast majority of devs would be fine with changing
requirements. Problem is I don't think there is an easy way because most non-
dev don't truly understand the costs involved.

Fr example can u imagine telling a plumber no the bathroom is now going to be
30 feet to the left. The plumber says ok but that will cost u a week of work.
How many people would say no, u have 1 day to do it and u will be held
accountable for my estimate and not ur estimate because I don't trust u when u
say a week. Now assume the walls are closed and it's only after u open them u
learn there are other issues. Doesn't matter, one day. This is what most de s
deal with. I assume ur not like this but this is how most devs have to work.
It's frustrating. If u would be given the week then u would be fine, but
instead ur told the timeline and/or cost. U may even be told no u can't use
those tools they r too expensive, but u need to complete the task in the
faster then even people who can use the tools.

My whole point is it's often not the change requests that are the issue, it's
what it entails, in that the schedule and costs are not adjusted fairly.

------
marssaxman
It takes time away from real work without making that work significantly
easier to accomplish. It is frequently used as a tool of control by managers
who want to be in charge, thereby defeating its own reason for existence. The
terms and practices tend to be hokey and faintly demeaning.

The problem is not the specific body of techniques used to schedule tasks and
manage time; the problem is the way that the hierarchical nature of
traditional management structures diminish agency and discourage transparent
communication. This leads to misapplication of effort and destroys motivation,
crippling productivity.

Empower people to act responsibly and they generally will. Exercise empathy
and people will trust you. Give people the information they need and they will
reciprocate. Agile development was an attempt at doing these things better,
but it has been reduced to a collection of code words and empty rituals by
managers who don't realize that it is actually their philosophy about the
purpose and nature of management itself that needs to change, and not merely
their choice of techniques.

------
bunderbunder
This somewhat mirrors my own experience with trying to practice Scrum: The
spot where agile practices fail is invariably in management misunderstanding
how it's supposed to work. Techies may get lost in bikeshedding every single
user story, but it's management who hires Uncle Bob to come deliver a 1-week
mandatory all hands training course and then doesn't bother to show up for it.

If they had, or if hey had bothered to read a book or something, then they
would probably have seen that nice chart that's invariably somewhere close to
slide (or page) 4 that lists all the things that $agile_process is and is not
good for, accompanied by warnings about the need to be adaptable.

It's part of why I'm uncomfortable with name brand agile practices, because
they make it way too easy for folks to interpret the guidelines as rules, or
to interpret a useful tool as a silver bullet. For a while it bothered me so
much that I was inclined to throw the baby out with the bathwater. I don't
like to think that way anymore, though. Incompetent leadership will cause a
team to be dysfunctional regardless of how it's organized. Blaming X or Y
organizational technique for your boss's bad behavior is a gross
misunderstanding of the situation.

~~~
Zigurd
> _If they had, or if hey had bothered to read a book or something_

Agile is simple, but it isn't easy at all. Without management buy-in to sit
through the bikeshedding to find the technology gems among their technical
talent's ideas (that they did a good job of recruiting and compensating,
right?), Agile is going to turn into a swamp where mediocrities fool each
other into thinking they are doing something.

Doing this while engaging low-bid outsourced implementation resources is 10X
harder. Unless you pay through the nose for True Believers like ThoughtWorks,
you're going to get fake Agile.

~~~
bunderbunder
Oof, yeah. If what I've experienced is at all indicative, agile and
outsourcing mix like nitroglycerin and shaking.

------
akkartik
This was very entertaining to read, and we all engage in these these analogies
between software development and building houses or bridges or whatever. But
nobody talks about this implication: the reason construction is so much more
reliable and robust is that our forebears tried lots of different houses and
bridges before we settled on the ones we see today. That was only able to
happen because nobody was insisting that all houses look alike and use the
exact same materials. Since bits are easier to copy than atoms, we've made a
fetish out of exact copying ("reuse"), and we peer-pressure each other to copy
more with the complaint that they're "fragmenting" if they don't submit. I
think it's _extremely_ silly. When something like Android starts feeling it's
too fragmented, that's just a symptom of deeper issues, and force-upgrading
everyone to the newest version just keeps us from better understanding the
deeper issues.

Tl;dr - if you want software to be more reliable, insist less on reuse, and
allow copies to diverge more.

~~~
digi_owl
Nah. buildings are alike because we have measured, tested and documented every
damn material for their behaviors under various uses.

Thus if you want a wall of a certain size and shape, you have a list of
materials to pick from depending on the weight is to carry.

The reason people insist on upgrading to the latest and "greatest" software is
because there are no rigidity to APIs etc.

The Linux kernel gets more use than GNU/Linux user space because the kernel
devs are held to a more stringent API rigidity. This makes kernel behavior
predictable.

Similarly, Windows, for all its warts etc, gets used in business because
Microsoft built a reputation for predictable APIs. Only with 64-bit Windows
can you no longer run 16-bit binaries (dating back to Windows 3.0!), and
that's because the 64 and 16 bit CPU modes are mutually exclusive.

------
kelvin0
It seems like all (pretty) good ideas, this one was meant as a set of
guidelines to help teams build better software. That's until agile became a
dogma (to some) and a means to an end in itself, with most the focus on
getting agile 'right' and the project success being secondary. It's kinda like
the idea of unions when they where first started to protect workers that were
being exploited like farm animals. Nowadays some big unions could care less
about the workers, and care more about their own survival as an entity and get
trapped in activities which have nothing to do with their original mission. Of
course, please don't see this exmaple as saying all unions are bad.

------
joeblow9999
Agile is for managing upward and a lot of developers would rather, you know,
develop

------
ajankovic
It's not just developers. My friend works in the sales department and he hates
it. Every functional request that he make has to go through the usual "agile"
process and it's just blocked by the weeks of sprints that are trying to keep
up with the increasing backlog.

Some of those requests are very important and will benefit with actual real
monetary results, but he has to personally escalate it through hierarchy and
force dev team to break their sprint rules and force them to work on it.

In other words he has to make them be agile by force.

~~~
eldavido
As a developer, it is highly upsetting to me when sales does this.

A well-functioning product development org has processes in place to decide
what gets done first. These processes take into account tons of inputs
including bug feedback, enhancement requests, potential for outages if
something isn't fixed, long- and short-term competitive and strategic
concerns, customer requests, and internally-sourced architecture requests.

Then some selfish jackass comes along (from whatever department) who just _can
't wait_ because WE NEED TO GET THIS DEAL, so the entire process is thrown out
the window to satisfy the whims of one customer, who may not even be large,
high-revenue, or strategically important, and the wrong works gets done.

Please, stop the madness. Don't go around the product team, and if you're in
eng, please don't tolerate this bad behavior.

~~~
douche
Fuck those people. Sales that are that pathological are all kinds of broken.

------
vemv
Probably an essential mistake is to put multiple people to work on a
greenfield project at once, when the requirements are particularly uncertain.

Better to allocate a single full-stack dev to experiment for a couple weeks.
He also will interact with the business owner daily. Let him focus on the
business logic and also the core user interactions.

On top of that MVP foundation (i.e. on week 3), you can put the rest of the
team to refine backend, frontend, graphic design and so on.

~~~
ninkendo
> Probably an essential mistake is to put multiple people to work on a
> greenfield project at once, when the requirements are particularly
> uncertain.

This statement rings so true to me that I really hope there exists a fleshed
out version of this theory, with examples to prove it and maybe a catchy name,
etc.

Where I am now, I've literally participated in an identical thing being built
in two ways at two different times:

\- The first time, I was the initial full-stack dev, along with one other guy
(we were more of a duo... we paired a lot and worked pretty fluidly, it was
kind of a 2-person equivalent of a single-person experiment.) The result was
finished in 3 weeks and was flimsy but cohesive. Eventually the team was
reduced to just me and I carried out the project for a few more months before
a proper "team" was on board.

\- Then, the company noticed what we had done, decided that a bunch of other
people had done similar things (it's a large company, after all), and then a
_250-person organization_ was formed to write an MVP that was largely
identical in scope. I wasn't in any leadership position in this new org, so
nobody really cared that I had experience in this. I was reduced to writing a
tiny insignificant part of the larger whole while our director drove the
requirements. We're 10 months in and haven't shipped the first milestone yet.

In the first example, we were almost _too_ successful. The resulting product
was used by thousands of people, for important things, with a lot of
satisfaction and kudos from the users. But the total size of the team never
really exceeded 5-10 people, so it got to the point where we were burned out
supporting it, and there weren't enough reserves to call in to help because of
the "second system" distracting everyone:

In the second case, we don't have our first customer yet (although we've only
kind of "soft" launched.) We did a massively half-assed attempt at agile that
was basically "waterfall, but more vague, and please work harder", where we
kinda half-assed came up with requirements, split everything up into 10-15
major "tentpoles", each of which was developed by separate teams. 6 months
later we decided to start "integrating" all of it. 4 months after that, things
finally kinda sorta work end-to-end.

I've gone through a ton of self doubt through the process. In the first case,
it worked only because there was almost no communication: we just did what we
felt like, explored, and we were lucky that the end result worked. "Clearly,
this will never scale, and is no way to run a _real_ software product", I
remember thinking.

When the org got huge and we did our second system, I thought "Finally, I can
learn to do what real software devs do and work for a big team with
communication and requirements, etc". And inevitably when the result is a big
pile of shit, I can't shake the feeling "this would've been better if I knew
how to do real software development and work with a large team." Self loathing
ensues.

So I witnessed the pendulum swing each way. The first way was massively
successful, but I suspect isn't sustainable (the product is withering due to
lack of support now.) The second isn't successful at all, and is a complete
mess, but maybe it'll be better with time.

The only thing I know for sure is that few companies in the world can afford
the amount of wasted time and energy we've spent on the second system. I
suspect the real world works more like the first case but I don't have enough
experience to know. I can't shake the thoughts of "I haven't seen real
software development yet", and I don't know how much validity there is behind
those doubts.

~~~
ebiester
> Our highest priority is to satisfy the customer through early and continuous
> delivery of valuable software.

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

[http://agilemanifesto.org/principles.html](http://agilemanifesto.org/principles.html)

It sounds like the system started off as agile and the second system lost the
plot.

------
Dirlewanger
Paraphrasing a comment on /r/programming about this yesterday: If there is a
decent set of requirements, then the framework used is irrelevant.

~~~
taneq
But Agile, as I understand it at least, is explicitly designed for cases when
requirements _aren 't_ fully known.

~~~
forgottenpass
Agile is designed for that case, but most development methodologies are
designed for that case.

The idea that requirements are set in stone, or - more specifically - the idea
that not setting them in stone is breaking conventional wisdom is just running
us in circles.

Requirements are just a name for detailed goals. They change as goals change.
Diffs can be applied them just as easily as to the codebase. Maybe a team has
them over emphasized and too rigid, maybe too undocumented and in flux. But
prescriptive development methodology doesn't give teams tools to figure out
what works for their projects.

Development processes aren't really improving with every new trendy thing that
comes out, they're just finding new ways to package and shuffle things around.

~~~
taneq
> but most development methodologies are designed for that case

Modern (ie. post-XP) software methodologies, yes. Traditional engineering? Not
at all. Software is unique in that it's essentially free to convert your
design into your end product.

It's one thing to iterate weekly when your build process costs $0.02 of
electricity and half an hour of server time. It's another thing entirely when
you have to obtain many different parts (some with long lead times, others
custom built, and small batches always cost far more per unit) and then
assemble them manually before testing a physical object.

------
IanDrake
I think a lot of commenters here are missing the point being made in the short
story.

Agile is good for startups building a product where they don't already have a
known product/market fit. It's understandable in that situation.

A client of mine uses it to unburden itself with upfront design for a 3rd gen
system that is well known and could easily be built with waterfall. There have
been (what I would call) two false starts already. I don't see why agile is
beneficial in this situation.

------
jasim
Agile is used to justify both rigidity as well as chaos. The one hour standups
and forced sprint metrics are on one side. The utter lack of planning that is
waved away by claiming agility is the other. These are two extremes, and the
word seems to fit both the bills depending on who is doing the complaining.

------
robmccoll
While well intentioned as an abstract concept, all discussions around agile as
a business concept to me inevitably lead me to conclude that agile sits
somewhere between a cult and a cargo cult and that anyone drinking that kool-
aid will at some point in the discussion run across no true Scotsman
fallacies.

------
walkingolof
I see the benefits with agile, but I cant help feeling that something is lost
in a process that so completely controls the employees ... it is probably
great to churn out good software, I doubt however that great software happens
in that environment

------
brudgers
_So we just bought a port-a-potty, and screwed around on the internet for two
weeks._

It seems to me, the there problem isn't agility, it's a lack of
professionalism.

------
snarfy
Agile is supposed to be a development process, not a business process, but
I've never seen it implemented that way.

------
aphextron
It's kind of like communism. Seems great on paper, but it just never really
plays out effectively.

------
bane
Agile, IMHO, was meant to be a sort of zen-like "process-less process". After
a few decades it became understood that software development wasn't working
and doubling down on borrowed traditional engineering practices wasn't
resulting in better software, only incredible delays in delivering broken
software.

Here's the manifesto:

"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 interactions_ over processes 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 the items on the right, we value the items on
the left more."

This is deep stuff and an incredible (and rare) set of pragmatic philosophies
set down by folks who'd been suffering through the industry for a while.

Processes are intended to minimize risk and ensure reproduction of already
achieved work. If you aren't making yet another copy of something that already
exists, you don't want a process.

(sorry if this comes off a little braggardly), I've been known to run
incredibly effective teams that produce tons of work very quickly. I use what
I call an "Agile-ish" approach based on some personal meditations on getting
software done. I call this approach the "Get Shit Done" model.

1) Is this new work or reproduction of old work (should I explore and evolve
or reproduce?)

2) If this is new work, the goals are set down as very coarse milestones with
exit ramps in case things are working out.

3) If this is new work, work is broken down into a check-list in a pipeline
with the following steps: To Do->Doing->Paused->Done

Work is first filed as tickets in To Do. When it's being worked on it moves
along to Doing. If, during "Doing", new work is identified, it's created and
put into "To Do". If necessary the current work that's "blocked" is simply
moved into "paused".

Once Paused work is unblocked, it moved back into "Doing". It either finished,
creates new work tasks or is paused again. Rinse and repeat.

Kanban boards work pretty well for this, but you can do it with a spreadsheet
in a pinch just fine.

4) If this is new work, work is only considered "Done" if it's checked in,
tested and documented (and builds). Everybody hates it when they're doing it,
everybody loves it when they need to figure something out later and the
customers drool over getting rapid delivery of already documented, tested and
validated stuff.

This scales pretty well for teams of 1-to-100 (but starts to strain on the
larger sizes).

Teams are organized into hierarchies each with their own pipelines. Each team
has a team-lead. I meet once a week with all the team leads and require all
team leads to meet with their teams once a week. During crunches or abnormal
events, we meet more often. This creates a cascading "clock" that identifies
things that are taking too long and might need extra attention. I give team
leads extraordinary autonomy to figure out the details at their level. This
also gives people a week to be create and figure out ways around issues and
problems. Team members can generally float or matrix if needed. Work moves
along a general "discover, productionize, deploy" model.

What's amazing about software is that it's almost always new work. If it's not
new work, you still don't really need a process to reproduce it. Just copy the
code into the new place, configure it and start it up. This is unlike any
other engineering endeavor in human history and it takes entirely new ways of
thinking to get it done.

What I've found is that many many organization simply want to repurpose
waterfall models and apply "Agile" sounding names to everything. I once turned
down work because the customer had a 500+ page manual on their formal "Agile
Software Process Methodology". No, no, _no_ , NO. You don't _get_ it.

Here's another protip: Sprints are for engineering, Kanban is for Research. If
you know what you are doing, use Sprints to force a development clock. If you
don't know what you are doing and need to figure it out, Sprints just make
everybody angry and create useless artificial pressure that accomplished
nothing. If you're engineering, you already know what to do, Sprints help
provide motivational energy.

------
InclinedPlane
Agile is just a collection of stuff that people put together in order to
ensure useful productivity from arbitrary teams. Often it's misapplied and
misused, usually in order to micromanage.

The roots of agile come from the bad old days when the typical software
project was a consulting gig with an elaborate negotiated spec and schedule
and a huge disconnect between the buyers and the developers, let alone the
users. And when the "software crisis" was in full swing, and many software
projects failed to deliver anything of use, at all. Back in the days when even
using source control wasn't common, and when regular builds and smoke tests
were even rarer.

Agile ensures a few things:

It ensures that you use an incremental development strategy: start with
something simple that works, then iteratively add to it over the course of
short periods of work to move it closer to the desired state of functionality
and capability. Because you routinely have workable builds this means you will
always have _something_ to show for your work at the end, because you have a
pattern of having something working all the time.

It pushes the team toward continuous integration and regular builds with
testing. Which avoids building up invisible technical debt due to undone
integration work as the project progresses. Agile avoids the "big bang
integration" problem.

It pushes the team toward visibility and interaction, so they get to know what
everyone else is working on and it forces collaboration related to integration
ASAP, all of which helps increase team cohesion and leads to higher code
quality. People get to see the products of other's work routinely, making it
easier to see what they're good at (and not) and aiding team mates in learning
from one another.

It avoids unnecessary over-complications and the tendency to procrastinate,
such as the notorious "second system effect". It ensures that people stay
concentrated on _real_ milestones and _real_ work not pie in the sky perfect
systems with schedule estimates off by orders of magnitude or not even
feasibly possible.

It gives the "stakeholders" more visibility into the work. The product itself
becomes the ground truth for the product, rather than a spec or a memo or a
contract. If those folks have concerns they can be addressed and taken care of
before it is extremely costly to fix. And if they want to make changes to the
design relative to their initial thoughts, that too can be done fairly easily,
resulting in an end product that is more suitable than would be the case
otherwise.

And it ensures that sprint by sprint, work gets done, the product moves
forward. With good teams this isn't a problem, but in the "enterprise
trenches" with demotivated teams of average or below average coders this can
be a real problem. It can be difficult to get anything done, let alone
anything more than just spinning their wheels.

All of these things are for the most part good things, and they are the reason
why the concept of agile has become so pervasive. The problem is that today a
lot of the agile basics just go without saying (continuous integration,
routine builds and testing, iterative development, short sprints for work, and
so on) while some of the other aspects end up being applied in a cargo cult
manner with no comprehension for why they were used as well as when they are
warranted and when not.

Even if agile practices were being used correctly most of the time, which they
aren't, it still would not be a good one size fits all practice for all
circumstances. Moreover, the modern perversions of agile have done a lot of
damage. Removing opportunities for use of initiative, creativity, and
expertise by many coders, taking responsibility for even the tiniest decision
out of their hands and transforming them into children. In some ways agile is
like a remedial course in software engineering, but a lot of high caliber
developers are finding themselves stuck with it even though it is restrictive
and harmful, because management is thoughtless.

------
fatdog
Agile, like anything, is perfect when you implement it perfectly. Nobody does,
but it's not the method's fault, the method is perfect. What I have seen is it
used as a chip on the shoulders that makes product meetings feel like dealing
with communist border guards.

Working in Agile shops can be a lot like watching lab mice running a maze. You
try to say, "hey, so this path you are working on, there is a map for it when
it was solved in <discipline x>." and the response was, "this is Agile, we
don't take grand designs or waterfall requirements, and we don't need anymore
chickens in our standup."

Or you say, "hey, so this thing you are building, for someone to buy it, we're
going to have to explain to them why it's good and how it meets their
expectations, can we create a sequence diagram or a model so I can plug in how
it meets standards and regulations and code and such?" and the response is,
"we don't need documentation, the code is documented, and if you had provided
us with the requirements we could prove it in our unit testing."

The trouble I have with a lot of engineering and dev culture is what it lacks,
and often irrationally rejects, is balancing the technical understanding with
a top down view. The best engineers have or at least appreciate this, and they
bring it with them. Unfortunately this gets them immediately promoted to roles
where they aren't actually writing code.

I've used this house building simile in Agile shops before, where any bunch of
carpenters, electricians, plumbers and brick layers can build a fine house
that will stand up, but the matter of whether anyone will want to live in it,
buy it, insure it, legally sell it, live anywhere near it, or trust that it
won't be knocked down by local climate or regulations - is an equally complex
problem you need someone with expertise to solve.

Everyone has complains, devs about managers, managers about devs, it's an age
old problem. A lot of Agile gets used to formalize an adolescent culture. I
look forward to the pendulum swinging back to a more balanced equilibrium.

~~~
drumdance
This is a frustration I had in my most recent project. Management did a good
job of coming up with interesting features in the abstract, but a terrible one
of communicating those features and working them into the app in a way that
was intuitive. I often found myself saying, "this is potentially a good
feature, but how do we explain it?"

We never had a good designer on staff, so that was a huge part of the problem.
A couple times we used outside designers but they didn't have a holistic view
of the app, so their designs created as many questions as they answered.

------
dschiptsov
Because the way you manage an orchestra does not eliminate the necessity of
each musician to be able to perform decently?

------
venomsnake
The moment the process becomes a goal instead of solution - now you have two
problems.

You cannot abstract away the need for common sense.

------
rimantas
Listen to one of the authors of the manifesto itself:
[https://www.youtube.com/watch?v=a-BOSpxYJ9M](https://www.youtube.com/watch?v=a-BOSpxYJ9M)

(BTW, he is very opposed to the use of Agile as a noun ;).

