I am a huge fan of roller derby, which is an assertive sport played on roller skates (see my Roller Derby page for a quick run down of the game).  I play recreationally and have great admiration for those who play competitively.  There are times when I mull about what lessons we can learn in the agile world from roller derby and today I’m thinking about hybrids.

Roller Derby is played on quads, roller skates with a wheel in each corner.  When I was a lass (a very long time ago now) you could only get this style of skate but now-a-days they have been mostly replaced in the public’s hearts by inline skates (or blades).

These two types of skates are very different to use and are very different in their benefits.  Inlines are faster, you can accelerate and maintain a higher speed than on quads.  But quads are more nimble, allowing you to change direction quickly and perform a number of agile moves.  They are very different in many ways, but at the end of the day they are both skates, enabling people to move more quickly than they could without the wheels.

In roller derby you need to change direction quickly, jump, stop, knock others off track and work together with your teammates to physically block other players.  This requires many things, but the agility which comes from a quad skate is essential.  It is actually a little offensive to be asked whether you’ve been inlining last weekend when you’ve actually been playing roller derby and I’m sure it’s similar when people who inline are confused with people who skate on quads.

The strong preference which people have for either quads or inlines and their unwavering belief that their preference is the right one reminds me in many ways of the debates in the software world around agile and waterfall.  You get the agile evangelists who will not hear of waterfall ever being useful and for whom it is unacceptable to even suggest you might ever use a hybrid approach.  Often these people will go further and have a particular favourite agile approach which they tell people should be used in all situations.

I am a great believer in flexibility.  Choosing the right approach for the work and not making the work fit my favoured approach.  There was a question asked recently in a group on Linked In on whether a hybrid between agile and waterfall could work.  In response there were many comments, including the following:

“The ‘hybrid’ thing seems to be a desperate measure by Agile proponents trapped inside a culture that is incapable of new ways of thinking.”

“hybrid systems fail because the only thing they deliver is the undesired negative effects of both systems while providing the benefits of neither”

“its a myth that waterfall and agile can be combined to create a hybrid”

So is a hybrid approach impossible?  Obviously many people believe that it is.  It feels to me that this is purely a belief, almost as if you can believe in either agile or waterfall but it is not socially acceptable to believe in both.  In the same way that you have quad skates and inlines but you can’t combine them.  Or can you?

These hybrid skates combine the inline approach of having each wheel one behind the other and also the quad approach of having two wheels on one side and two on the other.  They are faster than quads (bot not as fast as inlines) and more agile than inlines (but not as agile as quads).  Combining the two has allowed a different combination of factors which will suit certain circumstances.

Are there every any circumstances when combining agile and waterfall would be useful?  I believe there are.  I work in a highly regulated environment.  The regulator will define something which must be done, such as the production of a quarterly report containing certain information.  As ever with written specifications, there will be inconsistencies and undefined scenarios in the regulator’s documentation.  There will need to be conversations between the organisation and the regulator to better understand what is required and to decide the organisation’s approach.  This cannot be done whilst software is being written, it is less likely to be about how fields should be displayed and more likely to be about how the data should be derived.  These conversations can take many months and the requirements can then be documented (in whatever form you prefer, eg a big document or user stories with acceptance criteria).  You could then complete the work in a waterfall manner but in actual fact we know that there are always unexpected changes which occur as the work is being done.  For example, perhaps there are some strange accounts which were imported from a historical system and which don’t have the form of data which the specification assumes all accounts have.  It is therefore necessary to respond to change and have good communications between IT and the business.  This is an ideal situation for big bang requirements followed by an agile way of working allowing us to respond to change.

Hybrid isn’t the way I would choose to work if everything was ordered the way I like it.  I am agile through and through.  However, the world isn’t always ordered the way I think it should be (shocking!) and by choosing the approach to suit the work we get the best result we can.  In the same way I may choose to use a lean approach with regular retrospectives and demos when the work suits it rather than always using Scrum.  It’s all about understanding what each piece gives you and choosing the ones which suit.