Scrum bit my finger... and it really hurts!

This question was raised by Jeff Patton on twitter:

Are we (agile people and sw creators in general) better off with scrum as the default agile process?

This is something I've had on my "to blog about" list for some time... At STARWest in October last year, someone in the audience of one of the Agile talks (I forget which one now) mentioned that they'd adopted Scrum first and if they could do it over, they'd have gone for the XP practices first. This rang true with some of my own experiences.

For those who don't know... Scrum really doesn't give you any guidance on how to build software. It is simply a means of applying adaptive planning and management to projects, replacing older predictive/command-and-control methods of 'project management'. Although it gives you adaptive, iterative planning and management practices, it doesn't give you adaptive software or the ability to develop it iteratively.

XP, on the other hand, gives you adaptive and iterative planning and management practices (which are based on scrum anyway) as well as development practices that guide you towards implementing adaptive software that is practical to develop iteratively.

So, you could say that the technical practices (and associated skills) of XP are how we make our software agile; whilst the planning and management practices of Scrum (& XP) enables the team and the business to leverage that agility.

Teams that first adopt scrum with the expectation of that being an agile panacea get bitten. They eventually get frustrated as they find it hard to get the software to change direction as quickly as their planning process can.

The STARWest-delegate that offered their opinion was coming from a similar experience... They were trying to apply adaptive and iterative planning to software that was being built in a way that was hard to change - exacerbated by it becoming increasingly expensive to test... And it really hurt... My experience has been that such teams tend to spill the testing over into the next sprint (scrum terminology for "iteration") as the amount of testing and debugging exceeds the amount of time in the sprint that they are willing to dedicate to such activities.

My first experience with agile development was with XP, as was my second and third. It wasn't until 5 years after my first agile project that I worked anywhere that had attempted Scrum first. Since then I've worked with several organisations that have gone Scrum-firstand the experience seems to be mostly the same... it really hurts. Sometimes the organisation doesn't even realise that it hurts because for them it hurts less than what they were doing before - but all too often it doesn't give them the agility they're looking for. That doesn't mean Scrum isn't agile... just that the story doesn't end there.

Based on my experience, I'd say if you're working on legacy software (which most people probably are) then I wouldn't adopt scrum as your de-facto agile process... I guarantee that it will hurt! Adopting an iterative process and then trying to fit that to developing software not previously built with 'iterability' in mind is like trying to fit a square peg into a round hole.

Instead, incrementally adopting the development practices (such as those in XP) that make our software easy to change is, in my opinion, the place to start. Eventually you'll get to the point where your software is so easy to iteratively change that using anything other than an adaptive planning process (such as Scrum or the planning aspects of XP) would seem illogical. That to me is the less painful way to become more agile...

Should we adopt scrum as the de-facto practice? Absolutely not! Should we adopt any method as the de-facto agile practice? No... If we did, the industry would stagnate... Should we take (and innovate) from these methods the values, principles and practices that help us continuously get better at a) creating malleable software (such as the practices in XP) and; b) the means to take full-advantage of the malleability of that software (such as Scrum or Kanban)? Yes!

Saying this is one thing... Getting people to even consider making the less fashionable decision of focusing on learning how to soften our software first and learning how to take advantage of that second in the face of the bviral marketing behind scrum is another.

There is a disclaimer associated with my don't go scrum-first opinion. When the promises made by an adaptive planning process are broken by development practices that carry increasing costs with every change - there is the inevitable pain and disappointment of that broken promise. This pain might carry with it a lesson that the organisation needs to learn... The value of the practices and skills required to build easy-to-change software rather than hard-to-change brittle-ware. Sometimes that is the only way we as people learn, by experiencing a little pain. In this regard we don't change much from childhood to adulthood... "Keep your finger out of the baby's mouth... he's teething" - will the toddler listen? Probably not... but he'll learn his lesson when the baby bites his finger and it really hurts... and it still hurts!