
Manifesto for Half-Arsed Agile Software Development - virtualsue
http://www.halfarsedagilemanifesto.org/
======
wpietri
Beautiful!

The thing that really kills me about this is that 90% of the people who are
"doing Agile" (which is not a thing that you can do [1]) really believe that
they are an Agile shop. And then I will ask as many as 3 questions to find out
what they're doing is waterfall, or mini-waterfall, or code-n-fix. In the old
days I could say, "Hey, you should try one of the Agile processes." Now they
think they are doing that and doing it well (after all, they have
certificates!), so what can I even tell them?

Everybody I talk to who was involved in the Agile movement in the 2000-2004
time frame has this experience now. Common reactions are rage, tears, and
philosophical resignation. (I favor quiet rage, but I suspect resignation
would be healthier.) That there are some shops doing very well is consolation,
but the early Agile people were hoping for more.

For the whippersnappers who are curious about now-ancient history, my theory
on how we went wrong is here: [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/) A big lesson I learned was that if you don't have a trademark
and use it to keep quality high, your popular term will get buzzworded to
death.

[1] Agile is an umbrella for actual processes, like Extreme Programming. There
is no process called Agile to do. Saying you are "doing Agile" is like
somebody saying their house is in America, but not in DC or any of the states,
just America. If you point out that it's the _United States_ of America and
they have to be somewhere; they just shrug.

~~~
analyst74
I'm not expert in Agile, but from the pieces I used, and ones I read, Agile is
not something you can do "perfect".

Agile is not something you can follow to the letter, like you said it's a
bunch of processes that help you succeed. Which ones to apply, and more
importantly, how to apply each process is highly dependent on the
circumstances.

~~~
wpietri
In my view it's a family of processes.

The way we got the term Agile is that a bunch of people in the '90s were
experimenting with processes that were less insane that the waterfall approach
that had come to predominate. DSDM, FDD, Extreme Programming, Scrum, and
probably others that I'm forgetting now. All of those people got together and
said, "Hey, we all have something in common. What is it?"

The answer to that was the Agile Manifesto:
[http://agilemanifesto.org/](http://agilemanifesto.org/)

Agile is to an actual process what a subdivision is to a house. If you say you
live in the subdivision but are not in an actual house, then you're just
wandering around camping in back yards and parks.

I agree that a given process is a collection of practices, and that one can
compose different practices into a process, sort of the same way a talented
chef can walk into a farmer's market, see what's on offer, and compose a
balanced, nutritious, and tasty menu on the fly.

However, in practice, what "doing Agile" mainly means is what happens when an
energetic but unskilled 7-year-old decides to be helpful and make dinner.
Maybe you get a dinner composed entirely of candy. Maybe they use the stove
and make something that is a mud-pie version of a gourmet meal.

That isn't to say that people _can 't_ create a good process out of raw
practices. It's just that doing it is an expert-level activity, and it
requires an immense amount of dedication, experimentation, and careful
thinking. That's not what I see when I ask after shops that are "doing Agile".
That phrase seems to be used exclusively by people who _don 't_ want to think
hard about process, and just want to cargo-cult and half-ass their way through
things because they're focused on getting a project out the door and/or
pleasing the HiPPOs.

------
avighnay
In my language we have an ancient term/story called 'Yaanai Kanda Vaadham'
meaning the 'debate on the elephant' (the origin of the story is controversial
so lets leave that out). Perhaps you have heard the story, four blind friends
come across an elephant, each one holds a part of the elephant and equates it
to what he knows and understands. Hey! there is a wikipedia page on it

[http://en.wikipedia.org/wiki/Blind_men_and_an_elephant](http://en.wikipedia.org/wiki/Blind_men_and_an_elephant)

When merits of processes are discussed devoid of its purpose (delivering
quality software in business relevant time), the argument is similar to the
story. The process is just the means of reaching the purpose isn't it? It is
not like successful software was delivered only in the last decade, we have
been to the Moon and back before that.

Unfortunately, processes are always made in good intention to achieve a
purpose, this when transmitted from one person to another becomes a system, as
there is no guarantee or way of enforcing 100% knowledge for all people in the
chain. This deviates it pretty quickly from the purpose with focus only on the
practice and soon the system becomes a religion.

Then surprise! people shed blood over it after that demanding that their book
is the only truth :-)

------
herghost
In my experience "agile" isn't really a thing, more an excuse or reason to not
follow any rules at all. Devs get to play at building whatever they like,
solving the problems that interest them in a haphazard way and leaving behind
a trail of half-written, semi-functional code with little or no documentation
to allow anyone to work with them. As soon as anyone suggests that there's a
plan, or god-forbid, an objective or expected outcome from the invested money,
everyone suddenly scream, "AGILE" and that, apparently, is enough to shutdown
any and all detractors.

But then, try to suggest that there's a requirement that has changed or come
to light and suddenly the "agile is open to new requirements" part of the
approach is forgotten as the "progress" that's been made so far is too
precious to change.

/rant

~~~
UK-AL
That's odd because agile methods like scrum have a definition of done, which
has to be complete before you can class an issue as done.

definition of Done usually includes things like written code, unit tests, code
review, documented etc

I suspect most people doing a agile, don't actually do agile. And think its a
term for little structure.

Agile methods, such as XP programming are highly disciplined methods, more so
than traditional.

The main difference is that they react to customer change, and don't follow
plan than stretches 6 months into the future. The priorities of tasks can
change from sprint to sprint. Allowing the team to react to the outside world.

------
saosebastiao
It is a plain fact that people rarely distinguish between philosophy,
religion, and culture. As a former mormon who served a mission in a foreign
country, I witnessed this first hand: American missionaries (mostly from Utah)
trying to superimpose their culture on foreigners and calling it religion,
while foreign members pushed back (appropriately IMO) when they felt that the
religion didn't really clash with their culture which was being stripped from
them.

Now I am seeing this from an outside perspective; I'm not a programmer or
software engineer but I work directly with them in a weird sort of non-
supervisory product manager role. In my opinion, this is no different...in
fact, "Agile", which as far as I can tell is nothing more than a hand-wavy
underspecified form of Extreme Programming, has so much ambiguity in its
definition that you can't ask any two advocates and get the same response as
to what it is. And as such, whenever there is a problem with the outcomes of
the process, the only apt response is the No-True-Scotsman fallacy...which
makes development descend into the phenomenal failure of productivity that all
holy wars are.

This isn't unique to Agile. Lean and Six Sigma are also mixed bags of
philosophy and process, and they have been mixed bags of occasional success
and phenomenal failure.

~~~
UK-AL
Agile is underspecified because it is a general philosophy. I.E React to
change, rather than following a 12 months rigid plan.

There are different concrete ways to implement Agile, such as using Scrum,
DSDM, or various other methods.

------
BWStearns
This post gave me flashbacks.

I once had to sit through an 8 hour pre-kickoff meeting detailing in
excruciating detail how our team was going to be "agile". It involved at least
400 slides, described a weeks long change request process, and two-month long
"sprints". Even as a junior dev I know I am lucky I never had to suffer
through the rest of that contract.

------
mbesto
One word: budgets. The problem with "enterprise" isn't their reluctance to
adapt agile principles, but rather that people need to know "if I pay X, then
I should get Y" \- agile basically says "we think we know what X is, and we
know your version of Y isn't what Y will become"

~~~
wpietri
Yes. I think the solution to this is to get rid of budgets, and go for an
approach based around iteration, risk reduction, and a flow of delivered
value.

That sounded insane to me at first, but the Lean folks really turned me around
on this. Mary Poppendieck's books are great in this regard. One of her best
examples is the Empire State Building: they started construction on the lower
floors before the top floors were even designed. Nonetheless, the project was
completed on schedule and budget. How? As with Agile projects, scope was
treated as variable, and a lot of thought was put into maximizing efficiency
of the system.

I've also read some great stuff from the Lean Manufacturing community on how
shifting the approach to accounting is vital. Rather than having annual plans
and budgets and then trying to hit them, you have rolling projections n months
out and adjust allocation to achieve real-world effects.

~~~
mbesto
Yup. The problem is trying to explain to a client: "Ok, so we've got the 4
best back-end developers, 2 best UX/UI guys, and a scrummaster. Now they'll
cost you $100k/month, and we think that'll create 3 apps for you, but ummmm
we're not sure. But these guys are the best, so on average you'll get more
production out of them if you don't do agile" My conclusion is that agile only
works with talented people; most of the enterprise clients I've work with
(non-SaaS stuff) don't care whether they are Linus Torvalds or Joe Shmoe, they
just want to spend their budget and get their "app" within the budget.

~~~
wpietri
I think if it's a client situation there are ways to use Agile approaches and
still give them fixed bids. The initial setup is wasteful, but from what I've
seen once you deliver regularly you build trust, and they learn that they can
control risk in other ways.

As to talent, I have the reverse view: by putting people in boxes, waterfall-
ish processes train people to look untalented. I think perfectly ordinary
people can do Agile processes as long as there's good mentoring and
institutional support while they learn to step outside their boxes and make
shit happen. After that, nobody wants to go back to being a doll in somebody's
Manager Barbie Dream Office playtime.

------
chris_wot
Finally, someone who spells "arses" correctly!

------
taoquay
As someone working in enterprise, this manifesto sounds almost exactly like
how we use Agile here. The term "Agile philosophy" (instead of methodology)
was coined to go with our loose interpretation of what Agile should be.

------
badman_ting
I dunno, sometimes going back to waterfall sounds kind of nice. I'm tired of
the lack of direction, the attention-deficit school of project management
where every 3 months there is some new starry-eyed vision we all chase after.
I know this means my company is "doing agile wrong" and all that shit, I just
would rather be on a slow train wreck than a fast one.

~~~
UK-AL
The problem is that business conditions do change that fast.

However for a lot of small companies it is better than what they had before,
regarding consistent direction. Lots of startups change scope or features
daily and are in a constant state of panic.

Having a fixed two/one week sprint provides same restspite for developers. But
still allowing feature and priorities to be changed after each sprint.

~~~
badman_ting
That's what I thought for a while too, but most everything I have made in the
last 2-3 years got shoved in a ditch. We're not responding to the market,
we're just flailing around trying different dumb stuff.

------
asolove
It's interesting because "agile" can fail on both sides. This lampoons the
enterprise side, in which you adopt "agile" practices inside rigorous change
control and long requirements documents. But there is also the cowboy/ninja
failure mode, in which "agile" is used to rule out any strategic thinking,
technical design, or requirements gathering.

Not only can you fail on both sides, but you can be too far on one side and
think that you haven't gone far enough.

I've had startups tell me they were doing Scrum, but it had gotten so hard to
estimate their work that they had "broken agile" by having "grooming sessions"
to talk to stakeholders about upcoming work before it got into sprint. They
were shocked to learn this was a required part of Scrum and that many books
recommended that being up to 10% of the team's time.

Another company I talked with was so concerned about their developers
"continuously delivering" code that they were fighting to be "more Scrum" by
changing their QA folks to be in a staggered sprint one week after the
developers. They were shocked to learn that this was a widely-tried and
widely-panned approach that was philosophically opposed to the roots of Scrum.

Now, I remember hearing examples like these before I had really dived into
Scrum, and assuming it was a "no true Scotsman" where, whatever you did,
someone would find a way to say it wasn't Scrum. But after some very good
books and talking with experienced people (who were involved in the early
stages, not bandwagon consultants), I now feel like I actually understand what
Scrum is for and when it works, and can quickly spot people who don't
understand the philosophy. Has anyone else experienced this? I wonder whether
it is real experience or just an illusion my brain has created to give meaning
to many months of painful trial and error.

Nowadays I think of scrum as being about holistic product creation, about
building a team that can deliver what customers will pay you for over the
long-term. That requires breaking down most "process" to get "one-piece flow"
on a complete team working as one to deliver new features. But it also
includes the team building its own processes to make sure they are building
the right thing to a high level of quality.

That vision is anathema to cultures that value technical prowess, or pure
speed, or meeting corporate objectives, or anything else other than building a
team that can deliver value to customers over the long term. It's a challenge
and a priority change for both corporate political environments and built-to-
flip startups. And it's surprisingly hard to find a company that wants to pay
you to build things their customers like, rather than using some other metric.

~~~
tieTYT
> Now, I remember hearing examples like these before I had really dived into
> Scrum, and assuming it was a "no true Scotsman" where, whatever you did,
> someone would find a way to say it wasn't Scrum. But after some very good
> books and talking with experienced people (who were involved in the early
> stages, not bandwagon consultants), I now feel like I actually understand
> what Scrum is for and when it works

I get the "no true Scotsman" sense myself. What book(s) was most helpful in
pinning down what scrum is and isn't?

~~~
asolove
I recommend "The Scrum guide" and "Extreme Programming Explained" as ways to
learn about the systems themselves.

Thinking about it, the book that actually taught me to understand what the
early agile people thought was Christopher Alexander's book "The timeless way
of building." The book is about architecture rather than software, but the
underlying idea is right on. It starts by addressing what is the point of
building? Some people try to optimize speed, or predictability, or how good
the building looks. But Alexander says the point of a building is to be
lived/worked in, and it should be measured by how it improves the human lives
of people around it. This implies doing the design and building in a whole
different way, and thinking about the relationships between builders and users
in a different way.

The "agile" idea is similar. People who try to "use agile" to accomplish their
goal of just making software really fast, or making lots of money, are missing
the point. Agile is actually about building software that is good, in a way
that is sustainable for users, builders, and a company, and makes everyone
involved better. If you use Scrum in the context of those values, you may
succeed.

But the vast majority of people who adopt scrum, and perhaps the majority of
consultants and explanations trying to "sell" Scrum, just use it to wring
every ounce of effort out of your employees, or to ship something crummy fast.
That ends up not really working, and in my experience making environments even
worse than they were before.

~~~
tieTYT
Isn't that the architect who inspired software design patterns? Is that the
same book that inspired it?

~~~
asolove
It is indeed, and the book I mentioned is the prequel to his book "A Pattern
Language."

But there is an enormous difference between his real idea of "design patterns"
and the much more static idea that you see in, for example, the Gang of Four
book. The easiest way to see this is to consider that the methods and goals of
"A Pattern Language" are centered around making buildings that add to the
quality of human life (and the first few patterns deal with the goal of world
peace), and would be totally useless to someone building a gulag. Whereas the
patterns in the GoF book are just about preventing code duplication, and would
find themselves just as useful in a program for violating people's privacy as
one designed with a more benign purpose.

------
jhare
In the best of worlds your practices evolve from your principles. Compound the
relationship between your principles and _current_ practices with the effects
of the real world and you end up somewhere in between. That's life. It's easy
to stand from a "higher elevation" like a consultant might, point your finger
and say "You are not doing this." It's a harder thing to really make it
happen.

I see parallels in people bickering about whether some element of a service is
or is-not RESTful, when maybe 95% of the functionality of the service is
acting/quacking like a duck.

~~~
icebraining
In a recent book, which I learned from a podcast[1], Lant Pritchett argues
that much of the increase of education in developing countries is to a great
extent fake, being inflated by governments which "have created all the
appearances of schools that provide education but without actually doing it "
by producing "enrollment statistics, numbers of buildings, numbers of toilets,
numbers of textbooks, numbers of everything (...) all of which can project the
image that there's a functional system and providing real learning there."

I think a similar effect has happened to RESTful architectures; people making
them have (inadvertently, I believe) produced very convincing emulations while
skipping the parts that effectively distinguish them from RPC systems.

[1]
[http://www.econtalk.org/archives/2013/12/lant_pritchett.html](http://www.econtalk.org/archives/2013/12/lant_pritchett.html)

------
al2o3cr
Disagree with the title; if anything, these practices are correlated with a
SURPLUS of arses involved in the project. :)

~~~
neosergio
TRUE. The problem are the people who consider themselves as "agile".

------
thenipper
This is so on point for any company not just software ones. I work at an NGO
and not a tech company, and this just reminds me of every meeting we have
about internal processes.

We end up creating grandiose plans, but they usually just turn into endless
bullet points for strategic road maps rather then actionable items

------
gdubs
This describes a certain kind of corporate agile that I like to call "Agile in
a Waterfall".

~~~
eitally
I think this is probably the most common "style" in most large enterprises.
The people footing the bill still demand macro level waterfall estimates, but
when it comes time to execute the project, it's split into smaller phases
(perhaps 4-6mo) which are in turn split into 2-4wk sprints.

In my personal experience as an enterprise apps director, this is
significantly better than pure waterfall but still causes all sorts of stress
on the IT side. I think the single highest impact change for the better would
be to take a product-centric rather than a project-centric perspective. At
least in my company, business "owners" don't pay for KTLO work, only projects,
so there's no incentive for anyone to ensure high quality products.

------
coldcode
If this is half-arsed, then what is the enterprise definition of full-arsed?

~~~
arethuza
Probably CMM Level 5

------
Yhippa
This reminds me that anything "Agile" and enterprise business is fundamentally
incompatible thanks to the quarterly earnings report (for public companies at
least).

------
allochthon
I've been a little disappointed to find out that aspects of this view are
sometimes adopted at startups with a lot of VC funding, and not just
enterprise companies.

~~~
MartinCron
Yeah, that is the one thing I would remove in this manifesto. References to
"enterprise" as all sorts of companies are infected with this half-arsed agile
mindset which is an insult to both agile and half-arses.

------
dschiptsov
The buzzword of the day is "reactive".)

