This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
You can’t do that, it isn’t Agile!
Have you ever heard that phrase? I confess that I have heard it, and yes, I even caught myself saying it. But how can that be? Isn’t agile development all about making changes and doing what is necessary to create great software?
So where does this come from? Usually it comes from some change that one party wants to make to the process, and another feels the need to resist. This of course is counter to the basic premise behind agile, which is that change can be good.
One of the first agile methodologies to capture the application development community’s imagination was extreme programming. We were all reading the rainbow of books, starting with Kent Beck’s White Album…er book, Extreme Programming Explained. And what was the subtitle? “Embrace Change”!
More often than not, the argument “that isn’t agile” translates to “that isn’t Scrum as I understand it.” As we all know, Scrum has a certain number of prescribed activities. These pretty much boil down to:
- Release planning
- Sprint planning
- Daily scrums
That really is it. Everything else, all of the books and papers and good ideas are there to make these three things happen more easily. So if you see somone add a story to the backlog that doesn’t follow the “As a ___, I can ___, so that____”, don’t panic. If you see one team decide not to estimate tasks, its ok. Do what is best for your team, and remember the goal is working software, not a Scrum merit badge.
Now Extreme Programming has a few more practices that should be followed. Even then, you are well advised to keep the working software goal. The XP practices will help you get there, and I highly recommend using them all. But if you don’t, you may still be agile. You may not necessarily be doing XP, but you may still be agile. More importantly, you will have working software that satisfies your customer’s business need.