[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.

I thought I’d write a post about a way of working and a chart that I use, which is so simple (and necessary) I’m surprised it does not exist in a more recognized way in programming methodologies. I call the chart the Slam Dunk and though its simplicity makes it versatile enough to fit many situations, for me it exists primarily to cover The Sledgehammer scenario.

Every now and again software vendor teams have to get something built fast. By fast I mean speed that defies the backlog-sprint-retrospective cycle. It is always a single thing, though it may have component parts, and ideally requires the entire team to work together. Those not coding contribute to the thinking/testing and/or get the pizza and drinks. It helps if it is agreed by all to be essential to obtaining some competitive market advantage, though more commonly these sessions are about fixing serious defects and addressing painful product-market gaps. Such development work entails a work practice that you won’t find a formal approach for, namely the Guerilla session.

I can’t tell anyone how to run a guerilla session, I can only tell you how we do it. Sessions start late morning, 9AM for us, and have never ended before 5AM the following morning, therefore they cannot be called on an ad hoc basis and we always have at least one week’s notice. If you’ve ever attended a hackathon it’s kinda similar, only it’s got commercial pressure stamped all over it and nobody is doing it for networking or fun.

We spend the morning scoping and planning the work - what code will be written, what design work needs to get done, who’s writing the test plan: feature, regression, browser etc., when will we commit and when will we deploy? Deploying code is the definition of a successful session and nobody goes home until this is done and the entire system is tested in production.

The Agile Story that ignited the flame on the session generates Tasks and against each Task we create a checklist, rather like a pilot’s takeoff procedure, because we know we’re going to get to the point where we’re too tired to think straight and will need clear signposts to what we’re supposed to be doing at each stage.

Then it’s time for lunch – always a range of pizzas, coke, bbq wings and chips, with loads of dips. You might think this is unnecessary information, an optional step. Just try a guerilla session without junk food for the troops and see how far you get. We order more than we can eat; around 1AM when energy levels start to drop, it’ll be time to pause and graze on the leftovers. Brainpower needs nourishment.

Over lunch, while the guys ‘n’ gals get busy, I transform the whiteboard Tasks and checklists into a Slam Dunk Chart. To create the chart you need 3 columns in a spreadsheet: Task, Description and Value. Create a simple list grouped by Task as shown below:

Against each task I put the number “1” in the Value column. This is the data that the pie chart plots and the reason that in the figure above every checklist item has equal weighting. You can get more sophisticated and weight work if you wish to, but I’m a binary thinker and 1/0 is the simplest way to do it. For me that’s the thing with a checklist item, it’s either done or not. As we close out each item I set the value against it to 0 and it disappears from the pie, meaning that the remaining items take up the space. This not only shows progress, it indicates the need for the entire team to focus on what remains. It is very motivating to see bigger and bigger, yet fewer and fewer, slices of the pie as the night wears on. When that last niggly item is closed off and the pie chart is an empty circle the relief on the faces of the team is a wondrous sight to behold. The sun is rising, we are bleary eyed and dog-tired, at least one person has fallen asleep in their chair, but slam dunk baby, we did it!

I’ve read many times about teams that adopt a ‘sledgehammer to crush a nut’ approach and trust me, it works. This is not the how of such sessions, just the way in which I track them for the team. If you have a big ol’ nasty nut that you intend to crush in one session, then I hope this little technique helps.

[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.