Distributed Management and Work-Life Integration

Reading time ~ 4 minutes

This was posted on my office wall recently…
Dilbert.com

It brought home what the last decade of international teams and ubiquitous business email access has achieved for many of us software professionals.

Since the late 1990’s I’ve worked in globally distributed or virtual teams. There’s a huge amount of positive things to be said about the working experiences I’ve had with these teams over the years.

  • My cultural boundaries have stretched
  • I’ve had opportunities to work with great people all over the world
  • I’ve learned a mountain of cool stuff
  • I’ve met hundreds of new friends
  • I’ve visited amazing places
  • and…

  • I’ve left my family at home most of the time.

Sadly small children and transcontinental business trips don’t really mix. My family have been incredibly tolerant and I always look to bring something back for them. They have a pretty tough ride but they support what I do and I appreciate their patience.

However…

With teams in the UK, India and the US there’s almost always a full working day of support, conversations and questions that happen outside the normal working timezone. As the pressure to deliver and support these teams has increased I find myself checking my work mail when I should be attending my family.

I recently reached the point where I was clearing my emails down during public holidays so that I could filter through and achieve something when I got in the following working day.

I check my email during breakfast at 6 or 7am and reply to things that came in during the US evening or India morning.

I commute to work and check my mail again to find another series of mails from India and a few UK early starters.

I check my mail when I get home from work to respond to anything urgent that came in during my commute.

I check my mail before bed in case there’s anything new that will derail my plans and priorities for the following day or that I can respond to before the US working day is over and 24 hours are lost on a decision.

(I also occasionally make time to write this blog, enjoy my family, study and maintain the house)

If I don’t clear my morning and evening international backlog my day job doesn’t have time & space to get done but this is all at the expense of other parts of life.

So how do I get things back under control?

WIP Limit vs Buffer Overrun

Here’s where Scrum, Lean & Kanban meet personal time management…

Set yourself a WIP limit. When that’s full, decide what doesn’t happen or has to be traded out. If you don’t make a decision, something will fall on the floor and chances are you’ll have a pile of half-done stuff. (a buffer overrun).

Build a visible backlog and keep it groomed. When new work comes in, prioritize and size it. (Take a look at the Covey Matrix as a powerful means of prioritizing). If I don’t have clear visibility to my backlog of work (not just my email inbox) then once again my mental buffer overruns and things fall on the floor.

This is where my problems are – relying on my mental buffer and inbox to be my primary and secondary backlogs!

Determine how big your backlog should be and whether it should be tiered (e.g. week, month, quarter). Just like a mature agile team, don’t build a backlog that’s bigger than your planning (or thinking and coping) horizon. If it’s important it’ll come back when you have the capacity.

Next, just like your agile projects, get your backlog visible. When new work comes in, take your stakeholders to the backlog and have a prioritization and trading out conversation.

Some things will have time deadlines and some of these you can’t avoid so what else has to give? If you have more items with time deadlines than you can cover, take your stakeholders back to your backlog and force the prioritization discussion again.

I recommend pipelining work into “emergencies“, “small“, and “not-small“. This is enough to provide an interesting mental mix but aim to limit multi-tasking to a maximum of one item in each area. (Clarke Ching has some fantastic insights and demonstrations on why multitasking is evil).

It’s also worth rewarding yourself. You’ll find items that fall in the “distraction” quadrant of the Covey matrix are often where some rewards lay hiding. Identify a few interesting, fun things and make sure they get some airtime in with all the priorities to pay off some of your priority fatigue.

Simple right?

OK, this won’t break the email addiction but it will help manage the personal backlog and priorities more effectively.

When it’s personal rather than a project this seems so much harder.  With all that time teaching teams to trade out and prioritize, it’s time I started to eat my own dog-food.

Epilogue: This article has been waiting in my backlog for a couple of weeks to be rounded off before publishing. Yesterday the manager I’m pairing with planted a large kanban board by my desk with a list of the top priority management goals and activities that we have on our planning horizon right now down the left hand side and the associated tasks and states all prepped up! It’s not our entire backlog but it’s well more than we can achieve in the next 2 weeks and covers all the known top priority things.

Now it’s time to start managing the load properly again.

Escaping the Oubliette (Part 1a) – Debt Prevention

Reading time ~ 2 minutes

This is a partial re-post of Escaping the Oubliette (Part 1). I’ve split the article into smaller readable components.

Great, I’ve got my incoming defect strategy nailed,

Now how do I prevent defects and debt in new code?

In 5 words…

Continuous attention to technical excellence.

Here’s my top 7 (there are plenty more)

  1. Acceptance Criteria – Be really disciplined on your acceptance criteria & acceptance tests, team up with Analysts, Testers, Product Owners if you have them and attack your stories from every angle. A good approach to this is a “story kick-off” where the whole team dismantles a story before starting.
  2. Thinking Time – don’t just start coding right away, task things out, try the 10 minute test plan, discuss your approach with your peers and for more complex or large items, try the “just enough design” approach.
  3. TDD – It’s hard to start but has an immense impact.  I’ve just seen a team complete their first project using TDD. 3 weeks into their final round of post feature-complete testing, their defect run-rate hasn’t had the testing spike seen on prior projects. In fact they’re keeping on top of all new incoming defects and have time to start paying down the historic backlog.
  4. Pair Programming – Do it in half-day trial chunks if you don’t have the stomach for going full-tilt. I’ve performed remote pair-programming with colleagues across the Atlantic using decent phone headsets and online collaboration tools for hours at a time. The net result of 2 days of remote pairing was finding and fixing about 10 extra defects in a thousand lines of code that neither of us would have found coding alone.
  5. Peer reviews – there is still a huge space for these in agile teams. But here’s the thing. Be really tough. A peer review is not a hurdle. It’s a shared learning exercise. Functional correctness is actually the smallest component of a peer review. You should trust your developers that far. But there’s a whole series of other aspects to review. See the joy of peer reviews.
  6. Small tasks – I once worked with an outsourced team who when taking work would disappear into a hole for 2 weeks and return with a single task in our configuration management system containing edits to 200+ files and multiple condensed edits to the files. My rule of thumb is one reviewable task per activity. If you’re going to add new functionality and refactor, that’s 2 independent tasks that can be identified and reviewed separately. This means you should be able to easily deliver 2 reviewable, closable tasks per day.
  7. Fast Builds – make it insanely simple for a developer to perform an incremental build that validates new code against the latest main code line. (small tasks are a big help here).  This includes the right subset of unit and functional tests. Aim for a target of a 30 second response time or less between hitting the button and seeing the first results.

In the next article in this series I’ll focus on “Tailing” – How do you start reducing the old defects.

Breaking The Seal (Part 1)

Reading time ~ < 1 minutes

Following on from my last post; “Communicating in Patterns” here’s the first of my regularly used concepts – alluded to in “Don’t Open More Barrels Than You Can Consume“.

Name: “Breaking The Seal” or “Cracking Open” etc.

Analogy: (This one makes me think of the campfire scene in blazing saddles even though it’s only partially relevant)…

You only open the lid on a new can of beans when there isn’t enough in the current can to feed the family.

Underlying Concept: One of the key ways of delivering maximum throughput on teams is to limit WIP (work in progress/process). Teams inexperienced at this tend to start additional items or “break the seal” on new work when blocked or when a team member has completed their last personal task. We need the team to take a hard look at the work at hand, consider swarming around a given item or story and only open the lid on a new item if there really is no additional value to be gained from another member of the team helping out on the current top priority item.

This works on many levels – here’s a few…

  • Every time you open a new can you risk not finishing it all and having to throw the leftovers away.
  • Opening too many cans and forcing the family to eat them all causes bloating.
  • Eating excess beans takes longer and leaves no room for dessert.
  • Unfinished cans in the refrigerator tend to get pushed to the back and go moldy.
  • Very few people like cold beans for leftovers. (actually – sometimes I do)

Don’t Open More Barrels Than You Can Consume

Reading time ~ < 1 minutes

One of my colleagues is a Theory of Constraints guru so this stuff comes naturally to him but even so, his casual remark on a conference call not long after joining us stuck with the whole team. It’s now a poster next to my desk so that all my drive-by visitors can see his wisdom too.

“Starting more work doesn’t mean you’re going to get any more finished.”

My boss also repeatedly says:

“We need to see a few things 100% complete, not a pile of stuff 80% done”

I have my own pattern for this that I’ll be posting pretty soon – the title might be a bit of a giveaway.