Tag Archives: clean

Stop Working With Blunt Tools

Posted on by
Reply
Reading time ~ 2 minutes

Clarke Ching introduced me to a story of 2 woodcutters – one worked furiously but finished late whilst another stopped frequently to sharpen his tools and finished early.  (He tells it better than I do) – I think it’s actually based on an Abraham Lincoln quote:

“If I had eight hours to chop down a tree, I’d spend six hours sharpening my ax.”

Let’s think more about developing software the Lincoln way…

What tool sharpening should you do before you start chopping?

If you paid off or prevented some of the debt you were facing before new work started, would it enable your project to run faster, more smoothly, with reduced risk, a lower chance of defects or a lower maintenance cost?

A previous employer had a great strategy. Every new release of the product had 2 top priority named features on the priority list for “cleaning up” and “levelling up”.

Cleaning up:

  1. Get all unit and regression tests passing (and keep them there).
  2. Address all build failures and warnings (and keep them under control).
  3. Delete all functionality, code and tests that will have been deprecated for more than 3 releases. (and add alerts to functionality that will be removed in the next release)
  4. Fix all defects that put us below releasable quality before we’ve even started (and keep them there).

Levelling up:

  1. Raise the tools we use to those that are best supported, newest in the market or offer improvements to our working conditions.
  2. Raise the libraries we use to the latest supported versions and address any issues.
  3. Raise the platform versions we’ll support when the product ships and address any issues. (and remove support for obsolete or out of date platforms).

No major release started full-tilt on functional work until these were cleared.

Like all good practices, this isn’t new thinking, it correlates to 3 components of the lean 5S strategy; sort (seiri), straighten (seiton) and shine (seiso). Rather than just describing what was done, here’s some tangible benefits for the clean up & level up approach…

  1. There were no unpleasant surprises for our customers on a new release. We had a standard platform, support and deprecation policy and kept to it. Our customers liked it when we did predictable things.
  2. For the development teams levelling up was a common risk. Addressing this at the beginning of a project was a valuable de-risking activity. Where we hit critical problems, we could make clear, early upgrade decisions and where there were fewer issues we would develop full-time on updated versions throughout the project with regression on older supported platforms available from prior development cycles.
  3. Removing old parts of the product made life significantly easier for the teams. The reduced testing, regression and maintenance load allowed us to speed up development – much like scraping barnacles off the hull of a boat to help it run faster. Cleaning up also allowed us to take some sensible baseline code metrics before any new work started.
  4. Giving teams space and time to clean and level up before starting functional work had a positive impact on morale. We felt that we were trusted to “do the right thing” rather than “just ship it”. This empowered us to continue doing the right thing throughout the rest of our work.

Give your teams some time out to sharpen their tools and sort, straighten & shine the workshop before new work starts. It will make a difference to the performance of your team and the quality of the end result.

I’m Drowning in Confetti

Posted on by
Reply
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.