
Agile Is Dead (Long Live Agility) - ternaryoperator
http://pragdave.me/blog/2014/03/04/time-to-kill-agile/
======
bananas
I found that no methodology works as well as getting the right people in and
let them organise themselves. If you have the wrong people, it doesn't matter
what methodology or process you bring in, you're screwed.

On that basis, methodology isn't that relevant.

I just watched a company apply SCRUM to apparently solve process problems and
it just made things worse because the staff aren't disciplined or interested
in what they do.

That's after five years of agile consultants and perpetual change.

If you want a manifesto with real values:

1\. Fix shit when it goes wrong right away.

2\. Tell people what you are doing.

3\. Write everything down somewhere centrally that everyone can get
to(tickets)

4\. Have a rough vision and make sure people are working towards it. Don't
plan the details too much.

5\. Be opinionated. Someone's got to win an argument.

that's it.

~~~
shadowmint
The _point_ of that article is that you need to be self reflective and open to
change.

I'll post it here again, without any of the other distracting things he said
about verbs and so on. Just take a moment to think about what these steps
actually mean:

    
    
        - Find out where you are
        - Take a small step towards your goal
        - Adjust your understanding based on what you learned
        - Repeat
    

If you want to work as effectively as you can, you should actively change your
process _constantly_ based on reflecting on past performance against your
goals.

...if you don't care, or can't be bothered, well, that's fine too (self
reflection _isn 't_ easy); just realize that your own set of pedantic dogmatic
rules is no better than any other Agile process set.

~~~
chrisconley
Spot on. This has been sort of an obsession of mine lately using the game of
hangman and decision theory to "prove" why this works and how it applies to
software development.

There are so many dogmas out there (Fail fast, MVP, Agile, Lean, etc) which
all boil down to the same thing: Maximizing information gain and minimizing
the cost of failure.

I'm planning on a blog post/email course/talk/something in the next few weeks
but it's not quite ready yet.

~~~
sillysaurus3
_This has been sort of an obsession of mine lately using the game of hangman
and decision theory to "prove" why this works and how it applies to software
development._

Oh come on, you can't tease us like that! You have a duty to satisfy our
curiosity now. :)

How can hangman with decision theory apply to software development?

~~~
chrisconley
Well, I've started on a landing page for an email course. It's pretty rough
around the edges, but I suppose I could take this opportunity to solicit
feedback. ;)

I would also be thrilled to get my first signup. :)

[http://chrisconley.io/delivered/](http://chrisconley.io/delivered/)

------
beat
And today, I read this oldie-but-goodie over at Martin Fowler's blog...

[http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.ht...](http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.html)

In Fowler's terms, the _intent_ of the original Agile Manifesto was
EnablingAttitude, but the _result_ of the term "Agile" in many environments
has been DirectingAttitude. It's a nasty cognitive dissonance - that "Agile"
has in many places become a heavy, clumsy, tool-driven process that gets in
the way of developers rather than helping them work efficiently.

And I'm not saying this in the "just let us hack" mindset either, because I
pretty much despise that sloppy, careless mentality. It doesn't work in
environments larger than a few people, much less genuinely large projects. But
process needs to be scaled to team size, talent, and risk tolerance. A broad-
strokes "Agile" process that restricts competent teams is worse than useless.

~~~
michaelochurch
_And I 'm not saying this in the "just let us hack" mindset either, because I
pretty much despise that sloppy, careless mentality. It doesn't work in
environments larger than a few people, much less genuinely large projects._

There's a surprising low upper limit on the size of a closed-source codebase
before which it becomes a lead weight. Why? Because large projects (beyond
about 6 devs in 2 years) without modularity generate a lot of maintenance
work. (Modular design is to pay that maintenance cost upfront, which most
executives don't like.) Maintenance needs to be done well, but the only thing
that motivates good people to do it (instead of hopping to another team,
changing jobs, or demanding a $500k+ salary) is either (a) caring about the
module as a client, which means they typically aren't more than 25%-time
maintainers because their main project is whatever uses the module, or (b) the
possibility of gaining a national reputation in OSS.

The open-source ecosystem can motivate the kind of work that large codebases
need. (That doesn't mean they never turn to crap. It means that it's not
inexorable.) Corporate codebases don't have that.

Twitter hasn't open-sourced, for one example, Storm because they're nice guys
(not to rag on them; this is one of a million examples I could use). That may
be a factor, but the main reason is that they don't want it to turn to crap,
and the open-source ecosystem is more robust against that than anything in the
closed-source world. If you rely on something but it's not extremely
proprietary, you should probably open source it for its own health.
Proprietary stuff should probably be kept as data, not code.

~~~
beat
That's why software organizations need to be modularized, just like code, so
the small teams can work efficiently. But on the other hand, doing that just
pushes complexity around. Instead of having a team chaos problem, you have an
API and requirements chaos problem.

~~~
bokonist
_But on the other hand, doing that just pushes complexity around._

This. In my experience moving to small teams, service-oriented architecture,
and semi-open allocation, the underlying problems of coordination were not
solved. We had all sorts of issues coordinating API work and being blocked
because one team's API was not performing up to par, but they were not fixing
it because they had competing priorities. What ultimately helped get us moving
again was getting a new engineering lead who had very good overall product
judgement and could bang heads to get people on the same track.

If your app is intrinsically decoupled, then obviously small teams and SOA is
a good idea. But if your app is inherently interconnected and requires
coordination among complex pieces, then you are really choosing your poison
either way.

Ultimately, I think the only proven solution for building high quality,
complex software systems is to have Steve Jobs or another extremely talented
and charismatic BDFL.

------
fsloth
Personally I find that this line "Responding to Change over Following a Plan"
does much more harm than good. It should read "You should have a plan but
should rather be prepared to change it constantly than stick with it
dogmatically".

I would say that when you are within a project team it should emphasize the
agile values but once you are on an organizational level where several project
teams need to co-operate to deliver a product the constraints given to teams
should be formalized over the right hand side, strongly, but in a way that is
ready to take immediate feedback from the realities. Preferably, my dream
system would be formed of strong spec based contracts between teams, enforced
by automatic tools and architects, who work as part of feature teams
implementing features and have the ownership of the spec-framework and can
swiftly change it to respond to changes.

Completely forgoing specs and plans leads to anarchy and headache where the
only two-channel communication with developers is facilitated by broken unit
tests and system-test or (the horror) customer side regressions.

Good software systems are composed through a firmly kept set of as strong
constraints as possible, IMO, and someone needs to own the constraints.

~~~
gns24
I think this hits the most interesting point. Personally I agree with the
article that the best way to develop efficiently is to continually take small
steps in the right direction and reevaluate where you are after each one - you
save a lot of time by not planning things you don't need that way and it's
much easier to maintain focus. But against that, people need estimates for how
long projects will take and how much they will cost, and that demands a plan.

~~~
fsloth
"you save a lot of time by not planning things you don't need that way" Yes,
but on the other hand you will lose time if you do not plan those things ahead
of time that you can plan ahead of time. It's much cheaper to catch ill
defined requirements while planning on paper than once the constraints reach
production and people start implementing features and tests based on them.
Although you cannot plan _everything_ there is always _something_ you can plan
- and should plan. Unless you have a spec or a plan at day 0, you do not have
a documentation platform available when the shit invariably does hit the fan
and you need to do the learning-organization-disco and facilitate a change to
your product because some real world constraints were not known or
acknowledged before hand.

------
planetjones
Well said. A friend of mine is another company are supposedly moving to
"Agile". Their approach is to have whole day meetings to discuss how it will
work! Three months later they're still planning how their Agile, Scrum based
thing will work. The conferences, the consultancies, the big companies, etc.
really have destroyed the essence of the Agile manifesto in many ways.

~~~
mcv
It's not that they've destroyed the essence of the manifesto, it's that the
organization is simply inherently not agile, and incapable of dealing with
agility. This is pretty common for large organizations (thought there are also
a lot where it kind of works). Their real problem isn't so much the
introduction of Scrum, it's changing the very nature and culture of their
organization. They should focus on that first, and then Scrum will follow
naturally.

------
jrochkind1
> _anyone who comes up with something bigger or more complex is just trying to
> sell you something._

I don't think being misled by snake oil salesmen is the only, or even the
primary reason people get misdirected away from true agility toward 'agile'.

There are intrinsic motivations and interests in most human organizations
which lead against actual agility.

A few of these include:

* The need for people in many positions to feel and be able to represent themselves as in control of the process and product;

* the desire to have someone else to blame when something goes wrong;

* the interest in shortcuts and magic bullets, instead of realizing how much work and time things will actually take (including from non-technical stakeholders).

There are social/organizational reasons that make true agility hard,
especially in large organizations, especially in organizations where software
dev/IT is just one component of a larger mission. But that doesn't change that
actual agility is the only way to produce high-quality software efficiently.
And we probably do need people investigating and suggesting how we overcome
these barriers; but indeed, the 'agile' industry has not succeeded in doing
so, they mostly take the easier path of figuring out how to cater to these
barriers while calling it 'agile', instead of how to change organizational
culture and surmount them.

------
willvarfar
Here's my favourite post about Agile:
[http://pindancing.blogspot.com.au/2009/09/let-agile-fad-
flow...](http://pindancing.blogspot.com.au/2009/09/let-agile-fad-flow-by.html)

Very worth reading entirely.

~~~
astrange
Although it's a little off topic, I'm fascinated by how much time 2000s
bloggers spent namedropping all the other bloggers (see paragraph 2).

When someone mentions your name all the time, they're trying to sell you
something, but what did it mean to mention other people's names all the time?
If they're selling the message that they're Spolsky's close personal friend,
it's hardly working.

I guess it lets you steal their page views if you summarize their post…

------
mcv
I understand what he says, but from a grammar perspective, he's wrong. He
complains that Agile, which started out as an adjective, has been turned into
a noun. He wants it to be an adverb instead, so he introduces agility, which
already is a noun. And then he says it's not a noun. (I'm sorry, but I just
couldn't not point that out.)

But other than that, I agree. What should be making our work easier has been
turned into something complex by itself. Though in a sense, maybe that's
unavoidable. Not everybody truly groks agility, so they have to be taught,
which means training and certification. Although personally I think if you
don't innately understand it, you can't learn it in a workshop either. Maybe
you need to discover it through experience, and I know people who never will.

So where does that leave us? Only the people who grok agility should work this
way, and those who don't should stick to something else? What about the
companies who want the hip new buzzword, but also want to have some handle on
the process they're using?

An agile process like Scrum definitely fills a need, but I've also learned
that Scrum in one place can be totally different from Scrum in another place.
Nobody completely follows all the ideas of Scrum, but maybe that's as it
should be: adapt what you do to what you need. And there may be a limit to the
amount of agility some companies can deal with.

~~~
NAFV_P
> _I understand what he says, but from a grammar perspective, he 's wrong. He
> complains that Agile, which started out as an adjective, has been turned
> into a noun. He wants it to be an adverb instead, so he introduces agility,
> which already is a noun. And then he says it's not a noun. (I'm sorry, but I
> just couldn't not point that out.)_

Your knowledge of English programming is excellent, it is a rare and
underrated skill. I can only recall one article on English coding posted on HN
[0]. BTW love the double negative at the end.

[0] [http://antirez.com/news/61](http://antirez.com/news/61)

------
usea
The agile principles are fairly solid, as far as principles go. They're
people-first and they downplay process and planning. You can't blindly follow
a plan, process, or ideal. Think. Communicate. The right thing to do changes
in every situation. You can't follow dogma.

But the idea that we should switch to a new word because the old one has been
abused makes no sense. Why rally behind a word? Brands and labels only serve
to stop people from thinking. They go against the whole idea.

Words become dogma. Hell, even principles become dogma. Trying to distill it
down to something that's easy to digest robs it of its value.

The solution isn't a better dogma. It's people who can think. If you don't
have the right people, no principle will save you.

~~~
Spearchucker
_You can 't blindly follow a plan, process, or ideal_

You can. The question that you might ask is whether the plan is good or not.

 _You can 't follow dogma_

As above. Dogma actually has its uses. The trick is knowing how, where and
when to use it, or someone who is dogmatic. Machiavellian, but its a tool
nonetheless.

Saying we don't need a plan is to thumb our nose at thousands of years of
wisdom. Sun Tzu was not stupid when he suggested choosing a path only once the
objective and environment are understood. Stephen Covey puts the same concept
into modern terms when he suggests beginning with the end in mind.

And that brings us to the disconnect we live in. Developing something using
agile practices does not require a plan. A plan is however required at a level
above the developer to steer development. As you go, you'll find yourself
becoming interested in that plan more and more. It's a natural shift because
the plan reflects the strategy, development is purely tactical. Understanding
the strategy is motivational - it answers the why. Development is all about
the how.

Real value as a developer only comes from experience. An experienced developer
is successful _in spite_ of any methodology, approach or framework, not
because of it. Something else we're really good at blinding ourselves to.

Experience has no price. It amuses me to no end that we as an industry place
higher value on the 20-something hacker than we do on the 50-something
veteran. We're unintentionally letting culture hobble our chances of success.

~~~
usea
You are right on all counts. I should be more considerate with my thoughts and
words. I appreciate your nuance. Thank you.

I would not eschew a plan, but I would alter or abandon it when it's favorable
to do so. I meant only to advocate pragmatism, not anarchy.

------
benjaminwootton
The author is quite defensive about the commercialisation around agile. I
don't think this is warranted.

I'm a developer, but I have described myself as an agile consultant in the
past.

This isn't out of cynically spotting an opportunity to make a buck. Its
because I've spent a lot of time working in agile environments, learning the
pitfalls and how to do it well, and want to share what I really and genuinely
think is a better way to deliver software.

When vendors and consultants start to coallesce around an idea, it usually
means that the idea is a good one that is gaining traction, coming down from
the ivory tower. It's a positive thing and not something to leave the
community that you founded over.

I've heard this argument many times over the years, and it always sticks in
the throat a little. I'm evangelising an idea that I passionately believe in
but am seen to be selling out the community ideals somehow. I walk the same
line on my current venture in the DevOps space.

~~~
SiVal
All of this is quite predictable if you just ask yourself what kind of people
refer to their personal opinion papers as "manifestos".

~~~
ternaryoperator
I understand your point, but in context it's a bit unfair. The manifesto was
issued in 2001, when waterfall was still the default methodology at most
businesses. They were indeed trying to break out of that mindset and felt they
were doing something revolutionary (which, in fact they were).

~~~
RogerL
I worked on big government projects using military standards that more or less
imposed the dreaded 'waterfall'.

What was our mantra? "Design a little, code a little, test a little".

Agile re-invented or popularized various ideas that had been around for a long
time. As always, you adjust for the problem at hand. Royce, the so-called
inventor of waterfall (he presented it as an obviously flawed concept, a straw
man), argued for copious documentation. Documentation makes a lot of sense
when trying to built a jet-liner, and is often a time and money sink if you
are trying to write, say, research code for computer vision.

So, "revolutionary"? I dunno? Certainly many places had taken the deliberately
flawed Royce model as the way to do things, and so there was a big change as
far as that goes. But I can't recall a time where some form of
iterative/evolutionary development method was not known about and practiced,
or where decision making was favored over process.

To make this clearer - the Royce-ers patted themselves on the back, and then
got hopelessly entangled with process. Yourdon came along. Wow, was that a
great process - which everyone got entangled with. Then there was Booch.....
And now, we have Agile. The details vary, to be sure, but the fundamentals
remain the same. Some good ideas for approaching engineering a solution gets
turned into conferences, endless books and training, independent consultants,
certifications, requirements to be certified to win contracts, and on and on.

I'm old.

~~~
ternaryoperator
>"Design a little, code a little, test a little".

That's not waterfall as used in the conventional sense. A key element of
waterfall was/is: "Thus the waterfall model maintains that one should move to
a phase only when its preceding phase is reviewed and verified."[1]

>The details vary, to be sure, but the fundamentals remain the same.

I disagree. Agile is distincly different at a fundamental level from
waterfall. If you walk into a modern shop doing mostly agile with continuous
delivery, you'll find that there is almost no process at all that maps
directly to waterfall. Literally, not a single one: not design, not coding,
not testing, not building, not deploying. They're all fundamentally very
different. Coding is probably the one that comes closest and if the site uses
TDD or pair programming, it will be clear how drastically different even that
is. [1]
[https://en.wikipedia.org/wiki/Waterfall_model](https://en.wikipedia.org/wiki/Waterfall_model)

~~~
emmelaich
People should stop using the term waterfall to describe any real process. It's
only been used to describe a fictitious cartoon of a process, purely for the
sake of their argument.

That wikipedia article is a bit of a mess, but read the article at footnote 7:

    
    
      http://www.idinews.com/waterfall.html
    

"There's no such thing as the Waterfall Approach! (and there never was)"

~~~
jasonwocky
There may have been no _capital-W Waterfall_ approach, but implying that
projects weren't routinely being run in a waterfall-esque, staged-handoff
fashion smacks of revisionism.

I was there. I was on those projects. They existed, and unless everything went
perfectly according to plan, they were messes.

------
neverminder
I never really understood this whole rage about agile and some people
preaching it like a religion. You can't fit everyone in one frame, people are
different. As the matter of fact the better the engineer the more quirks he
will have. Some people like to jog, some like to sprint and rest, but if they
cover the same distance and reach the finish in the same time, who cares what
methodology they use? Even though I probably use quite a few agile ideas I
don't call it agile or anything else, I call it development.

~~~
mironathetin
Good comment, neverminder!

I always understood agile development as a way to organize your team and
yourself in a way that works best for everyone. So don't follow a scheme, even
if it's called agile, but think yourself.

Probably this is, how I WANT to understand it, because I don't like to follow
rules that make me unproductive, even if others may become more productive by
following the same rules.

Who does?

------
lmm
The problem is real but changing the word won't solve it - we'll just repeat
the same cycle all over again.

~~~
thebenedict
Seriously. I like the focus on practical productivity but was surprised by the
conclusion. "Let's all change from saying agile to saying agility" feels like
quibbling over semantics. (Fixed spelling, thanks)

~~~
nardi
semantics*

technically that was a syntax quibble though, so the joke doesn't work as well

------
Ingon
Yeah Agile is used as a way to make money now days. For what other reason
there are Agile consultants, Agile agencies and Agile certification.

I firmly believe that Agile is about doing what makes sense in this team right
now. You let the team to decide on their process, on their way of work and get
away. And for good managers this is enough - you are empowering your team to
succeed.

Recently I had a great success demolishing standups in our team. We clearly
weren't getting enough value from them (I though they were plainly hurting
us), so it was time for change. I had a great resistance from the management
team, but some developers were keen to try a change (some of them were long
enough in the industry to remember the pre-agile days, when we were delivering
software too). So we tried it for some time, everybody loved it, and we
stopped doing it completely.

Now days we all agree that iterative development is the way forward. We should
also think if we can apply the same on a meta level - the team, the process,
the product, the design, the organization. Do small steps, check if you are
going into the right direction, repeat. It may work :)

~~~
hox
What was it about your standups that were hurting your team?

I'm on the fence with daily standup meetings. they definitely can help a team
communicate when there are a large number of external forces at play in a
larger organization and if there are no underlying asynchronous communication
channels available. on the other hand, in a team that communicates regularly
with historical communications available to new team members, they aren't as
useful.

~~~
Ingon
Among the negatives of standups are:

\- Rarely the right information. Every person in the team have different needs
for information. It is even harder to deliver the right amount and on the
right level if your team includes designers, quality engineers,
project/product managers.

\- Rarely at the right time. If your company culture includes flexible hours,
no matter at what time you put the standup somebody will suffer. Most of the
time the team members who come early suffer - they already started work, now
you are forcing them to get out of context and attend a meeting.

\- Sometimes standups are used as a way to force some team members to do what
they have promised (the what I'll do today). But if you are using them in this
way is really counterproductive - you either trust that your peers are doing
their best for the team or you might consider team change (which I understand
is beyond our control sometimes).

\- Failure to communicate (or "the what problems I have/had" part). If your
team members are mature enough and they had a problem during the course of the
day, they shouldn't wait for the next day's standup to let everybody know
about that. The should be proactive and seek resolution as the problem comes
up.

\- Finally the "what I did yesterday" part. This information is commonly used
by the managers, but there are better ways to deliver it. Most of us use some
way of tracking our work. We only need to flow this information to our
managers. It is also a mind shift for them - instead somebody pushing this
information to them, they should be proactive and seek it and pull it. If you
don't know what somebody is working on, then go and ask him. You don't need to
loose the time of the whole team for this.

That being said whether you will use standups or not depends largely on your
team dynamics. In new teams or teams formed largely by junior developers it
makes sense to have standups - its a way to force communication patterns and
certainly can be used as a casual form of a team building. But in my opinion
as the team matures there is less and less need for standups, so at one point
it just becomes a hurdle. And the good thing about being agile (not SCRUM) is
that you can evaluate your process and change it as you (and your team) see it
fit.

~~~
vpeters25
I find it really hard to understand how a quick, 5 minute meeting every day
can hurt a team.

> \- Rarely the right information.

You were doing it wrong: standups are not to give or receive information, just
to inform the team what did you do yesterday, what are you doing to day and
any blockers.

> \- Rarely at the right time.

We schedule them 15 minutes before the first team member goes out for lunch
(10:45 am), this forces a hard deadline.

> \- Failure to communicate.

You should communicate blockers to your SCRUMMASTER immediately, the daily
meeting is to remind him/her the blocker is still there.

> \- Finally the "what I did yesterday" part.... If you don't know what
> somebody is working on, then go and ask him.

This is so wrong in so many ways. The SCRUMMASTER's job is to keep management
off developers back and play interference so they can focus on getting the job
done.

A stakeholder should NEVER be invited to talk directly to developers about
what they are working on. If they want a daily status, they can attend the
daily standup where they cannot talk, just listen. If they have questions, ask
the scrummaster after the meeting.

The daily standup is a tradeoff, as SCRUMMASTER you promise the team they will
not get dragged to any other meeting during the iteration.

~~~
RogerL
That all strikes me as being incredibly rigid for a process called "agile".

------
maxehmookau
Spot on. The word 'Agile', much like 'Big Data' has been misappropriated by
marketers, who don't really understand it, the world over.

~~~
Nursie
'Cloud'

------
xsace
There is some truth in this post.

However I still thank the Agile "industry and business" as it allowed me to
open my eyes as a developer years ago.

Because believe it or not, some of the so called master/consultant are
genuinely caring about the values behind the manifesto, and putting a lot of
efforts into improving everyone practice of software development.

------
beat
Meanwhile, I'm watching helplessly from the sidelines as "DevOps" becomes the
next "Agile", tasting bile in my mouth and wondering when a brilliant concept
for reworking the culture-clash problem between developers and operations got
reduced to a "knows how to use Chef/Puppet" for recruiters.

------
malaporte
Funny how this post made me realize I've often been confronted with people
wanting to implement 'agile' by imposing us to follow strict processes. I'd
never seen it that way, even if the irony is pretty obvious.

------
teamfuture17
You're right that good ideas like eco and also agile follow that growth curve.
After a while the original idea and intention is partly lost on the way to
economy and marketing. I observed that in the organic movement around 2000 as
well. It is never totally lost, the impulse improved reality, but we need new
ideas, new movements to hold spirit, values and ideas high. I don't know what
you think about our impulse wholeheartedmanifesto.org which we started this
February. Let's focus on the doing and on being authentic.. that's what
counts. Thanks for your blog. Christine

------
projectileboy
Dave didn't seem to mind cashing the checks he got for all the "agile" books
his company published. This piece would have been interesting in, say, 2008,
but now he's just riding the wave.

~~~
lucisferre
From what I can see none of his own books are actually about "Agile". In fact
"Agile development with Rails" is probably the only one that used that word in
the title, and I can't really fault him for taking advantage.

Also he wrote some quite good books, 'Pragmatic Thinking and Learning' come to
mind. I don't think your comment is particularly fair, nor does it diminish
the point he is making in any way even if you're right.

~~~
robin2
"Pragmatic Thinking and Learning" was Andy Hunt, but as he and Dave Thomas are
kind of a double act I can see why you'd get mixed up.

As to your point about whether they wrote any books on 'agile' I think it
could be argued either way. More specifically, whether or not "The Pragmatic
Programmer" (the book they made their name with) counts as a book about
'agile' is an interesting question, and one that throws some light on the
wider debate.

Although they sometimes talk about "pragmatic programming" as if it were a
thing, in the same way as XP and Scrum, their approach was more one of giving
a smorgasbord of potentially useful techniques and practices rather than
codifying a tightly defined set of best practices.

~~~
lucisferre
Sorry you're right, I don't know why I thought that was Dave.

------
alphadevx
I once attended a meeting where a manager said "We won't be doing agile, but
we will work with more agility", which basically translated to we won't be
changing our existing process.

Agile to me is real: it has not been diluted as I know exactly how I will
implement an agile process (scrum in my instance). I don't care if others
misuse or misunderstand the term. For me it's concrete.

~~~
mcv
> "We won't be doing agile, but we will work with more agility"

At a previous client, I was sitting next to a really nice poster that
emphasized the difference between "doing agile" and "being agile". You don't
"do" agile. That's simply not a thing. You have to _be_ agile.

Working with more agility is totally fine. But if you do that, it means you
won't be sticking blindly to your existing process, it means you should
consider what you actually need from that process.

------
NAFV_P
> _Of course, this involves a fair amount of thinking, and the basic loop is
> nested fractally inside itself many times as you focus on everything from
> variable naming to long-term delivery, but anyone who comes up with
> something bigger or more complex is just trying to sell you something._

Basically, the process is recursive, but my explanation is more _agile_.

------
rvinay88
I like the comments section in this article. The industry really isn't as bad
as the writer thinks. Also the other comment that the word is bastardized but
the values live on is so true.

Changing the name to agility is only going to make everyone follow suit and
convert that into a marketing buzzword.

------
davidgerard
tl;dr you still can't Taylorise clue, but that'll never stop the Mgt. trying.

~~~
beat
I think that's the quote of the day. :)

------
jayeola
It's become another buzzword. Another phrase for people to throw at each
other.

------
FeloniousHam
Agree generally with the article, my particular views on Agile:

1\. Communication, communication, communication 2\. Short iterations 3\.
Concrete deliverables 4\. Client/customer engagement with deliverables

Everything else is details.

------
0xdeadbeefbabe
Since, agile is dead it's time for the Knights Radiant approach to software:

Life before death, strength before weakness, journey before destination.

------
burkestar
Disagree.

Language is not an immutable thing and is always evolving in its use to
reflect the concepts of the people using it. I think capitalizing Agile as a
noun makes it a "thing" that we can refer to collectively and ultimately helps
us communicate about the concepts that it entails. The unfortunate down-side
is when a popular term is misused due to ignorance and misunderstanding by a
large group of people - which will happen more prevalently as a word becomes
popular.

As someone who has had the pleasure of receiving Scrum coaching from Jeff
Sutherland, I can say that there is a HUGE difference in understanding between
people who spend time to learn it (from a book or coach) and those who muddle
their way through - never taking the time to learn about it more deeply and
put it to practical use (the only way to truly learn is through doing).

I work at a small company and teach an internal course on the principles of
Scrum to our project managers, so I have first-hand exposure here. It's
amazing how really smart people who have heard the terms used for several
years and even claim to have been involved in Scrum teams at past jobs still
have many misconceptions about the core principles and how to practically
apply them when the situation arises. There is definitely a shallow
understanding amongst a good majority of developers and it's exacerbated by
companies that claim to use "Agile" practices yet have only really scratched
the surface. It's immediately clear that many have used "Scrum-but" and really
only do standup meetings as if that will be all that is needed. Actually many
people think Scrum is "that process where you hold standup meetings".

I like Scrum because it brings together not only a way to manage a project,
but more importantly a way to lead a team of people! I think being a servant
leader to the team and providing them the necessary resources to be at their
peak effectiveness is a trait of a good leader. It's actually kind of amazing
all the different ways even very smart people can get "stuck" \- distracted by
a less important task that is shiny and interesting, slog through hours of
debugging to resolve an issue that someone else on the team could have helped
them with, not communicating with other team members that they can't get their
part done unless another has provided them something first. From experience,
just helping people identify these blockers and get the team unstuck has been
a big win.

I think tools absolutely are a big help too. I've used sticky notes on
whiteboards and it's good for small teams that are co-located. It breaks down
for distributed teams. We just started using JIRA and it is surprisingly good
at helping us managing all of our work which would grow unwieldy using more
primitive methods.

I'm not sure how I feel about the agile manifesto. I guess it has its historic
place as a reaction against the poor waterfall practices of the past and paved
the way for new methods to emerge. Besides that, it seems a bit dated and
hasn't served a useful practical purpose for me.

~~~
lucisferre
The problem with Scrum is it is rarely about principles and more about _a_
process. Not that there is anything intrinsically wrong with that, but
generally speaking, there are no one size fits all processes that will work
for (or "fix") every business and team out there.

If it's really working for you and your team, that's great though. But there
really isn't anything magic about Scrum. It's not the silver bullet many of
it's proponents sell it as.

And not that I think this is worth anything, but I _have_ learned it from a
coach, I'm even a "certified Scrum Master (tm)", which again isn't worth
anything, and I worked on a team where everyone was trained in Scrum, using a
coach. It was arguably one of the least "Agile" teams I've worked on.
Additionally, I've attended and even organized "Agile" conferences, both
before and after working with that team.

I agree 100% with Dave.

If you like Scrum I think that's ok, I don't actually think it's a bad
process, but in the hands of a mediocre team it's next to useless. However, in
a lot of ways things like Scrum are anti-agile. Call it "Scrum" if you want
to, but, and you're right, words do have meanings and "Agile" has been co-
opted by these consultants for all the wrong reasons.

~~~
collyw
>The problem with Scrum is it is rarely about principles and more about a
process.

I was thinking this recently about agile. Lots of "agile" followers seem to
advocate a lot of process SCRUM, or "always do TDD".

Does the Agile manifesto not say: "Individuals and interactions over processes
and tools".

Basically these people are doing the opposite.

~~~
lucisferre
I wholly agree. Which is what I find so confusing about Agile "methodologies"
and their ardent supporters. I'm not knocking the methodology (well I probably
am) rather that they have little, if anything, to do with agile in the
original sense.

------
caboteria
Be wary of any methodology whose name begins with an upper-case letter.

------
rip747
is it me or when an article is titled: "[something] is dead, long live
[something]", you immediately want to flag it out of existence? seriously,
comes up with a better title.

------
jrochkind1
Yes. Thanks for writing this Dave Thomas.

------
michaelochurch
So much of "Agile" is an attempt to "patch" the top-down, closed-allocation
organization that is simply incapable of hitting technical high notes no
matter how much it spends or how many people it hires.

Since organizations are tough to change and all dysfunctions have champions
(some deeply hidden) the "Agile" ends up having to make smaller and smaller
motions while its desire for control, as the velocity in an irrotational
vortex, gets stronger. Then it devolves into micromanagement, as discussed
here: [http://www.mountaingoatsoftware.com/blog/ssssh....agile-
is-a...](http://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-
micromanaging)

The reality is that the future just has no use for closed-allocation tech
companies. Every tech company needs to decide either to play for real and try
to excel (open allocation, highly selective hiring) or GTFO and do something
else.

Scrum is a _form_ ational hack, but closed allocation is a _found_ ational
problem and, if technical excellence is needed, a show-stopper.

~~~
Nursie
I mostly agree, apart from the no future part.

There are plenty of companies putting out bad software, slowly but profitably.
They occupy various niches where the people doing the selective hiring or
being hired selectively just aren't interested in playing. Sure, they could be
out-competed by an agile, well-staffed, disruptive new competitor. They could
be, but they probably won't be.

