
Dear Agile, I’m Tired of Pretending (2018) - dsego
https://medium.com/columbus-egg/dear-agile-im-tired-of-pretending-d39ab6a12003
======
bougiefever
I've been developing software for over 20 years, and I still can't estimate
how long something will take me when I've never done it before. This
uncertainty needs to become more than just a stick to beat developers about
the head and shoulders with. Most of the time the PMs understand this, but
there have been many projects where they just don't get it. I have suffered
great anxiety from being forced to give estimates when the truth is I have no
clue. It depends on how easy it is and how many unforeseen issues I encounter.
It was so bad that once my husband asked me how long it would be before I was
done cooking something, and I practically had a meltdown. That's when I knew
it was time to leave that team. Can we stop pretending we can forecast the
unknown? (edit typo)

~~~
xwdv
No.

Even bad estimates are better than _no_ estimates. If you are having meltdowns
your reputation is being tied too closely to your ability to give estimates.

You must never turn estimates into a promise, always remind people they are
estimates.

Want to give _fast_ estimates? Here’s how:

1) first determine the scale of the task? Is it a year, month, week or day
kind of task?

2) Then, it’s just 3 of those units. The smallest task takes 3 days. One day
to completely fuck up, one day to figure out why, one day to get right. The
longest takes 3 years. One year to fuck it all up, one year to learn why, one
year to finish it.

I suggest never giving estimates in units smaller than a day. They just become
noise. If a task is smaller than dayscale just say the task is too small to
provide any meaningful estimate but won’t take more than a day.

~~~
bb88
> Even bad estimates are better than no estimates.

No estimate is clearly better. Here's a common story I've seen across multiple
companies.

1\. Marketing management asks Engineering management how long it takes to do
feature X so they know when to launch the online ad campaign.

2\. Engineering management then asks potentially good coder how long it will
take. Coder replies with a time and "it's just an estimate."

3\. Engineering management reports to Marketing that coder's estimate leaving
off the most important caveat, and Marketing treats that as the gospel truth.

4\. Coder takes longer than expected because of some bad technical cruft that
some other engineer put in because he was potentially rushed or just plain
inept.

5\. Marketing is pissed because they now have to withdraw the ad campaign, and
starts blaming engineering.

6\. Under increased scrutiny, Engineering gets a bad reputation, who then
throws the coder under the bus in front of Marketing and other managers.

7\. This shows up on the coder's annual review who then leaves.

8\. Engineering hires replacement which will have a 3-6 month learning cycle,
and potentially writes worse code than the person that just left.

EDIT: The point is that if there's no estimate, management has to deal with
the uncertainty that the coder experiences. Hope for the best, plan for the
worst.

~~~
50656E6973
>1\. Marketing management asks Engineering management how long it takes to do
feature X so they know when to launch the online ad campaign.

Why can't Marketing just wait until the feature has been built to launch their
campaign?

~~~
TheOtherHobbes
Because campaigns have to be planned ahead too - anywhere between a few weeks
and a year or so, depending on the size of the project and the company, and
often timed to match big trade events.

And there's always the possibility that if you announce too late competitors
will eat your lunch.

One way to handle this is to spend some time on a formal estimate. Two to four
weeks of R&D to scope a project can help narrow estimates to something
approaching realism. You'll still be wrong, but you're less likely to be
hopelessly wrong.

Asking someone for an instant opinion is madness. That's not an informed
estimate, it's just a guess, and usually worthless.

~~~
fuzz4lyfe
Sounds like marketing needs to be agile

------
curtis
Any software development methodology or process is going to come up short if
it ignores the fundamental nature of software development, which is: _We do
not know what we 're doing until we do._ Any process or methodology that tries
to extract _promises_ out of the software development organization about
things that are still in the _we do not know what we 're doing_ phase is going
to result in disappointment at best and serious harm to the overall effort at
worst.

And it turns out that it's not unusual for software developers (and
consequently software development organizations) to spend more time in the _we
don 't know what we're doing_ phase than the _we do know what we 're doing_
phase. That sucks from a management point of view, but no amount of process is
going to make the problem go away. The best you can do is manage the risk. We
don't need good processes or methodologies nearly so badly as we just need
management enlightenment about how software development actually works.

~~~
LarryDarrell
That's the truth, except, I can't tell clients that "I'll know how long it
will take when I'm halfway done." The best I can do is look at prior work and
multiply by the LarryDarrell Constant of 1.5.

~~~
Skunkleton
> multiply by the LarryDarrell Constant of 1.5.

Funny thing. If you do this organizationally, then you eventually end up
making larger and larger estimates. IMO it is better for management to
understand the inherent risks associated with engineering estimation and build
the padding on their end.

~~~
Sharlin
Hofstadter’s law: It always takes longer than you expect, even if you take
into account Hofstadter’s law.

------
tootie
I was prepared for our weekly "I Hate Agile" post, but this one is actually
really great. It's a lot of the arguments I make to Agile haters. The
fundamental problem that drives most agile failures isn't in the team's
execution, it's in the business' expectations. One side is signed up for
incremental delivery, and one side is set up for a fixed scope and deadline
and the result is misery. I think this article makes a lot of good points.
Scrum isn't the complete answer, but it's a big step in an organizational
transformation. I think it's suffered a lot from being oversold.

~~~
Bartweiss
> _One side is signed up for incremental delivery, and one side is set up for
> a fixed scope and deadline and the result is misery._

This is a brilliant summary, thank you.

The best 'agile' experiences I've had are situations where the 'clients' are
directly involved, often within the same organization. Instead of a hard scope
or deadline, there's just a shared interest in producing a valuable product
efficiently, and the users are on-hand throughout the process for feedback and
reevaluation.

The worst experiences have been waterfall contracts, developed by an internal
simulation of agile. The software team does frequent "releases" to business or
management, who provide feedback and feature requests, but the actual
recipients are uninvolved outside of occasional demos, or contacted only
indirectly by non-programmers. The result is almost always thrashing, with
time and effort spent pointlessly satisfying the forms of agile even though
the real timeline and customer feedback are unyielding.

~~~
madeofpalk
> _waterfall contracts, developed by an internal simulation of agile._

We call this _wagile_

~~~
ksenzee
We call it scrummerfall.

~~~
tootie
We call it frAgile.

------
quadcore
_Agile never gave organizations a holistic, viable alternative to Waterfall.
Because there’s a difference between theory and practice. Product work is more
about practice. When we complain about “AINO” (Agile In Name Only), we’re not
being honest with ourselves._

I agree with most of the article. Specially the keep-learning part.

 _All Agile did was put software development teams unfairly under a
microscope._

I believe Agile has been tremendously beneficial for the industry globally,
especially in some subtle ways. For example, Agile says you have to
communicate a lot, if you want to get software done. Here is the subtlety: if,
_today_ , you stop telling the average programmer to communicate, they will
stop and go back to silo mode, "naturally". At least some of them. If you
think about software at the industry scale, you have to think about a wide
population which require processes.

I was once working in a nice little company where, one day, they introduced
agile. It was so much beneficial. Before, the bosses thought that talking was
simply a lost of productivity. You're a programmer right? So code, don't talk.
So we would develop software without talking to each other. After we had daily
meetings, scrums things and stuff. Our velocity has sky-rocketed.

You have to realise that before Agile, a fair portion of all software
development projects that were started would simply bust and never get
shipped. The code is a complete monster or the budget is nuked. When I started
in the company I just mentioned, I started working on a codebase that was the
worse code I've ever seen in my life. You would touch one line and everything
would stop working. It was a condensed piece of spaghetti with hacks on top of
hacks on top of hacks. Software architecture? That requires some talking and
thinking, forget about that, not permitted.

Now I agree with you, agile is not much useful for a hacker who consistently
get software done and understand deeply what's happening.

 _edit: not that I 'm an agile guru or anything. Actually I only know the
thing superficially. I show up at the meetings, when I'm ask how hard
something is, I answer, then I mess around with my office friends. Still I can
appreciate it works much better than any process the bosses can come up with._

~~~
xfitm3
I was interested in comp sci precisely because I didn't have to talk to
people, an area where every interaction is a performance. I want to be alone -
what's so wrong with that?

~~~
kjsbfkjbf
There is nothing wrong with that, but careers under capitalism are about
_signaling value_. I hope you find a place (or have found a place) where
you're appreciated. :)

~~~
ok_coo
I'm not sure why you're being downvoted but some of the best career advice
I've heard is someone saying you should assume when you go to work that you're
working under a communist dictatorship. I.E. Toe the party line, make your
boss look good, (pretend to) eat up the company propaganda, assume the
leader(s) (C-suite) will do whatever they want, when they want, especially
giving themselves bonuses regardless of company performance.

It's a weird contrast to normal life, considering a lot of us live in
democracies, but once I understood this and started acting accordingly, it
helped me handle my work life.

~~~
TheGRS
I don't know if that's great advice, but its certainly advice that will help
get you promotions and salary bumps.

Like anything there's a grey zone here. Understanding the political realities
of a business is highly beneficial and will help you move forward with the
company and let you know when to pick your battles. But I've watched people
who do nothing but this lose the trust of those at their level. And that trust
is crucial for agile development. I also personally feel like pushing back on
the company when appropriate can indeed provide a lot of value to the
organization. "Why are we doing this meeting?" "We need another week for
testing" "I'd like to see the roadmap you are planning". Just don't push back
all the time.

------
me_again
I have a theory that commercially successful software development
methodologies are like diets: they have to be almost impossible to follow.
This ensures that when you fail to lose weight/achieve bug free software, you
blame yourself for not following the rules exactly, rather than the rules for
not working.

~~~
ff317
That's probably a very apt metaphor, but there's an upside too: many diets
actually do at least temporarily help people in spite of their irrational
basis, just because $random_diet causes the dieter to observe and reflect on
their eating habits more carefully in general. Even a non-sense diet like "eat
only foods colored yellow or red" probably does a lot of people a lot of good,
compared to their usual state of being completely unconscious of their awful
habits. Same goes for software development practices.

~~~
sombremesa
I think with this analogy you're presuming that people are exposed to a
variety of foods and there is some positive correlation between action and
awareness. However, for someone who only ever goes to McDonald's to eat,
they'll just switch to french fries and ketchup for your nonsense diet.

------
nosianu
"Thou shalt not be negative" (HN) - well I'm sorry. Just some example text:

> _both Agile and Waterfall are focused on building. Design is about
> validating._

or

> _So…what’s the way out? It’s a smart focus on clear outcomes, not output,
> with roadmapped outcomes replacing planned milestones, with trusted product
> teams, not project teams, empowered to vet assumptions and discover the
> minimal path to value._

Satire? Enough words to fill a hot air balloon or two. "Smart" focus, "clear"
outcomes, "outcomes" vs. "milestones"(?), "trusted" product teams (as opposed
to... what?), "empowered" etc.?

Far more interesting than the contents of many links that make it to the HN
homepage is discovering the fact that they do so.

~~~
tootie
Honestly that statement is the nail on the head for me. There's a huge
distinction between an output and an outcome and a huge distinction between a
project plan and a road map.

~~~
nosianu
> _between an output and an outcome and a huge distinction between a project
> plan and a road map._

I mention neither of those.

I'm not complaining about your reply, I think it shows how those texts are (to
be?) used: Just like art. You project your own experiences into it, it's more
about getting you to think. So naturally different people are going to react
differently and read different things into the same text. That's perfectly
alright - you get something out of it (only) if you put something in. If there
is nothing to begin with, which may just be lack of experience (new
programmer), you'll get less out of it. If you have two decades large project
experience in various companies and teams you'll get a lot out of it. Let's
attempt to make the best out of it then, out of any text, if we are presented
with that opportunity and the headline got us to click on it :-)

~~~
itsdrewmiller
I think you misread the part you quoted, while GP read it correctly - it's
comparing outputs and outcomes, not outcomes and milestones.

~~~
nosianu
No I did not.

Let me quote again what I already quoted:

> _with roadmapped outcomes replacing planned milestones_

"outcomes" vs "milestones"

See?

~~~
jeremyjh
> It’s a smart focus on clear outcomes, not output

------
commandlinefan
You don’t hear the name Joel Spolsky much any more, but he was pretty
influential in software process thinking in the 90’s - not really for being
particularly insightful or original, but more because he was one of the first
people who thought of writing a blog about software design. One of his early
“observations” about software project management was that “you wouldn’t buy a
pair of jeans without knowing how much they were going to cost, why would you
expect your manager to sign off on a software project without knowing how much
it was going to cost?” The utter blithering stupidity of this perspective
highlights how managers look at software design: the purpose of software
methodology is to put a fixed cost on every software project. As long as
that’s what they’re looking for, software methodology is going to continue to
be a lost cause.

~~~
geezerjay
What's stupid in wanting to get an idea of how much a project costs in order
to decide if it's a good idea to pursue, let alonr allocate resources?

~~~
ALittleLight
"How long will X take?"

"I don't know, I've never done X before."

"Yeah, yeah. It doesn't have to be perfect analysis, just a rough idea for
scheduling. Not written in stone, ha ha."

"Uh, a week?"

"Okay, great, so if I say 8 days you should have it done by then?"

"Yeah, I hope so."

"Great, thanks."

Day 3: actually doing X requires unforeseen Y and Z which will each take a
month.

"We need to add Y and Z to the schedule, which will each take a month."

"There's no room for that in the schedule."

"Then I can't do X"

"We've already costed X and committed to it. We've got to do X. We need to
make X happen. When can you get back to me with a path to green for X? And
also, let's schedule a post-mortem to figure out why we missed on X."

At the post-mortem, PM doesn't show up: "Uh, turns out we missed on X because
I estimated it too quickly and the PM committed to those estimates. I didn't
know about Y and Z when estimating, and these are things I could have done to
detect them as requirements if I had known to do so."

Email from PM: "Hey, could you give me an estimate for X'? Doesn't have to be
perfect, ha ha."

~~~
geezerjay
> "How long will X take?" > > "I don't know, I've never done X before."

I fail to see how your example makes any case on how estimating how many
resources a project needs is stupid.

At most your example argues that asking inexperienced and clueless devs to
estimate stuff they know nothing about produces highly unreliable information.

The main difference between hacking away at a code base and software
engineering is identical to the difference between construction workers and
civil engineering. Sure, estimating is hard. Yet of you want reliable
estimates you need to check with experienced professionals.

~~~
ALittleLight
I've worked about 10 years at FAANG companies and I'm yet to meet the
experienced and expert devs who are good at estimating things. I think your
characterization of "inexperienced and clueless" devs is off.

The reason I think my example illustrates a problem is it's moving away from
agile. I shouldn't estimate X without understanding it? Okay, I'll take the
time to figure out, look around corners, etc. I realize I need Y and Z. I've
got to estimate those, to estimate X, so I start working with other teams to
figure these things out, and drawing up plans and schedules and who's doing
what when to get all this stuff delivered. Now we're basically at the
waterfall model where we're planning everything out before doing it.

The other problem is that all the process is genuinely a waste. If we need X
then let me work on it rather than do all the planning and scheduling
nonsense. The schedule will be wrong anyway. If I have problems, need help,
etc with X then I can raise those concerns and management can react in an
agile way.

~~~
commandlinefan
> If we need X then let me work on it

If you look through the managers who are weighing in on this thread, you’ll
notice a common perspective: they don’t trust you to actually work on
something. That’s why I have so little hope for any software methodology -
even if it starts from something positive (like XP, which was the precursor to
“agile”, did), it will be turned into “I know all of my programmers are
stealing from me, how can I stop them?”

~~~
hinkley
In part because we still measure effort in hours instead of in wear and tear.
That guy answering comments on Hacker News is probably trying to recharge, not
steal from you.

I learned recently that the crane operators that unload cargo ships at some
major ports can’t work more than four hours at a time. The movements are too
precise and take a great deal of attention. I think you can work two shifts
per day but there’s a mandated gap of some number of hours between them.

------
lordleft
The best way I've seen agile described is "designing code in a way that
acknowledges change.' I think there's a lot of value in understanding that you
may have to go back to the drawing board when designing parts of your program.
I have little regard for the entire industry that has risen up around agile,
however.

~~~
collyw
That makes complete sense as a good way to go about designing software, but I
don't think I have seen anywhere else describe agile in that way.

------
musicale
There is a similar problem in the research world; the work must be genuinely
novel (and fundamentally unpredictable), but funding organizations such as
NSF/NIH/etc. demand a timetable and specific deliverables.

The problem is usually solved in three important ways:

1) making the deliverables as vague as humanly possible

2) promising experiments and not results

3) applying for grants for work that you have _already completed_ , and using
the money to work on the next grant's project

The problem of having deadlines that are too far out is mitigated somewhat by
the pressure to publish. Publishing has fixed deadlines but somewhat flexible
deliverables.

------
Isamu
Agile is not science-based, it is an ad hoc bag of techniques that seem to
have merit. As such you have to be able to reason about what your practices
are and you have to relate everything to concrete business goals.

Your goal should never be to become "more agile". You should be looking to
improve efficiency, to make sure you are building the right thing, to improve
communication so that everyone is on the same page, etc. "Agile" is never
going to magically improve anything.

~~~
FpUser
"Agile is not science-based, it is an ad hoc bag of techniques that seem to
have merit"

Each participant of "Agile" development should have this hung on their work
place.

------
taylodl
Uncle Bob wrote about this in _The Tragedy of Craftsmanship_
([https://blog.cleancoder.com/uncle-
bob/2018/08/28/Craftsmansh...](https://blog.cleancoder.com/uncle-
bob/2018/08/28/CraftsmanshipMovement.html)). His perspective is Agile lost its
way once the Project Managers stepped in. It seems to me the problem with
Agile in practice today is there's too much focus on process and not enough
focus on, you know, the actual software being delivered. Add to that a host of
less-than-desirable ideas that have taken hold (don't even get me started on
_emergent architecture_ ) and you realize modern Agile has become a cesspool.

What to do if you're on an Agile team? There's value in the _Lean
Methodology_. Remember, the whole point was to deliver software your customer
needs to fulfill their business objectives. Continually assess your Agile
practice and see if what you're doing still makes sense for _the project you
're working on right now_ and for the current stage that project is in. This
continual assessment with a focus on the end goal of delivering software can
go a long way to addressing Agile's modern ills.

~~~
F_J_H
I had not heard of "emergent architecture" until you implied you hated it, and
so I thought I would Google it.

I have no idea what emergent architecture is in the agile context, but the
idea of emergence is fascinating to me, and has been ever since I read
"Emergence: The Connected Lives of Ants, Brains, Cities, and Software" by
Steven Johnson.

We see the idea of emergent design everywhere in nature and society. I'm not
suggesting everything can be built and designed "emergently", but certainly
some things can be. See the book (and concept of) "the cathedral and the
bazaar". The idea of something useful coming into existence without central
planning is an enticing one, and so I can see the draw.

~~~
LyndsySimon
Thank you for that book recommendation - I just bought it and am looking
forward to reading it :)

I also had not heard the term "emergent architecture" in relation to software
development. I'm intimately familiar with the concept of emergent order,
though, and my grokking it was part of my "political awakening" in my 20s. It
led me from being a libertarian-leaning conservative to an anarcho-capitalist.
To put it another way, I believe that the system create by independent actors
acting in their own self-interest naturally create the most efficient system
possible within the constraints of the environment within which they operate.

There's a name for this concept when applied to company management, but I
can't recall it at the moment :(. I want to say the word has a Greek root, and
it reminded me of "autarchy" ("self organized") but that wasn't what it was
called.

~~~
F_J_H
You'd probably like Milton Friedman's ideas, and I'd be surprised if you've
not already come across his work and YouTube lectures.

There is something to be said for small government, but also can go too far:
actors acting in their own best interest can obviously cause harm to society
or to the larger group as a whole (See "tragedy of the commons").

Related to emergence is rapid iteration, and it's importance to analysing
complexity, which is caputured nicely in "Boyd's law". See
[https://blog.codinghorror.com/boyds-law-of-
iteration/](https://blog.codinghorror.com/boyds-law-of-iteration/), and then
see if you can find the referenced paper by Roger Sessions. (Sessions seemed
to caputure the essence of "Lean Startup" before it was cool...)

------
mcv
_" It’s just that everyone does Agile wrong."_

Not everyone. Some are very successful with it. The problem is that everybody
wants to copy that success and tries to cargo cult themselves through it
without understanding it.

 _" let’s stop pretending Agile was some sort of cure all."_

That's certainly good advice. Agile is more of an attitude than a solution,
and attitude is not going to solve all your problems. Even if you are as Agile
as you can be, you still need to solve your problems. It's just that being
Agile might make you more flexible and effective at solving those problems.

And Lean is certainly more comprehensive than Agile. And I don't think they
contradict each other. In fact, they're very similar; they're both about
empowering the people who are doing the actual work.

 _" management thinks the focus should still be scope and deadlines and
efficiency, ignoring that the deadlines are arbitrary and the requested time
estimates are a form of waste."_

Then management is not Agile and hasn't properly learned what it is. That is
sadly common. Agile is not magically going to solve bad management, but Agile
does emphasize keeping management at a distance and empowering developers.

 _" Agile actually tends to mask the core problem, which is a systemic,
bidirectional lack of vertical trust."_

Does it mask that? I think it exposes it. Without that trust, Agile cannot
work. Agile insists on that trust. I suspect that every case of broken Agile
is caused by a lack of trust. Fix the lack of trust (or use a system that
works without trust if you absolutely must).

 _" Did you know story points were actually invented to obscure time and help
alleviate this problem? That backfired too, didn’t it?"_

Yes I did and no it didn't. Every single team I've worked in over the past 6
years knew this and kept repeating it every time someone comes along and tries
to match story points to actual hours.

This first half of the article suggests the author has mostly worked in very
toxic management cultures.

~~~
unreal37
I agree with a lot of what you said.

My last company (before going self-employed) had an agile environment and it
was mostly a good system to work in.

I don't recognize the fairly strictly Agile (not AINO) environment I worked in
in that article. Not perfect, but it worked and better than a lot of places
that had no good methodology.

------
mpweiher
I agree that almost all of the orgs I encountered that were _Doing Agile_ were
pretty horrible.

On the other hand, I've also been in orgs that were very successful in
developing software in a way that we would recognise as being agile. We just
didn't make a big deal out of it. And we didn't do standups (most of the
time), or 2 week sprints, or retrospectives. We didn't even pair consistently:
we split up on trivial stuff, paired on hard stuff, as needed and available.

In one org we started without TDD, and even without having much in the way of
automated tests at all. But when we _discovered_ testing and TDD, boy did we
ever embrace it. Not because anyone told us to (mid-to-late 90s, so no Agile
Manifesto), but because the difference for us developers was _night and day_.

So _develop software_. Concentrate on what helps you develop software. In my
experience, you will probably discover something recognisably agile all by
yourself. So when you discover that, help yourself to what helps you. Don't
make a big deal out of it.

~~~
maxxxxx
What you are describing is exactly what Agile should be. You have a team of
people who care about the craft and they slowly improve processes based on
real world feedback and experience. If something doesn't work you drop it and
try something else. This happens in environments where people respect each
other.

~~~
rtikulit
Management does not want to hear that software development is a craft. They
want it to be a trade, with fungible workers operating in a predictable
process with fungible components. The great tragedy of Agile is that it was
co-opted as the vehicle of this transformation. It was seized by management,
weaponized to other purposes, and then aimed right back at us.

------
alexanderdou
Perhaps I've just always been extraordinarily lucky, but I've never heard the
developers I work with complain about our Pointing and Development cycle (and
I'd like to think I do try my best to 1) proactively ask them for feedback and
2) recognize and squelch any of my own reactionary defensiveness that comes
from feedback).

One thing I see a lot in the comments is about time estimates and the amount
of pressure that that brings and the rarity in which it works.

In my teams we NEVER talk about time of delivery with Engineering. I've always
been trained to think of pointing as an estimate of "complexity" (e.g. 1 point
is roughly the complexity associated with a copy change).

Then, by getting a track record of historical points completed in a week, we
can transform our way from feature => complexity => time.

~~~
t0mbstone
Complexity only matters if it can be correlated to time.

For example, if you ask someone to transcribe 10,000 pages of text, and you
know that they type 60 words per minute, and that there are an average of 300
words per page, then you can estimate that it will take approximately 833
hours to transcribe.

If we followed your method of estimating stories strictly by complexity,
however, this is clearly only a one pointer story. After all, there is nothing
complex at all about the dull task of rote transcription, and all quantities
are known and established.

When people talk about "complexity" in software development, what they are
really talking about is how certain they are in their knowledge about all the
things they have to touch. The more things they have to touch, and the more
things they are unfamiliar with, the more things can unexpectedly go wrong.

Each task should really receive two estimates:

1\. How long do you think this will take?

2\. How certain are you of this estimate, given all the factors you are aware
of?

That would be too much work, though, so people condense this into a single
point value and hope for the best.

------
nerdponx
Ah, yes, the old "you're not doing it right, so read these 3 books and follow
10 bloggers every day" argument.

~~~
unreal37
That was the weirdest part. "How many books do you read? Go read more books."

~~~
bendixso
Seriously. Just keep piling more bullshit on top of the bullshit

------
Zelphyr
The biggest problem I’ve found with Agile hasn’t necessarily been Agile itself
but the lack of buy-in from company leadership. Even when we’ve had
professional Agile trainers come in and tell them that not only must they
embrace it for us to be successful, but they themselves must go through the
training. They usually waive it off as something they’ll get to eventually.
Almost immediately we wind up with a bastardized version of Agile that
basically doesn’t work because the leadership doesn’t understand why we “can’t
just” do something.

------
rayanm
Agile was dead to me when I finished my PhD and joined a company that paid a
Scrum consultant more than they paid me to help us move tickets without
knowing what was the project about.

~~~
kybernetikos
You'll probably find that the most highly paid people in most organisations
only have a fairly abstract understanding of the work being done. This is
nothing to do with agile.

~~~
rayanm
I am perfectly fine with paying more for a technical project manager, or a
team lead who can help us glue things together and see the big picture. But I
am not fine with hiring a consultant who doesn't know anything about our
product and thinks that Agile has some magic to deliver products.

------
bitwize
Agile in practice is a way for Corporate to have its cake and eat it too: get
the results and productivity associated with outstanding programmers, using
the programming talent they have/can hire, with a minimum of risk exposure.
Part of this is the attempt (also seen in other corporate quality efforts like
ISO9000) to distill skills into process: to produce a book of rules that,
rigidly enforced on relatively unskilled workers, will cause them to perform
at the level of highly skilled workers. Hence my repeated quip that "Agile is
attempting to emulate a good programmer with an array of average programmers".
Unfortunately for Corporate, It Just Doesn't Work That Way.

Now I believe that Agile was started with good intentions, but today it is
much more a motte-and-bailey doctrine. The motte being "Agile is the values in
the Agile Manifesto". The bailey being "Agile is Scrum and SAFe, and all these
meetings, ceremonies, and process are a necessary component of Agile". And I
think this is why people fall into no-true-Agile discussions and eventually
end up disappointed with something that showed a lot of promise. Agile started
off a plea from programmers to Corporate, and it caught Corporate's ear. But
once in Corporate's possession, it was deployed to serve Corporate ends only.

------
andrei_says_
I love this talk by Dave Thomas, one of the people whose names are on the
original Agile Manifesto.

Among other things he speaks about the simplicity of the Manifesto, about the
cultish movement and consulting services which rose around it and the cultish,
distorted, complex vortex of BS that has formed around a super simple concept.

[https://m.youtube.com/watch?v=a-BOSpxYJ9M](https://m.youtube.com/watch?v=a-BOSpxYJ9M)

------
logfromblammo
The longer I stay in this industry, the more anecdotes I accumulate that
suggest that software development is not _exclusively_ software development.

Software development is solutions development; but for a large subclass of
problems, custom-built software that automates the tedious, predictable, and
repetitive parts of the solution has been and always will be a competitive way
to solve them. It's synecdoche, a metonymy for "software development [and
other assorted disciplines of problem-solving]".

Software is the hammer in the toolbox. Things that look like nails get
hammered. The hammer is so useful to organizations that have many nail-like
objects sticking up, that handypersons who _only_ have a hammer in their
toolbox can still work continuously, and may never need to do anything else
but hammer things. This may become common enough that folks who also keep vice
grips, screwdrivers, hand saws, duct tape, and penetrating oil in their
toolboxes are _forbidden from using those tools_. They were hired for the
hammer; they should use the hammer. And what's all this nonsense about non-
hammer tools, anyway? We've never needed anything but hammers here, and that's
the way we like it.

Agile is about advising organizations with strict rules and style guides for
nail-hammering to loosen up and let the hammerers determine how to wield their
own hammers, and possibly also choose the length and width of the nails.

Despite the amount I actually get paid, working upstream of the problem far
enough to eliminate both the nail and the hammer--possibly using a more
appropriate tool--is apparently above my pay grade. Agile never fixed that. It
never even suggested that a non-hammer world exists. Even the CTO position
might as well be chief hammering officer. The 'T' restricts the domain of
authority. An organization that is agile instead of just Agile needs to have
someone around that can meaningfully restructure the company itself, such that
the assumptions already built in to its organizational hierarchy are not
inevitably replicated in the processes of all of its subdivisions. That's why
Agile never fixed anything. The CEOs still kept telling their CTOs to take
charge of all the hammers and pound something out. Those companies founded to
be Agile put different assumptions into their organization. When that changes,
going through the motions of Agile won't help them any more.

------
inlined
I’ve been a tech lead for 6 years and Agile has given me a lot of imposter
syndrome because I can’t seem to make it work for me. The biggest point for
our org is to cost work items and realize a consistent throughput for our team
on which we can make scheduling predictions.

Unfortunately my tasks tend to be nebulous. They involve investigating very
large potential systems and breaking out smaller tasks, many of which won’t be
fully understood till we’re in the trenches. How do I cost the time it takes
to learn how Spanner will handle my design and update architecture
accordingly? How do I cost “interrupt driven” work like getting buyoff on a
given architecture? One of my OKRs was literally “Create a security model for
a new foundational technology that is acceptable to all integrators, follows
Google Cloud best practices, and can be represented in Kubernetes.” How would
you break that into (bi)weekly sprints? You don’t even know what work you’ll
have to do until you go to a committee of stakeholders and get told where you
have to go back to the drawing board.

~~~
keithnz
See, this is about agile going wrong.... back in the early days of XP, a term
started popping up "Brain Engaged", meaning that you don't blindly follow
perscribed processes. The manifesto tried to capture this in somewhat frilly
language. So be agile ( not in the dogmatic process sense of Agile with a
capital 'A'). You have to do something like "create a security...blah blah".
You don't have to do anything bi weekly, what you need is a way of of doing
that where you can get feedback as soon as possible, how do you iterate
through possibilities and arrive at a good decision? how do you involve the
people who need to be involved in a way that you get good contribution? How do
you make it so it is robust, how do you progressively work towards the goal
while minimizing risks and failing fast? If nothing else, the core of agile is
feedback loops and communication with the various people involved at a rate
that people need.

------
RocketSyntax
"We don't want to follow the agile process..." followed by "why isn't agile
working for us?!"

I blame the ambiguous manifesto.

~~~
specialist
The Agile Methodology is to argue about The Agile Methodology.

------
todd8
In addition to the difficulty in making a meaningful estimate, I'm frustrated
by how often management really wants to hear a particular answer and won't
settle for anything but that answer. It can go like this:

1\. Developers size development of X and says it will take roughly 12 months.

2\. Management says the rest of the organization is going into system test in
9 months and needs X finished by then. Couldn't there be some way of speeding
up the development of X without impacting the rest of the organization?

3\. X's developers say no, not really.

Now management tries one or more of the following:

\-- find someone else to size the work that X's developers will be expected to
do

\-- hire some outside "expert" to size X

\-- hire contract programmers that claim to be experts in X that will join the
X team

\-- suggest reduced functionality for X

\-- propose some modified "streamlined" component testing for X

\-- promise to provide X's required dependencies ahead of their scheduled
completion dates so X's development won't be gated by these requirements

Now jump back to step 1. Repeat until X's team relents and says that maybe,
just perhaps they might be able to finish X in 9 months if everything goes
perfectly even though the company has never done X before

This is now passed up the management chain and it becomes part of the official
overall system's schedule that planning, marketing, sales, finance, etc. is
depending on.

Iterating over all of these estimates is a big waste of time. Management has
already decided that they want X in the system and will keep pushing until an
estimate comes back that they accept.

If X's team is lucky, some other team will fail to make their estimated
completion date and X will end up with the 12 months it might take to finish
X. Every team in the organization is hoping that it will be a different team
that first has to admit that they will not make their date. This causes a kind
of game of chicken where every manager is unwilling to be the first to admit
that their team is going to miss it date. Consequently, every date in the
organization cannot be relied upon. The distributed file system needs the TCP
stack to be finished on time, but the TCP stack needs the ethernet device
drivers to be finished on time and no one will admit slippage of any dates
first.

~~~
tra3
> \-- suggest reduced functionality for X

Limiting the scope in a reasonable matter should reduce dev time, no? Assuming
it's a true reduction in scope and not just lipstick on a pig..

~~~
todd8
Yeah, I thought that point might be confusing because I wasn't clear. You're
right limiting the scope could reduce dev time and it might often be a welcome
suggestion. It doesn't always go that way though and some proposals for
modifying the functionality are costly because they can require re-
architecting the design even before development starts.

Usually, lightening the ship by throwing functionality overboard in a panic
doesn't happen until around half way through a project, but what I was
referring to was the sort of impractical proposals that come from non-
developers about how to reduce development time.

"Couldn't we remove the ability to customize user icons--everyone in the icon
based user view can have the same icon." Okay, why have icons at all if every
icon is identical?

"Deadlock, what's that?, do we really have to detect it in the first release?"
Hmm...

"Can we leave out distributed shared virtual memory segments?" They weren't
included in the original sizing

"Do we have to do persistent client caching?" Well then we will be no better
than competing products.

"Does X have to run over both UDP and TCP?" That was originally a requirement.
We can go back and examine that in light of other parts of the system
depending on X.

------
KZeillmann
Oh look, it's the weekly "Agile is bad" post. I've successfully worked on two
teams (including my current job) where we're a truly agile dev team. We value
interactions over processes and tools, collaboration over contracts, and
responding to change over following a plan.

Agile is not and has never been a cure-all. Scrum doesn't solve any problems.
It's supposed to reveal the problems that exist and make them apparent to
anyone looking at the scrumboard. If you don't change your team dynamic and
just start looking at a JIRA board every day in 30 minute "standup" meetings,
you're not agile. You're just cargo culting.

I'm tired of people blaming "agile" \-- which is mainly about self-organizing
teams and adapting quickly to changing circumstances, for what's really a
management failure.

------
stcredzero
_But but but, the problem is Waterscrumfall, not Agile as intended in the
Manifesto_

Here's the thing. Corporations are hierarchical. Human beings are
hierarchical. We're also communal, but start putting us into larger and larger
group situations where we're facing competition, stress, and we must engage in
concerted effort, and we go into hierarchical mode.

Why does everything tend to go back to waterfall? It's because that's how
management likes it, for reasons which go down to basic human nature in the
kinds of environments technology companies create. Heck, even the financial
markets demand fictional planning and forecasts of the unknowable future.
Bosses want to be able to make plans.

One thing which Waterscrumfall has achieved, is that the iterations are much
faster. That even fits the "next quarter" mindset of the financial markets.

~~~
mbar84
Very well said. If there's a methodology that starts with: these are the
people involve, these are their incentives and this is the expected outcome in
game theory, then I think we'll be making progress on methodology.

~~~
stcredzero
Methodologies are pretty good about that in the short term. If Agile were bad
at that, then it wouldn't have spread. I think the problem is more Agile in
the long term. It's a more general problem faced by longer term software
projects.

The answer might be to have shorter term software projects. Make everything
more modular, have a standard backplane into which everything can plug into,
and enable competing short term projects. I think today's trend is to make
corporations into ecosystems, and this change might be able to shape
incentives positively.

------
arendtio
> How does the first line of the Agile Manifesto begin?

It is kinda funny. For me the first line has always been:

> Individuals and interactions over processes and tools

And when I am asked to explain Agile, that is always at the core of my
message. Form a team, let them do their work and start learning how they can
improve how they do it.

From my perspective, the primary role of a (software development) Project
Manager/Scrum Master is to create an environment where the team can optimize
itself while not drifting into personal conflicts (create a healthy
environment for collaboration and feedback). Everything else, like
planning/risk management/change management/stakeholder
management/reporting/presenting come afterward.

Those other things are important too (and should not be skipped completely),
but if the team doesn't work, most of the other tasks create little value.

------
forgottenpass
I don't know any description of Agile better than meaningless buzzword.
Buzzwords are not without value. They are a tool for selling a change without
describing all the nitty gritty.

"Agile" is a lie that before 2001 nobody at all had ever done iterative
software development, and all software process ideas that came after 2001 are
by definition "agile."

"Agile", as with any other buzzword, is not for people who actually understand
the details of the change; it's for someone who needs a handle onto concepts
that would fly over their heads without a buzzword. Lets stop litigating the
term, and move on.

------
SkyBelow
>Quit with the local optimizations already, and realize trust is the №1 issue.

So how do you trust someone who would outsource your position if they believed
it would save money and reduce their work load? Management and employees have
an inherently adversarial relationship that is poisonous to trust. I think it
can still develop at times, but under our current culture where everyone knows
someone whose job was made redundant with little recourse for their
employment, you might as well be asking for a coconut to grow in an active
lava flow.

------
jacques_chester
In my experience, these discussions boil down to anecdotes at twenty paces.

I've seen software development done very poorly and done very well, sailing
under a variety of flags. But on an eyeballing there are far more bad
experiences than good that get labeled "Agile".

Whether this is because of causal differences or because it's easy to affix
any label to anything (and most experiences suck regardless of the label) is
hard to tell without a control-group universe were the Agile Manifesto was
never written.

If anyone needs me, I'll be counting to twenty.

~~~
chris11
How do you like agile at Pivotal? I'm curious, they have some really strongly
heard opinions about how to do agile correctly.

~~~
jacques_chester
Pivotal on the whole does software development as well as I've experienced.
When you hit the sweetspot for our core practices it's really impressive.
Everything just sort of flows.

Sometimes it goes off the rails. That is in the nature of things. But it goes
off the rails as an exception, rather than as a rule.

If there's a key to the magic it's (1) hire for empathy as well as smarts and
(2) reflect on what can be done better.

------
dnprock
I personally found that a good methodology: each team member has clear area of
ownership/responsibility. John does X, Jane does Y, Ann tests X, Jeff tests Y.
Everyone logs their own tasks. We define and work towards a sprint. No
elaborate planning, no estimates. The peer pressure is enough to get everyone
moving.

Managers often tell me that my process is chaotic. They want more visibility
and deterministic completion dates. We adopt Agile process. Now we have long
sprint meetings. I think we get less done.

------
couchand
One of the most useful segments of the article:

> _So find a good booklist. Follow some good blogs. Here’s a start: If you
> haven’t read Sense & Respond, Lean Enterprise, A Seat at the Table, and
> Everyone Is a Change Agent, I suggest you do so pronto. Your leaders too._

I'd add Peopleware to that list.

> _Start reading posts by John Cutler, Melissa Perri, Bob Marshall, Allen
> Holub, Laura Klein, Erika Hall, Neil Killick, and branch out from there._

Anyone care to add their own handful of books and bloggers to these
recommendations?

------
peterwwillis
> let’s stop pretending Agile was some sort of cure all

But we won't. That's why snake oil salesmen were so effective: we want to
believe in the cure-all. No matter how often you chastise, people'll keep
buying it, because they're aspirational. They want there to be greener grass
on the other side, and they're willing to try anything to find it.

The business doesn't actually care about Agile at all. It just has heard of
the term and realized it has something to do with getting work done better. So
leadership will say things like "We're an Agile organization now", not having
the faintest idea what that means. A snake oil salesman doesn't need to know
how snake oil works; he only needs to know what it promises, and how to sell
it.

You can have the perfect software development methodology and people will
still do it wrong. But if everyone has the same goal in mind, is highly
motivated, and is willing to cross aisles to work with other people to do the
best job possible, a methodology will naturally arise. Self-motivating humans
can get some crazy shit done. The best working organizations I've ever seen
followed no methodology. They just did what was needed to keep a site running
well and making money, and it was kind of wonderous.

~~~
alexandercrohde
I think this is one of the most realistic responses here.

I think it's in most party's self-interest to keep playing the "agile panacea"
game.

1\. Salesman sells something that doesn't exist, pats self on back

2\. Engineers asked to build integration/features on arbitrary timeline

3\. Doesn't happen, everybody unhappy

4\. Scapegoat needed. Says we didn't agile right. Project Manager hired / Deck
of Fibonacci cards bought.

5\. Go back to 1

------
tetha
I'm currently experiencing this, and especially the whole delivery vs
discovery, knows vs unknowns and their impacts on estimations. It's quite
interesting, especially how differently you have to handle delivery vs
discovery projects.

Basically, my team consists of some devops engineers mostly working on
maintaining and extending the config management, and some other technical
consultants who deliver and execute projects, ideally fully standardized.

For the standard delivery projects, it's extremely valuable to hammer the
scope down into a precisely known constant and track the time spent to
implement specific parts, as well as the delays incurred for different
reasons. This allows for a strong, deliberate optimization of execution time
with a measurable, predictable business impact as well as a reliable
estimation of these tasks.

Discovery projects on the other hand? Yeah. We're pretty good at giving a
lower bound for the time necessary by tracking similar tasks in a job.
Extending a database entity is going to take a roughly similar time each time.
Packaging, downloading and extracting binaries isn't going to differ that much
in time from the last 3 times we did that. If you can identify a bunch of
similar tasks you've done some time ago already, you can give a lower bound -
"The tasks we consider familiar will take about 2 weeks".

But after that? Who knows. At that point we're rather estimating by asking:
When do you stop feeling silly about it? Do you need a year to do this? A
month? Two weeks? A week? A day? So usually we hand our project managers
something like "This will take 2 weeks we know, plus 3ish weeks we don't
know".

------
karmakaze
I wish the post visited each of the principles. I can't find one I disagree
with. It's all in the interpretation and implementation. Agile for me is not a
single methodology that you develop. It's about refining and redefining
processes that work for you team and org.

Principles behind the Agile Manifesto

We follow these principles:

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

Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.

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

Business people and developers must work together daily throughout the
project.

Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing
teams.

At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.

------
ngngngng
Most of my complaints about agile have centered around estimates. I'm of the
opinion that anyone claiming to give accurate estimates for software
development is a liar.

But I would like to see an organization that only had the team lead give
estimations. This would remove the temptation on individual team members to
size too large and fill the time, while also keeping management happy that
they're receiving estimates for tasks they requested. Measuring throughput
would immediately become a lot more natural since team members wouldn't fall
into the trap of "When a measure becomes a target, it ceases to be a good
measure."

I was actually just rejected from a job I applied to since I voiced a few
small concerns with agile/scrum in the interview. My friend that joined that
company recently reported he was doing maybe 10% of the work he and I were
doing before he left my team. Even though I aced the technical portion they
didn't want to risk hiring me since I asked their willingness to flex the
rules of scrum.

------
bpyne
Organizations have to find their own way of working. It's going to change
based on the size of the organization, its goals, and its people. With the
exception of 1.5 years in a software company, most of my organizations have
been internal IT. What I find is that user areas, who initiate projects with
us, often don't have a clear view of what they want but think it's going to
help the organization. Our job is to build models quickly so that they can
validate an idea. Only after iterating through a few models can they reliably
say the benefit/cost of the idea.

A very good engineer within my organization said to me, "Our job is to get
something in front of them quickly so they can figure out what they don't
want." Our successful projects have been ones in which we kept to this maxim.

I think this is what the author was trying to say but I had a hard time
following his writing style.

------
mizchief2
The whole point of Agile is to force the entire organization to recognize the
fact that we don't know how long it will take to crate a satisfactory product.
That doesn't mean just dev time but also figuring out what you want it to
actually do throughout the process.

Instead of thinking you can write a perfect requirements document, then can
just design and build it (waterfall) doesn't work.

The idea that you can have any sort of meaningful estimate even when you don't
have perfect requirements is insane. Having an estimate with perfect
requirements doesn't even work.

The most effectivly analogy I've used lately is: "Take your car to a mechanic
and say "My car is making a funny noise, how long will it take to fix?" and
see what kind of response you get"

------
jnwatson
In the same way that software is eating the world, software management is
eating traditional company management. Software projects are getting more
important, sometimes centrally important to the future viability to more and
more companies that aren't traditionally software oriented. Software projects
are moving up the stack so they touch every part of an organization.

Agile is being blamed for problems that are really organizational, company-
wide issues that a software team has to deal with because they now are central
to how everything runs. The author's suggest to read more general
business/organizational management type books is apropos, because the overall
goal is agility of the entire organization, not just the software team.

------
btilly
Software development has some fundamental challenges that have been faced
since the start, and always will. Understanding them matters. Here are some of
the big ones.

1\. Developers need to communicate with each other. A lot. This takes time.
The amount of time goes up non-linearly with the size of the team. ( _The
Mythical Man-Month_ claims a scaling law of n^2.)

2\. Adding process + documentation of various kinds can turn that from
unbounded time spent speaking to a large but bounded written effort.

3\. Nobody is good at predicting schedules.

4\. Good news travels, bad news doesn't (until the last moment).

The traditional solution was to solve #1 with #2, put a lot of effort into
schedules for #3, and get blindsided over and over again by #4. The average
result was that the average delivered software project took over 2x what was
estimated, cost over 2x, and was delivered with under half the promised
features. But, no matter how delayed, usually didn't start slipping the
promised deadline until about 2 weeks before the first official release
deadline. And these were the success stories, since most software projects
never really got delivered.

What Agile opened up was the perspective that there were other approaches
possible. For example we can solve #1 by having small teams, which makes #2
unnecessary, solve #3 by making projects small enough to not need good
prediction, which creates a feedback loop to avoid #4. And that is not the
only valid tradeoff.

But this is not a one size fits all. Real world data shows that a team hits
peak throughput at 5-8 people, declines, and doesn't get back to the same
overall throughput until 20+. (After which it is almost linear, but with much
lower individual productivity.) The teams as drawn on the org chart don't
matter. The teams as they actually interact, do.

If you understand your options, and understand the tradeoffs, you can figure
out how to customize the right solution to the people/organization. If you
don't understand the tradeoffs, the best that you can do is blindly copy what
worked somewhere else and pray that you got it right. And if it turns out that
you didn't, develop superstitions about what you should have done instead.

------
chiefalchemist
> "So let’s get on board with continuous learning, and let’s stop pretending
> Agile was some sort of cure all."

Did anyone - who has seen shiney new panaceas come and go - believe it was a
cure all? What it is, like MVP, is a way to mitigate risk. It doesn't
eliminate risk. It can only mitigate it.

Furthermore, it still boils down to team and people. No tool will save a
dysfunctional team. The key isn't the tool. The key is the key agreeing on the
tool, and sticking to it. That is, tool is not a proxy for deep and solid team
work.

------
awinter-py
IMO focusing more on systems than people in management is a mistake.

To the extent your work isn't repetitive, the only job process can do is set a
cadence on communication & decisions. Yes 2-week scrum does this but in my
experience it distracts companies from the real goal of management --
attaching subject matter experts to projects, i.e. concentrating time &
resources towards a goal.

Process can get rid of bad people and share around your best people, but
unless you have an assembly line, beware of any other claim.

------
rb808
I think most of the people who wrote the agile manifesto said "Agile" been
warped into something they don't agree with. Its supposed to empower teams,
not enforced from on high to increase pressure on teams.

Heres's a good one by Dave Thomas. A quote: "Agile is an adjective not a
noun".
[https://www.youtube.com/watch?v=a-BOSpxYJ9M](https://www.youtube.com/watch?v=a-BOSpxYJ9M)

------
acbabis
"Agile transformations" are bad, but I still think agile itself is fine. Teams
of self-organized, competent developers tend naturally toward agile-like
practices. I've seen agile's story-centric model of development help new
developers grow by giving them responsibility for specific, testable units of
work.

As a lot of people have already said, the problems arise when managers expect
agile to give them software on a timeline.

------
mixmastamyk
So, Agile solved one problem when requirements are less than clear. Small
batch sizes improve responsiveness, costing a bit of throughput. Like the old
kernel HZ setting. Now you've got 99 problems, and responsiveness ain't one.

Yet folks expect Agile to solve everything for some reason, and forget all the
other issues around bags of meat working together. Those continue to need
handling and still get out of control at times.

------
petemill
It is a balance: We don't know how long something we've never done before is
going to take, and at the same time, we often need some time boundaries so we
don't go off tangent building some wildly ambitious re-write of the world.

Perhsps the qustion we ask in projects shouldn't be "how long will this take?"
but: "How long do you want to spend on this problem?".

------
akkartik
_" Stop unfairly putting dev under a microscope and letting everyone else hide
in a black box. Why aren’t we just as concerned with how strategy teams
operate? Or how legacy architects are constraints in the system?"_

Are other ladders in an organization not subject to performance review?!
Managers? PMs?

~~~
outworlder
They usually don't get _anywhere near_ as much scrutiny.

Dev gets performance reviews _plus_ the microscope.

------
thrownaway954
I just always double what I think it will take. I've been doing software now
for 20 years and I have NEVER seen something come in on time. If I think it
will take a month, I say it will take two. This has saved me more than I can
count since I pad for the unseen circumstances that will occur.

------
_pmf_
But think of your manager. He cannot stop pretending because that's all he
has.

------
ltbarcly3
It's almost like there is "No Silver Bullet".

[https://en.wikipedia.org/wiki/No_Silver_Bullet](https://en.wikipedia.org/wiki/No_Silver_Bullet)

------
amai
Agile works since 1947 at Toyota:
[https://en.m.wikipedia.org/wiki/The_Toyota_Way](https://en.m.wikipedia.org/wiki/The_Toyota_Way)

------
perfunctory
The root cause of the problem is that workplace is inherently undemocratic.
While we live in democratic societies, we work in feudal organizations. Unless
we fix that, nothing will change.

------
bassman9000
*And while we’re at it, we’ve got to stop treating dev teams like they work in a factory."

Beautiful

------
LeonigMig
Great rhetorically, not sure how comprehensible the logic was.

------
mratsim
_Pardon the interruption ..._

------
ChrisCinelli
“I estimate that 75% of those organizations using Scrum will not succeed in
getting the benefits that they hope for from it . . . Scrum is a very simple
framework within which the “game” of complex product development is played.
Scrum exposes every inadequacy or dysfunction within an organization’s product
and system development practices. The intention of Scrum is to make them
transparent so the organization can fix them. Unfortunately, many
organizations change Scrum to accommodate the inadequacies or dysfunctions
instead of solving them.”

This was Ken Schwaber, co-creator of Scrum. _10_ years ago. Ten years after,
things did not get a lot better for big corporations that were born with
leaders used to waterfall.

I agree with almost everything in this article and I completely agree with
what Tootie wrote above: "The fundamental problem that drives most agile
failures isn't in the team's execution, it's in the business' expectations.
One side is signed up for incremental delivery, and one side is set up for a
fixed scope and deadline and the result is misery."

As the article rightly noticed being Agile is not just building faster. It is
delivering "value faster". That also means: "do not build what does not need
to be built" and every 2 weeks be willing to scratch what you have worked on.
Instead in most of the big companies the business people present shiny objects
to the leadership and their goals is to build those shiny objects. Nobody
wants to say: "We were wrong". The result is a few projects were people worked
for 1 year and then the project is abandon. Even if the idea was good, nobody
wants to work on little improvements.

It seems that Agile, Scrum, and most of classic agile lingo have a bad
connotation for most of the people in these days. Some (over) simplifications
that were made to make Agile easier to adopt ended up making things worse.

People in big corporations are used to the "flavor of the month" Most of the
people really do not look for a revolutions there. They are just looking to
how they can seem smart to impress their bosses and being promoted. That how
Scrum got in. And that is why it will never realize its full potential there.
They do not want to change how they think and how they do things.

I run a pretty successful team inside a bigger organization. I wanted to use
story points. Start from scratch and have the team get a sense for what 1
point is. And my boss really wanted us to use story points. He only had one
requirement we had to use this equation 1 story point = 1/2 day of work...

Trying to explain him that one of the reason you use story points in the first
place is to stay away from time did not go anywhere. All the other teams were
using that equation and we could not be the only team that was not to using
it.

Frankly speaking, I think it is hard to work at the "inter-team" level if you
cannot use the same unit. That's why in Agile you want truly _autonomous_
teams. But big organization were not organized in that way. So you need to re-
organize the company in a different way... but assuming there is the desire,
who is going to drive that change? Who is going to take the risk of changing
something that work in some way in a way that is not going to work too well
for a few months?

In my humble opinion, it is almost impossible to change an existing a
waterfall organization and make Agile work inside of it. Only a leader with a
lot of trust by everybody in the company and a lot of courage may be able to
make it work.

Most of the people that hate Scrum, Kanban or other flavor of Agile had
experience with a "Cargo Cult" Agile preached in big companies and usually end
up thinking that Agile is sooo screwed up. A big corporation will usually
embrace embracing some things that usually really help (ex: standup meetings)
and change a ton of other things that will make things worse.

You like the Agile mindset, you are going to be a lot more successful if you
start from scratch with new young people or people that really want to commit
to make things great.

For a new organization is easy to start with a simple "Agile template" and
make sure that the team is really onboard with a continuous improvement
mindset. Keeping regular retrospectives will make things evolve quickly in the
right way.

------
sureaboutthis
People get far more done if they spend less time labeling things and thinking
there's a new canned technique that's better than what's been done before.

