Weeknotes #13 - Leading & Lagging Indicators

Leading & Lagging Indicators

The discussion around metrics is a common one when working with teams, and this week was no different. In one sprint review this week, the team running the review presented a scatter plot showing an average cycle time of 10 days for their backlog items.

Now, I have no problems with this as a metric, however used in isolation it can be harmful, mainly as it is a lagging indicator of flow — it’s information that is only available after something has finished. To balance that, you need to use a leading indicator. A powerful metric so few teams use is Work Item Age — which shows the number of elapsed days since a backlog item started and today's date.

Stuck Work Chart — Each bar = a work item and how long it has been in that column

In this scenario now we can clearly see that whilst the average cycle time looks good, the flow of the current WIP is a cause for concern. We now have greater transparency around our flow of value to the customer, and what items we need to focus on/actions we can take to move these items forward.

Typically if this was a common pattern in a team I’d offer to suggest it once a week as an alternative way to run a standup. It shouldn’t be treated as an inquisition (note: hide the names on any dashboards to avoid this trap) but a team discussion on how we can get ‘flowing’ again.

Embedding Agile in the Portfolio

This week we had a quick sense check at the end of our team sprint review around our OKRs for this quarter around embedding Agile in the portfolio.

It’s good to see we’re on track with validating some of our hypothesis around WIP and having empirical evidence to support the changes.

One cause for concern however was looking at one delivery portfolio and the active WIP with the target dates for completion, and forecasting how many items were likely to go over our portfolio 90-day service level expectation (SLE). Taking the WIP age so far and target date minus today's date, it currently looks like 72% of the portfolio is due to go over this 90-day SLE. Obviously this is worrying for us and the Lean PfMO, but it does give us a chance to be proactive and find ways to slice work items down to be smaller. 

A conversation with just one person alone yesterday found that two items could be moved to done as the scope was being treated as every line of business in the company, whereas a slicing exercise was to deliver to respective business lines and learn from the feedback before commencing future work. We’re hopeful that there are more instances of these in order to improve the portfolio flow.

Impediments

Impediments, blockers, issues or whatever your preferred term of choice is are common when trying to adopt new ways of working in an organisation such as ours. One thing that’s really important in modelling the right behaviours is demonstrating Agile leadership in removing these challenges. However, in an IT estate of >600 applications, and trying to spend time determining what’s fit for purpose in shifting from Project to Product, it’s impossible for myself and our team to get involved in removing every single challenge a team faces. 

A discussion this week lead to six or seven issues being reeled off to me one by one, as well as multiple cc’s on emails/chat messages. After probing one or two I found a common theme around the team having not really done anything in terms of trying to tackle the issue and/or understanding the needs of others who may be slowing them down.

Good Scrum Masters / Delivery Managers should help teams to understand that if they find an issue, they have to own the resolution first, and try everything they can to remove it. If they’ve exhausted all options then they need to be able to present what the issue is, the approaches they’ve taken and the impact (ideally quantified) it is having. To engage senior leaders in the role then #DataOrItDidn’tHappen makes the point 10x stronger than anecdotal, one-sided arguments.

RIP Martin Burns

I was sad to read on Monday on my Twitter feed about the passing of Martin Burns. I didn’t know him personally, but always enjoyed the interactions I observed on my Twitter timeline, in particular his staunch, passionate yet well articulated points in defense of SAFe. I had the pleasure of finally hearing him speak in person by attending his talk on 10 Years of Big Room Planning at the Agile Business Conference last year. The number of tributes from the community over social media and at conferences all over the world this week is testimony to the impact he had as a person. There is a GoFundMe open for donations. Thank you Martin for providing inspiration to those who you didn’t even know, you will be sadly missed.

Next Week

Next week I have the quietest week in a while, so lots of free time to work with teams. I’ll be adding to our ways of working (WoW) backlog with some ideas on the next things we want to tackle as well as working on slicing some of that 72% down to hopefully reduce our WIP and cycle time.

Weeknotes #01 - The Week That Was!

Why weeknotes?

Recently, I’ve been inspired a lot by reading the Weeknotes of both Sam Lewis and Rita Goodbody, who are doing some excellent work with Novastone Media. What’s great about their work is that each week they share their learnings (please give them both a follow!), both being very open around challenges they’re facing, accomplishments they’ve made each week and share their stories. After getting into the habit of checking Twitter on a Friday afternoon for their latest posts, I figured why not give it a try myself. 

Special mention to Sam who I have known for a while now through the Kanban world, who first introduced me to the concept. 

Like him I really like this point:

Writing creates a basic feedback loop. Before getting feedback from other people, you can literally get feedback from yourself.

So yes, this will be something I’ll be trialling for a bit…

Helping others learn, whilst learning myself

This week I ran a ‘Hands on with Azure DevOps’ session for our Project Management group. Having been asked by another area of PwC to run a similar session in March, I offered out the opportunity for the PM’s to be the first to experience it…with the proviso that it was the first iteration so not everything would work smoothly! 

One thing I have learned in adoption of new tools is just showing how to use it isn’t enough, so I created a sandbox Azure DevOps collection/organisation setup each attendee with their own project, then showing them how to do something, then they get to create their own variation within their environment. I had printed workbooks as a supporting tool (in case they got stuck), but deliberately only had enough for one per pair, forcing a bit of collaboration. A few things went wrong, mainly in how I structured the first bit of the course by having them create multiple teams, on reflection I realised that keeping it simple and using the default team would have been better. Generally, people said they really enjoyed it and that it has helped them learn a lot more, with also some feedback that the pace was maybe a little too quick, so there’s a bit of learning for me as well around my delivery.

Training, training and more training

The rest of the week has been mainly filled with continuing internal enablement through our team running 1-day Agile Foundations courses. 

On Tuesday I paired up with Marie to run a session, and yesterday myself and Dan delivered another. I’m shocked that so many people have signed up (out of a function of 220 people, 180 people will have attended by the end of March), as we were very clear in wanting people to “pull” the training, rather than be forced to attend. One person who attended yesterday said in the intro that they had ‘high expectations’ because they had heard so many good things, which was nice to hear and set the tone for a good day. Based on the feedback we received it seems all attendees really enjoyed it. One individual let us know that it was “probably the best training they have been to in years” which, whilst very flattering, does make me wonder what other training they have attended!

Mid-flow on my favourite topic (metrics)

The course itself is very hands on, we’re keen to give people the principles and also dispel some myths that Agile = Fast and/or Agile = Scrum, something which is a bit of a personal bugbear of mine. We introduce the manifesto and the principles then support that with a game of Agile Eggcellence, then cover Scrum before lunch (using the Scrum guide — not some internally warped version of Scrum) as well as the often overlooked technical excellence aspects such as CI/CD. After lunch we introduce the Kanban method using Featureban, then go into User Stories, Minimum Viable Product, again supporting that with some examples and the Bad Breathe MVP game.

Final section of the day is centered on business agility — here we look at INGs Agile Ways of Working journey (to inspire — not to copy/paste!), the outputs from the State of DevOps report, as well as internal/client case studies. 

The main thing here is in an IT context to open up the discussion around what our impediments are and, more importantly, how can we collectively overcome them. Once that’s done we finish with a game of “40 seconds of Agile” — a variation on 30 seconds of Scrum with some Pocket Scrum Guides for the winning team.

Marie and Dan have both grown into the delivery of the training incredibly well. When we first started these sessions it was myself doing the majority with themselves supporting, whereas now most sessions are split 50/50. 

They are both also great at weaving in their own experience/stories into their delivery which for me, adds a further element of ‘realism’ for attendees. I’m very fortunate to work with them (as well as James and Jon in our team) as part of our Agile Collaboratory team, in particular due to their enthusiastic yet pragmatic approach.

Going for (Agile) Gold

Eyes closed — no gold medal for being photogenic

Wednesday night we held our first Agile Olympics event within one of our London offices. The event was in two parts, for the first half teams were given a case study around product decomposition and had a roughly an hour to analyse a case study and do some initial visioning around the product and producing a vision with various increments as part of it. The second half was a quiz using the Kahoot app, with prizes for the top three teams for both rounds. I was heavily involved in helping formulate the case study and write the quiz, as well as being one of the main judges for the case study outputs from the teams. It was a really fun event, with nine teams across different business lines entering. All of them did a great job in focusing on user needs and business outcomes for their product, rather than outputs and making a list of features. Some Partners appeared to be a bit upset at their quiz performance and demanded copies of the answers which, given the quiz contained a number of anti-pattern questions (what is Sprint Zero, etc.) shows to me we still have work to do internally. We’re hoping this is the start of many events where we can grow the Agile & DevOps coaching network across the UK.

Project to Product

Over the Christmas period, I found myself immersed in Mik Kersten’s Project to Product book. For me, the book is brilliant and very much represents the future of work for large organisations that they need to adopt in order to remain relevant/successful. Product thinking and the whole #NoProjects movement has been a keen interest of mine in the past two years, with us slowly starting to introduce some of that thinking internally. The past few weeks we’ve been formulating our first Value Stream which, for our context will be a service (with a set of long-lived products) or a major product, with multiple teams within the value stream supporting that delivery.

One of the things we’ve been looking at is the roles within a value stream, whilst teams will self-organise to choose their own framework/ways of working, what should be the role of the person ‘owning’ that value stream?

The working title we have gone with is a Value Stream Owner (VSO), with the following high-level responsibilities:

The owner for the Value Stream must be able to manage, prioritise and be responsible for maximising the delivery of value for PwC, whilst staying true to Lean-Agile principles. 

Specifically, there is an expectation for this individual to be comfortable with:

• Small batch sizing (MVPs/MMFs), prioritisation and limiting work in progress (WIP)

• Stakeholder management and potentially saying ‘not yet’ to starting new work

• Learning and understanding flow metrics, using these to gain better insight and improve the flow of value

• Inspect and adapt — You will be familiar with the concept of ‘inspect and adapt’ and showcase that in your work

• Focusing on business outcomes over outputs

• Ensure that continuous improvement is at the core of everything you do and that you encourage all members of the value stream to be on the lookout for new and better ways of creating value

It’s proving to be challenging, mainly due to finding suitable groupings for such a large IT estate, but we’re getting there…hoping to formulate the team(s) in the next 2 weeks and start working through the Value Stream backlog.

Next week

Next week I’m heading out to Wroclaw, visiting one of our suppliers which should be interesting (I get to meet their Tribes — and no they are not a music streaming company!). Travelling abroad always presents a challenge for me, I don’t like compromising on not attending key meetings in the UK just because I’m out of the country, so will be a delicate balancing act of getting value from the trip vs not getting behind on other work. I’ll be sure to share next week how that goes.