Thursday, August 9, 2012

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.


  1. A very nice way to put it — and I've met some of the described characters in projects. (And it's even possible that I've acted like one of them as well, at times).

    However: A 'fearful tester', isn't that a *bit* far fetched? ;-)

    1. They're actually based on a "tester" I did know on a past (legacy) project who would run scripts which had been written years ago, never deviated, never really understood what the value in the script was, just ran what was on the page and ticked/crossed if they passed failed.

      Not surprisingly this tester was terrified of change.

  2. Nicely explained. Here you described the well written article from your in-depth knowledge. Truly impressive and nice information

    Java Training in Chennai Core Java Training in Chennai Core Java Training in Chennai

    Java Online Training Java Online Training JavaEE Training in Chennai Java EE Training in Chennai