Those of us who work in a client-focused bespoke-software development arena know the joys of working on multiple platforms for multiple-clients, all wanting their own work first.

In such an arena it’s difficult to keep account holders updated with sprint plans and priorities. It’s even more difficult explaining how sprints work and why sprints have to stop on specific days and why work that doesn’t fit can’t just roll over a sprint and push everything back by a day or two. Keeping clients and account managers happy, keeping track of what’s booked into specific sprints, all with client deadlines and delivery dates, quickly becomes a nightmare task.

History of the Spreadsheet

What started off as a good idea, keeping track of commitments through a shareable spreadsheet, quickly became a problem in itself. A few good functions tied into team availability, keeping track of who was in and how many hours of dev time each sprint had available helped us to manage the workload and identify where we could fit work in, was a massive improvement over the old way which was “they who shout loudest gets their work done first”.

Very quickly the spreadsheet become fractured and difficult to control. With multiple inputs and updates needed throughout a sprint it become more work to keep the spreadsheet together than it was saving work in giving us the information we needed. If something becomes more expensive to keep it going, than it gives you back in savings, be that time, money or just an overall headache, then ditch it and find a different way to do it. Agile is a great software-development methodology but heck, pick the bits that work and apply them to every part of your development process.

Back To Basics

Under-fire football managers and political leaders love the phrase “Back to Basics”. It identifies a point at which a new fangled process and wonder-idea hasn’t worked quite as it should. It’s a face saver, a way of rallying the troops back to think about the original problem, often after having spent more time trying to fix a problem in a problem, in a fix to a problem. (Kind of like having to fix the box before you can *urgh* think outside it!)

It’s the same approach we took. Back to basics. What do we really need from the sprint-planner spreadsheet? Actually we just need account managers to understand that we can’t do 300 hours work in a 150 hour sprint. To understand that pushing the client back a week isn’t going to help if we’ve already committed to two months worth of work previously. We also needed to re-connect everyone, company-wide, into the idea of sprints. Get them really involved in it, as opposed to just moving numbers around a spreadsheet.

For me, going back to basics with software development methodologies means going back to white-boards and post-it notes. Ditch the computer and make it a tactile, involved process. Give people something that they can physically pick up and move, where they have to do mental arithmetic to check it fits, enhances their involvement and gives them a feeling of authority and input into an otherwise “developer controlled” process.

It’s a weird phenomenon but show people at a meeting something on a screen (kind of like death-by-powerpoint) and they quickly switch off. Make it paper based and tactile and immediately everyone is back with you.

The Sprint-Ban Board

The “Sprint-Ban” board is our attempt to break free from the broken spreadsheet. It is essentially, a very high-level, slightly twisted, Kanban board listing epics by sprints.

The first four columns indicate the next four sprints, the last three break the current sprint into three states – Waiting (Sprint backlog), In Progress (Dev has picked this up), Complete (The most final and complete “Done”). KISS is a well used acronym and something that kept coming back to me as I put this together.

In our prioritisation sessions we can move the post-its around, seeing what fits where, in-line with client deadlines and priorities. The development team can quickly see what is coming up and the accounts team can easily see where new work can, or can’t, fit.

Anyone can get up from their desk, walk to the board, and check where we are. No more writing an email, asking for an update, which comes back in an email.

Get up, walk, look. Simples. (Okay, so this doesn’t work so well for remote workers – which we will have – so I’m thinking webcams and a Sqwiggle account)

When You Know It Works

Recently a challenge cropped up where an urgent project needed slotting in (in our industry an urgent problem isn’t normally a bug or a new feature, it’s a live people-impact issue that we need to react to straight away) – the dev team were able to relinquish control and ask the accounts team to come up with a plan using the board and the post-its. It was a great feeling of success when, between them, they were able to use the board and decide what went where, without overloading the dev team with too much work. That’s when you know it works.