When Everything is Important But Nothing is Getting Done

The typical challenge

At the end of the day, there were 300+ projects for a combined product and engineering team of almost 40 people. After review, some projects ended up being duplicates, some requests were already closed out and others were no longer necessary.

Create a Unified View of All Existing Work

The goal was to create clarity and visibility of all of the asks, all in one place… The mantra was: “if it’s not on the list, then it doesn’t exist.” Even though we knew the list was unmanageably large, we encouraged people to add more at any point.

Categorise each project with urgency and impact

When you commit to quantifying urgency and impact, you create a shared language as to why you’re working on something: Urgency is a byproduct of deadlines and dependencies. Do you need something tomorrow, or can you get it in two weeks? Is a project a dependency for something else to move forward? Impact is a combination of potential value created versus the likelihood of achieving that value.

Impact vs Urgency

• Low urgency, low impact - avoid
• Low urgency, high impact - strategic bets
• High urgency, low impact - treadmill, no progress
• High urgency, high impact - get it done now

Focus on the high impact, high urgency projects. Avoid low impact, low urgency projects.

Getting work done

“Start With Project Number 1, Work on One Thing At a Time, In Order, Until It’s Done” Once there was a single queue/stack rank, we began work on projects starting from number one and working down the list.

Too Much Work In Progress

We learned the hard way that there was a direct relationship between the number of concurrent things you were trying to do and the increasing inability to complete any of them. This is called the “Work In Progress” (WIP) problem.

Parallelization vs independence

As I alluded to earlier, when it came to effective parallelization we learned the hard way that the size of your teams didn’t matter. What was important was the level of independence of your teams.

Create A Clear Finish Line (Definition of Done)

1. Did it solve the user problem?
2. Was it deployed to production?
3. Has it been in use for a ‘long-enough’ period of time?

Three types of software teams:

1. Delivery Teams Standalone teams with no relationships outside of the engineering organization
2. Feature Teams - Output-focused cross-department teams — think owning a group of features such as a “chat stream” or “feature x”.

Outcome teams

Generally speaking, you want to be aiming towards the third option, Outcome Teams. This is because this is the most bang-for-your-buck type of team organization as they are most directly tied towards driving business outcomes

Ownership, features and independant

Ownership of one outcome and however many features are necessary to achieve that. These teams work well when they are full independent (including presence of other departments’ stakeholders) and can work on many features on an as-needed basis.