Transactions for Managing Technical Debt

Posted on by
Reply
Reading time ~ 4 minutes

If you’re losing capacity maintaining brittle code or infrastructure, the “litter patrol” in a related neighborhood may be good practice but how do you visualize and manage the true source of your pain?

This is based on a mix of my own experiences and great nugget of insight picked up from Jim Highsmith at Agile 2010 who in turn credited Israel Gatt.

First the paraphrased nugget from Jim…

“Teams need both debt reduction and debt prevention strategies.”

Here’s the quote from Israel back in December ’09.

“If your company relentlessly pursues growth, the quality/technical debt liability it is likely to incur could easily outweigh the benefits of growth. Consider the upside potential of growth vis-a-vis the downside of the resultant technical debt. When appropriate, monetize technical debt using the technique described in Technical Debt on Your Balance Sheet.”

Here’s my expansion to Israel’s article…

How do we know we have debt?

We “know” it’s there, we feel it. But do the right people know about it? You may be allocating permanent team capacity to keep bailing without seeing the hole.

  • Train all your teams in spotting technical debt
  • Develop and communicate your debt strategy to your teams and stakeholders.
  • Determine a common unit of currency (points, hours, money, NUTs) that your stakeholders can understand and engage with and use this to describe the transaction decisions you’re making.

Communicate current debt – “Balance”

  • This is obvious but hard to achieve. For the debt that hurts; quantify the cost and determine what you could do if it were resolved. Get that opportunity cost shared and get your solution sponsored. In most large companies if you can demonstrate a cost reduction or productivity improvement you can get support.

Communicate new debt – “Recent Transactions”

  • Not the decade-old pile in the corner! Focus on what you’re forced to add because of deadlines and market pressure. Every time you make a debt-related compromise, get that conversation exposed. Determine the maximum acceptable age for any debt being added, a cost (in your selected currency) and a priority. Whilst there are cases where a debt may never need to be repaid, chances are you’ll need to pay the next transaction off.

Limit debt – Set yourself a “Credit Limit”

  • What’s the maximum debt your team/project/product is willing and/or able to tolerate? Set a credit limit and stick to it. If we blow our limit, we’re in trouble. My personal rule-of-thumb is if it’ll take more than one whole sprint for the entire team to clear all new debt then you’re worryingly-leveraged and heading away from releasable software. This approach means a simple default credit limit for a new project (using story points as currency) is the same as your velocity – simple to calculate and remember. You could convert this into the average hours (and therefore financial impact) a story of that size takes if that means more to your leaders.

Whatever you do, don’t over-mortgage your product. You don’t want your product portfolio to collapse under unrecoverable bad debt.

Set a maximum age threshold – “Payment Terms”

  • Use topping & tailing approaches to control and ratchet your debt age to keep the span down.  If your debt exists for more than N sprints (say 3) promote it to the top of the priority stack. Fixing new debt when it arrives is hard work and items do slip through. For those that escape, setting a maximum age means you’ll cycle all your debt through and keep it fresh. Even tough problems get resolved rather than rotting in the debt heap.

Visualize and report your debt – provide a “Debt Statement”

  • Put all debt visibly on your wall as cards or stickies, give it a different color, heading, whatever – make it visible. Now every sprint let’s highlight the numbers, the growth, reduction, reiterate your limit. If you’re using an electronic tool, try putting all the debt items under a single parent and tracking cumulative flow and burn-up of debt rolled up to that item.

Prioritize your debt – “Positions”

This is getting a little more advanced and difficult to manage – I’d reserve this for only projects that already have high debt where the simple strategies alone are too invasive.

  • Partition your debt into 3 positions. New:Short-term, New:Long-term, Old:All.

Set a different credit limit and payment terms for each of these and as part of prioritization set a ratio of effort/pay-off against each that ensures that at a minimum debt is sustained at a constant level but focus on cycling through so that the contents remain fresh.

Taking Action

Here are a few other points to explore – mostly around debt reduction.

• What “small wins” exist for you? Are there some simple debts than can be cleared quickly?

• If you sacrificed a team member for 1 sprint to pay off some short-term debt, would you be able to increase the overall team performance in later sprints?

• If a particular single debt item is too big for a team to swallow in a single sprint, can you call in or implement a parallel “SWAT Team” to fix it?

• What capacity do you need to reserve to sustain your current debt level?

• If you were going to reduce your debt burden by 10-20% what effort/capacity would that require and how long would it take?

• Can you demonstrate a return on investment for a particular piece of debt-reduction?

• Worst-case scenario: Could some debt control run “under the radar”? (And if this were discovered, what problems would be caused?)

Wrapping up:

Develop both debt prevention and reduction strategies for your teams, don’t just focus on reduction.

Treat technical debt like real personal or business debt: use “credit limits”, “statements”, “balance”, “transactions” & “payment terms” to your advantage.

To achieve effective reduction, work through the Oubliette strategies and in worst cases, consider a “SWAT Team”.

The Point of Maximum Learning

Posted on by
Reply
Reading time ~ 2 minutes

This post draws on some exceptional leadership training I attended in Cincinnati some years ago, a personal near-legendary experience from Summer 2009 and the fact that many of us actually flip back and forth from being visibly outgoing, strong and confident to being introverted, quiet and shy.

Recognising this model was something quite special for me – it highlighted why I gain so much from conferences, talking to customers, like-minded strangers and other controlled but potentially stressful situations…

http://www.socialpedagogy.co.uk/concepts_lzm.htm

In order to learn we have to explore, leave our comfort zone and enter the learning zone. Beyond the learning zone lies the panic zone where we are blocked (by fear) from learning – lessons here are only recallable in similar negative situations.

  • Individuals must find their own way into their learning zone, it’s unique to them.
  • Forcing someone out of their comfort zone out of their control may tip them immediately into panic.
  • The point of maximum learning lies at the cusp of the learning and panic zones.

I believe this is why we learn so much from failure and stressful situations and why we often only realize it when we face them a second time.

It’s also why I learn most from group workshops and preparing presentations. Getting out of my comfort zone and talking to people in public gets my adrenaline going and brain working.

A cautionary note. I’ve found that having recognized what’s happening and broken the seal on the comfort zone it becomes somewhat addictive. The boundaries between comfort, learning and panic zones shift and you need to keep finding something else to drive you onward.

Chris Matts is somewhat of a master at demonstrating learning on the fringes between learning and panic – talk to him about exploring deserted conference facilities at 2am armed only with a shopping bag, red wine and no water.

What things do you do that make you really uncomfortable but maximise your learning?

 

Improving Your Retrospectives

Posted on by
2
Reading time ~ 3 minutes

Inspired by Carl Bruiners – he described many unsuccessful retrospectives as “Happy Clappy” or “Toothless”.

– I love the term “happy clappy”

Last weekend  I hosted/facilitated a short session at the UK Agile Coaches Gathering on “How To Improve Retrospectives”. A valuable hour or so of shared challenges and lessons. Here’s the highlights I was able to capture.

Let the Team Vent

  • If you have a very frustrated team with a succession of issues, give them time for catharsis. 2 or 3 “venting” sessions to let off steam rather than retrospectives needing concrete action may actually be necessary. After the sore points have been drained, circle the team back around to actually solving some issues
  • Facilitate the venting to keep it constructive, not personal and ensure they are actually draining issues, not fuelling flames

Think Lean

  • Prevent batching and waiting by raising issues sooner with the potential to address improvements rapidly before a retrospective even happens
  • Capture your data points and lessons as soon as they come up – on the board for the team to see every day. Discuss them as part of the stand-up
  • Track activities, lessons and problems on a timeline during the project or
    sprint, not at the end. There will be less head-scratching and forgotten issues in the retrospective. It’ll be faster to get moving, you’ll have fixed more and people will feel the time spent has been more productive
  • Consider setting a threshold / count of the number of issues or lessons raised as a trigger for a retrospective rather than just sticking to a sprint rhythm

Figure out what to do with “stuck” actions

  • If there are recurring problems beyond the team’s control, take them off the table. There’s no point in self-flagellation. Raise them in a forum other than retrospectives
  • Define a clear, workable escalation path for when a team needs support to resolve a retrospective action
  • Work with “management” to clear at least 1 stuck retrospective action in order to build team trust in both the management and process – prove it’s working, worthwhile and supported

Keep it interesting & fresh

  • Once a team is used to the general structure of retrospectives and using these relatively effectively, use variety to keep things fresh and interesting – see the “Agile Retrospectives” book and associated mailing list for ideas
  • Retrospect on your retrospectives, – e.g. using start/stop/continue

Beware of US/UK social differences

  • Thanking and congratulating each other is not a common cultural behavior in the UK. Get teams comfortable with other activities and working as a team before approaching some of the “softer” areas
  • Recognise your team members may not be happy talking about how they “feel” about projects, each other, values or any other “hippy” concepts

One of attendees at the coaches gathering described a painful retrospective experience where a single member of a team effectively shot down a retrospective by refusing to participate in sharing feelings. I’ve had similar derailing experiences where a single team member didn’t want to take ownership of any actions or decisions and pulled a team with them. In both cases we just called a halt to that part of a retrospective and moved on. There’s always next time.

Deciding What To Do

  • Capture actions for the team and actions for “management” independently
  • Use dot voting or similar consensus-building activities for selecting actions
  • Encourage people to vote for what they’re motivated to address and capable of resolving, not just items they think are important
  • Limit the number of actions to commit to & address, you can always come back for more
  • If you complete all the committed items, consider pulling one more new action through

Agree When & How actions will be covered

  • Some items are “just go do”, others have more cost. Address just go do items as they come up
  • Consider use of stories for larger actions in backlog and prioritization
  • Try “sprint tasks” to keep “customer” activity/velocity independent of “non-customer” actions and improvements
  • Identify owners for taking management actions to the management (typically a coach, team lead or scrum master)

Thanks to Sophie Manton, Mike Pearce and other attendees for the insights & lessons they shared at the Coaches Gathering.

5S Your Scrum Board – (Part 2) – In depth

Posted on by
Reply
Reading time ~ 7 minutes

I’m a big fan of Goldratt’s Theory of Constraints for getting important improvements made in the most suitable order for a team. Our current scrum board is the result of focusing on the most evident, soluble problem each day for a couple of weeks. No grand plan, just good emergent design.

Note this is a very long article as some readers of part 1 asked for all the details as soon as I could get them written, today’s the first time I’ve been near my blog in a week. I’ll switch back to shorter posts after this for a while.

Here’s an in depth look at each of the areas of our board…

scrum board with placeholders

Using the peripheral space for useful stuff

 

Feedback

A single sticky with a quote regarding some feedback. The last 3 sprints we’ve left one up there that says “It shouldn’t be all that hard” . A reminder not to generalize (“it” was much harder)

Theme

One sticky. Our current theme is “Contact Management”, The next will be “Dashboarding” or similar. Just a little reminder of what the overall focus of the sprint or sprints is. This helps when clarifying or controlling scope, questions, debt & defects.

Capacity

During sprint planning we look at who’s in, when and what other commitments they have (beyond the usual overheads and maintenance activity). Capacity is calculated in half-day (4-hour) increments for each of us, totalled up as a whole team in hours. We then subtract 40% for overheads & support.

We track a second capacity number under the first which is the actual total effort hours of tasks completed in the last sprint. Generally this is a fair bit lower than the forecast.

The differences between these two figures are useful input for understanding our capabilities & overheads.

We limit tasks during sprint planning to around 70% of our maximum delivery capacity or close to our previous delivery capability  in order to leave space for unknown / discovered activities and hurdles. If planning another story would take us over this level, we hold off until we’ve actually been able to deliver the first – there’s no point in breaking stories down into tasks if they’re highly unlikely to happen in the next 2 weeks.

If we really do well, we can always reconvene.

Tags

At the moment we have 2 sets of tags on the board; “Blocked” and “Please Test”. The team no longer uses the “please test” tags so they’re likely to be removed this week. We assume coding tasks include developer-led testing activity and any other testing is planned in as scheduled tasks. This has reduced dev-test handover as the whole team focuses on the set of tasks required to complete a story, not their individual tasks.

I’m likely to add “red tags” soon for tasks that need particular focus or expediting. We’ll limit the use of red tags to one WIP item at a time and only when needed.

Key

A color key for our tasks. Currently we have

  • blue : code & test
  • green : design & ux
  • yellow : test
  • orange : management noise
  • pink : support & bugs

Stories

 The top horizontal swimlane of our board contains stories and story activities.  The left-most column of this contains story cards in priority order from top to bottom for stories planned for this sprint. The space here is deliberately small. The last 2 sprints we had only 2 stories listed, in the next sprint we’re actually reducing it to 1 and having the whole team pull single stories through. (Update – We ended up pulling single stories as a flow after this point right to the end of the project)

“Extra”

A placeholder for “extra” stories.

If we really do clear all the stories on the board, this area is a placeholder in rough priority order for the next 1 or 2 stories we might play. These are not broken down into tasks unless there’s certainty that we’ll actually work on them in this sprint.

Physical Holders

A more traditional lean technique. We have an individual holder for 1-2 pads of each color of stickies. We can quickly see if any are running low and replenish stock. We also have a holder for story cards although that’s rarely used (we generally don’t add stories when stood at the board).

There’s also a holder for pens. We ensure there’s enough marker pens in the holder for everyone to have one during our standup and we ensure that there’s one of each whiteboard pen color needed for drawing graphs and totals on the board.

Hours (on stories)

This is the initial estimate in effort hours of all tasks we identified prior to & during sprint planning that went onto the board at the start of the sprint. We compare these with total hours completed at the end of the sprint to learn from and improve our tasking and estimation.

Over time we hope to gather enough data to see the typical ranges of hours spent on stories of each size (we expect a bit of overlap)

Sprint Tasks

Our second main horizontal swimlane is “sprint tasks”. These are all the activities required by us as a team in order to be able to complete the sprint and usually deploy our working software to production.  We also tend to add extra technical debt cleanup items into this swimlane.

This approach seems better at the moment than having specific (and artificial) stories for these activities.

It’s up to us how much trade-off we have between sprint tasks and story tasks in a sprint. Since creating this swimlane we’re finding 40-60% of our effort is going into this area however this is because we’ve been prioritising some technical debt and deployment improvement activities. That rate will adjust over the next couple of sprints.

Support/Bugs

The bottom swimlane on our board is for support issues and bugs. Right now we’re not using this very much as our support and old bug fixing activity has been relatively low.

We’ll see how useful this lane is longer-term.

Note, bugs related to work we’re actually doing are either fixed immediately and not added to the board at all or are added into the stories swimlane relevant to the story they’re found in.

Todo/Next/WIP/Done

Todo, WIP and Done are the typical status lanes for tasks you see on most boards these days. “Next” is an addition we added in very early on and has been a bit of a game-changer in managing the flow of tasks effectively here’s a link to the full article on the “next” column.

Retrospective Input

I talked a little bit about this at the UK Agile Coaches Gathering this weekend and I’ll expand more in a standalone article shortly. Put simply, we found that getting potential retrospective input visible every day during the daily standup has been more effective in driving continuous improvement and makes it easier to collate retrospective data at the end of the sprint. Mike Pearce also recommended something similar over the weekend – maintain your release and sprint timeline with pitfalls and lessons so that there’s less head-scratching at the end.

Graphs:

We’re tracking burn-down of task hours for both sprint tasks and story tasks in parallel (different colors). Then on the same graph we’re also tracking the burn-up of total capacity. It’s working okay for us at the moment but I can’t help thinking it’s still not quite right so I’m sure we’ll revisit this.

Beneath the burn-up/down we’re tracking per-sprint velocity as a basic bar chart. Straightforward, simple, easy to complete and easy to understand.

Sprint Schedule / Countdown boxes

As of the end of the last sprint we removed the sprint schedule, the list of historic dates wasn’t adding anything for us. We have the current sprint dates at the top-left of the board instead and have used this space for a set of countdown blocks 10..1 with effort hours to do and forecast remaining each day. This gives us immediate feedback as to whether we may have a problem in meeting the end of the sprint with current task scope. I’ll write up the experience on the countdown boxes separately once we’ve been using them a while.

“Done Done”

This serves a couple of subtle purposes…

There’s something very satisfying about taking tasks from the board and dumping them in the “done done” box.

We clear down the board into “done done” at the end of each sprint. This makes it clear that we’re not really done until we’ve completed everything and cleared the decks.

Although the box itself is basically a trash holder, it serves as a constant reminder that we’re not done until we’re done 🙂

We’ve added a few more things since I drew the original picture of our board…

Running Totals

After the daily stand up we sum up the total effort hours for each horizontal/vertical swimlane square/block and scribble those on the board. We can then transpose these into tracking graphs.

Right now we only track todo by horizontal lane and overall done but we have the data available for cumulative flow tracking if we feel the need.

Debt

We’ve added a very small space for newly accumulated or discovered debt related to our current work. It’s deliberately small to keep things minimal. When it fills up we’ll need to do something with it (if not sooner). It gives us one more line of slack if things go unexpectedly in a sprint for some reason whilst we still focus on deploying working software. This is still a running experiment but the intention is to treat this like credit card debt – it’s a short-term postponement mechanism, not a backlog.

Next Sprint Tasks

In much the same way as we have “extra” stories, we’ve added a placeholder for tasks we need to do in the following sprint but don’t have capacity for right now. This stops us overloading the current sprint tasks lane once things start moving without forgetting important future activities.

An Update (November 2013)

I’ve been rooting through my old photos and found a picture of the board toward the end of the project (September 2012) so you can see what it *actually* looked like as it evolved beyond what I’ve described above.DevOps Email Marketing Project Board Sept 2012

If you’re interested in even more whiteboard designs (and how they evolved over time) take a look at “A Year of Whiteboard Evolution”.

Closing Comments…

Don’t be afraid to adjust your working area if things don’t seem to be flowing right.

This isn’t the end for our board adjustments, what we’re using will certainly be different in a few weeks time however today it serves our needs well and must remain simple enough for new team members to understand.

I strongly recommend reading Henrik Kniberg’s recent book. I read the review draft last week (July 2011) and saw close similarities in the board structures the PUST teams at RPS were using and what we have here. I also share the same view as Henrik that each team – even within the same group – should be free to choose their own board style.

Try taking a few of these ideas away to experiment with but you probably won’t need them all.

5S Your Scrum Board – (Part 1) – A Place for Everything

Posted on by
Reply
Reading time ~ 3 minutes

Some weeks ago I joined a new team. I don’t like causing disruption but I do like to get the pace of improvement going on my teams. Here’s how we started out together…

During my first week I observed my new team’s activities. They were trying hard and doing pretty well but hitting some hurdles. Their most obvious challenge was the impact of covering support activities and cleanup tasks in addition to new story delivery.

Other than the loss of expected delivery capacity, this unplanned work was causing problems during stand-ups. The flow and continuity of useful conversation was being lost as the team stopped to hunt around for the right coloured super-stickies, a working marker pen and figuring out where to put the tasks. (but… they were aiming to get these tasks visible!)

So…

Borrowing some 5S tricks from Lean, I started work…

  • Seiri (Sort); eliminate all unnecessary tools, parts, and instructions.
  • Seiton (Straighten); a place for everything and everything in its place.
  • Seiso (Shine); clean the workspace, and keep it clean.
  • Shitsuke (Sustain); don’t revert to old ways, continue looking for better.

I skipped Seiketsu (Standardize).

Each team I’m working with is establishing their own natural, effective way of working within a common framework. I don’t believe seeking further standardization is something that will help them right now. (Although I’ll be setting up a community of practice for sharing successful and failed ideas shortly).

We added a small new change to our board, stand-up and/or tracking every day over a week – generally this involved scissors, tape, markers and old cereal boxes!

We reviewed & cemented the successes and added a couple of bigger changes during our retrospective.

Here’s the current result. – I’ll post a photo in future (I’m writing this at home on the weekend).

scrum board with placeholders

Using the peripheral space for useful stuff

Clearing the decks, having specific right-sized places for consumables (colored sticky pads  pens, story cards) and swim lanes for support items & cleanup tasks solved a number of problems quickly…

  1. The support/new work split is clearly visible and we’re able to balance it better.
  2. For new work, we’ve reduced the number of planned stories on the board to a minimum and have a clear priority order.
  3. The team are now in the habit of making all new tasks visible on the board without interrupting the flow of the stand up – it’s not such an effort to add new tasks any more.
  4. There’s always enough of each coloured sticky pad and some pens right by the board. If the holders are looking empty, one of us restocks.
  5. Progress and status are clearly visible at a glance so we know if we have a problem and whether to adjust.
  6. The team felt like things were under more control. Allowing them to focus on doing their best work and to try other improvement & collaboration activities.

When the team started their next round of sprint planning we had another 5S lesson – Seiri…

The great thing with this team is that all stakeholders are on-site and easily accessible. Having faced a painful hurdle on their previous sprint with a story that turned out to be significantly harder than expected, they discussed and adjusted priorities with their sponsor.

They pulled the part-completed story off the board, moved it right down the backlog and picked up something cheaper.

The team completely reset their board at the end of the sprint – even with work started or planned but unfinished – just to remove all the noise.

Interesting (but obvious) side-note – Perceived value is influenced by perceived cost. If something looks too expensive, previously less-valuable items become worth discussing and implementing.

IF the team were going to continue unfinished work, they would re-evaluate the remaining and  completed tasks, understand why they didn’t finish, learn and re-plan appropriately rather than assuming what’s on the board was correct.

Longer-term, I’m expecting this approach to also encourage more flow/pull-scheduling of stories. I’m aiming for us to only pull new stories onto the board when there’s a to-do slot free.

Finally I stepped back for a while to let the team self-organize and see if they could sustain the changes (a trick from my friend Carl).  About 80% of the changes have stuck with no support needed. Progress tracking and clearing the board down have needed some revisits. There were specific causes for these falling over but they’ve been recognised, addressed and are back on-track again.

In Part 2 I go into more depth on each of the areas of the board, what they do and most importantly why use them.

Dietary Manipulation (Part 3) – Coffee

Posted on by
Reply
Reading time ~ 2 minutes

This line of articles just doesn’t seem to want to die!

Okay, so….

Today is day 3 of the filter coffee machine near where my team sits being broken despite repeated repair attempts.

There’s one on the floor below but that means carrying full cups of hot coffee all over the building – it seems most of us have been drinking alternatives most of the time for a few days.

We weren’t really aware of the effect this was having on us until we spotted it yesterday!

Sat in a team meeting. A usually energised team were so lethargic we actually called the session short, had lunch and took a walk to the pub to wake ourselves up!

If that’s the impact going cold-turkey on filter coffee had on a 30 minute team meeting, I’m dreading seeing what it did to team productivity this week.

However…

Anyone that’s given up smoking will know that by day 3, the worst seems to be over, as nicotine levels in the body drop further and withdrawal dies down.

Today had been my most productive day all week.

  • It might be that I’ve finally capitulated to instant caffeinated coffee rather than very good – but not very caffeinated – tea.
  • It might be that the half-life of coffee in my system has dropped below withdrawal symptom level.
  • It might just be that I’ve gotten over a momentum hurdle on some of my work.

Chatting to another of the team, their sentiment is the same so I don’t think it’s just me. Now we’ve recognised the risk, we’re making the effort to reach the other machine.

Regardless – it’s a little disturbing (but in hindsight quite obvious) how much the continuous supply of good filter coffee impacts the energy levels of a development team!

Advice to managers – good coffee is a necessity, not a perk.

Have We Started Yet?

Posted on by
Reply
Reading time ~ 2 minutes

Here’s a great, simple tool for tuning and visualising WIP (Work In Progress) on your team.

Add a “Next” column between “Todo” and “In Progress” on your Scrum / Kanban board.

Team members only pull items into “In progress” from the “Next” column – and only when they actually start work on it, not when they plan to work on it.

Keep the “Next” column itself deliberately only wide enough for 1 task and replenish this with team input on priority/necessity when the “Next” column is empty.

This simple clarification has a huge impact on knowing who’s really doing what, when something has actually started and what we intend to do next.

For one of my teams I’m working with at the moment, this small tweak has had a knock-on impact of dramatically reducing the number of items in the WIP column to at most 1 per person (many tasks are covered through collaboration), per type of work (new features, debt/cleanup & support).

The team now use the full width (3 tasks wide) of the WIP column to indicate coarsely how “done” an individual task is (rather than filling the width of the column with potentially active tasks) which in turn has given us all much greater visual clarity on whether we’re actually going to reach our next goal – even when sat 10-15 feet from the board!

Here’s an example of what we have…

card wall picture

It’s really rewarding to see a team that instinctively “get” the value and benefit of simple visual management.

Give this a try with your teams and see how it works out.

I’m pretty sure next sprint we’ll only be pulling 1 story onto the board at a time – I’ll post about this in future.

 

Arrrr – Thar Be Treasure in Cambridge!

Posted on by
Reply
Reading time ~ 2 minutes

I’ve been quiet on the writing front for a couple of weeks as I get up to speed with my new job. In the meantime, I wanted to share one of my leaving presents from my former crew and some software community highlights from this fantastic city.

In order to protect the innocent, I’ve had to do some minor editing to anonymize some of the content however my 2 favourite landmarks are still nice & clear as is some of the entertaining corporate commentary.

Credit to Stoots The Quartermaster and Squelch the Ship’s Artist/Brawler for this gem!

The Captain's Treasure Map

Treasure! – click for a full-size version

For anyone thinking of joining the local treasure quest, there’s a fantasic, forward-thinking software scene in Cambridge (UK). I’ve been up here for 7 years now and I’m still having a blast.

The team at Software East are busy putting on fantastic events and following the huge success last year, the second “Agile Cambridge” conference is happening in September with keynotes from David Anderson & Jurgen Appelo.

For those considering a career here; whilst not exhaustive, the Cambridge Network is a great place to start looking, and for an example of the kind of companies that make working in Cambridge special, take a look at these guys.

Meanwhile you can often find a large contingent of my former crew at The Portland Arms on a Friday Lunchtime. Every other Monday a few of us head down to The Old Spring for the now regular “Agile Cambridge Monday Meetup” and once a year the Cambridge Beer Festival becomes a regular lunchtime and evening haunt (and a recruiting/networking hub) for much of the city.

Of course there’s all the usual culture, architecture, students, music and everything else here but you can read about all that from the usual tourist guides.

 

Swimlane Sizing – Complete & Fast Backlog Estimation

Posted on by
12
Reading time ~ 5 minutes

Thanks to Adrian Wible for sharing this tip when I was in Nevada a couple of years ago. It’s now one of the most powerful simple tools I have at my disposal. I use it frequently with teams to rapidly size their backlogs and recalibrate their sizing.

This can be used with teams at any experience level but works with least pain if teams aren’t used to story points beforehand.

Teams new to story-points (or even working together) often get hung up on the numbers themselves and instinctively want to start converting to hours, ideal days, elapsed days or similar. The value of story points for teams during estimation sessions is in the relative sizing, not the actual size.

This approach keeps numbers entirely out of the mix until the end and allows participants to focus solely on the relative sizing of stories.

Once we’re over the relative sizing hurdle, adding numbers becomes a straightforward activity.

I’ve done this same activity with electronic tools but I’ll describe the manual version here…

Preparation:

Get your deck of incomplete user stories on readable cards or stickies.

If you also have a couple you have completed, these are useful triangulation points but not mandatory

In a room with your team, get yourself a large flat clear surface. I recommend tabletops in the middle of a space as you can swarm your whole team around all sides – this isn’t so simple with a wall.

Using string or sticky tape mark out 8 “swim-lanes” on the table (Requires 7 lines)

Your table should look something like this.blank table

Don’t put any labels on the swim lanes

 

 

 

 

Activity:

Divide the deck of stories amongst your team and ask members to spend a maximum of 5 minutes silently placing their stories in the swim lanes – with stories of increasing size from left to right.  E.g. smallest stories in the left-most lane.

You might want to lead the team through the first 1 or 2 random stories to give them some anchors or triangulation points to work from.

Don’t say anything about story points or numbers, if anyone asks just reiterate we’re looking for size relative only to each other.

If needed; guidance on complete unknown stories at this point should be to assume they are “very large”. The next round of sequencing will allow others to move them if they feel confident in doing so.

Once all stories are placed, you’ll probably have some “clumping” of stories, as in the table here. (assume X’s are story cards).

Give the team 5-10 minutes to again silently move any stories to different lanes where they feel their size relative to others makes them more closely aligned to those in another lane (stories must be wholly in a single lane – no overlaps).

Encourage team members to quickly look at and consider the location of each story on the table.

A team may occasionally find a deadlock where a story is “stuck” moving back & forth between lanes, you may intervene, pull the card out for discussion or allow the time boxing to encourage the card into a single location. Generally if there’s uncertainty, I choose the larger option but the last step of the process will resolve these.

Your table should now look something like the example here.

Once all the cards are placed and reviewed, ask the team to rate their satisfaction/confidence on the relative sizing and placement of the cards (use a scale of 1-5). For any team members indicating a low satisfaction level (1 or 2), ask them to describe their concern and for the team to decide upon how to act (either move a card or validate its current position). Time box this to 2 minutes per team member if possible. Use this opportunity to re-place any deadlocked stories – if a team really can’t decide, be cautious and go for the larger option.

Once relative sizing is agreed with a reasonable level of confidence for the whole team it’s time for a couple more questions.

For all the stories in the left-most column, do you think you’ll be working on anything smaller?

If the answer is “yes”, call this column 3 or 5; if the answer is “no”, call this column 1 or 2 (a single number from these options – use your judgement and instinct).

Now assign remaining numbers across the top of the columns using a subset of the common modified Fibonacci sequence used for story point estimation: (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, !/?)

This will give you a table of stories much like one of the following…

 

 

 

 

 

 

(I usually prefer the far-right column remains unsized to be broken down further to make it clear that this is a coarse exercise and cannot be used for commitments).

That’s it! You’ve just estimated & sized (using story points) your backlog in well under an hour.

It’s coarse, quick and dirty but chances are that even when you learn more, most of these won’t change relative to those in other columns .

More Depth:

The use of “silent sorting” is a powerful practice for agile teams. It removes debate and ensures focused thinking however in this example its use coupled with the lack of numbers is to avoid a common problem with inexperienced estimation teams during planning poker exercises known as “anchoring”. This is where an individual on a team will speak up with their view on what size a story should be before the remainder of the team have selected their view on size therefore influencing and anchoring all others estimates for the same story to a given point.

If you reuse this approach for additional rounds of backlog items I recommend preserving some of the older stories in the swim lanes to provide triangulation points for newer stories. Without these anchors your team’s velocity and estimation may see large shifts and greater unpredictability based on the shape of the new backlog.

Teams will quickly get used to which numbers match which lanes. This practice is still valuable however you may need to encourage teams to remain focused on relative sizes and not the numbers.

I generally hold the following views (and have found these actually do transfer well across teams)

  • 5 is typically a “medium” sized story for a sprint
  • Anything greater than 8-13 requires further decomposition
  • Seriously consider also decomposing stories of size 8-13
  • Anything greater than 20 is in reality an unknown needing further investigation and decomposition before it can be sized sensibly.

These views can in themselves anchor others’ estimates towards some specific numbers. As a facilitator an awareness of the range of numbers used and their meanings is useful but be cautious that this information does not influence the outcome of the team’s process.

Update: March 2015 – 4 years after posting this article it’s still the second-most viewed page on the site. I’ve now added a second article offering some more theory to help explain how swim lanes and story points hang together with traditional estimation concepts.

Acting on Difficult Advice

Posted on by
Reply
Reading time ~ 2 minutes

There’s a time & place for external consultants in organizational transformations. They can help you in unique ways but you have to pay attention and act.

Some years ago I had a game-changing conversation with an exceptional guy we’d hired in. Everyone loved his straight-talking, he had a way of talking common sense that resonated all the way from individuals on teams to our execs. We knew that one or two conversations would never be enough so I asked him to join us permanently – he was exactly what we were looking for.

His response (paraphrased)

“I’m flattered and I’d love to – but one of the great things about what I do is that I can tell you the painful things you don’t want to hear – knowing I’m right – without having to worry about losing my job and knowing my boss has my back.”

We managed to get him to speak to our local leader at the time about what we were trying to achieve.

“…you do know that the level of change you need here is going to have an impact on productivity for a while right? Are you ready for that?”

“…absolutely not, we have to complete our transformation with no impact on our current delivery commitments to the business”

It wasn’t that his advice was wrong. It was that the boss didn’t feel safe to take the hit. Needless to say the rollout stumbled. Fortunately we knew it was coming and corrected as best we could.

If you invest in a consultant, It’s your responsibility (and risk) to act on their feedback. Be prepared for painful input and… please …do something with their advice – that’s what you paid them for in the first place right?

If there’s a risk or impact, weight it up, bring your stakeholders in, explain the situation and reset expectations. You are empowered to act but here’s the trick you’re missing! It doesn’t all have to be just on your shoulders.

In fact, you don’t have to have the difficult conversation yourself at all, you’ve just paid for someone to do it on your behalf. If they’re really that good, they’ll be more than capable and willing to do so and probably more credibly than you.

That kind of ROI is priceless.