Dominic Cronin's weblog
On-line resources for the Agile Tridion Development talk
Links to on-line resources for the Agile Tridion Development talk I gave at the Tridion Developer summit 2014, Amsterdam.
Why Scrum when you can Maul?
I'm currently doing a Scrum project, and I suppose it's not surprising that we occasionally make reference to scrums in the sport of Rugby football. According to Wikipedia, the use of the term in the context of development projects seems to have come from a 1986 article by Takeuchi and Nonaka describing a new approach to manufacturing cars, photocopiers, cameras and the like. Their analogy compares a relay race to a game of rugby, and although the term Scrum is used, it's really incidental to their point, which is that a "holistic" team-based approach can be more useful than the sequential approach which was widely in use.
If you really want to know how Scrum came to mean what it means today in software development, you might follow some of the other links in the history section of the Wikipedia article. Suffice it to say that the use of the word Scrum in this context probably just refers to the concerted approach of a Rugby team rather than to the specifics of what a scrum is in Rugby.
What most Rugby players today would call a scrum is something of a set piece which is used to re-start play after an infringement. The forwards of each team form a well-defined structure, putting their arms around each other and holding on to each other's clothing (binding-on). Three distinct rows of players on each side face their opponents and "engage" with them in a carefully controlled ritual.
When you're creating software in a Scrum team, the idea is that each team-member should be able to dynamically shift their focus as necessary to make sure they are contributing to the most important goal of the team at any given moment. Of course, a Rugby scrum is a great analogy for general team-work and having a concerted goal, but it doesn't really say much about the need for team members to spot when a colleague needs help and come to their assistance. This is far better illustrated by another feature of Rugby - the Maul.
A maul in Rugby takes place when a player wants to move forwards with the ball and is stopped by opposing players. From going forwards, he turns back towards his own supporting players, who bind on and drive the maul forwards. More players can run in from behind the maul, bind on and add their strength to overcoming the obstacle. All this happens without a whistle being blown or play being stopped. A team with the right training and discipline can generate and control a so-called "rolling maul", where a stable formation is maintained while driving forward and gaining sometimes significant territory.
You can see how this works in this training video, and if you're interested a quick search of YouTube would yield many examples of teams putting the technique to use with great effect.
I'm quite sure that Scrum as a brand is very well established, and I'm not proposing that anyone should start up a new software development method called Maul (although if you do, I want the credit!). Even so, the game of Rugby has more metaphors to offer than the simple one of team effort in a common cause. The scrum itself illustrates a formally organised set-piece, with the players fulfilling their specialist roles. In free-flowing play, such as mauling, the team expresses its ability to self-organise and respond to unforeseen conditions. You'll also see the benefits of cross-disciplinary working. When things turn chaotic, the relevant specialist probably isn't where he's most needed, so the players on the spot do whatever's needed. As that happens, the rest of the team are dynamically reorganising so that when the ball comes out, it will be into the hands of the right player.
Of course, you can take this too far. Forthcoming posts: Should the Scrum-master role be re-branded as scrum-half? OK - never mind.
Total quality
Total quality
I used to work in manufacturing industry. I made cookers and fridges, and mechanical excavators, and bits of trains. I was a manufacturing engineer, and I spent my time trying to make it better. Much like now, when I'm a computer programmer (hey, that shit was 15 years ago or something), and every day I'm trying to make it better.
Back then, it was a given that it was impossible to ship a 100% defect-free car (or substitute for car any manufactured item of equivalent complexity). Nowadays, it's a given that you can't ship defect-free software (or at least that it would be prohibitively expensive to do so).
So when you buy a car nowadays, how likely do you think it is that you'll be able to drive it for at least six months without taking it to the garage? Pretty likely eh?
And now to the crux of it - we've come to accept that it's impossible (or commercially infeasible) to produce defect-free software. Fifteen or so years ago, the Japanese motor companies started shipping defect-free cars as a matter of routine. The rest of the world's car manufacturers couldn't hide any more. They had to start doing the same thing.
Software development techniques are at a similar crossroads right now, with test driven development etc. Who will be the first to start routinely delivering 100% defect-free software products?
Who said it couldn't be done?