Tag Archives: priority

Distributed Management and Work-Life Integration

Posted on by
Reply
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.

Priority Fatigue

Posted on by
2
Reading time ~ < 1 minutes

This came to me at 5am after a bout of insomnia…

In the last few years the concept of technical debt has really taken root. Teams discuss it and use it to ensure important leftovers get cleared, not just business-critical priorities.

Here’s a fresh verbal anchor…

“Priority Fatigue” – The wear that sets in if you do nothing but focus on the priorities of your products or leaders all the time.

If you’re using Scrum or Kanban; chances are you’re working through some kind of prioritized backlog of work. Most Scrum practitioners are aware that despite iterations being called sprints the team are actually running a marathon. Every now and again your team needs to take a breather and at the end of a release they need proper recovery time.

Clearing technical debt is a common way of recovering. Another approach used by forward-thinking organizations is to have periodic innovation days or weeks where everyone “downs tools” and does something interesting instead. Good team-building days or activities are a third option.

These are all ways of addressing priority fatigue on a team.

Weekends and holidays are the personal slack that we use to pay off some of our individual priority fatigue however many of us don’t actually rest any more.

Our lives are so full we don’t have time to recover. In fact, many people now continue (at least partially) working even whilst on holiday – it’s frequently expected these days.

In the same way we relieve priority fatigue for teams, consider taking time to step back reward ourselves as individuals in innovative ways. If nothing else; take some regular time out to do something interesting even if it’s not important. **

**Caveat: don’t overdo it! Strike a balance with your priorities.

The Oubliette

Posted on by
Reply
Reading time ~ 2 minutes

An oubliette is a particularly unpleasant dungeon characterized by a well-like opening. During medievil times these were used “to forget” (oublier -in French) about “unwanted guests”.

Imagine how you’d feel stuck at the bottom of an oubliette?

It’s probably one of the least inspiring places to be. Expect feelings of despair & hopelessness. You might find yourself asking “What do I do?”, “Why do I bother?”, “It’d be easier to just curl up and let it end”.

I’ve seen development teams end up in similar situations. Untamed defects build up around them over a period of years until it’s too late. The backlog is so deep there’s no hope of getting out. Even committing the entire team to just fixing bugs for over a year won’t save them.

It starts with a brittle codebase. A prior combination of poor architecture, lack of clear standards, lack of debt management and years of too much corner cutting. Often the underlying culprit is repetetive “business pressure” with a team that have not been empowered to say no. This mountain of cut corners and poor decisions offends the sensibilities of all but the most cavalier of developers but once the pit starts to get deep and squishy, what incentive is there to improve?

Your business cannot see delivery of features sacrificed to refactor the codebase, it adds no business value!

The gradual drip drip of quality problems continue as your ability to keep up with demand for new features slowly leaches away, the team slows down further, it costs more and takes longer to develop as the business piles on the pressure for even more new features in less time.

The oubliette spirals towards oblivion and like a prisoner at the bottom of the well, your team and codebase become starved of quality.

Don’t let this happen to you.

(Here’s the first part of how to escape and prevent the oubliette)

Blame

Posted on by
Reply
Reading time ~ < 1 minutes

When your project goes wrong because you’re dependent on another team, whose “fault” is it really?

  • When did you identify the risk?
  • What did you do to mitigate it?
  • What relationship did you build with the team you’re dependent on?

When did you start really collaborating to resolve the dependency?

Too often we throw our problems over the wall and blame the people that aren’t there to catch it for our own laziness.

  • Are we too lazy?
  • Are we too busy? (what else is more important?)
  • Are we secretly looking for someone to take ownership of our problem?
  • Are we cynically looking for a scapegoat?
  • Are we just incompetent?

Think about government lobbyists – they spend their entire time fighting for what they need to achieve…

If something is that important to the success of your goals, why aren’t you sat next to the people you need it from making sure it’s on the top of their priority list too?

YOU ARE RESPONSIBLE FOR YOUR OWN COLLABORATION FAILURES

Learning to Say “No”

Posted on by
Reply
Reading time ~ 2 minutes

The great thing about working with software development teams is that on the whole they’re a nice bunch of people who just want to get on and do the right thing.

The tricky thing in large-scale enterprise product development is that there’s often aggressive targets pushed through sales & marketing onto product managers.

A common response is to take a shotgun to the enhancement request backlog and ask for everything from the development teams and negotiate down from that point.

Craig Larman & Bas Vodde summarized this brilliantly using game theory in the second of their scaling agility books as the “your fault” game.

Assuming like many large companies you’re faced with the challenge of an annual commitment-based project/backlog and you’ve whittled that down to the best you can do; chances are your product manager will come back at some point through the year having visited a customer or partner and, like Columbo, ask for “just one more thing”.

Agile development is meant to give us the flexibility to do this right?

The typical nice guy response is “well… it’s going to hurt … but we’ll try”…

Great! When your team gets kicked around the room at the end of the year for failing to meet their release commitments, I’m pretty sure I know whose “fault” it’ll be.

FrAgile

So… Time to dig yourselves out of that abusive relationship, get a backbone and learn to say “No”.

OK. Maybe that’s a bit harsh. How about…

“Sure we’d absolutely love to do that but here’s everything we’ve already committed to for you. What would you like us to drop first?”

That still sounds pretty collaborative – but now it’s on your terms.

You’ve also just highlighted that being Agile doesn’t mean not making commitments if that’s what your business needs, it means managing your customers better.

If the previous “we’ll try” conversation is the norm for your teams, chances are this is the first time your product manager has ever been put in this situation. Don’t expect it to be pretty or easy. You’ll need to stand your ground and limit the options available.

I’m a fan of visual management so here’s my take.

  1. Take all the features you’ve committed to already and put them on cards or stickies.
  2. Draw a box around them so that there’s no room for anything else.
  3. Bring your product manager to the table, hand them the new feature or item they want on a card of similar size to an equivalent feature.
  4. Ask them to trade out something so that the card fits.
  5. Once the trade-out decision is made. Confirm any timing impact on the other features.
  6. Optional… (but recommended If you’re in a low-trust environment) Get the decision in writing recorded in whatever your system of record is.

If you can’t get your product manager in the room, do the same thing with excel and coloured blocks representing each feature in a pipeline. Adding a new feature in anywhere in that pipeline extends the end date. If you’re on a fixed-date commitment that means something falls off the end.

Simple?

Give this a try or adapt something similar for your own needs.