An Agile Murder Mystery

It's been a busy few months, and I really want to put something on the blog, but have been incredibly busy.  So I've stolen the following article from my book the Software Minefield.

This was a Cluedo-based activity I was hoping to do at the Wellington Agile 2012 conference.  Sadly it didn't make it, so it ended up getting written as an article instead (I'm never going to waste a good idea).

Around Wellington and Twitter I've seen and heard through friends about a lot of Agile projects which haven't quite worked.  As I gathered stories, I noticed a few familiar characters coming out time and again.  Heck, in the early days it turns out I was one of the usual suspects!  Enjoy ...

It was supposed to be a weekend company retreat to discuss our recent Agile implementation, hold a retrospective and look to the future. However early Sunday morning we were woken up by Scotland Yard's finest to be informed that Dr Black, our Agile coach had been found dead, murdered beneath their Kanban board.

So there I found myself in the drawing room, here together with a group of the usual suspects, and found myself wondering, "which one of you killed the Agile process?".

---

Mrs Peacock, the suspicious Product Owner?
It's easy to succeed if you don't aim high enough?

Although originally each Agile sprint had delivered as promised, she was beginning to suspect the success was coming too easily, and maybe this was because people weren't working hard enough.

She was pushing hard to double what was delivered in each sprint because she wanted more business value, and was annoyed when they failed to deliver.

---

Colonel Mustard, the resistant Project Manager?
All this Agile is mumbo jumbo, stick to what works ...?

Resistant to the Agile move, Colonel Mustard looked upon Agile practices such as stand-up meetings as if they were a form of voodoo. Thus to make sure the team did not miss anything he had them follow old Waterfall processes together with Agile ones to reduce the risks?.

---

Reverend Green, the evangelistic Architect?
As my good book says, the problem with this project ... it's just not Agile enough?

Reverend Green had been away on some Agile learning courses, and carried around several books on Agile. He was enthusiastic to learn that the team was being turned into an Agile project. However he argued constantly with the Agile Coach complaining the transformation process was too slow and that it just wasn't Agile enough according to his theory books.

---

Miss Scarlett, the cynical Business Analyst?
This is just another company fad ... it'll be abandoned soon

Although not hostile to Agile, Miss Scarlett saw Agile as another company attempt to jump on a bandwagon. Although she followed process, she never got involved fully and never saw the value.

---

Professor Plum, the anti-social Developer?
The great thing about Agile - no more documentation. I can just get on with developing all day.

Professor Plum was originally keen on the idea of Agile feeling it would involve no more documentation, and full days of coding. However he was less than happy to find that he would still have to interact with the rest of the team during stand-ups, which he saw as another drain on his time. He just wanted to be left alone to code.

---

Mrs White, the fearful Tester?
We had a process before Agile where we got products out the door eventually. So why change it?

Mrs White had a number of years on the project, and was used to the rigid software development processes that had been around as long as her, and which she had mastered. She was fearful that a change in the organization to Agile would render her skills and job obsolete.

---

Although people are increasingly getting exposure to Agile projects, not all of it is good news. A lot of Agile projects don't stay Agile, and revert to either V-model or Waterfall. Taking part in local Agile Wellington events I've networked with a good deal of people from the IT industry and heard their war stories of Agile transformation gone bad.

There are a number of obstacles for an Agile team, - without an Agile coach, there may just not be enough experience in the team to make the transition - there may be issues with co-location and delivery of software which means Agile is just not feasible

And sometimes Agile just won't work, because whether consciously or not, it's sabotaged from inside.
From our list of suspects, do you have a favourite for the murderer? Most people will have someone there they'd like to accuse. The list of suspects is drawn from commonly encountered personality types on Agile projects.

Who is the murderer? They all are!

• Mrs Peacock rather than being pleased that she was getting working software overloaded the sprints, but then turned it into an issue when everything was not delivered.
• Colonel Mustard by keeping both Agile and Waterfall practices to "play safe" overloaded his staff with tasks to reduce their efficiency.
• Reverend Green wanted the kind of Agile process he'd read in theory books, and so failed to see that the project had real needs not directly covered in theory. And so was needed to be pragmatic in it's application.
• Miss Scarlett never got into the spirit of Agile. She didn't want to talk much in stand ups, so people never got much information from her of any use.
• Professor Plum looked at only the things in Agile he liked, and was upset he couldn't pick-and-choose what bits of Agile he played along with for his own convenience.
• Mrs White used every opportunity to say how the old system was better, and like Colonel Mustard continued to use the old ways of doing things.

Of course maybe some of this is slightly unfair. And Scotland Yard have another theory. Dr Black committed suicide.

Why? Because Dr Black was in a position to address all the team's divergent needs, but didn't.

• Mrs Peacock should have been encouraged to increase what they were aiming to achieve during each sprint. It becomes an issue though when it becomes dramatic when everything from the forecast was not delivered. To me, this is a key litmus test for a team who think they're Agile, ask them "tell me about a time you failed to deliver everything in a sprint". If they give a tale of woe, it's worth exploring. The thing is no-one knows the capacity for an Agile team, and the measures we use to size up stories is imperfect. This need to be appreciated, as well as the fact that if something is not delivered this sprint, it should be next sprint. At least we know now about problems around it.
• Colonel Mustard should have been persuaded to drop his Waterfall use of project measures, and educated on how the Agile ways of measuring the project worked. Although Dr Black should have attempted to mentor the Colonel, in the end they might have had to force "just do it my way" for a few sprints. This would have pushed the Colonel out of his comfort zone, but after a few sprints he would hopefully have learned that the sky didn't fall in, and get comfortable with the Agile way of doing things.
• Reverend Green should have been mentored on the reason some Agile processes were incorporated, but some processes stayed the same.
• Miss Scarlett, Professor Plum, Mrs White each needed training and mentoring on the Agile process. They needed to be encouraged to participate, to understand the values and avoid choosing out only the bits they liked. Sometimes like the Colonel they might have to be forced to "just do it" Dr Black's way. However Dr Black should never have stopped trying to get the message of the value of the Agile way, so that people would become educated and accept the values in the Agile methods.

Maybe then, a lot of needless bloodshed would have been prevented.
CASE CLOSED

Learning to test with Big Trak

In the 1980s, Big Trak was the toy you wanted if you were a boy.

It was amazing - a motorised truck which you controlled by entering a program into the keyboard (see below).  You could choose to move it forward, backwards, turn left, turn right and then enter a number which would allow it to turn/move a specified distance.  See a dated demo here!

Hence,

• UP 2
• LEFT 15
• UP 2
• LEFT 15
• UP 2
• LEFT 15
• UP 2
• LEFT 15

would cause it to move around anti-clockwise in a box pattern.

You could do up to about 100 instructions, meaning you could do some really fancy patterns.

The toy line has recently been revamped for the 21st Century as Big Trak Jr, and you can buy them reasonably cheaply from places such as here.  [Yes I got one myself]

It's something I'd recommend anyone who's passionate about testing to get their hands on, because it's a very tactile learning tool for teams.  Samantha Laing (@samlaing) was asking for Agile workshop ideas for testing, and I think this really gets the point across.

If you've got hold of a couple, set up an assault course to navigate around, and ask a couple of teams to develop a program to get the Big Trak around the various obstacles.  More than likely you'll see at first someone blundering on, trying to do a big program all in one.  See how that works for them ...

Big Trak really parallels what we do in software.  You can give it to a developer, and it makes a lot of very nice and pleasant beeping noises, so you can assume it's making progress.  But you test it by hitting the GO button, to execute the problem, and more often than not you've missed something and it throws itself off the table or runs into the skirting board.

To make the Big Trak do something cool, you have to balance the programming you're doing with the execution (testing) using the GO button.  There is even a TEST button to allow you to test out a single line command.

We way to build up a complex program to get around an assault course is to do as with software, program a bit at a time, and test.  Then add a little bit more.  For instance the team might have to trial-and-error the distance to the first obstacle before turning etc.

Programming with the Big Trak it soon becomes obvious that if you are going to play with this toy, you're going to have to keep using the GO or TEST buttons.  The program really has no meaning until you hit the GO button.

Likewise in development, what we're working on has no meaning until we've attempted to execute it.  Testing our software, playing with it, is a vital step to seeing if we're doing things right, or sending our Big Trak over a cliff ...

The Death Star wasn't Agile - the video ...

Yep - why read, when you can just watch!

Are you not entertained?  

The Death Star wasn't Agile – and other Imperial failings …

This started as a joke I put up on Twitter, but the more I thought about it, the more I feel how we could learn a bit from the Empire, by looking at how they run projects, and how not to fail like that in our teams.

1)  Death Star Vs Alderaan

The Death Star is a planet killing ultimate weapon.  Woot!  And part way through Star Wars IV A New Hope, it appears above Alderaan, and blows it to smithereens.  

This Governor Tarkin claims this is the first demonstration of it's firepower.

Now if this was a truly Agile project, then in the first part of the film, the Death Star would have gone around blowing up an asteroid first, then a small moon, before moving onto Alderaan, to effectively show the capability of it's destructiveness in a couple of iterations.

Okay so the Death Star worked - but what if it hadn't?  Instead of feared throughout the galaxy it'd have been on the "and finally" section of the news.


2)  Getting the Death Star working

There is a gap of 20 years between the films Revenge of the Sith and A New Hope.  In A New Hope it's said that the Death Star is only just operational.

And yet in Revenge of the Sith, the Death Star is shown under construction – that means they took 20 years to finish it and work the bugs out of the system!

Ever heard of deadlines?  C'mon we've got a galaxy to run here!

3)  Blowing Up The Death Star

The plans of the Death Star appear in the second film, Attack of the Clones.  In A New Hope, the Rebel Alliance get a hold of them, find a weakness (the exhaust vent leading to the main reactor) and attack it.

Yes – it took over 20 years to get the Death Star working, but they kept to the original plans – they never went “wait a moment ...” and thought of a better way?

4)  Stand-Up Meetings

The Empire never got the hang of stand up meetings.  Look at this – only Darth Vader is getting into the spirit of it.  And even then he ends up force-choking another member.  Which is a novel way to keep meetings from over-runing.

5)  Armour Plated Solutions

In the Battle of Hoth the AT-AT walkers won victory over the Rebels landspeeders.  Ish.

The AT-ATs were better armed and armoured.  They won, they took out the bases reactor and shields.

But they were also very slow.  By the time they got to the reactor, the Empire had given their competition the Rebel Alliance enough time to get ahead of them and move on to a new base.

Had the Empire used landspeeders themselves, they could have quickly taken out the reactor, and wiped out the Rebels there and then.

6)  Embracing Failure

No-one in the Empire really learns from failure – as they often end up being force-choked to death.

This is particularly bad as sometimes the one to blame for Luke Skywalker getting away is Darth Vader himself.  Poor management.

7)  Hoping the Little Problems go away

On Endor, the Empire was plagued by little fury pests.  Rather than deal with them decisively, the stormtroopers just hoped they'd go away and not bother them.

In the end those pesky Ewoks ended up ganging up and becoming a giant problem which brought down the Empire.

When you can, exterminate those Gremlins before they gang up on you!

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.