Is this agile?

The picture below has been going viral around the internet the last few months.

It's of course easy to giggle at this, then come into work and go without a shade of irony "oh yes ... the reason we're not going to get this story finished because we're not going to get the analysis/development/testing tasks done on time".

Thinking back to last week's post, it's important to remember that everyone (as above) is in the same boat.  Everyone drowns together.

If your agile boat is running a little low in the water, and the leak is not your end, you need to be asking everyone in the boat, "how can I help?".

Taking tasks from the board ...

I've been doing an excellent bootcamp with my personal trainer the last month.  Called "Dan's playground", he's been training us in a series of exercises, with things getting interesting this last couple of weeks.

We've been given a board of tasks to complete as a team ...

We have to complete all these activities to a number of repetitions (which can be shared amongst us as we see fit).  The only constraint is we have a fixed time to finish it - typically 40 minutes, but it's being reduced to 30 minutes recently.  We get 2 minutes as a team to plan, and then we have to get down to it.

I'll ask this now ... DOES ANY OF THIS SOUND FAMILIAR?  [Hint: agile]

Our group has a diverse level of fitness levels and body types.  With my scrum training (and I mean rugby scrum here), I have no issues doing the bench pushes (see below) ...

But as for hanging from the monkey bars for 180 seconds, no thanks.

Here's how we typically do it.  We ask people in the team "what do you feel most comfortable / really want to do?".  And start from there.  People go away, do as many as they can, and come back to see what's left.

Inevitably there's some areas which none of us are really too keen on, and it ends with us all working together at the end to get it done, but we do get through it.  It's also important to me that I don't monopolise the bench pushes, and encourage others to "have a go", because they might really love it when they try it.

But most of all, with this approach we get the job done.  There are some things we really know we can do, and some things which are either a bit unpleasant, or else stretch us.  And that's okay as well.

What's interesting is how much this overlaps with what we explored recently in the Kiwi Workshop on Sofware Testing, exploring testing roles.  Two of the experience reports talked on stepping outside of the testing role when needed, and how important it was for the whole team to step outisde of their role once in a while to "get shit done".

In the gym exercise, it would be very easy to define ourselves by roles,

• "I'm a strong man, so I only do bench pushes"
• "I'm a gymnast, so I only do monkey bar work and floor exercises"
• "I'm a runner, so I only do running stuff"

With such an attitude, we'd fail every one of our challenges.  Instead as an agile team, we need to define ourselves by the activities we have on either our sprint board (if we're agile) or our personal trainers activity board (if we're doing a gym session).

We need to focus on "what needs to be done" and "what can I do".

As I talked in the previous blog on Storming-Norming-Forming-Performing, there's something fascinating about looking at how we make decisions and evolve as groups.  I often feel the even two-week sprints aren't rapid enough for learning.

Earlier this year, a project I was working on arranged a series of bootcamps, and it really helped to connect together everyone who attended - it was all about working together.  Without doubt, if you're starting a new agile team, it's well worth engaging the services of a local personal trainer, and have a couple of compulsory exercises to help the team work out how they approach activities and work together to a common goal.

Tales about team building ..

I’ve recently watched and was inspired by something on Netflix.  I’m not going to tell you the title, but see if you can guess it from the description below …

• The lead character is a bit of a wash out
• They are introduced to a group, and time is ticking down to a big event
• At first no-one gets on particularly well.  They try to prepare for the big event, but it doesn’t go well.  They bicker a lot.
• Almost when all hope is lost, there is a bit of a breakthrough.  There is a sign of promise, and it bonds everyone together.  The lead character finds themselves stepping up, and suddenly it looks achievable.
• Just on the eve of the big event, something goes wrong, and it feels like it’s all going to unravel.
• But when it matters, everyone knows what’s expected of them, steps up as a team, and everything goes off well.

Does that plot sound more than a little familiar?  I’d love to know what program came to mind for you, but I’m actually talking about a Danish TV show called Hjørdis, where they’re putting on a big, anti-bullying show at school.

But this plot has been used a lot in films like The Mighty Ducks, Cool Runnings, Dodgeball to name a few.  It’s what Carl Jung called an archetype.  It’s a kind of tale we find we like to use a lot in storytelling, especially for the genre of sports or "let's put on a show".

Since watching Hjørdis, I've found myself wondering why we like to tap into this kind of story so much.  Is it because it’s just good drama?  Is it because we just love the underdogs who come out on top?

I think far deeper, it’s that although we might like to think a bit of the Star Trek Enterprise model, of a crew all being “the best of the best”, and being able to take on everything the Universe throws at it (from rogue self-aware technology, alien invasion schemes, God-like energy beings, and a profusion of planet-of-the-Nazis), this isn’t the case.  Most successful teams aren’t successful because they have the best people (although ability is a factor), but because of how well they work as a group.

In fact psychologist Bruce Tuckman put together a model for this (and maybe some Hollywood blockbusters should start giving him credit), which is known as Forming-Storming-Norming-Performing.  And it pretty much follows the plot points above.

According to Tuckman, if you put together any group of people, on the way to becoming successful as a group, they will live out the drama of those plot points.

Let’s take the original Star Wars movie as an example, and show those stages.

Forming

Everyone meets up with one another.  Luke finds out about Leia and Obi-Wan, and they pick up transport to their destination through Han Solo.  Right now, they’re a group with just loose affiliations with each other, and no general purpose.

Storming

Quite literally, they’re storming through the Death Star.  They’re shooting a lot of Stormtroopers, but also taking a lot of shots at each other.  They all have widely different goals, but learning to align some of them, with mixed results,

• Luke wants to rescue the princess
• Leia wants to get the secret plans to the Rebellion
• Han wants to lie low, not get caught, but get out of there (also get paid)

Most of all, they’re bickering.  A lot.

Of course, this is also where much of the best dialogue comes from,

• “Wonderful girl. Either I'm going to kill her or I'm beginning to like her.”
• “Look, Your Worshipfulness, let's get one thing straight. I take orders from just one person: me”
• “It's a wonder you're still alive … Will someone get this big walking carpet out of my way?”
• “No reward is worth this.”
• “You came in that thing? You're braver than I thought.”

Norming

They get away from the Death Star, but they’re some TIE fighters in persuit.  Han and Luke get to the guns.  Leia and Chewbacca take the helm.  The droids run damage control.  Everyone slots into place, and they work together, taking down the enemy.

At the end, even Leia gives Chewbacca a celebratory hug!

Performing

Luke flies with a whole lot of other pilots against the Death Star.  His number seems up, when out of the blue, Han Solo flies in to cover his back.  They blow up the Death Star and everyone gets medals.

It’s of course interesting to note that when J. J. Abrams rebooted Star Trek in 2009, he followed a much more Forming-Storming-Norming-Performing plot for his team.


For those of us not writing Hollywood scripts, and just working in software teams, where does that leave us?

When we find ourselves on a team where there’s bickering and tensions are rising, it’s very easy to say “this team is not working”.  But the truth is, it’s a quite normal phase in team evolution.  You need to try and work with the team, coach it, give it time and focus on moving beyond this phase.

For more on dealing with conflict in teams, you might want to revisit my post on the Kobayashi Maru of office relationships.

The Project Manager's Yellow Brick Road ...

I've been thinking a lot about this article this weekend - it was originally written and published for Teatime With Testers in 2011.

It was inspired by getting to work closely with a couple of our Project Managers at Kiwibank, in "getting shit done" mode.  Really centrally it is about leadership - and how good leaders help to nurture and also give space to their team, so they have the freedom to do their best work.  [That's what good Scrum Masters do, don't they?]

This theme was central to many of the talks this week at the Agile NZ, and none summed it up better than the talk by Ian Taylor, who has founded and ran a company on this premise since the 80s ...

You might have read the book.  You more than likely have watched the movie.  But are you living the values?

Once upon a time, there was a software engineer called Dorothy who worked for a small Kansas IT company.  But her career felt too restricting, and she yearned to move to a bigger company.  So when she got the offer to up sticks and move over the rainbow to Oz (or was it Aus?) she uprooted herself and followed her dreams.

It seemed that someone had dropped a house on her predecessor, and Dorothy had to step into her shoes.  Yes they were very nice ruby slippers, and brought with them some considerable power, but with one previous owner (now deceased) they seemed a little cursed.

Dorothy was immediately greeted by a delegation of little people from Oz, who truth be told were glad to see the back of the previous Project Manager, who they felt had mistreated them.  It was all quite exciting, but Dorothy realised she didn't have a team yet.

After meeting with Glinda from HR, she was told to follow the Yellow Brick Road.  This was a golden path set out for projects, and the Wizarding CEO at the end expect delivery of a completed project, or would get almighty angry. The Wizarding CEO lived in a gleaming Emerald City - so called, because it provided all the green to fund projects.  But the path before them was hard set, and Dorothy shouldn't deviate for any reason.

All looked like it was going to be smooth until the Disgruntled Business Owner Elphaba arrived.  She had liked the previous Project Manager, and was more than a little annoyed to find Dorothy in her shoes instead.  She told Dorothy in no uncertain terms to "watch out my pretty".

A little unnerved, Dorothy decided to head down the golden path of project management regardless.  The first person she came across was a lion, who was being terrorised by some flying monkeys who were the Business Owners enforcers.

Dorothy managed to shoo the monkeys away, and the cowardly lion was pleased to see Dorothy.  He explained his tale of woe to Dorothy.  He worked as a Business Analyst, but was too scared by the wicked Business Owner Elphaba  and her enforcers.  His work was never good enough, and he just kept having to make changes to it.

Sometimes he felt the changes being made didn't make any sense, but he was too afraid to say, feeling it better to do what he was told, and hope to please her one day.

Dorothy took pity on him as he started to cry, and told the Cowardly Lion, if he'd do some requirements analysis for her project, she'd help to keep the flying monkeys of his back.  The Cowardly Lion was encouraged by that, and promised he'd follow her.

They went further along the golden path to their objective.  The Cowardly Lion had written a few initial requirements down, and was learning to not take it personally when Dorothy made suggestions.  They were not complete rewrites, but enhancements, making better and better requirements.

But they soon realised requirements were nice, but they really needed something developed now.  They came to a field, to see a scarecrow having the stuffing knocked out of him by more flying monkeys.  Dorothy ran after the monkeys, but there were too many of them.  To her surprise, the Cowardly Lion let out such a fierce roar that they soon scattered.

The Scarecrow was a sorry sight.  They gathered him together as best they could.  He worked as a Developer, but he was always being told by the flying monkeys how stupid he was.  He felt he was too stupid to carry on as a Developer he was sure, and was thinking of giving it up and going into something else.

Dorothy told him that was nonsense.  They needed a Developer to help them, and here he was.  The Scarecrow wasn't sure at first.  He finally agreed to take it on, but only until they found someone more suitable and cleverer.

So they set out again.  This time Dorothy didn't seem to have much to do.  The Cowardly Lion passed the Scarecrow his notes, and talked them through a bit at a time, so the Scarecrow wouldn't get overwhelmed.  Every so often they got to something they weren't sure of, and Dorothy would make a decision on what she thought would be right.  But mostly they could sort it out between them.

The Scarecrow seemed to forget his initial reluctance, and got designing and coding, asking questions of the Lion as he went along.  The code seemed to be coming together, but they couldn't really be sure.  What they needed now was a Tester.

As luck would have it, at this point they came to a metal man, who'd rusted into a statue.  He made a plea, but no-one could work out what for.  It was the Scarecrow who noticed that in the metal man's hand was a piece of paper which read,

Category 1 incident

I have noticed I am starting to rust, and require immediate lubrication, as I'm continually losing motor function as the corrosion continues.

The Scarecrow worked out that maybe the metal man needed oiling. He found a nearby oil can, and together he, the Lion and Dorothy oiled and pulled until the metal man could move again.  He said he was called Tin Man, and he worked as a Tester. Unfortunately he'd not got on well at his last project, and was told he raised too many defects. In fact his coworkers told him he didn't have a heart with some of the things he came to them with. So they'd left him outside to rust. He'd tried raising a defect report to get oiled, but no-one helped.

Dororthy couldn't believe her luck, just as she needed a Tester she found one. But she was concerned - the Lion was only starting to find his courage, and the Scarecrow was only starting to believe in himself. A Tester without a heart could set them back all the way to Munchkinland.

"Look", she told the Tin Man, "we have to get this project as finished as possible before we see the Wizzarding CEO in the Emerald City. I need you to really look for the big things, and try not to make too much fuss over the little ones".

"Oh", said the Tin Man. He was quite taken aback. Usually it was his job to point out all the faults in other peoples work, and he was very good at it. But what Dorothy said made sense to him, the big issues were the important ones, and he'd tackle them first, but list the little ones for later reference.

Even so testing did not go well. The Tin Man asked questions of the Lion, who became afraid and lost his voice. When the Tin Man noticed problems in the Scarecrow's code, the Scarecrow said this was proof that he didn't have a brain, and shouldn't be doing this.

But it did get better - as the Scarecrow worked on the bugs, the software became more robust, and the Tin Man remembered to tell him this, and how good the new builds were. The Scarecrow even started making suggestions to improve the design. The Lion began to realise the Scarecrow and Tin Man were deferring to his judgement and calls about how the requirements should be interpreted and became more confident. And the Tin Man began to realise he was a valued equal member of the team, and felt they were all working together to improve quality.

The wicked Business Owner tried many time to take them off course, to send them in the wrong direction or to send them in circles. But Dorothy managed to keep them on the right path and pour water on their problems.

By the time they reached the Emerald City, their work was done.  The Wizzarding CEO was much impressed, and he told them as much in his teleconference.

The Lion had shown his courage, the Scarecrow his brains and the Tin Man his heart. And it was all down to Dorothy's leadership.




The Wizard of Oz is obviously a classic film. What's interesting is that though Dorothy is the heroine, she of herself doesn't do anything that amazing.  Though she defeats both the witches of the East and the West, it's more by accident.

However in her journey she meets a dysfunctional group of people in the Scarecrow, Tin Man and Lion. But through her mentoring and leadership, they become capable of much greater things. This is a quality of truly great leaders.  And thus they are shoes we should all aim to fill ...