What Is Your Problem?

• November 18, 2008• 3 min•

There are five commonly accepted Agile processes in practice today:Scrum, Extreme Programming, Crystal, Unified Process, DSDM.  Often times people who are interested in starting with an Agile process want to know “Which one is best?” or “Which one should you start with?”.  Unfortunately the answer is the classic consultant response: “It depends on what problem you are trying to solve.”

First, a little background on me – I started using XP in 2001 when I worked for the dot.com at the beach.  I was a programmer-turned-XP-Coach after the boss\owner had read Kent Beck’s book Extreme Programming Explained (1st Edition) and asked if we could make it work there.  After my time with the dot.com ended, I used XP to develop a moderately successful, niche commercial software product for print shops with a very low defect count.  So low, we never used a bug tracking tool!  In 2005, I took a Certified ScrumMaster class from Ken Schwaber and have been involved with many Scrum projects since then.  While I do a lot Scrum today, my heart is still with XP – it just speaks to the developer in me more than Scrum does.

Here is my answer to those people who are curious about my opinion on what Agile process new teams should be using:

  • If you are having problems “getting things done”, use Scrum.  The 30-day Sprint coupled with the Sprint Review has a powerful focusing effect on both the business and technical people.  It helps both decide what is minimum feature set they can deliver now, while prioritizing what needs to be done for the future.  The inspect-and-adapt cycle which runs throughout Scrum will direct teams to the places in the enterprise that need improvement.
  • If you are having problems with releasing a quality product or you need to improve the skills of your technical people, use XP.  XP places a clear emphasis on the technical aspect of programming (not so much in the 2nd Edition) and gives you concrete practices to follow.  The central artifact of XP is the code and many of the XP rituals revolve around making the code better – testing, refactoring, continuous integration, coding standards, simple design, pair programming and so on.  If you can stick with XP long enough to get over the learning curve, it is very powerful.

Recently, I attended the SD Best Practices Conference and I was interested to hear Rick Brenner and Nancy Van Schooenderwoert say this about XP and Scrum:

The technical practices of XP give [teams] a sustained productivity increase, while Scrum practices give a quick productivity boost and then level off.

This observation is in alignment with my experience with both processes.  Scrum is much easier to start than XP because, as a colleague of mine likes to say, “Scrum is about the stuff you should be doing already.”  By design, the Scrum framework throws in your face all the nasty things, i.e. gunk or friction, that have accumulated in your organization; the processes, people and artifacts that get in the way of delivering finsihed software in 30 days and challenges you to fix them.  It does not ask people to do too many new things in their day-to-day lives, but it does requires you address what the teams find.  This is why Scrum is VERY hard to do and many people fail with Scrum – the organizational inertia is sometimes too powerful to overcome.

XP does similar job in finding organizational dysfuntion, but inspect-and-adapt is not the central focus.  The focus of XP is quality and demands rigorous discipline and attention to the process.  Since XP is about a whole new way of writing code, working together and communicating, you need to be mature, skilled and disciplined.  If you have team members committed to changing the way they write, test and design their code, XP will soar and you will get the sustained, lasting improvements in quality and productivity.  If you do not, XP quickly devolves into hacking and creates a BIG mess.