The World's First Agile Project … or “We tried fire and it didn't work”

We tried coffee and it didn't work ...

There are two coffee machines at work.

The one on the left is totally automated, you press a button, and it delivers a not-bad (but mediocre) coffee, with synthetic milk.  And believe me the "latte" is no such thing - it's pure evil!

The one on the right though everyone agrees makes nicer coffee, but no-one uses. It's a manual coffee maker. You have to steam, stir and froth your own milk in a jug, then add an expresso shot or two.

Everyone agrees the one on the right makes nicer coffee, but everyone tends to use the one on the left.

Why? Well no-one really knows exactly how to use everything on the machine on the right, and there are no instructions. I actually always use the one on the right, one of only two people to use it. I've found to get good coffee it's kind of trial and error until I've got it “just right”. I've played with some of the buttons, functions and nozzles. And now I've got a working technique, and an alchemist brew to great coffee.

So why is everyone using the one on the left? People I think are afraid of “getting it wrong”, afraid to “play around” and make a few dreadful coffees, occasionally sending the machine into it's messy clean cycle whilst learning how to operate it.

Much as covered in the famous article “we tried baseball and it didn't work” people are so afraid of getting it wrong they're settling for mediocre coffee, or spending a small fortune getting coffee from Starbucks, whilst I enjoy great coffee provided by work!

We tried fire and it didn't work?


This has had me thinking back to our ancestors – the “prehistoric cave man”.

It's a bit of a misconception that prehistoric man is any different to ourselves (genetically we're identical). Many people feel smug that they're more intelligent than them. Certainly we benefit from better education and knowledge, but they were as educated and (in their own way) as skilled as us. In fact “they are us”.

Which brings me to fire. Again we do pre-historic man a huge disservice by saying they “discovered” fire. Do we talk about the “discovery” of the computer, atomic bomb or laser? No we talk about the “invention” of those things as the word "discovery" is indicative more of accident than design.

Okay so more than likely the first man-made creation of fire might have been accidental.  [The same goes for the discovery of penicillin!]  Lets look at it as pre-historic man would have seen it. You have created fire, ooh it's nice and warm, it gives off heat and light You just have to see with children the mesmerising effect it has. There would be a huge desire to touch it. And ouch how that burns!

This is where the modern engineer would say “we tried fire … and it didn't work! Lets agree to not make fire again”.

There's no doubt in my mind the first experiences of prehistoric man with fire would have been incredibly negative. “Oooh pretty … ouch it burns … ouch my hair is on fire”.

We all know the benefits of fire – keeps you warm, gives off light, cooks food (killing bacteria), and most animals have a fear of it.

So fire comes with a lot of benefits, but it's not perfect, it has some side effects as well. But to get to all “the good stuff” you have to get through the immediate “bad stuff”. And sometimes the downsides can feel so intimidating. We talk about man “taming fire”. But what we're really talking about is knowing the risks of fire, and “managing them”.

But forget iPhones and atom bombs – things that go in and out of fashion – fire along with the wheel is arguably the greatest invention of mankind. Without fire we don't manage to migrate to colder areas of the world, we don't learn to cook, we don't learn to cure animal hides, we don't learn metallurgy and smelting, we don't learn to generate power. Fire is the invention which drives all these developments.

Fire isn't something that “just happens” - to be able to control fire we need to learn the skills that go with creating fire and controlling it. What's interesting is these knowledge and skills existed before writing, and when vocabulary were basic. Prehistoric man didn't have colleges and books, yet they had effective ways of passing on skills of fire making, control, hunting to the next generation. And through this environmental culture the skills of fire making have been very effectively from one generation to the next right up to modern times, we've not suddenly “forgotten” how to create fire just because someone's not written it down.


So yes indeed – you could say with some authority that fire was the first Agile project!

The Stand-Up Meeting

Over the last couple of years, I've got to rather love the stand-up meeting and what it represents.

The idea of the meeting is you and a large group on your team/project meet, possibly daily (hence “daily stand-up”), and discuss briefly what you did the day before.

If there are any issues, this is the time to deal with them.

They're usually held around the office (in someones bay), and are a quick, informal spot check on the progress of everyone.  If someone is having issues or stuck, they benefit from the whole group being able to help.

Ideally any reports should be brief, and any issues dealt quickly with.  If issues are more complex, they should be dealt with directly after the meeting usually between a couple of affected people.

The idea of standing up is to keep the meeting brief.  You don't drag out the meeting beyond your endurance to stand up – most people get fidgety past 15 minutes.  The meeting provides a forum for information exchange, keeps everyone focused on what is needed, but doesn't go on so long it becomes an overhead of lost man-hours.

Alas one project I worked with had a very different kind of “daily stand up” - you can see the warning signs of how you “don't do” stand ups here – they were held in a meeting room (uh-oh), everyone sat down (oops) – and the result?  They'd go on for an hour.  Yup about 12% of the working day lost in a stand-up (making it a significant overhead).

That's not good, and overrides the reason of having them.

This is why Agile Jackson says “You do not sit in my stand-up meeting muther-lover!!!”

Keep It Simple (Stupid)

Do we sometimes try to make things overcomplicated for the sake of it?

As I've said, revisiting Michael J. Pont's book on Software Engineering, he starts out that software is complex.  But the only way to work with it, it to break it down and manage it as a number of smaller, simpler components.

If those components are still too complex, then maybe they need to be broken down into even smaller parts.

There is a certain elegance in simplicity.  If you look at Apple products (and I'm not one of Apples biggest fans) I will concede their products do have elegance, and an ease/simplicity to them.  It's no wonder so much of the industry look to them as setting the style of products.

In Agile too, there is a drive by using stories and slices of functionality to try and keep what's being worked on very simple.

But why?  Simple concepts are easier to understand, manage, develop and test.  Simple is good.


But when it comes to communication and documentation?  What then?

I used to have a certain amount of jealousy when I read some other people's work – their writing would feel more professional than mine.  They'd use big words, which I'd often not really understand.  And it would be impressive.

But my style was much more down to earth, and much plainer.  I then did a night course in history, where my tutor explained to the class how a historical papers used to be submitted, and they almost got extra marks for being difficult to read.  But there had been a recent fashion to keep the English much more plain and contemporary, because it made the arguments much easier to follow and made the work so much more accessible.

I know I've worked on projects where I've read huge documents of requirements, and have a “Eureka!” moment when I actually realise what they're actually saying.  That happened on the last project – I was on there first, and I a peer tester was brought in, and made to read the same requirements as me.

At the end of the day he said he'd had trouble with the document, and didn't really understand it.  I managed to sum it up for him in about 2-4 sentences of explanation.

Although I'm not an Agilist, I'm coming to the end of this, and realising how much I'm getting there.  If something can be summed up in a couple of paragraphs of explanation, why not do it that way?  Why develop so much documentation, that it's overly complex and unreadable?

We do as an industry - be it manager, analyst, developer, tester – have a fetish for trying to complicate things, primarily through the fear that simplification will diminish the value of what we do.

Take heed from Apple – keeping things simple but elegant doesn't mean they're not of value …  People value what Apple does because they manage their solutions to keep them simple, and that takes skill and ability.  And as anyone knows any Apple product that looks so simple, does not come cheap ...

Just do it!

It was interesting seeing someone’s comment on Twitter about their developers a couple of weeks ago.  They were all bickering about what would be the best way to implement a solution for their software.

 

Overall this is not a bad thing to try and come up with a plan before getting starting.  Fools rush in and all.  But the bickering was going on, and the clock was ticking.  “Just fucking do it!”, was the exasperated Twitter comment!

 

It reminded me of a really valuable exercise I was put through when I was a graduate at Dolphin Systems.  All us graduates were put on an outward bounds “teambuilding” exercise.

 

In the morning we all had to answer questionnaires and were assigned “personality types”.  The types fell into two basic kinds “leaders” and “soldiers” is the best way to sum it up.  Not surprisingly I was in the leaders – generally all us “leaders” (well we were young grads who thought we knew it all) had a tendency throughout the grad program to be a bit argumentative.

 

Anyway – that afternoon, we were split into two groups for a task.  We had an hour to build a raft.  At the end of the hour come what may we’d be made to put what we had into the water, and we’d have to sail it.  No excuses.

 

I looked around my team, “Wait a minute ... we’re all the leader types”.  

Charlie from Templecombe twigged, “They expect us all to bicker don’t they”.  

James from Rochester summed the feeling of the group, “They’re want us to fail don’t they”.

 

Watching the “soldiers” team get on with it, we all kind of silently fell into place and got busy.  We realised the challenge ahead, we were limited in time, and we had to finish.  We added ideas as we went along, but didn’t argue too much about it.

 

We realised our tendency to fight for things would fail us in this task – which would mean humiliation and wetness.

 

We managed to build our raft.  It went into the water, it supported us, and we won the raft race.  No sinking feeling required.

 

As my exasperated colleague summed it up on Twitter.  When time is running out, and it’s going to hurt if you’re not done, drop the attitude and “Just do it!”.

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.

Making the BIG decisions

Having discussed Challenger, and how the disaster was part customer pressure, and management caving into that pressure.  Its interesting to review my career – thankfully never been put in quite such an awkward position!

However many years back when I worked in RAVEN avionics, I did have to make a risk/safety call.

I was working on testing the software for a new piece of equipment called the D-pod that would be added to the aircraft.  It was going to be delivered in 3 phases.

Phase 1 delivery when released would be put on an aircraft – but never get off the ground.

But phase 2 would involve flight trials – and the test pilots wanted to move it forward.

I should have known I was going to be put on the spot when the Lead Manager spoke to me.  In my entire career he only spoke to me three times!

Did I know of any reason why an aircraft should not fly with the latest software using the D-pod?

So I went over my tests – they'd pretty much all been run.  I went through my defect database and looked at the severity of the defects I'd raised.  Four builds ago there was a high priority defect where the software caused the onboard computer to crash.  But it was a minor crash, which would recover in 8 seconds, and no major systems were involved.  Plus it was fixed now (and I'd signed it off).

The only outstanding defect was if he tried a certain sequence, the software and pod would become out of sequence, and it would need a ground reboot to resynchronise (moderate), and a few button oddities.

So yes, good to go.

It was an anxious decision – I double, triple checked I'd not missed anything.

But it felt very much like I was holding a pilots life in my hand – my Challenger moment.  Of course there were more checks than just me, and had everything gone wrong, test pilots are trained for this, and there's always the last resort of an ejection system.

But still, one of the biggest decisions in my life.

Looking back, and why I don't want to blame people over Challenger too much.  I realise I wanted to please my manager, and pretty much tell him what he wanted to hear.  I don't know if that's such a wise start point sometime.

I do concede how valuable that defect database was for making the “big decisions”, objectively, scientifically.

People often ask me these days if I miss avionics.   I'm slightly glad to be away from the massive complexity and the life-and-death-ness of it, which was a major source of stress to some co-workers!

Safety is critical ...

It was a cold January morning in Florida, 28th January 1986, and there was going to be another routine flight of the Space Shuttle.

NASA had gone to great lengths over the years of the Shuttle program to assure the public that the Shuttle program was synonymous with safety – it was just like riding the bus.

Two minutes into the flight, Challenger exploded, leading to the deaths of all onboard.

At the time much was talked about that “space flight has some risks in it”, and this was an unfortunate act of nature.  It was only years later, after an investigation, that it turned out to be nothing of the sort.

Engineers at Morton Thiokol, who produced the rocket boosters on the craft, had been concerned about the launch conditions.  It had been freezing overnight – unusual conditions for Florida.  Evidence on previous flights showed that the O-rings, an important component that contains the integrity of the boosters, had shown severe wear on previous launches where cold had been a factor.  And this was considerably colder than any previous launch.

Engineers met with their managers, who spoke with their customer NASA about these concerns.  NASA was not happy to have to cancel an important flight.  Previous flights had been losing interest from the public, and this one was a PR stunt in launching a teacher into space.  To cancel it would be a PR gaffe.

NASA as customer, agreed to cancel the launch, and go with Morton Thiokols recommendation.  However it made overtures about how disappointed in Morton Thiokol they were, and how this would affect future business.

So the  Morton Thiokol management climbed down, in the face of customer pressure – and reversed their recommendation.  With tragic consequences.

It's easy to take an anti-management line on this.  But really NASA as their customer should not have put them in this place.

This is a scenario played out large that many engineers and often their managers have been put into.  Delays can be costly and bad PR, but catastrophic failures can destroy lives, careers, companies.

Scientist Richard Feynman, who was part of the subsequent investigation put it neatly - "For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled."