Agile in its Second Decade
Join the DZone community and get the full member experience.Join For Free
Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.
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 it up.
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.
Published at DZone with permission of Dave Rooney, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.