
The Church of Agile - aninteger
http://www.thechurchofagile.org/
======
grandalf
I think Agile is a response to the reality that in many organizations writing
code is a thankless and cynicism-inspiring burden.

Agile tips the balance and puts the technical team in control of process and
expectation management in a way that lets everybody feel very good about how
much they got done, regardless of whether there is good code being written or
successful product/market fit.

It's also possible to justify quite a bit of architecture debt by deferring to
agile principles and punting on systems thinking in favor of finishing a few n
point stories, rinsing and repeating.

I'd say that if you have a team that is cynical due to changing requirements
and technically naive management (or clients/stakeholders) then agile might be
a great approach.

Or, if the sort of predictability and transparency offered by agile is of
great value to the organization for some other reason.

In general I think that sprint velocity is a vanity metric that has nothing to
do with product market fit or system quality.

The "retrospective" meeting is a nice idea, but the presence of a few
complainers/gripers on the team can turn this into a morale-draining
blamefest.

~~~
Domenic_S
This is a weird comment. Assuming we're talking about a company of any real
size, why is product/market fit the responsibility of engineering?

~~~
jrs235
>regardless of whether there is good code being written or successful
product/market fit.

I don't think OP is suggesting that engineering is responsible for
product/market fit but rather sprints and burndown charts provide some
visibility and satisfaction that work is getting done (regardless of whether
the code is clean and regardless of whether it is the work that ought to be
getting worked on).

I take the OP to be pointing out the reason that agile gets adopted and it's
short comings that get overlooked because it makes people feel good.

Clueless management is clueless. They often feel that nothing gets done
without some visible artifact. Agile allows the dev/engineering team to help
show the tasks and behind the scenes things that need to be done. Clueless
management likes Agile for this visibility. But Agile doesn't necessarily
ensure proper product/market fit, especially early on when the first sprints
deal with architecture setup foundation code. Clueless management doesn't
understand this (and it is managements job to ensure the dev team/engineering
team is working on the correct solution).

~~~
Domenic_S
That sounds like an indictment of clueless management, not of Agile.

~~~
jrs235
Correct. And to that some would say that the latest agile craze and the large
number of shops using agile is because of clueless management. It's not the
miracle cure some people want it to be.

------
1_2__4
In my experience Agile is most prevalent where the engineering culture is the
weakest. When engineering culture is strong and effective, it's unnecessary.
Where engineering is simply the business side's bitch is when you end up with
a massive multi-tentacled PMO organization attempting to use their Agile
hammer on anything vaguely nail-looking, cheered on by Chief Revenue Officers
and Heads of Product who love that they have a direct line to individual
engineering teams... Without any of that pesky engineering leadership getting
in the way.

~~~
lowbloodsugar
I've used Scrum in startups with strong engineering culture, and it helps
align engineering and "the business" (sales, marketing, 'what are we
building', 'for who'). As an engineer, Scrum helped me expose 'the realities'
of software engineering to people who did't get it. For example, the
communication helped us change priorities to get value into the product.

Unfortunately, "Agile" is now mainstream bullshit, and, as you say, its now
used by the business to just bypass any kind of engineering mastery, and just
hire a bunch of junior devs and tell them what to do. "Scrum masters" are just
"yes men". Most times, when a company says "We do Agile" they mean "We hired a
bunch of script kiddies on a constant death march".

Scrum is about empowering developers, but Scrum itself does not empower them.
If the developers are already empowered, then I believe it's useful for
communication and direction. If the developers are _not_ already empowered,
then Scrum is actively _bad_. Scrum cannot empower developers. Scrum with
disempowered developers is just disempowered developers but now without any
kind of SDLC safety net.

~~~
lasereyes136
I agree with your statements.

But it has nothing to do with Agile or Scrum. It all has to do with company
culture. It reminds me of my favorite Henrik Kniberg quote "If your company
doesn't like the truth, than maybe Agile isn't for you". Very few companies
realize value from script kiddies on a constant death march (great quote BTW)
and that prevents no one from trying.

------
foo4u
> Programming in C/C++, Java, Javascript, that's easy, anyone can write code.
> But having the skill of standing in a circle and saying what you've been
> working on, what you will be working on, and if you have any blockers, that
> takes pure talent.

That may be the dumbest thing I read all week.

~~~
dcwca
It's sarcasm

~~~
mikestew
Consider that the writer of the comment to which you replied already knows
this, and stands by what they wrote.

------
languagehacker
This is a website written in PHP by someone who doesn't like how their scrum
team is being run.

I'm going to assume that based on the tone of this site, the author is a very
junior developer -- mostly because I think a mid-to-senior software engineer
would be brutally embarrassed to publish and share something like this with a
wider audience.

Everything there is to be said about agile has been said. Good teams adopt the
right take on the process for them. Teams with poor cohesion, who would likely
struggle with or without project management, may have some cookie-cutter
version of the process forced on them. This is usually a sign of a
dysfunctional team -- not necessarily a dysfunctional process.

The author may actually be the bad apple derailing a process that works for
the team as a whole. Look at all the complaints! Assuming it's actually a team
of seven, you're talking about one seventh of the team probably visibly
seething at every standup because they feel put upon by someone forcing a
process on them. I imagine that's a lot of tension for the other six people to
bear.

Look, I've written plenty of things I'm embarrassed by -- particularly in the
beginning of my career. Blog posts and the like are a great way to let off
some steam about how unsatisfied you are with your job. But if you're anything
like me, you're going to look back at stuff like this and regret how bad your
attitude was.

My advice straight to the author: You probably spent more time writing this
site than the amount of time you've actually lost to your daily standup. If
you're not happy with your job, then quit it.

But I've got to warn you: odds are you're not going to be running the show at
the next job either. I can tell from this site that you're just really mad
that people are telling you what to do. Answering to someone else is a part of
literally any job. It's a pretty fundamental part of participating in society.

You're going to end up being just as miserable wherever you land if you don't
take a look in the mirror and invest some time into improving your attitude
and focusing on positive, productive interactions with your co-workers.

~~~
grandalf
Since it sounds like you very much favor agile, I'm curious about your take on
the following questions:

\- What adaptations to classic agile have you seen successful teams make that
you think were very smart decisions?

\- What sort of project is agile best for? worst for?

\- How can agile help to find product-market fit? Or is it completely separate
from that?

\- What sort of alternative project management approach do you think has
failed so often that Agile became necessary as a fundamental rethink of the
old way?

~~~
languagehacker
I really hesitate to say I'm in favor of agile. It's just a flexible tool for
getting things done which prioritizes team empowerment and short feedback
loops over top-down command-and-control project management.

Some good adaptations I've seen are largely around handling distributed
collaboration, and favoring out-of-band communication practices over regular
interruptions. For many teams benefit from replacing a daily standup with a
status email. A good compromise is also a daily status email with standups
every other day. Having a mid-sprint status meeting and a regular standup time
in slack is also a good compromise.

I think engineers in particular get caught up on the rituals they're asked to
attend because they view it as invasive. The rituals are just part of it, but
in my opinion, the end goal is to provide regular feedback loops for measuring
progress and actively communicating. This way, teams can react to changes and
blockers before they prevent a group from delivering on its commitments.

Agile is good for teams that are matrixed and highly empowered. If there are
strong dependencies on external teams, then it's hard to get out of the
proverbial waterfall.

I don't think agile is appropriate for handling questions around product-
market fit, but it does help a team to iterate on a product in measured paces
in response to the product / sales cycle.

In terms of an alternative project management approach, I think maybe the
question needs to be framed differently. Other approaches don't need to fail;
agile just needs to be different in a useful way. Agile has a focus on self-
organization and measuring progress in short intervals. It suits the
increasingly distributed and technological ways in which groups perform work,
specifically because it's up to the team to implement the process in a way
that works for them.

~~~
AnimalMuppet
The real problem with agile (even well-done agile) is the interface with non-
agile upper management. Sooner or later you usually run into someone who wants
to see your detailed project development plan and timeline, or some such.
Answering "Why would we need one of those? We just talk to each other" does
_not_ go well, even if it's true that you actually _don 't_ need one of those
because you've addressed the problems the document is supposed to address
simply by regular informal communication. (Been there, done that.)

If upper management doesn't "get" agile, at some layer you have to transition
to non-agile. There's an impedance mismatch at that layer. If someone doesn't
actively translate things into upper-management terms, they can decide to kill
the project, simply because they can't tell what's going on.

~~~
languagehacker
This is why middle management exists -- to insulate working groups from hard-
and-fast commitments and timelines. They do this by using their professional
experience and understanding of the capability of their teams to know what
overall product to promise under what kind of timeline.

I don't know about many companies with 50 or more people where the CEO "does
agile" personally, for instance.

------
CSMastermind
When most people say Agile they mean Scrum. Scrum great up around the culture
of web consulting. That makes it a good way to do web consulting, an alright
way to do web development, and a pretty bad way to do anything else.

------
felipeccastro
I wonder if any of these Agile haters ever had the pleasure of working with
RUP (Rational Unified Process) and endless UML diagrams.

Agile was a response to that trend, cutting the BS and recommending teams
would focus more on software quality and collaboration and less on worthless
processes. It was a cultural shift more than anything else, and a very welcome
one.

Sure, lots of people tried to "sell Agile" by pushing sticky notes everywhere
and replacing "Project Manager" with "Scrum Master", as if these changes alone
would solve all their problems. This does not mean that Agile itself was a bad
idea, it only means that anything that goes mainstream is bound to be
misunderstood and misused by a lot of people.

------
maxxxxx
"Agile" should have stopped at the Agile Manifesto. Everything else just made
it worse.

~~~
organsnyder
Whenever a movement takes root, an ecosystem jumps up that attempts to
productize and commoditize it. We're seeing the same thing with DevOps, which
is being sold as CICD, ignoring the cultural bits that make CICD effective (in
fact, if you do the cultural bits, you'll probably end up recognizing the need
for CICD at some point, regardless of whether you included it initially).

Peeling back the layers, a lot of these philosophies include principles that
have been found in high-performing organizations for decades:

1\. Transparency

2\. Seeking input from all levels of the org chart

3\. Involving stakeholders early and often

4\. Constructing incentives around desired metrics

5\. Fast feedback

6\. Rapid iteration

7\. Reproducible processes

8\. Constant, systemized reassessment

That last one is where "Agile" has lost its meaning: Hiring certified
ScrumMasters® doesn't make you agile. Scrum and the like can be useful
frameworks, but if you don't absorb the above principles into the core of your
organization (including outside of the IS department!), you'll end up with
AgileScrumFall at best.

~~~
maxxxxx
The same happened with OOP and design patterns. It will happen with FP too. As
soon as something works and is useful, "gurus" and consultants appear who make
it digestible to mediocre devs and upper management but in reality they are
just caricatures of the original intent.

------
tannhaeuser
I think the flat hierarchy in the Scrum religion is an oversight. When
designing a religion, what you generally want is a sense of accomplishment as
you climb the ladder towards alumni status, with knowledge revealed in rituals
such as commercial lectures and materials along the way. This is what gives
people a sense of achievement, keeps people stick to a religion, and makes a
decision to drop out increasingly hard. L. Ron Hubbard did know about this
aspect of human nature all too well.

------
tannhaeuser
Is the term SCRUM trademarked? Asking because I'm still seeing a business
opportunity here for selling "official" SCRUM master certificates. Believe it
or not (and reflecting on non-engineer's desire for status symbols of even the
most absurd kind), there are people who, when asked what their profession is,
will without irony answer "scrum master".

~~~
t0mbstone
That business idea already exists...

[https://www.scrumalliance.org/certifications](https://www.scrumalliance.org/certifications)

------
gnicholas
> _Thou shalt spread the word about Agile to everyone I know._

Probably shouldn't be "I". Only posting this on the off-chance that the author
reads HN comments.

------
lasereyes136
He forgot the mumble talker in his list of people that come to the Daily Stand
Up.

------
tempodox
A nice desecration, as I hoped it would be. The bit about git hit the spot.

