For quite some time I've been working on a post to commemorate the 10th
anniversary of the Agile Manifesto. I suppose that, as the 11th
anniversary has now passed, it would be rather silly to continue to
celebrate the 10th! :)
Part of my foot-dragging has been the feeling that I wasn't adding
anything to the discussion about a decade of Agile. Every now and then
something would spark my interest and I might add a bit to the post I
had started, but it just wasn't resonating with me.
In January, though, Dave Nicolette returned from a blogging hiatus with the post “Agile” considered harmful
His thoughts about "post-chasm Agile" really shook loose a lot of
feelings I've had for the past number of years. More recently, I met up
with a couple of friends in the Bay Area for dinner. They too were
disenchanted with what the Agile world has become. They used the term
"ashamed" to describe how they felt about being associated with Agile,
and those conversations triggered my Occupy Agile
blog post. In that post I also talked about yet another discussion in
2008 with Scott Ambler about the state of the Agile movement.
All of us shared this common feeling that the Agile world as it is today
in 2012 is not what we learned years ago. Each year it seems that
there are calls to rewrite the Agile Manifesto, a new certification
scheme pops out of the ground, more automated tools are created and
marketed to simplify collaboration, and we move further and further away
from the values and principles that defined the movement in 2001. The
shame wasn't a reflection of the original purpose of Agile being wrong,
but of how the people in the community have behaved.
I agree that the Agile Manifesto was a statement, a line in the sand,
made in the context of the world of software development of the 1990's
up to the dot-com implosion. It specifically focused on the issues
within software development, which is one of the key problems cited by
people people who believe a new Manifesto is needed.
Many of those people feel that we have solved the software development
problems and now the issues are elsewhere. Scott Ambler wrote about
this in Reworking the Agile Manifesto
in 2010, Bob Marshall in Agile Coaching is Evil
, and Adam Yuret in Working Software isn't Enough
I agree with all of those posts that there is more to fix than just the
software development process. I also respectfully disagree, especially
with Bob, that we needn't focus on just the software. If I didn't see
as much really crappy code as I do, I would be more open to the
suggestion that we can declare victory in the software practices war.
Of course, I'm not hired to come in and look at how wonderful
everything is, but I would like to be pleasantly surprised just once by
clear, expressive code following Kent Beck's 4 Rules of Simple Design
, integrated continuously with effective and efficient automated checks running constantly.
Actually, I wouldn't be surprised, I would be shocked.
I suppose, in deference to the opinions of people like Scott and Bob, I
should stop looking at the software trees and view the whole
organizational forest in order to address the bigger issues that lead to
developers writing crappy code. I wish, though, that I had confidence
in the belief that making the silly organizational pressures disappear
would magically solve the software problems.
Yes, we need to solve the big problems around matrix management, siloed
business units, focus on efficiency and utilization vs. effectiveness.
I try to do that in practically every engagement I have. I also deal
with developers who really, truly don't believe that they should be
testing their work. They don't believe that integrating more than once a
month is important. I deal with testers who only want the final
product to test. The don't believe that an investment in automated
testing is important. I deal with architects who believe their job is
to design the hell out of everything so that the developers can't screw
In other words, I have to deal with the very problems that the Agile Manifesto set out to solve in 2001.
Are there bigger problems to be solved? Absolutely. Should we focus on
them? Absolutely. Have we truly solved the problems in software
development? In some cases, yes, but in what I would argue is a vast
majority of cases, not by a long shot.
So, to me, over 11 years after it was created the Agile Manifesto's
values and principles still apply. In some situations they are less
important than in 2001, but in many more situations very little has
changed since then. I will certainly work to improve the organizational
environment in which teams exist. I will certainly work to foster much
higher levels of collaboration (and ideally integration) between the
development teams and the business people for whom they are building
systems. I will certainly work to help organizations integrate Lean
thinking into how they approach not just the software being built but
the whole process from "concept to cash".
I will do so, however, while also working to ensure that the way they
build software is as good as what I learned from XP (and later
Industrial XP) over a decade ago.