So we have a bunch of indicators suggested from our senior leadership team as measures for a program health check.  One of these is something we’re calling “Failure Demand”.

Over the last couple of iterations, we’ve got a first glimpse at this – we know it’s one of the trends we wanted to track, so we started with a simple question to each of our teams:

“How much time (as a %) did your team spend on non-feature work this iteration?”

We asked the teams to keep a track on a day-to-day basis and prompted them with a reminder at the end of the iteration.  Our first check ended up with a range from 20-60% of people’s time spent on work outside the agreed, valuable feature set they’d been issued e.g.:

  • Defects in existing code that needed to be fixed.
  • Maintenance work on our platforms.
  • Faults diagnosis / 2nd-3rd tier operations support for our platforms.
  • Answering ad-hoc requests from people who kept our email addresses over the years and know who to call to get a problem fixed.
  • Trading out a team member – in some cases we have SMEs that we still need to loan to another team, but they won’t contribute to their team’s goal, so we can calculate them as a % on non-feature work for that team (imperfect yes, but it highlights a “failure” of us to cross skill, or ensure features are discrete enough that any team can work on them independent of other teams).
  • Work in the communities of practice / presentations / brown bag sessions / training courses (not failure demand really, maybe something else, but we don’t know how to track it yet).

Then today I thought maybe we could get a bit more visual than simply displaying the average in a bar graph… and I remembered these box and whisker diagrams from high school.  A few more searches and we had a template to build a box plot in Excel.

So here’s our first chart.

We want this graph to converge over time and trend downwards, i.e. trend towards 0% for most teams.

And here’s the box plot template for failure demand if anyone wants it.

More work on features.  The last week we’ve spent a lot of time trying to process the backlog of work into decent features with enough information that any team can pick them up and run.  Today we published v2 of The Pledge…

The Pledge is our attempt to document what we think is the minimal set of information that needs to accompany any feature and it should be generic enough for application across any of our projects (and signed using our team mascot).

Today we looked in more details at where we get our money from.

Initially, we had identified 5 “portfolios” (remember this diagram) –  Front of House; Back of House; External Customers; Lifecycle & Growth; and one portfolio aligned to an existing in-flight project, with a business unit we do a lot of work for.

Over the past few weeks the waters had got muddied – without the regular rhythm of portfolio backlog prioritisations, portfolio showcases and with less than ideal involvement from our business reps – we’d forgotten what a portfolio was, what we were going to do with them and there seemed to be confusion spreading across the floor.  We also told the existing project managers who weren’t in an iteration manager role that they’d be transferred to a role more aligned with managing a single sponsor (a “portfolio”).

Our agenda was simple: Review the initial logic; Take a look at what we had today with in-flight projects + known work in the pipeline; and come up with some kind of happy compromise.

The initial logic:

What’s the smallest number of portfolios possible, where for each we could have a single person who could come to the wall and make a priority call, without having to pick up the phone and go to the CEO for a decision.

When we reviewed the portfolios though, we realised we had many more sponsors and the initial idea no longer stood (although we did agree it’s a valid goal).

Reviewing the current landscape:

We white-boarded out all our current sponsors, across all our current projects in-plan for this financial year (20 in total).  We also took a look at what was coming up (an additional 6 projects on the horizon).

That gave us a list of 10-14 names (depending on whether projects were active / not) with clusters of projects under each.  But the initial intent still rang true – we could call each sponsor and ask for a priority call for work in their projects (what’s the next most important thing for you?); without calling the CEO.  Bonus.

Subsequently, much discussion ensued… We didn’t have answers, but here’s some of the questions we asked:

1. How do we decide the next most important feature in our portfolio?

With 10-14 portfolios to chose from, and effectively 10-14 different buckets of money, it becomes tricky to balance a fair and equitable split of our teams’ capacity across the multiple buckets.

2. Can we squish a couple together to get a smaller total number of portfolios? 

In short, no.  We still needed that one person who could come to the wall and make a priority call without getting on the phone to the CEO.  In each case, we decided we couldn’t squish a couple of sponsors together – they had competing interests and we couldn’t align their motivations (we tried slicing by theme, by product, by technology to try and get some overlaps).

So we consciously compromised on the number of portfolios (too many) to ensure we retained visibility.

We’re hoping that as a few of the carry-in projects drop off, we can drop a couple of portfolios and then it’s a case of maintaining sensibility in future. (How often do we trade off a little madness now on the promise we’ll be better behaved in future?!)

3. How do our sponsors read the wall?

Each portfolio will have a couple of cards alongside it – Sponsor name, + key contacts who have the delegated authority to make priority calls; a list of the multiple projects included in the single portfolio; and some kind of meaningful title.

4. What do the colours mean?

We’ve got 5 coloured cards, which we decided will still reflect the initial portfolios – i.e. where we get our money from.  Although we now have portfolios with different sponsors, there’s a couple of generic areas we work in: Front / Back of House; Lifecycle + Growth (self sponsored); and External customers (where we won a tender, the work will be funded out of that project, but it’s handy to know how many external clients we’re working on).

What’s next?

Wall update, plus the necessary ceremonies to keep it alive.  Et voila, here’s the before and after shots:

Ok so today I learn from one of our team members that they’re talking in code at stand up.  I now have to try desperately hard to keep a straight face in the mornings.

By way of background for you – our team is still in early days, we’re a little dysfunctional (aren’t we all) and stand up at the moment doesn’t have the sense of common purpose that it probably should.  I believe this is largely because we’re trying to combine two groups – incoming work and program management – which were previously separate functions with minimal overlap.  Once something came through the front door for solution design, a project manager was assigned and the work became a project whilst our “presales” team went back to liaising with our customers about their next big ideas.  And so this handover happened many many times over: Onboard, throw it over the fence and deliver.  And that had worked well for us for a long time.

Fast forward to July this year, the two teams are being semi-combined into not-a-PMO function, but there’s some lead time until we start developing up “features” that cross everyone’s skill sets – and so standup and our wall today really reflect more of a personal task list of to-do items, rather than activities we share to achieve a common goal.

Coupled with this sense of “I’m vaguely interested in what my colleagues are working on but it has no relevance to my own work” we do of course also want to drive an outcome and so we’re seeing this behaviour where one personality (not the same one every time) will start to drive to “what are you working on today” or “what are you doing today” and then get down into detail of how we’re going to make this thing happen.

So that’s when a couple of our team started talking in code.

“we’ll give the tree a good shake” and “let’s kick it around for a bit and see what we come up with”  are now code for “how do I get these guys off my back”.  Unprompted, I’ve now been let in on the joke which apparently only started this week and now find myself in the awkward position of trying not to giggle and encourage this recalcitrant behaviour (even though I really am tempted to).


A few months ago I came across the “two hands rule” which we found worked really well in a large team (we had a program team of 20-odd in a single stand up every morning at one point).  It’s a quick, handy way to keep people on track and remind us to talk about something after stand up, rather than trying to cram our whole communication for the day into a single 15 minute time slot every morning.

Today we really properly finished the rewrite of a number of features related to an external client project.  I’d like to post a case study with before / after examples shortly, but need to work out how to protect the innocent first…watch this space.


We made some deliberate compromises in the way we’ve restructured:

* Valuing e2e view and line of sight to the customer over feature size.  i.e. not breaking out into smaller tasks to target a specific technology component, an individual SME or similar; even if we think we could get it going faster across different teams in parallel.

– So that we retain an understanding of what’s important to our customers and encourage pairing / cross-skilling

* Valuing correct features at the program level, over some tough decisions about task ordering at the team level – i.e. the program features are whole-of-team, but epics and stories that make up that feature (which the teams work out themselves) may not have the full slice, e.g. Lab builds vs Production builds split.  We think it’s better to get it right at the feature level first and worry about team practices later.

– So that we encourage teams to work together towards a common goal

* Capturing intent of the whole over clarity of our piece in the puzzle – this work is part of a broader program, for which we’ll deliver an infrastructure component, but additional work in the application layers is required to deliver value to the end customer.  In restructuring our features we’ve chosen to capture that broader business value in the way we phrase the feature, but to limit what’s expected in the build via the acceptance criteria.

– So that our teams understand what’s important to our customers and are encouraged to collaborate and break down the barriers into our parallel constructor teams, rather than putting the blinkers on from the get-go.


We’ve set up a weekly showcase in the form of an open-office “trade show” every fortnight.  Each of our 8 teams has the opportunity to demo their software in their workspace, and wander the floor to drop in on other teams and see what they’re up to.  This our second showcase for the program and the first time we invited business reps.

w00t.  We’re away – first cab off the rank, some cost savings associated with our ongoing hardware contracts.  Not insignificant, although it pails in comparison to the new targets we’ve calculated, but it’s a start!!!



In parallel we’re thinking about the goalposts for measuring our successful transition – first feature complete, first benefits landed; there will be more to come, but it feels great to be able to celebrate lift off after only 5 weeks.