Reducing waste by making your goals visible

Metrics are good, but they’re not enough. If you want metrics to drive change, they need to be visible. Not just to managers, but to the team. The right metrics, visible to the team, drive improvement. Visible only to management, drive control. Visible to no-one, drive nothing.

Good metrics need to be communicated clearly and persistently. There needs to be a continual focus on whatever the priorities are. If it’s out of sight, it will be out of mind. If it’s digital, rescue it from individual screens that are easily covered up.

It’s why kanban boards can be so effective when used well. It’s easy to see when the team is taking on too much work, or where there’s a queue waiting for tasks to be pulled. The board radiates information to the team, about how much work is in progress, and who is working on what. It becomes the centre of communication about tasks and removing waste. Make it physical, if you like, and the team is co-located. Use Post-its. Let dog ears and grubbiness indicate age. Do your backlog pruning via environmental effects – older & more used notes are more likely to fail behind the radiator and get lost.

Put (work-related) personal tasks on there too. Keep yourself honest. It’s good for the team to know you’re reviewing CVs, or preparing for that strategy meeting, or learning Haskell the hard way.

But keep it clear. Use a Kanban if WIP or queueing are your key metrics. Use Scrum if velocity and deadlines are key. Use a dashboard if that makes your priorities and progress clearer.

And make sure your key priorities (4 or less please) are visible at a glance for the team, and easy for anyone in the team to explain to a passerby. They don’t need detail, but pointing to a big pile of waiting tasks to justify recruiting a new tester is a clear message.

development leadership

Measuring the wrong thing

Process improvement requires measurements. How do you know what to improve if you can’t see where things aren’t working, and how do you know you’ve made the right change without seeing those numbers going in the right direction?

But measuring doesn’t mean you’re measuring the right thing, and measuring the wrong thing can lead to the wrong outcomes, and can be very harmful (see Liz Keogh’s talk on perverse incentives )

The key to the success of any metric is that it is owned by the team so they have complete control over the changes needed to affect it, so they feel ownership, and that improving the metric has a useful business outcome.

Metrics that I’ve found useful in the past include:

Number of bugs introduced by a release.

This is a tricky one to work with because it can easily be a perverse incentive, and the feedback cycle can be slow, especially with the usual 6-12 month release cadence. However, on one waterfall project I took over there was a strong negative perception of the quality of the code, and big count was a useful proxy as the customer had access to JIRA so the big list was already visible. Reducing this number was a combined effort where testers and developers had to approve requirements, developers and testers invested in automated testing at all levels, and testers joined the developer daily stand-up in order to catch bugs before they were released “have you checked that page in Welsh?“, “We found problems on that page last time because IE was too slow“.

Number of releases per month.

On an agile project we noticed that releases were getting held up because testing was slow and produced a lot of rework, which were then tested against more features that had been pulled from the backlog, increasing testing time. Each release also took half a day, so we had to schedule them carefully.

So we set a goal of focusing on releases for a month and measuring how many we did. There were other measures within that, such as monitoring work in progress on the testers, time taken to do a release, and cycle time from start of development to live release, but they all drove the big number, visible to the whole company, of more quality releases.

Questions answered per day.

This can be a very useful metric for research projects, especially when following a fail fast approach, when you want to prove something can’t be done before you invest in doing it. In order to do that, you need lots of questions with quick answers, to accelerate learning. Any answer, positive or negative, is progress. It means we have learned something.

“I cheerily assured him that we had learned something.
For we had learned for a certainty that the thing couldn’t be done
that way, and that we would have to try some other way.” – Thomas Edison

Age of Pull Requests

Successful agile projects rely on peer review, either via pairing, or a formal review process such as git PRs (and I won’t discuss that in this post). However, when we started working with these on one project, we discovered that we were building up a large debt of Work In Progress because the team wasn’t incentivised to review each other’s code, so one of the developers set up a nag bot for any PR older than 4 days. It lasted 2 weeks before it was no longer needed.

What about you?

What metrics have you used to incentivise the team? What problem were you trying to solve, and did the metric work?


Sense and Respond by Jeff Gothelf and Josh Seiden

Sense and Respond: How Successful Organizations Listen to Customers and Create New Products ContinuouslySense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously by Jeff Gothelf

My rating: 5 of 5 stars

Having read Lean UX, I was expecting a good book on how organisations could deliver projects. This book is about much more than that. The authors are coming from a point of frustration where agile delivery and Lean UX projects have failed to reach their potential because the organisations surrounding them were not supportive, so this book is about how to reshape an entire organisation to meet the challenged of the modern world, with lots of positive and negative examples, which is refreshing to see in this type of book. If you’ve ever had a strategy meeting, or ever found your project success limited by your organisation, go read this book.

Easily the best book about dysfunctional organisations and organisational change I’ve read since Peopleware.

View all my reviews

Buy on Amazon UK :

development ux

Always be finished

I’ve been living on a building site for a while, at home and at work. The work at the office above ours was ambitious, chaotic, noisy, messy and overran. It was a challenging project, turning a “derilict” into a funky new office.

Home was a simpler proposition, a greenfield site, with a well tuned team putting up a batch of similar houses. Each house in the project was a clear finishing point. The work was completed on or near budget, although there have been many bugs in the finished product. Nothing to break the deal, but enough to be annoying, and a few that need serious attention before things get worse.

The most interesting thing for me however was complete the overall project looks. At each stage the customer perception is paramount, so roads and car parks are built and finished in places where in a few months they’ll be ripped up to put houses on because that’s the most central place to put the marketing suite so customers can see their house quicker.

And the perfectly manicured lawns at the show home will be ripped up to build a driveway for the garage. And the landscaped street gables get cut back to move the marketing suite. But at each stage there’s a clear “here’s what’s being built” and “here’s the rest” even when what looks complete is not the final vision.

The perception even extends to certain rules for residents to ensure consistent façades and a complete presentation, with no unsightly trade vans, for the entire site until the last one is sold.

When you build software, how finished do the “temporary” solutions look to the customer and the developers. Do they look hacked on, unreliable and in desperate need of a bug fix, or do they look finished and smooth to the end user, with a few backlog tickets describing what it really should do. No hint to users or competitors that something is about to change.

It’s not enough for everything you release to be complete and tested. If users can see the cracks, it will colour their impressions. Fix the snags and delight your users.

development lifehacks

Give yourself time to think

I’ve spoken before about how a quick time out to grab a coffee can help you get to the bottom of a problem, but sometimes you need longer. You need time to switch off and think. 

I feel guilty about just sitting and thinking, despite trying mindfulness techniques, so for me, my best thinking comes when my body is busy but my mind is free. Sometimes in the shower (and apologies to my wife for those days when I take an extra 10 minutes to think through something), sometimes swimming, sometimes mowing the lawn.

Take time to get bored. Boredom is not boring. Boredom gives you ideas.

Read these…

Action is good, thinking then acting is better. Make time to think.


“Why Agile Works” review

Why Agile Works
Why Agile Works

Coming from an Enterprise background in a previous life, of the cascading-waterfall, multiple-signoff, change-control, duelling-project-manager variety, this was a fascinating book. 

This is a book about Agile For Enterprises. Not for the teams like mine that carved an agile garden in a world of fixed-price contracts. This is for the managers who want to know where they sit on The Maturity Model. Those who need to justify why tearing up the hierarchy is a good thing, and how to make a company, not just a silo, agile.

It’s a book about the why and some of the how.

It’s definitely worth a read if those enterprise descriptions sound familiar, or PRINCE2 matters to you. Otherwise, I’m not sure you’ll get much out of it.

code development programming

Jettison sandbags to focus on your goal

wp-1450118468278.jpgWhether your deadline is near or far, there will always be things on your team list that you don’t need to do. It’s tempting to take ownership of everything, all the servers, all the code, all the admin. As a team of top developers, you could also write a better timesheet management software than the one you’re stuck with.

But should you?

Does it help you with your mission? Does it provide business value? Can you do it better and cheaper than what you can buy in? Do you have a unique circumstance that means you can’t just style an off the shelve solution? Really, are you that unique? Do you want to support it once it’s released?

More important than any plan is a strong purpose, a goal. Something small that everyone understands so that any task can be quickly evaluated against it. If the task doesn’t fit the goal, it’s irrelevant, ditch it. It’s baggage. Even if it’s an existing system.

What’s your team’s purpose? Or at least your 12 month goal?

development programming

The Fog

Agile is about the here and the now. The moment, turning on a sixpence as the weather, and the market changes. Adapting to your environment and delivering, delivering, delivering at a consistent high quality.

But what if you’re delivering the wrong thing?

It’s not just about the pivot, it’s about the plan and the dream. How can you decide between prioritising the mobile app or the chat interface unless you know where you’re going?

Yes, we prioritise, reschedule, re-evaluate constantly, and we only ever have a clear path for the next timebox, no matter how much our Gantt charts and managers persuade us otherwise.

But what are you doing next? Do you need to build your storage layer for SSDs or the cloud? Are you optimising for read throughput and fewer writes, or network performance and fewer reads?

Don’t let the immediate goal cloud your thinking. You may not be able to see clearly where you’re going in terms of detail, but you should be clear what direction you’re heading, where the big obstacles are, and who’s nearby.

Out there in the mists are the challenges, the gaps, the shortcuts and the dead-ends. Don’t shoegaze yourself into a corner.

Don’t forget, the feedback loops don’t stop at your retrospective intervals. Look up once in a while to make sure you’re on track.

development programming

A task/story is not a feature

Agile is easy. Take the requirements, break them down into tasks, schedule them, do them, review them, test them, ship them.

And then you realise, as many on the agile journey do, that your “spreadsheet import” task is too big. It doesn’t get finished in the same timescale as other tasks, so it sits on its own branch, drifting from the mainline, or it holds up the release until it’s done-done-done.

  • As a user
  • I want to import spreadsheets
  • So I can use data created by other programs

Break it down. Make each task count. The feature fractures into tasks, micro-features, one for reading each format you want to support; one to deal with classes of bad data, those mismatched quotes and uneven lines, one for paging to deal with larger spreadsheets.

Just as we have to break down each interaction into multiple facets, and multiple services, to create the smoothest possible user experience, so we break down each feature into componentized tasks to let us integrate more often, review more often, release more often, and provide the smoothest possible developer experience.

If your process doesn’t flow, fix it, smooth it, deconstruct it.

development leadership programming

! Not the lazy programmer

There’s been a popular stereotype about good programmers being productively lazy. Automating tasks to avoid work. It’s an easy thing to share but I don’t think it’s quite true. It’s about reducing inefficiency.

It’s not that developers don’t want to work, we want to do interesting work. Not repetitive work, not work that gets binned, not work to make life miserable for ourselves or others, and not work that can be done easier, cheaper and faster in a different way.

At it’s heart, software is a process that turns data, sometimes with human input, into other data, and sometimes into information and insight. Great developers understand processes, sub-processes and the connections between them, and inefficiencies smell. They distract, like a stone in the shoe, or a dam in the river. Sometimes we can quickly throw out the stone and run faster. Sometimes it takes years of rubbing away, fighting the blockages, until the path is clear.

Sometimes we shave yaks (and btw, check out that gif), Not because we’re too lazy to climb the mountain, but because we know we’ll have a better chance of getting there with a warm coat and a good plan.

Don’t be lazy. Be efficient. Be effective. And route around or remove any blockages in the way.