Reflecting on The Decline of Agile
Originally published on AgileSoftwareDevelopment.com
Recently James Shore wrote an article called The Decline and Fall of Agile where he talked about how Agile, and Scrum in particular, is failing many companies. The main reason I started writing this series of articles on our team’s experiences was to help myself examine why we’d had such a hard time with Scrum in various ways. In this part of My First Agile Project I’m going to go through Mr. Shore’s article and compare it to our experiences.
In the article, Mr. Shore focuses mostly on the engineering aspects of Scrum, or lack thereof. In our experience, Scrum’s lack of proscriptive engineering processes is hardly the biggest problem. It could be that we haven’t had enough time to run into the walls of difficult-to-manage code that he’s seen but thanks to some of the other problems we’ve had with shifting requirements and the like, we’ve all revisited chunks of our code during the project and we aren’t slowing down because of it. Read on for more on Mr. Shore’s essay and how I see it through the lens of our project. It may be that Agile is declining, but if so it isn’t for the reasons he’s seen.
According to Mr. Shore, our project should be failing due to the fact that we don’t do the recommended XP-style engineering practices like Test First, or pair programming. At least, that’s what I assume he’s talking about since he never mentions which practices we should be doing. But I don’t see that at all. I see our project having trouble because of incomplete control of the backlog and other “project management” centric issues that I’ve talked about many times (see Part 5: Our Top 5 Agile Mistakes).
I won’t go so far as to say our code is a paragon of beauty or anything, but even without coding Test First (indeed, without many unit tests at all in some cases) and working mostly by ourselves we have a good code base. I’ve gone into my coworkers’ code and made changes without spending all day on it and we’ve all taken over things from each other with usually just a minimal knowledge transfer. And since we’ve been working on this project for a year and a half now, we’ve gone back to old code multiple times. Despite the essay basically saying Scrum is deficient because it doesn’t have XP’s engineering practices, this hasn’t been a problem for us.
I’ve always thought one of benefits of Agile was that it wasn’t a bunch of rules you “had” to follow but Mr. Shore doesn’t seem to feel the same way. He disparages the idea of taking Agile as a “Chinese buffet” where you take what you want and leave what you don’t. Unfortunately for our project, we didn’t know about some of the important things in Scrum/Agile but we also left behind things that we didn’t and haven’t needed without looking back. I like that there’s wiggle room in Agile. I like that there’s no checklist of approved procedures and methods for us to follow. In my experience everyone picks and chooses parts of methodologies that work for them, no matter what. Not every piece is going to fit your puzzle so you can’t force it.
If not doing every part of a theoretically perfect “Agile method” means somebody is going to say we aren’t doing Agile, fine. We’ll still call it Agile, as I’ve never seen the problem that some people seem to have with the name. We’re being agile in the dictionary definition so we’ll call it Agile. It works for us, we like it and we’re going to keep with it. We’re also going to work on making it better for us if we can. And if we want to try out pair programming or writing tests first, we’ll do that too and maybe we abandon it. We’re being agile.
This brings me to my final point. Maybe he and I are looking at this from different perspectives but I don’t like the talk about ‘rescuing Scrum’ and rehabilitating the Agile brand. The point of Agile is to help teams. If a team is having problems, the point should be to help them, not to make Agile look good. If parts of Agile or Scrum are helping, great. If something isn’t going to make a team’s life better, it should be left behind. I won’t say anything about the certification parts of the essay beyond saying that if somebody thinks they can take a course and apply methods X, Y, and Z to their project and succeed, they’re deluded. You have to live with it to determine what works and what doesn’t. Then you can keep the parts that work. But if somebody wants to say we’re not Agile because we’re only doing what works for us, they can keep Agile and we’ll keep working.
Thanks for reading. If you have comments on this post, and based on the sea of commentary around the web about it so far I imagine some of you do, please leave them in the comments below. I’m curious what you think. Thanks again and stay tuned next week for more of My First Agile Project.
You should follow me on Twitter here!
|
|
