Bert Heymans: How to help a Scrum team define and implement WIP limits in their process, a Kanban starting point

Bert shares a story of a change that affected a small team, of 6 people. As this story starts, we hear that the team was working within the Scrum framework, but they had a testing column in their board what was always full/busy. Bert started to help the team figure out why that was, and what they could do to get out of that anti-pattern. They discussed Theory of Constraints, Single Piece Flow, and Work in process limits (WIP limits), and decided to try and impose a limit to the number of items in the testing column. This proved to be a huge change for the team, and Bert shares some tips on how we can help teams going through similar changes.

About Bert Heymans

Bert is a long time Lean Management aficionado and project management tool specialist, along the way he fell in love with business analysis and teaching business analysis techniques. In 2016 he founded Lean Coffee Ghent and has been at it since.

You can link with Bert Heymans on LinkedIn and connect with Bert Heymans on Twitter.

Bert Heymans: Finding the right level of transparency between a Scrum team and its stakeholders

When we work with teams that are under pressure of a tight deadline, it’s not so easy to find the right level of transparency with the clients and stakeholders. On one side we should protect the team, on the other side, the team needs to be open with the stakeholders to be able to find a solution when it seems the projects are going over the schedule and budget! In this episode, we explore some of the lessons Bert learned about finding the right level of transparency between the team and the clients and stakeholders.

In this episode, we refer to XP Explained by Kent Beck, and the concept of Single Piece Flow, a key part of Lean Thinking.

About Bert Heymans

Bert is a long time Lean Management aficionado and project management tool specialist, along the way he fell in love with business analysis and teaching business analysis techniques. In 2016 he founded Lean Coffee Ghent and has been at it since.

You can link with Bert Heymans on LinkedIn and connect with Bert Heymans on Twitter.

When will we finish? Using data to forecast when teams will deliver…by Nick Brown

When will we finish?

Using data to forecast when teams will deliver…

 

Confessions of a Scrummaster

Before we start, confession time.

If you had asked me 18 months ago how I would predict the delivery date for a piece of work, I would typically have taken a team’s velocity and used a burn-up chart to estimate an end date.
As well as focusing on story points (rather than working software), I would often find these estimates to be way off, which had the potential to let customers down with aligning to their expectations.

Looking back, I can see where the flaws were, without taking data from the system to get the ‘true’ picture. It was incredibly naïve to think that in an environment as complex as software development, we could estimate for a single date for delivery. I was ignoring one of the cornerstones of Agile in empirical evidence and instead trying to apply ‘traditional’ estimating approaches for delivery.

The actual data I needed was right in front of me; I just wasn’t using it…

The case for data

Data-driven companies are becoming more the norm — 39% of executives say their companies are already highly data-driven, according to our most recent survey.

Given this is the case, if we are serious about Agile and encouraging companies to embrace the agile mindset, then we owe it to ourselves as practitioners to use data to help individuals/teams/execs on that journey.

We should no longer rely on outdated approaches like RAG statuses that are inconsistent and heavily influenced by groupthink/cognitive bias. Instead, we should look to be objective and transparent, using the data we gather from teams as a means to collaborate.

If a user story is an invitation to a conversation, then the same should be said for data…

How can we use data to forecast when we’ll finish?

A large amount of teams are unaware of just how much data they are gathering, and how little is needed to forecast. Troy Magennis has a wealth of free tools available for people to take advantage of, with very little data (gathered via physical or digital means) needed in order to forecast.

With some of our agile teams at PwC, we use a product called Senseadapt to leverage our data (also available for JIRA) to forecast end dates for development.
This is done by taking the traditional burn-up and using Monte-Carlo simulation to visualise the landing zone, which is a range of dates we may potentially finish.

How does it work?

Step (1): We build a mathematical model from the actual behaviour of the board.

Scope is calculated through new items being added to the backlog and completed work is items moving to ‘Done’ on the board.

As real data is used, it captures key information such as; how long have cards spent in a particular state, how many got blocked, the amount of rework, etc.

Step (2): Take the remainder of the backlog and run it through the model 1000 times – each time, the model will slightly randomise the behaviour of some of the cards as they go across the model ‘board’.

This allows us to draw the forecast lines for both Throughput (based on a team’s historical performance) and Scope (ranging from zero additional scope through to an increase at the current average rate).

Step (3): Visualise the ‘landing zone’ which is where the forecast ranges intersect.

Through this visual, we can provide a delivery date range which is far more realistic than the traditional ‘single’ date we are so used to operating with. The vertical lines show the earliest likely finish dates through to the latest, which enables teams to be transparent (using their data rather than traditional ‘estimates’) and show the business the key role they have (managing scope) in agile delivery.

This is a screenshot of the visualisation from one of our teams:

As you can see, we use story count (1) on the Y-axis as opposed to story points (more on why that is here) and you can easily visualise the earliest (2) and latest (3) range of finish dates, opening the door to a conversation with stakeholders.

Aligning to Agile Principles

Metrics are often treated with disdain in the agile world, viewed negatively due to the connotations with governance, micro-managin

g Project Managers and those who enforce ‘process’.

It’s time to reclaim these and get back to data-based coaching for agile teams. Metrics such as the burnup are invaluable if you want to follow the principles of agile. Inspection of the throughput and scope allows for adaption for the remainder of the backlog due to the transparency shown visually to everyone involved.

Let’s get away from estimating and use our data to forecast the range of finishing 

Working with deadlines using data

Typically, teams will be working with a deadline imposed on them by the business and, while the above visual is helpful in setting expectations for delivery, it isn’t immediately clear ‘what will we get’ if we’re working with a deadline.

This scenario is easily accounted for through a different visualisation. Again, the Monte Carlo simulation forecasts completion of the work 1000 times. However, this time, you get a different visual, the potentially deliverable scope (PDS) chart.

Through this visual, it is easy to see what stakeholders are 95% likely to get, with this being anything above the probable line. Likewise it’s also clear what stakeholders are highly likely not to get, which is below the possible line.

What it does, however, is that it encourages questions and the conversation around the potentially deliverable scope in between the two lines.

It is in effect saying ‘this is where we could get to in the backlog’ with the onus on the close collaboration between the teams and the business through working closely together, refining stories, slicing stories, etc.

On a recent project, we used the two visuals above in combination whereby the landing zone didn’t present a date that was months away from what the business expected.
We then used the PDS to visualise what we could get to in the next 6 weeks, with the business looking at this from the perspective of an MVP and, once they saw where the probable and possible lines were, committing as many resources as possible on their side to try and help collaborate with the team to get as many of those stories in the ‘possible’ section to ‘Done’.

Validating the model

What’s really advantageous about this approach is that it allows us to historically look back and validate our model. With a recently completed project, we were able to compare multiple forecasts from the 27th January through to the actual finish date of 17th March.

The forecast was run every few weeks and then, as we grew closer to finishing, every few days.

As you can see from the animation above, even back in January, we were able to accurately forecast a 6-week finish range. This allowed the team to manage the expectations of the customer, rather than hopelessly targeting an end date that was not possible, one which could have been given with a traditional ‘give me an estimate’ approach. 

 

 

 

 

 

 

Summary

This is a new take on agile metrics and how you can leverage a lot of the data which you probably already have to forecast delivery dates. It provides a far more realistic view of the future than a “guesstimate” influenced by groupthink and allows you to be totally transparent with your stakeholders. Through moving away from the notion of a single finish date, which we know is highly unlikely in the software development world, we are encouraging that core value of customer collaboration over contract negotiation.

We have found that when this visualisation is presented to stakeholders, they can start to see just how important their role is on delivery dates and that it encourages the conversation around those items that could be deferred to a future release. We can protect the team from the pressure that come from trying to meet deadlines with a scope that is unachievable as well as reducing the waste from traditional ‘estimating’ approaches.

To find out more, check out Senseadapt or leave a comment below/contact me on Twitter.

About Nick Brown

Nick currently works as Agile Lead at PwC in London.
Nick has previously operated as a Scrummaster for teams within PwC and as a Scrummaster/PM for Royal Mail on their Digital programme. Rather than focusing on a particular framework, Nick uses data-based coaching to help teams find a way of working based on agile values and principles, whilst maintaining the focus on the continuous flow of value to the customer.

 

You can link with Nick Brown on LinkedIn and connect with Nick Brown on Twitter.

Get The Booklet!
How to deliver on time and eliminate scope creep By scoping projects around outcomes and impacts, not requirements!
Get the Product Owner Booklet!
Avoid scope creep! And learn to scope projects around impacts and outcomes, not requirements!
Get These Valuable Lessons Today!
Down-to-earth, hard-earned Scrum Masters lessons and the Tips from the Trenches e-book table of contents, delivered by email
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Internal Conference
Checklist
Internal Conference
Checklist
Download a detailed How-To to help measure success for your team
Motivate your team with the right metrics, and the right way to visualize and track them. Marcus presents a detailed How-To document based on his experience at The Bungsu Hospital
Download a detailed How-To to help measure success for your team
Read about Visualization and TRANSFORM The way your team works
A moving story of how work at the Bungsu Hospital was transformed by a simple tool that you can use to help your team.
Read about Visualization and TRANSFORM The way your team works
A Quick & Practical Guide to Agile Projects for BI
No Spam. Only your book. And you can unsubscribe any time.
Start Reading Now