The Agile Haka

In ye olde days, software development used to be something hacked together by a lone programmer.  We all know the geeky stereotype ...

Today though software is more complex, and it takes more than just one person to deliver solutions.  The lone wolf programmer is a thing of the past, we've got teams!

Here are 10 ways that the Agile team of analysts, developers and testers can emulate the success of their sporting heroes …

1  Diversity

In cricket you need good batsmen, good fielders, good bowlers.  Ah but most prized is the all-rounder.  They are a person comfortable with playing in several positions in the team.

In any sport, an ability to play in several positions is a big bonus.  If you only play as a second row in Rugby, and they've got two good second rows, you'll find yourself on the bench as a sub.  If you have a preference for second row, but can do flanking, number 8 or prop - well we might be able to find a place for you.

The same goes with software teams.

If you’re a tester with some background in analysis, you can work with the business analysis on defining stories or requirements that you know you’ll be testing later.  You can help make them more testable.

If you’re a developer turned tester (guilty as charged), you can hold technical discussions with developers over what they’re doing, and be able to contribute some initial ideas for tests, and talk intelligently with them over any defects at a low level “is the program locked in a forever loop”.  Heck if your coding is good enough, you could even help a bit with code reviews.

If you teach developers to think more like testers, then they’ll learn to test their software earlier on, and fix the obvious defects so much earlier.

A team with diverse skills can change roles more rapidly as a project grows and matures.  The lead tester for instance can take a two week trip to Disneyland, but that’s okay, as there’s a developer who wants to have a go at testing for that sprint.

People are afraid that diversity and knowledge sharing makes people replaceable.  And that’s a big fear.  But it makes every member of the team more valuable, interested and engaged.

2  Clear Objectives

This may seem a bit obvious – but in football the objective is to score more goals than you concede.  In cricket it’s to score as many runs as possible, without losing too many wickets, and trying to get the opposition out quickly and with minimum runs lost as possible.

In software development, how often are our objectives so clear?  It’s definitely one of the advantages of the sprint approach to development – rather than a long several month death march of getting all these requirements coded and tested, usually there is a 2 week sprint, during which only a couple of stories and features need to be added.  It’s easier to maintain a constant pace of work.

We’re all guilty on those long project of starting and going “well we’ve got ages to do this” but by the end going “oh my God – never going to be finished in time”.  It’s like being lost in the middle of a marathon race and not really being sure how far you’ve got – it feels like you’ve got 20 miles, you’re sure of that, not long to go now, going to be done and dusted soon.  Then you pass a sign that says “You have run 12 miles” and you just want to give up there and then and cry.

Not that I’ve ever run a marathon.  A 5km is good enough for me – and yes, I’ve felt that way finding that the marker I thought was for 4km was really for 3km.  Yeah that’s a bit pathetic I know (but I was dreadfully ill that day)!

3  The Scoreboard

It helps to be able to keep score as you’re playing your game.  In cricket it helps when fielding to know how many runs the opposition is scoring, and how close they’re getting to your score.  Likewise it helps to measure your progress when you're batting.

I actually finished a Rugby game once where we thought we’d lost 30-34.  But it was in the showers that the referee told us he’d misread his notes, and we’d WON 36-34!

Good scoreboards let everyone know at a glance where we’re at – yes, even in cricket where people claim to not understand the rules.  A Kanban board is the perfect scoreboard for the Agile team – at a glance the position of the project is clear for all to see.  What’s been achieved, what’s left to achieve, how long you’ve got to do it.

4  Trust and Respect

You’ve got to trust the people in your team.  In Rugby you need to be able to trust in the ability of the person you pass the ball to, to know if you go to ground, someone is going to secure the ball from you.

Every member needs to feel respected and be able to show respect to the rest of the team.  I consider the way to do this simple – “do unto others” – treat everyone as you expect to be treated yourself.  As an ex-developer, when I as a tester go to someone to say I think I’ve found a defect with their code I always ask myself “how would I want to be told my software has a bug in it” and do that.

I used to also be a bit guilty of when I was a team leader of delegating only the simpler work to the other members of my team.  I thought at the time I was saving them from “the hard stuff”, not over-taxing them and a slight fear of dissent if I did.  But really I was showing a lack of trust in their abilities, and even worse, leaving them with the boring work and perhaps taking the “glory work” for myself  – I’ve learned from that.

5  Skill Balance

Every sport contains a mixture of offensive and defensive gameplay.  Offensive players earn the team points, defensive players prevent the team from losing them.

An offensive heavy team will score many points, but concede almost as much.  They will win often and fail often.

A defensive heavy team will fail to score many points, but will concede few either.  They will win a few, and lose a few, but more often draw.

Only a team with balance of offence and defence will succeed often.  In the world of software, obviously your developers are the strikers who win the goals, and your testers prevent own-goals.  With the analysts pretty in mid-field, feeding the developers for victory, but helping defend a bit with the testers.

[Have to admit this one is very much a Sun Tsu’s Art of War rip off]

6  Cheerleaders

Okay maybe not pom-poms and miniskirts.  But it’s important to feel supported and cheered on in your actions on field.  Rather than jeered at by other staff and management.

7  Decisiveness

In cricket every time a batsman goes out he has a quick chat with the other batsman.  They agree a pattern that who will make what decisions on running or staying safe – usually one person will decide if the ball goes behind the batsman receiving, the other if it’s in front.

Sometimes they’ll agree on calls.  I don’t personally like “Go” and “No” as they’re too similar sounding.  I prefer “Run” and “No”.

Decisions to run or not have to be made quickly.  Too long and you’re losing valuable time.  Once made you really need to stick with them.

I once had a disastrous cricket partnership where my partner went “run”, and indeed I ran.  But he was hesitant, and went “no – go back”!  Alas I was most of the way there, and by the time I ran back, I’d been got out.  Being got out happens in cricket, but it was a particularly frustrating way for it to occur.

My partner did apologise afterwards, but it was his hesitancy that cost us (he probably had enough time, but he stopped mid-run).  But I think he learned a valuable lesson on decisiveness, as did I.

Hesitancy can be dangerous in software development – it’s too stop-start.  That doesn’t mean it’s a good idea to throw caution to the wind.

8  Communication

In Rugby when the ball carrier is under attack, he usually has support nearby from his own team.  “I’m here” or “Geordie wants!”  lets the ball carrier know someone is ready to receive the ball from him.  He doesn’t need to take his eyes off the opposition; he knows support is behind and to the side.

Good communication in a team lets our teammates know we’re nearby and we’re ready to support and give them options.

As my old Rugby coach warned us – bad communication means we’re not acting as a team, we’re just acting as a group of individuals who all think we can win the whole game by ourselves.  And negative communication is worse of all – temper and annoyance propagates from one team member to the whole team, and before you know it the team is turning in on itself.  A team that turns on itself will always lose.

The other thing he warned us was that 90% of communication was non-verbal.  Our attitude, the way we carry ourselves under pressure can be infectious to the rest of the team, for good or ill.

9  Post Match Analysis & Training

You’ve just lost a big match!  Take it from me, the bar after the game is the wrong place to discuss it.  It turns into a post-mortem, and even perhaps an exercise in blame management.

To me a post-mortems aren’t retrospectives.  In my experience they can be too much dwelling on failure and blame, and not enough focus on a more positive message of what to build on.

Bad matches can be soul destroying – but they happen – I’ve had 3 so far where I’ve come away going “I’m never playing rugby again”.

The best time to go over matches it is at your next training session, to work out what went wrong, to come up with ways to prevent it happening again, and start training and trying out new things to overcome that shortcoming.

Training sessions after a big loss where you’ve worked on your weakness, almost drilled until you’ve comfortable and got an element right can lift moral, and everyone walks away more confident.  They can be wonderful interactive chances for people to say “look when he’s doing this, I’m not really sure what I should be doing”.

But retrospectives don’t just have to be about the negative.  Sometimes in a game something goes really well, and you want as a team to build on it and see where you can take it with more training.

A freedom to fail is important in Agile, as building on failure allows a team to lead into success.  Yeah that sounds contrary to everything you’ve ever heard doesn’t it?  Like building a good house on rotten foundations.

But a training session is in sport an opportunity to try things out, and get them wrong with little impact.  I’d declare them “safe” except I suffered my worst injury in training rather than at a match.  But you do training to make the mistakes there, to learn from them, and make the big changes there so that come the big matches you’re going into them certain you’re going to perform well.

10  Commitment

It’s good to have a healthy sense of scepticism.  Especially as a tester where it’s your job to not accept everything at face value, and prove software behaviour almost from first principles.

But too much skepticism can become a negative cancer within teams.  You’ve got to have commitment.  Change may come into a team, and you might have concerns about it.  And if you do, you really should voice concerns about it, and hopefully those concerns will be allayed or compromise reached.

Teams are groups of people - it would be abnormal for any group to feel identically about any given situation. There's going to be diversity of opinion, and not everyone is going to be 100% happy all the time

But as a team member you need to be committed to giving your all to making a success.  It’s the kind of professionalism that’s expected of sports heroes and software heroes alike.

Of course that said commitment is a two way street – employees need to show commitment to the project, and the project needs to be committed to it’s employees.  Beware when it feels like it only flows one way!


But at the end of the day the most important thing is an individual commitment to want to make the team work, and to want to succeed.  Without that, all the other points above just fall apart.