I think we've all been there. There's that one big present under the Christmas tree wrapped in the fancy paper. Maybe it's just from mom to you, or from the grandparents. Who cares? It's HUGE! You patiently wait through the socks, Pop Rocks and Big League chew combo, and Mad Libs (really? for Christmas?) to tear into that bad boy. Paper flying, hands a blur, you open it and find . . .
Hmm. It's not quite what you pictured. In fact, it looks a little used. It's not that is bad, but. . . Then it hits you. What you really wanted. Yes. What you really wanted when you opened that box was. . .
Let me say that it's not that XP didn't work for us because XP is bad. Far from it. XP meets all the tenets of the Agile manifesto and taught us a lot. If XP is working for you, keep it. If you're used to it then don't move to something new for the sake of moving to something new. Move to something better.
XP didn't work for us because:
- We did not fully embrace the entire XP method. For example, our customers didn't participate in the planning game on a regular basis.
- We had no tools to support the process. Scattered Word docs are not enough to organize, track, and predict the progress of a project.
- We had no escalation point. We had no coaches or mentors who had success working with XP on a regular basis.
Scrum was attractive to us because:
- It was easy to understand. Scrum told us how to run the project, not how to code it. Simple, accessible training was readily available on the web.
- We had tools to support the process. I'll talk about tools in a future post in more detail, but there were both internal and free, 3rd party tools available for executing Scrum.
- We had built-in expertise. Our leaders in management were familiarizing themselves with Lean concepts (primarily for manufacturing, but also for software development). Scrum experts volunteered time to help us ramp up quickly.
If you're in a position where you're debating trying Scrum or XP, I would first mention that part of being Agile is to avoid strictly adhering to a process for the process' sake. I've heard plenty of complaints about tiny aspects of XP and Scrum that could easily be changed. This is a sure sign that the team isn't really Agile with a mindset focused on continuous improvement.
Having said that, I just haven't seen enough success with XP in practice to recommend it. If you have a mix of senior and junior developers and want to up-level your junior developers' skills at the expense of your senior developers' productivity, then definitely pair people up using XP. This could be valuable in a temporary situation where you want the junior developers to take a sustaining/support load off your senior folks' backs. But once your senior people are free I'd then recommend Scrum for everyone involved.
Scrum isn't perfect, by any means, and the first thing you'll need to do is modify the process to fit your team and project. The benefits I've gotten from Scrum (lighter project management load, better predictability) haven't paid off like clockwork every sprint. But when things are clicking, your leadership tasks are light, your developers aren't working overtime, and the release happens smoothly, well, then you know you opened the right present after all.
Next up: Getting Started with Scrum
Technorati tags: Extreme Programming Scrum Agile