You’ll Never Get Sustainable Progress For Free
Posted by Davy Brion on February 21st, 2010
Ayende recently wrote about how most software development processes ignore the actual building of software. Which reminded me of an excellent post written by James Shore over a year ago, and that i commented on as well. What James (and Ayende) are saying is that if you don’t actually take care of the way you build the software, no process can guarantee that any kind of perceived progress in the beginning can be sustained over the long run. Sustainable progress takes effort, and you’ll never keep it up if you don’t put the proper practices in place to enable it.
The sad (and typical) part is that the methodology which makes everything sound easy and prescribes the least amount of effort required is the one that took off the most. Obviously, i’m talking about Scrum. Scrum makes no mention whatsoever about technical practices that are required to enable sustained progress and Scrum proponents will proudly proclaim that it doesn’t need to since it’s about product development instead of software development. You can easily become a certified Scrum master while you might not know anything about real-world software development. In fact, i’ve seen plenty of people boasting that certification on their resume and their linkedin profiles while they really shouldn’t be involved in any kind of professional software development to begin with.
And since Scrum is simple enough for middle-management (you know who i’m talking about… the ones that are usually not competent enough to promote to upper management) to understand, they jump on it as well and before you know it, they’ll be talking about the Scrum concepts as if they actually knew what they’re talking about. Teams and even entire departments in large corporations are told to be ‘agile’ and follow the Scrum rules and concepts for every new project. And they do. And it works great… for a while. We all know what happens after that.
Then take a look at Extreme Programming (XP). It’s been around for a while now. And it unfortunately doesn’t have a good, catchy name. In fact, its name is probably one of the biggest reasons why it never took off the way Scrum did. XP prescribes a lot more than Scrum, and even details the technical practices that you’ll need to enable sustainable progress. And while you don’t need every single one of them, they all provide major benefits and the more of them that you do use, the better off you’ll be. So what is the problem with XP? I never really understood why so many people jumped on Scrum, and now Lean (until the Toyota recalls that is) but never really got into XP. Well yeah i do understand. XP takes more work and effort to understand and apply. And that, my friends, is the price you’ll have to pay for sustainable progress(*).
*: i’m talking about the actual effort and work, not XP in itself
February 22nd, 2010 at 8:38 am
Scrum is about project management. Just like you would not expect filling deadlines in ms-project to actually get the job done or get you “Sustainable progress”, you need not expect the same thing from Scrum.
Scrum is mearlly a set of tools meant to bubble whatever problems and delays (technological or other) your team that put the iteration in danger, it doesnt tell you to do TDD, pair programming, refactoring or whatever – since it is just out of scope.
The way you should look at it is that XP and Scrum are complementing each other, not contradicting. Scrum handles the people, XP the technology, which leads me to this:
“You can easily become a certified Scrum master while you might not know anything about real-world software development. ”
In an ideal world, that would be an axiom. Scrum master is a problem solver and coordinator, and it’s got nothing to do with technology. In fact, you are probably doing yourself good if someone from HR holds this position. What you are refering to, are team leaders.
February 22nd, 2010 at 8:45 am
“it doesnt tell you to do TDD, pair programming, refactoring or whatever – since it is just out of scope.”
and that’s the whole point… because it’s out of scope, a lot of people who simply jump on Scrum because it’s ‘popular’ don’t really spend enough time on establishing some practices that you _need_ when developing software. Scrum might be a general project management methodology, but i don’t think it’s too far-fetched to claim that we’ve got about 40 years of history in this industry to back up the claim that software project management is _very_ different than any other kind of project management. And as such, it needs to be dealt with differently than other types of projects.
XP is not just about technical practices btw… it covers a lot about handling people, team interactions, etc…
February 22nd, 2010 at 9:21 am
“XP is not just about technical practices btw… it covers a lot about handling people, team interactions, etc…”
While its true that XP touches how teams should interact, it does not describe how to manage people in the traditional way.
From a company point of view, i think that adopting scrum first is a bigger step in the right direction than adopting any development methodology. Even if at first, you are practicing a mini (failing) waterfall. The reason for that, and i’m sure you will agree, is that changing the set of mind of managers is by far harder than changing a developer’s one. That, ofcurse, is true only if the organization is a learning one, and not one that lets failures move it completly off track.
The thing is, Scrum helps up see actual problems that can be addressed, while pure XP does not. For example, you can be the best agile developer in the world, you might practice TDD, can pair program with your dog, unit test with notepad and understand what the hell quicknet is supposed to do
, but if the product manager keeps bumping on you every five minutes with a new requirement, none of those not gonna help you get sustainable progress, and that type of problems are what scrum comes to solve.
By the way, if your organization’s DNA is already tuned to that, I.E. good interactions, product managers knowing their limits, responsible developers, good colaboration etc, there is not point in implementing Scrum. If it ain’t broken, dont fix it.
February 22nd, 2010 at 9:31 am
“While its true that XP touches how teams should interact, it does not describe how to manage people in the traditional way.”
which might not be a bad thing if the traditional way of managing people hasn’t really turned out to be very succesful
“but if the product manager keeps bumping on you every five minutes with a new requirement, none of those not gonna help you get sustainable progress, and that type of problems are what scrum comes to solve.”
XP actually does cover that as well… Kent Beck’s Extreme Programming Explained and James Shore’s The Art Of Agile Development cover this pretty good, but if you don’t have those books near you, you can check out the following link:
http://www.extremeprogramming.org/rules/iterationplanning.html
and particularly the following statement:
“If the iteration has too much then the customer must choose user stories to be put off until a later iteration (snow plowing).”
Scrum might have a better wording for this, but essentially it doesn’t really say anything more on this topic than XP does