Captain, You’re Wrong!

Reading time ~ < 1 minutes

With limited time and bandwidth, leading a large global development team on a large complex project requires rapid decision-making on difficult problems.

Some years ago my team found the cost of delay on a wrong decision corrected later was generally far lower than the delay of holding out to be sure of the right one.

Many times I had to look at what little information we had and either make (or support the team in making) an arbitrary judgement call.

The reason this approach worked for us was that we were all willing to step up as soon as we knew were wrong (usually in light of new, previously unknown information) and call each other out. In fact I took it as a matter of personal pride that I could be wrong so often and yet my team could still outperform those around us.  In that team it was socially acceptable to be fallible and we encouraged less-experienced staff to challenge their more experienced counterparts.

The phrase “Captain, you’re wrong” is still music to my ears. It usually meant someone on the team was right!

Try this: When you’re stuck making a decision, choose the one that seems least wrong. You’re an experienced professional, sometimes your instinct will be all you have left to work with. Make it clear to your teams that if they find a decision isn’t working for them they can revisit it – as long as we get on with it now with no debating.

Breaking The Seal (Part 1)

Reading time ~ < 1 minutes

Following on from my last post; “Communicating in Patterns” here’s the first of my regularly used concepts – alluded to in “Don’t Open More Barrels Than You Can Consume“.

Name: “Breaking The Seal” or “Cracking Open” etc.

Analogy: (This one makes me think of the campfire scene in blazing saddles even though it’s only partially relevant)…

You only open the lid on a new can of beans when there isn’t enough in the current can to feed the family.

Underlying Concept: One of the key ways of delivering maximum throughput on teams is to limit WIP (work in progress/process). Teams inexperienced at this tend to start additional items or “break the seal” on new work when blocked or when a team member has completed their last personal task. We need the team to take a hard look at the work at hand, consider swarming around a given item or story and only open the lid on a new item if there really is no additional value to be gained from another member of the team helping out on the current top priority item.

This works on many levels – here’s a few…

  • Every time you open a new can you risk not finishing it all and having to throw the leftovers away.
  • Opening too many cans and forcing the family to eat them all causes bloating.
  • Eating excess beans takes longer and leaves no room for dessert.
  • Unfinished cans in the refrigerator tend to get pushed to the back and go moldy.
  • Very few people like cold beans for leftovers. (actually – sometimes I do)

I’m Drowning in Confetti

Reading time ~ 3 minutes

What happens when card-walls, foam board and stickies get out of control?

The same thing that happens with poorly maintained software.

“…But we spent time on them we can’t possibly throw them away!”

Time for a litter patrol I think…

About 2 years ago I ran some Agile training up in Scotland. One of the early exercises was to get the team to brainstorm and develop a backlog for a new product. (later exercises covered release planning etc.)

On every table was a pile of coloured stickies, marker pens and biros.  I asked everyone to grab a pen and some stickies and collaboratively start developing a coarse list of features and end user needs. All but one person in the room grabbed a biro and sticky pad and started listing as many things as possible – on a single sticky!

There’s some lessons to learn from this abut giving good instructions but the big thing for me was realizing how our culture has changed so much at the site I’m usually based at.

In 3 years I’ve seen a team transform from nothing on the walls to everyone having their own personal whiteboards, pinboards, information radiators at every wall and corner, a myriad of story maps, coloured indicators, charts, tables, diagrams and the real killer – A0 size portable foamboards covered in stickes everywhere!

Sounds pretty good – all that information right?

Perhaps we’ve come too far.

I sat down in a meeting room today and looked at the board that had been “parked” in there sometime in the last 6 months and recognized my own handwriting.

It was from a difficult release retrospective I’d led for a large team. The board was covered in things to “try” and a few things to stop doing. The original retrospective didn’t end so well. I pushed for selecting a top 3 actions (from nearly a hundred ideas grouped into logical sets) and failed to reach a conclusion.

Looking at the board today, despite the pain at the time I reckon that team have actually achieved or tried nearly half the things on the board and most have stuck.

I’m going to take it back to the team shortly as it’s a great way to see just how far we’ve come.  Quite a neat find!

But…

This is one of nearly 100 foamboards in the building. (We have about 10-15 scrum teams). My team sees these particular boards multiple times per day during various unrelated sessions but we don’t do anything with them – they’re just parked.

Many of our boards are delinquent, things are starting to look a bit untidy. In some cases there are multiple boards that are the output of week-long workshops speculatively planning releases that we’re now in full swing on.

They were useful once but now they’re hiding in corners and we don’t know what truths they hold.

We have photos of them in the wiki but they’re not important enough to keep right in front of the team and maintained.  We still feel an attachment to them – all that energy and time spent getting those thoughts visible…

Time to clean house I think.

I can either be brutal or more selective. Much like clearing out the garage, sometimes having an impartial person to help clear up may be needed.

My Lesson: Just because you spent time on it doesn’t mean it needs to be kept. Remember the XP acronym; YAGNI?  “You Aren’t Gonna Need It”

It applies to all artifacts developed during a project, not just code.

If something has served its initial purpose or achieved most of its intended value, make a clear decision on what to do with it. Are we into diminishing returns? Should there be some explicit action to retire the artifact?

If you care that much about it, how about giving it a wake?

Whatever approach you take, don’t let your information radiators rot. All that out of date noise will cloud out the actual information.