Coaching Flow: Implementing an effective flow system

Delivering a continuous flow of value to the customer is one of the defining characteristics of an effective SAFe enterprise. But flow is not easy to achieve, and many impediments occur along the way. Success requires a knowledge of what flow is and how to achieve it. In turn, this requires people who are knowledgeable in flow and can coach individuals, teams, and trains—and even LPM—to achieve a higher flow of value. This responsibility can be fulfilled by any number of different SAFe roles, including SPCs, Scrum Masters, RTEs, STEs, and any savvy leaders that seek to optimize the flow of value in their part of the organization.

 

In this session, Chief Methodologist and SAFe Fellow Andrew Sales will introduce new guidance on Coaching Flow in SAFe. Specifically, he will review the responsibilities of a Flow Coach's responsibilities: Facilitating Value Stream Mapping, Establishing the Kanban Systems, Measuring And Accelerating Flow, and Growing a Flow Mindset, and the techniques that these individuals can use to unlock the flow of value at every level of the Enterprise.

 

As Chief Methodologist, Andrew is passionate about helping SAFe Enterprises identify better ways of working through the application of Lean, Agile, and DevOps at scale and evolving SAFe guidance to support these goals. In addition, he fulfils the role of Framework Product Manager, ensuring that Scaled Agile has a clear vision, roadmap, and set of priorities for how the Framework will meet the needs of our customers . Andrew has successfully guided numerous organizations through SAFe transformations from across a wide range of industries, drawing on his many years of Lean and Agile experience. He previously led the Agile Services Practice across EMEA for CA Technologies (formerly Rally) and is a regular speaker at Agile conferences and contributor to the Agile community. He is a lifelong learner and recently completed research exploring how organizational structure impacts organizational performance.

2023-Coaching-Flow-Andrew-Sales Download

Em Campbell-Pretty: Afternoon, folks. Good afternoon to those on this end of the earth. So myself and the Pretty Agile team are coming to you from Melbourne, Australia, and this is actually technically the SAFe Australia online meetup. But it doesn't take me too long to look around this room to recognise some, some Kiwis, and, a few Kiwis actually and a token Texan, at least I've spotted so far. So thank you, everyone, for joining.

 

We are really thrilled to have Andy Sales, or Andrew as he's formally known, back with us today. He was last here at this Meetup, I don't know, maybe 18 months, getting close to 2 years ago. Probably when all any of us did was sit online talking to each other. And you and I were just chatting while we were waiting to kick off about this still being online. And it's so interesting, right? We're about to top 80 people on this call. We never got 80 people in an in-person meetup in Melbourne. That never happened in all the years we ran in-person meetups. And, of course, I don't think Andy would have had time to drop by. Could you fly via Melbourne on your way to Nashville, Andy? Probably would've been a bit inconvenient, I'm guessing.

 

Andrew Sales: Sounds very efficient.

 

Em Campbell-Pretty: . Alright, anyway, so…  we're trying to do a little bit of time tracking here. I've known Andy since before he was at Scaled Agile; what were you saying? Six years at Scaled Agile, Andy?

 

Andrew Sales: Yes, about six years there. And I think you and I met when I was at Rally before I joined Scaled Agile.

 

Em Campbell-Pretty: So we've known each other for some time. Andy's been with Scaled Agile for six years. He was doing SAFe before that, and a bit earlier this year, I think, he was appointed as the Chief Methodologist. Very fancy title, Andy! Maybe that's why we've got so many people who turned up. You've got such a fancy title now.

 

Andrew Sales: My kids keep asking me what it means, and I'm still trying to explain it to them.

 

Em Campbell-Pretty: Okay, haha, we won't ask them. We'll just say it's very fancy, and we're all suitably impressed.

 

So Andy's going to talk to us today about coaching flow. Some of you might have caught a little bit earlier he was mentioning this is new content, so new fresh content, a little bit of experimentation on the Australians as the Brits like to do. So I think this is par for the course. I think, Andy if you're good, I'm going to hand it over to you. Folks, drop your questions in the chat as we go, and Andy - you'll run through this deck, and then we'll have a good - I don't know - 20 minutes or so for questions at the end of the session.

 

Andrew Sales: Fantastic. Can you see the slide, Em?

 

Em Campbell-Pretty: Yes, I can. Which I'm hoping means everyone else can. I saw some thumbs up. I think we're good.

 

Andrew Sales: Great. Okay, well, let me kick things off just firstly by saying thanks again to Em and Adrienne for inviting me to speak here. I think it has almost been two years. It's always a pleasure to get on this Meetup and share some of the new ideas and IP that we have. And today, I want to talk about coaching flow.

As you all know, a few months ago now, on March 15th, we launched the latest version of SAFe 6.0, and although there were six themes that described all the things that we knew about that release, the overarching theme was really flow, and there was a huge focus on how we measure flow, how we accelerate flow, how we really implement flow at every single level of the framework. From teams moving stories through iterations or whether it's the SAFe Portfolio, moving new business cases, through the Portfolio Kanban system.

 

One of the things that you'll see as I go through this talk is that that new release also puts an emphasis on multiple roles in the framework in really helping the organisation understand how to implement flow. So we have some new IP coming together. It'll be a new extended guidance article called Coaching Flow. You'll see it drop next week, either during or before or slightly after the SAFe Summit. And it's really going to help us, help those who need to now adopt a flow mindset in their role and help them understand the work they need to do to help the organisation affect flow and accelerate flow. When I go through this, you'll also see that we have a brand new set of responsibilities that fall under coaching flow, but really at their heart they can be applied and picked up by anyone who has the responsibility to help implement a flow-based system.

 

We already did the introductions, but I'll just briefly say a few more things. I'm at Scaled Agile, of course, in the role of Chief Methodologist; one thing I'm always doing is working with partners and SAFe Enterprises to really understand how we need to continue to evolve the framework. So what are the big challenges they're facing? Where do they need new guidance, whereas the current guidance [is] supporting them or not supporting them? So although we did the big release on March 15th, that certainly doesn't end the evolution that we're doing. We're continually evolving the framework, and we've got lots more exciting things to come later this year.

So let me get started [with] the content, and if you think about the latest evolution of the framework, one of the things we did was change how we think about the Lean-Agile mindset. The Lean-Agile mindset really forms the foundation of this new way of working. Agile, of course, is described by the Agile Manifesto. We see the teams working in an iterative manner, adopting Agile methodologies, but we also see Lean being applied across the Agile Release Trains across the Portfolio. As we start to apply Lean to our product development processes, one of the big changes we made in 6.0 was to remove the House of Lean as our best method of describing what we mean by Lean and bringing in the five Lean thinking principles that you can see on the slide here. We didn't lose all the goodness associated with the House of Lean that's been picked up by other things like the core values. But these five Lean Thinking principles I found to [be] hugely effective in explaining the journey that organisations are on as they adopt SAFe.

 

It starts with helping organisations identify their products. That's at the beginning of any product-based approach.

 

And then, of course, step two identifies the Value Streams, the people, the systems, [and] the work needed to actually deliver value through those products. And so now we have Value Stream thinking built into the foundation of SAFe.

 

And of course, once we have our Value Stream identified, then we can apply the good Lean principle to make value flow without interruptions, which will be the focus of course of the talk today.

 

To finish out the last two principles, we don't want to delay delivering value to our customers

 

And, of course, pursuing perfection is an important Lean tenant. We talk about continuous improvement in SAFe all over the Framework.

 

So we have this focus in terms of organising around value. We have this focus in terms of accelerating and making the value flow without interruptions. And I've just put a little definition at the top of this slide about how we really think about flow within SAFe. We want this nice smooth, linear and fast movement of work product through all the steps in the Value Stream. And you'll see as I go through the talk and the slides we can think about value streams and workflows at any level. We'll certainly think about them in terms of the work that teams do, the Agile Release Train, or even work moving through the Portfolio.

 

We see other thought leaders, particularly DevOps community folks like Gene Kim. You can see the quote on the slide here. Also, recognising that flow and a smooth flow of work is critical not only to shorten lead times but also to improve predictability. There was a recent survey I saw of senior leaders and executives asking them what was the most important thing for them as they move their business forward into the digital age. And predictability was the number one thing they wanted to see.

They truly believed that if they could be predictable as a business, it meant they could make and meet commitments to their customers, [and] to their stakeholders. They could really start to plan what their strategy would look like and successfully execute on that. Flow is at the heart of what it means to be not only fast but also predictable when we take new ideas and products to market.

So, a little bit of history here. We started on the work to research Flow about two years ago, perhaps about 2 ½ years now. And we went back to the roots, we went back to Lean Thinking, we looked at the lean thinking principles that you just saw described by Womack & Jones. We went back to Goldratt. We spoke to enterprises who were struggling to accelerate flow. We spoke to enterprises who were doing it very successfully, and one of the breakthrough moments that we felt we had was what you see on the slide here.

 

We started to recognise that wherever flow was taking place, whether it was teams again moving stories through the iteration, whether it was the ART delivering features through the continuous delivery pipeline, whether it was the Portfolio shepherding through new business cases, there were always eight properties that really governed where the flow was working effectively. You can see these on the slide here, and many of these will be familiar to you. Things like work in process, any flow-based system has some work in process: too much there's a challenge: too little we're starving the system. We need to balance that work-in-process.

 

There'll always be a biggest bottleneck. Number two that we need to address, we'll talk about how we do that later. Any flow-based system has handoffs either from one person to another or perhaps from one team to another. And there's always some kind of feedback. It may be technical feedback in terms of how we're developing the product. It could be customer feedback as to whether we're developing the right product.

 

Batch size. We've talked about that in SAFe for many years now. Governs flow, deeply. Batches get too large, they get stuck in the system. And, of course, things like queues, [and] too much work building up makes it very hard to be responsive. Importantly, we mustn't forget that there [are] workers in the system doing the work and also policies that govern that work. We'll come back to this later in the slides, but once we really understood these properties, it helped us to unlock the accelerators that we could apply to each property to really think about how we could improve flow. For us, that was a real breakthrough moment.

Now one thing that no one would've seen before is what you see on the slide here. This is our brand new Coaching Flow responsibility wheel. One of the things that I hope you've seen in the new update to SAFe 6.0 is what we're calling responsibility wheels. We have them for every single role in the Big Picture, and they are the four, five, or six key responsibility areas that that role really needs to embody in order to be successful. And that's helped us move away from what was previously a long list of responsibilities, sometimes very hard to parse. Now for any role that an organisation is helping to support their development, be it Scrum Master, RTE, [or] Product Manager, you can quickly see at a glance the four or five areas that that role needs to think about to be successful.

 

Now, when you look across all the roles in the Big Picture, you'll see at least four, five, maybe even six that have flow as one of their responsibility areas. Things like Scrum Master/Team Coach, RTE, [and] STE all of them have some aspect of flow. Even the teams in the ARTs have a focus on delivering value, which pre-supposes that flow is taking place.

 

One role in particular, though, the SPC, the SAFe Practice Consultant, really plays a larger role here than anyone else. And one of their direct responsibility areas is coaching flow. So for all those roles that have some kind of responsibility, this new coaching flow responsibility wheel is helping them to understand the steps they need to go through at whatever level they work at. Whether it's a Scrum Master working within a team, an RTE working across the ART or even someone like the SPC working across the whole organisation, these five responsibility areas really form the five steps that we want them to follow to help implement flow in the domain that they're supporting.

 

When we get to the last responsibility area, growing a flow mindset, of course, this one puts even more pressure on the leadership. I was away last week in South Africa doing a trip visiting customers. It was a great opportunity to hear from them directly and a lot of them were raising the same problem. “We've put in place the events, the activities, the artefacts, the roles that SAFe describes. What we're challenged with is really improving the systems of work.” And, of course, that comes down to leadership. That's a big part of what we're going to talk about today. How do we really improve the systems of work to improve flow? So I'm going to go through each of these new responsibility areas. Some, of course, aren't new, but they've come together as these five steps, brand new guidance that you'll see next week that we hope will support those playing this new role.

The first responsibility area, I'm sure, is fairly familiar to most people, but I want to share some templates and tools that I think will make this even more effective. Anytime we start to think about how we can improve flow, it needs to start with the first step, which is really visualising and understanding what flow looks like. And our best lean tool here is still Value Stream Mapping. We've had Value Stream Mapping and say for some time not to be confused with Value Stream Identification when we think deeply about how to organise our ARTs but rather the process we go through to map all the steps in a particular workflow.

 

Organisations are typically doing this by looking at a set of features they've delivered previously, going back and reflecting [on] what were the steps that all those features went through—and then applying some rough metrics to each step. And I always say here, and you'll see some good examples on the next slide, try and get the right level of precision. It really doesn't matter whether one step took two days or, three days or, five hours, or seven hours. When you start to build out your Value Stream Map, some steps will simply jump out as the biggest bottlenecks and delays. We tend to find that over-precision here gives diminishing returns in terms of the amount of effort it takes from your part. But we want to map out the steps, whether these are steps across a team, an ART or the Portfolio. And want to add some very important metrics. 

We want to ask ourselves for that particular step, how much time was spent actively working on the work, what we call Active Time, how much time was spent waiting for the work to start what we call Wait Time and then of course, Percent Complete and Accurate. What percentage of the work that arrives at your station can you process because it's ready, it's complete, [and] it meets your quality standards versus what per cent you have to send back to get fixed? And, of course, anytime the work moves backwards in the process, it imparts huge delays in flow, [and] it slows things down enormously.

What I have here is a really nice example of what this looks like in practice, and one of the things that I noticed as I shared some of these ideas last week is that the discipline that this slide, this Value Stream Mapping Canvas, brings was really well received by organisations who have tried to apply Value Stream Mapping but perhaps have sometimes felt challenged.

 

So this is what we call a Current State Value Stream Map Canvas and it has some important information on it. Think about this as the output of a workshop where we have the required subject matter experts, people who really understand this workflow, coming together to reflect on what it looks like. In the top left, knowing that we can apply this to any workflow, we have the key details around what Value Stream, this is whereabouts in the business it is, what triggers it, [and] what value delivery looks like. Also, some interesting data around what the feature request per month is to understand the delivery rate that we need to achieve.

 

In the middle, we have our baseline metrics. I'm going to talk more about metrics later, but what is the total active time? What's the total wait time? What's the efficiency of this process? This one is 23%. Honestly, that's very efficient. A lot of organisations we're seeing are struggling with single-digit or low double-digit percentages when they start looking at the ratio of active time versus total time across these workflows. And then, what's our flow velocity? How many features can we actually deliver per time period through this particular workflow?

 

Once organisations start to map these workflows, they're recognising a couple of things. The first thing they're recognising is that the development activities are typically pretty well optimised. These are experts working in their field who really understand what it is to effectively develop new features and understand how to work with the systems and tools they've worked with for many years. They're often finding the biggest delays and opportunities for improvement live in the Continuous Exploration step as we bring new ideas together, define them, [and] get them ready or perhaps in the Release steps as we look to deliver this workflow to the market. So, we need to make sure that our value stream maps are nice and broad to pick up on all these opportunities.

 

Then you can see in the top right the organisation that's gone through these steps has highlighted the biggest cause of their delays. Some are due to waiting, some are due to problems with specialisation, [and] some are due to misunderstandings in terms of the work to be done.

The real magic comes when we think about the future state and the message to any role that's looking to coach flow is that at any time you need to have a current state and a future state Value Stream Map. So again, whether this is a Scrum Master working with a team, an RTE working across the Agile Release Train at all times, these two canvases form the basis and foundation of what they're trying to do in terms of improving flow.

 

What's nice here on this future state version is you can see some target metrics. What do we want flow efficiency to look like? What would flow time be if we wanted to achieve some of our goals in terms of accelerating time to market? And there's a really important underlying message in these future state target metrics. If you think about SAFe principle #1, Take an Economic View; at some point, it will simply be not economical to keep chasing improvements in some of these areas. So we need to understand what good looks like; we also need to understand when it is good enough.

 

On the right-hand side, you can see they've defined certain features they are going to help them to implement this future state. Not only does the future state include less steps, it might include brand new steps they need to optimise the process at some point. It might improve by reworking the steps, perhaps replacing some manual steps with automated steps. But these features will go into the next PI Planning session. And like I said, this future state canvas forms the basis of everything that this flow coach is trying to do in terms of achieving and changing the system to improve flow.

Now, these tools are all available today. Just very quickly to remind you this, you have access to SAFe Studio, the canvases that I've shown you, [and] the workshops that you can use to run with your stakeholders; it's all there for you to download. And, of course, the expectation is that you're running this on a continuous basis. Once you support the organisation [in] achieving the future state, the future state becomes the current state, and we need to rinse and repeat the process.

 

But truly, I can't emphasise enough that going back to our Lean roots, Value Stream Mapping is the foundation of any flow coach's work. Starting by understanding the workflow and where to improve it provides them [wit]h the tools they need to go to the second step.

The second step is pretty familiar as well. We understand about Kanban systems, but many organisations struggle to understand where across the organisation we need to apply Kanban systems and what it really looks like to apply them effectively. So this forms the second step that the flow coach needs to think about in terms of now visualising flow. This will help them unlock further opportunities to improve flow as we get to the future steps.

And I've just put a reminder on this slide because I found it useful myself. What is it that Kanban is trying to do at the heart? And a little definition here from the Kanban guide is worth just reflecting on. “The Kanban method provides a strategy for optimising the flow of value using a visual pull-based system instead of work being pushed to or by the team.” The other thing I heard last week as I got the opportunity to speak to customers is they were simply struggling with the amount of demand versus the amount of capacity. Huge over demand in terms of requirements, new business cases, new opportunities, [and] limited capacity in terms of those that could deliver it. And it was getting so extensive in some areas that this was becoming a huge stress point: stressful [for] the teams who felt they were overloaded, stressful for those stakeholders who had the responsibility to deliver on these new opportunities.

 

Kanban is there at its very heart to help us balance demand and capacity. Once we do that, we find that flow accelerates through all systems that are applying this. So the three practices we're going to help the organisation adopt, of course, is defining and visualising a workflow, managing the work through that workflow and, importantly, then helping to continually improve that workflow.

In SAFe, we have a very specific approach to Kanban systems. If you look very carefully at the updates we did to the Big Picture, there was one very small but important update at the team level, which is now on the Big Picture. We have a Kanban system across the backlog. Even at the team level, it's becoming unarguable that teams are seeing huge benefits through visualising the work in this approach. So now we have Kanban systems at every level of the framework and what we're trying to create is a connected set of Kanban systems that really allow the organisation to flow the work from strategy to execution.

 

Keeping in mind, of course, that not all the work goes top down. A small proportion does, the epics that need to be governed effectively, but a lot of the work is coming in sideways: the Agile Release Train picking up new features that they understand they need to deliver, the team's picking up new stories, what they need to do to continually support the health of the system. What we find, though, again and again, is that if the work gets to the team and by that time the team is overloaded, there's too much work in process or too much to be done, we haven't controlled the demand on the system early enough. So these connected Kanban systems allow us to control demand at the earliest possible opportunity, which is across the Portfolio. That way we can really balance the capacity we have across our teams and ARTs to effectively work on the highest priorities.

I only have one slide on this today because I think this is fairly familiar to a lot of you, but I will point you to the link at [...] the bottom of the slide [...], where we've put together a brand new article with some of the key steps needed to successfully put these Kanban systems into place. And, of course, it starts with mapping the workflow. We know this now; we've just completed our value stream map. We have the best understanding to date of what the workflow looks like in our particular domain, but the value stream map doesn't translate directly to Kanban states. We're going to arrange the steps in a way that makes sense. We might combine some of the steps from the Value Stream Map, [or] we might separate other ones out where we need more visibility.

 

Then we're going to identify some buffer states either where the work needs to be processed as a batch or perhaps where we want some more visibility as to where there might be bottlenecks in the system. You can see here we have a buffer state showing all the work that is ready for testing before the testing begins. And that's a great way of identifying and helping the organisation find areas where we might be over-constrained, we might not have enough people, perhaps we have not enough specialisation.

 

When we think about applying our WIP limits on Kanban systems, we always start from the right-hand side, start from the downstream activities and ask them what capacity they have to process work and then work back left through the system. And that way, we often find, although we might have huge development capacity, we might have limited capacity [in] testing and validation. We constrain it by the limited capacity. That's how we make sure the system doesn't become overloaded.

 

Then, of course, things like policies, we need to be very clear about who can do the work, what it looks like to complete the work, our definitions of done things around shared ownership, [and] what it means to apply our quality standards.

 

And finally, any Kanban system needs classes of service. So, making sure we have clear understanding of what it looks like when we need to expedite something through the teams, the ARTs or even the Portfolio versus things that may be more traditional pieces of work or things that are attached to a particular delivery date. So I'm not going to say too much more about this, but this is absolutely the second step in any flow coach, and the work they need to do is to help the organisation visualise and start to improve their workflows at every single level.

Now, once they've completed those first two steps, they then really have the opportunity to start measuring flow. They've got a good understanding of the workflow; it's visualised now, [and] it's starting to demonstrate and show where it's struggling. And, of course, if we're building these Kanban systems into our ALM tools, we're starting now to get some metrics back and some real data that we can use to drive opportunities.

Now, one of the other big things that was connected to flow that was really impactful for us at Scaled Agile was the flow metrics. We really felt that up until this point, organisations were struggling to really understand where the work was in the process [and] what was the true objective measure of how things are progressing. Often, it felt like this was a subjective viewpoint using our traditional phase gate approaches, our RAG status or whatever it might be. It really felt to us and what we've seen through our customers that the flow metrics turned what was once intangible into something that became tangible.

 

The six flow metrics form part of our measure and grow approach. I won't have time to go into the overall measure and grow approach today, but I will just say that flow is only one of three dimensions We need to measure. We obviously need to measure competency. Are we getting better in the Lean Agile skills that we're supporting the organisation adopting? And we need to measure outcomes. Are we delivering the value that our customers and stakeholders expect? But alongside that, we need to measure flow. Are we truly improving the efficiency and effectiveness of the systems we use to deliver the value to those customers? And there, we see six flow metrics.

 

The guidance importantly is not to apply these metrics at each level. We are not recommending that a team apply all six flow metrics. We are not recommending that an Agile Release Train or Portfolio apply all six metrics. Instead, we're going to apply the metrics, the flow metrics, where they help us to make better decisions. It could be that a Portfolio applies two or three of these. An Agile Release Train maybe applies four of them; maybe a team applies two. I'm going to show you some examples. But always select them where they help us to take better decision making or generate better insights. 

So, let me briefly go through the flow metrics, and I'll say a few things about how we're seeing these apply today. So, the first one, of course, is flow distribution. And we're seeing that many organisations today are really struggling with the long-term sustainability of their solutions. As they develop new solutions and deliver new opportunities into the market, they're finding that the work to maintain the health of those systems and solutions is eating up an increased capacity compared to their ability to deliver new business features. One of the challenges they're also facing is that they don't have a good grasp on what that capacity looks like.

 

So flow distribution very simply allows us, typically measured across an Agile Release Train, to look at the balance of work of new business features versus perhaps the work going into maintenance to support the health of the system itself. What we find is that organisations that focus too much on business features tend to find the health of their systems degrading over time. Similarly, those that focus too much on the health of the systems without delivering enough business features tend to end up with dissatisfied customers. So, not only do we want them to measure flow distribution, we want them to set some intentional targets as to what they want this to look like in the future.

 

We saw a really nice application of flow distribution in the Portfolio recently. A Portfolio decided to measure flow distribution across investment horizons. The question they wanted to answer is, do we have a balanced Portfolio that's going to deliver value today and value into the future? So they looked at the distribution of H1 work, H2 work, [and] H3 work, and that allowed them to adjust and target a particular target distribution quarter by quarter as they look to balance the Portfolio and the work that it does. So, flow distribution is critical to help identify the different types of work in the system.

The second one, which we typically see measured at the team level, which I think is familiar to everyone on this call, is flow velocity. Measuring the number of stories, in this case, that the team is delivering each iteration, I think it still has real value. New teams, of course, as they start to apply the outputs of their retrospectives, want to see flow velocity going up initially, but longer term, we really wanna see flow velocity stabilising a great indicator that teams understand their capacity, they can commit to work, and they can deliver their work predictably. This all rolls in the importance of predictability that I spoke [about] at the beginning.

 

One thing to keep in mind with all these flow metrics is we always measure them on the work item that appears at the level that we're measuring. So if we're using flow velocity within a team, we're measuring it against stories. If we're using things like flow distribution at the ART level, we're measuring it against features, and we're really encouraging organisations to move away from this idea of rolling up work from the team to the ART to the Portfolio level. Once you have 10 or 20,000 user stories across the Portfolio, the noise that's contained in that data makes it very ineffective to really steer effectively.

Perhaps one of the most important ones is flow time. This really describes very clearly what it looks like for someone waiting to receive the benefit and the value captured in that feature. How long does it take from when we start implementing a feature to when that feature is complete? And we know that in SAFe, we want all our features to fit within a PI. We can see on this histogram that some are outside of that time box. That may be a good thing, [or] it may be a bad thing. It may be that we intentionally delayed them because it was the right thing to do. It could be that they were the most important features, and we have a challenge on our hands that we need to resolve.

 

One of the things I heard last week that some customers are doing nicely with this one is they're looking at the different types of features and how they fit into the flow time analysis. Is it always one type of feature that takes [the] longest? Is it the features that cut across multiple teams that we really struggle with effectively delivering? So make sure, of course, that when you start to optimise the system, you're really focusing on those systemic improvements and not just focusing on the things that are easy to resolve.

 

The other thing that you can do with this one that can work very effectively, typically measured across the Agile Release Train, is hone in on specific parts of flow time. Maybe you want to look at the development flow time, maybe you want to look at the continuous exploration flow time, and that will allow you to measure more precisely and identify the areas where the real improvements can be delivered. 

Then, of course, coming back to what we said around work in process, if we really want to manage the amount of work in the system, it can help to visualise the amount of work getting into the system. And something like flow load is typically measured across the Portfolio or the Agile Release Train. This example is from the Agile Release Train using a cumulative flow diagram. So, at any point in time, showing the quantity of work in each state in the ART Kanban system.

 

What I always say here is if your arrival curve, the speed at which work is moving into the implementing state, is that a steeper gradient than your departure curve, which describes the work moving to done, it means that more work is moving into the system than leaving the system.  This is the number one leading indicator for longer flow times in the future. So, as flow coaches, we need to monitor these flow load diagrams to help understand where it looks like we may have problems coming down further down the road and mitigate those by managing and putting in place our WIP limits or perhaps adjusting the ones we have.

Now, the flow efficiency we've already seen, so I won't say too much about this. This is the one that we are typically seeing doesn't come for free out of the ALM tools you might be using. Some ALM tools are starting to put this in place, asking the person doing the work to either mark the work is in progress or waiting. But typically, this is the one that comes out of a Value Stream Mapping workshop that we saw earlier.

 

This is the one that helps organisations recognise that efforts they make to improve the total active time really are diminished completely when we look at it compared to the total wait time. Up until this point, many organisations are focused all their improvement efforts on helping people to work faster. When they start putting this in place, they start realising that the work they need to do is to move the delays out of the system. That's where the optimisation benefits really come. 

Finally, to close the loop, we talked about predictability as being something critical to organisations looking to implement SAFe. The ART predictability measure is probably familiar to all of you. It's one of the metrics that SAFe really mandates. This is where we measure whether the ART has successfully delivered the objectives they committed to. Have they achieved the planned business value against the commitment they made in PI Planning? Don't forget, if we want to measure predictability across things like the Portfolio, there are other ways to do it. We may measure whether we've [...] met our key milestones or key deliverables. But across the ART, certainly, the ART Predictability metric is the number one approach. 

A couple of important things I want to say to summarise that I'm sure many of you have seen those flow metrics - hopefully as you've gone through the new materials associated with SAFe 6.0. We need to be really careful we don't chase these flow metrics at the expense of everything else. And this is something that I've seen some organisations do, which can lead them to further challenges down the road.

 

One of the things we talk about in the metrics workshop that I'm going to be doing next Friday at the Summit is ‘complimentary metrics’. As we improve flow time, what are the things that, if they move in the opposite direction, would be unacceptable to the business? So, a complimentary metric for flow time might be something like Customer Net Promoter Score. We can improve flow time by delivering this value. We can improve flow time by delivering less quality. But if we start to impact Customer Net Promoter Score at the expense of flow time, then we won't have achieved our goals. So, we always need to think about what is the complimentary metric as we start to define some of our future state targets.

And then finally, of course, and I don't think I need to say too much on this, just be careful anytime we start applying metrics; the job here is not to use these to manage by the numbers. Behind any metric or change in a metric there's often a story that needs understanding and working with the teams to really see what the true situation is. So if you see a drop off in things like productivity that could be due to a team onboarding a new technology, perhaps sickness, perhaps new team members, a whole raft of different things, we need to take the time to really work with the teams to understand what's behind the numbers.

 

 

Okay, let me say a few things about the penultimate section. Accelerating Flow again was a huge part of SAFe 6.0. The storyline that we're trying to put in place here is that once you understand the properties of flow, those eight properties that I showed you at the beginning that apply to any flow-based system. Once you understand how to measure flow, then the next step is to accelerate flow. And those three things create this closed-loop system. Any flow coach now can recognise and describe flow to their stakeholders [and] to their team members. They can use the flow metrics to understand where impediments to flow exist, and then, of course, they can apply the flow accelerators to adjust each one of those properties in a positive manner.

 

I don't have time today to go through all of these. I'd encourage you to have a look at them. Some of them we have touched on as we've talked about other slides, things like visualising and limiting WIP, other things that you'll recognise from existing SAFe material, [and] things like working in smaller batches. But I chose three that I just wanted to highlight, which I think are new to SAFe and are worth saying a few things about.

 

 

SAFe has never spoken about bottlenecks before, and that's the second accelerator. Bottlenecks appear in any flow-based system, and there's usually a largest bottleneck that we need to address. We often see bottlenecks appearing as work piling up behind the state in the Kanban system. But sometimes bottlenecks, particularly those built out of specialisations, lack of particular skills, we need to use things like retrospectives to really surface those.

 

What we're understanding and seeing that organisations are struggling with here is the biggest bottleneck is often something beyond the team or ART’s control. And the expectation was SAFe, through their eyes, is that the teams and ARTs can really address any of the impediments they see, and that's simply not the case. Left them to themselves. The teams in the ARTs can only affect a small number of the systemic impediments that they're experiencing. So, the bottlenecks are truly where we need to bring the leadership on board to help us change the system. Again, be very careful of just addressing the low-hanging fruit. These are the things that will really move the needle in the positive direction.

 

 

The second one I wanted to share, which I think is so pertinent after the years that we've been through, is optimised time and zone. The reflection here is that if myself and Em perhaps were doing the same piece of work, maybe one of us was doing it in an office environment, [and] maybe another one was doing it remotely. I would suggest we'd see two very different levels of output and productivity. I won't suggest which one would be higher, but the scenario and the environment in which you work has such an impact on the type of work and the levels of productivity. So when we talk about optimising “time in the zone”, it's not about saying we don't want any meetings. It's saying that we want to create really good collaborative opportunities for our knowledge workers. We want to make sure they're not task-switching too much. We want to make sure there's a good balance in terms of time. They have to really focus on the work at hand versus collaborate with other teammates. And it may be that since COVID, we've almost gone in the other direction; meetings were required to ensure that we actually work together since we were distributed. I think all of us are struggling now with trying to find time during our busy weeks to really find how we can be productive with the work we need to do that delivers value so organisations need to attend to this now more than ever.

 

 

The last one I wanted to mention, which we see a lot in the field, is number eight: remediate legacy policies and practices. Some organisations are struggling when they bring SAFe in to really at the same time mitigate and remove the ways they used to work. We have a lot of respect for the previous ways of working. They got us to where we are today. They helped the business be successful. But many of these things, and you see some examples on the slide here, are simply counterproductive or actually contradictory to the new ways we want to work. It also finds that organisations then struggle in thinking that SAFe is bringing an extra layer of activities and events where actually SAFe is there to replace many of the ways that you work today.

 

So, if you have a system demo in place that needs to replace your current methods of measuring. If you're now having an objective way to really evaluate system progress, that needs to replace some of the more subjective methods that you are using to report on the progress of the development activities. So we're asking organisations to really look very carefully at where their more traditional ways of working are counterproductive and where they need to remove those to help them focus on the new Lean-Agile ways of working.

 

 

Now, all these accelerators have real context. In the new and latest update to 6.0, there are articles that describe how to apply these accelerators at each level. So, if a Scrum Master is applying the coaching flow responsibility wheel, they're going to use the Team Flow article to help them understand how to apply these in their domain. If an SPC is working across the whole Portfolio, they can use the Portfolio Flow article.

 

 

Although I don't have time today to go into detail on this slide, I put it here as a reference because, of course, I'm happy to share the PDF. There's this deep, deep connection between flow metrics and flow accelerators. And I put together a simple table here to try and illustrate that. I'll just describe the first row and leave the rest of you to look at in your own time.

 

Something like flow distribution, we talked about that. It helps us understand the balance of work in the system; too much in one direction, the system is really going to struggle. That's the problem that we're going to surface. There are flow accelerators that can directly be applied to help address that problem. We might be seeing maybe we're not getting fast enough feedback; maybe we don't understand how to balance business and technical requirements because we're not validating the technical feedback on the system or the feedback from our customers. Maybe we need to manage queue lengths if we make sure we don't overcommit to work; it allows us to change the distribution of that work more easily.

 

So, every one of these flow accelerators applies directly to the problems that you are going to surface through the flow metrics. But let me finish out with the last step in the process, which is about growing a flow mindset. And I only have a single slide on this.

 

 

Any flow coach, whether they're applying everything we looked at today, at any level in the organisation, needs to help the organisation really think about what it means to grow a flow mindset. And it's worth just pausing and thinking about this a little bit deeply. Everything we do in SAFe, whether it's the roles we put in place, the new events, [or] the new activities, really [have] one purpose, and the purpose is to put a systems lens on the way the organisation works. We want to lower that water level [and] let those big boulders and rocks start showing through so the organisation can truly see for the first time where it needs to apply itself to improve its ability to deliver value to its customer.

 

Over the last five or six years, as I've been working at Scaled Agile, the demands on organisations to accelerate value flow are always increasing, increasing at an ever-increasing rate. So, the pressures here to be able to deliver value are extreme. The pressure is coming from internal stakeholders; the pressure is coming from external stakeholders as these organisations look to compete.

 

So we need these flow coaches to help the organisation get trained in these concepts. Everyone needs to understand what it looks like and what it means to do Value Stream Mapping. Everyone needs to understand what it means to visualise workflows. We need them to help make the work transparent. We need to see the flow of work at every single level. Remembering that the facts are friendly. If we can't see the issues, we can't manage them. The number one response when we help organisations put these Kanban systems into place is 1) That felt really good. 2) Oh my god, look at that - look at how much work we have to do. So it's a critical step.

 

And then, of course, we need our leadership and our teams across the entire business to take ownership of what it means to improve flow. I always say that the Agile Release Train has two critical missions. The first mission is to build the solution it's tasked with developing. That's the mission that most organisations focus on. But the second mission is the mission to improve the way that it delivers that work. And that's the one that we are talking about today.

 

Finally, of course, we need to use the flow metrics to help us understand where to apply these improvement opportunities. And we need to be careful not to apply them in the most obvious places. Sometimes, the most obvious places are the easiest places. The true systemic improvements are the ones that really change the way the organisation works. Those are the ones that will truly unlock the greatest opportunity to accelerate the flow of value. So I know there was a lot there, but I'd like you guys to have everything to see all the new stuff. And with that, Em, happy to take any questions on anything that I've covered.

 

Em Campbell-Pretty: Thanks, Andy. That was awesome. I know I appreciated the full view, and I'm guessing others did as well. We did get a few questions as we were heading through the session. One here from Andrew. What are your thoughts on using average cycle time equals average week divided by average throughput, i.e. Little's Law as a flow metric?

 

Andrew Sales: We talk about Little's law. I'm just going to move us to this slide so we can have this up while we're.. so apologies for running through the slides. So we talk about Little's Law a lot, and we talk about it when we talk about queue sizes. We do find Little's Law very useful. The challenge that was mentioned there, of course, is that when we think about any queue, we're thinking about average wait times. The average wait time will be the length of the queue divided by the processing rate. That was the point that was being made.

 

Let me say one thing about that. We find it particularly useful for one reason. I think when organisations see Little's Law, and they realise the average time a customer's going to have to wait for a new feature is relying on those two things, the amount of work in the system versus how quickly they're processing it. They suddenly have a light-bulb moment. They realise that they can affect that wait time in two ways. They can affect it by either working faster and improving the processing rate, or they can affect it by reducing the queue length. And that is very analogous to the value stream map that we saw where we talked about active time versus wait time.

 

Up to this point a lot of organisations have put almost all of their transformational efforts focused on improving the processing time. How can we get people working more effectively? How can we support them working faster? Little's Law is another means and another tool that helps them realise that if they simply control the amount of work that gets into the system, when they get that request for a new feature, and they drop it into the Kanban system, it's going to go through much faster because there isn't a big queue of work.

 

So, I find Little’s Law is very useful for that purpose. When it comes to actually measuring things like throughput, [and] cycle time, we don't tend to talk about in SAFe just simply because cycle time has so many accepted definitions within the industry it's become a little bit difficult to work with. When we measure things like flow time, we tend to do it directly out of the ALM tools rather than derive it through the means you described. But it doesn't mean that Little’s Law isn't any less effective in helping organisations understand the impact of queues on the wait times of their customers.

 

Em Campbell-Pretty: Thank you. Andy, I've got one here from Lavanya; I think it is. Kanban is a list of work items or issues. How do you integrate that with [a] flow mindset and prioritise it accordingly?

 

Andrew Sales: Yeah, I mean, I'll just try and move this to the right slide as we talk.

 

Here's the thing. I think the Kanban approach, the Kanban systems, I mean, let's be clear, so when the teams adopt an Agile methodology, it may be Scrum, it may be Kanban, regardless of that, the visualisation of work is seen to be effective in all scenarios. Hence why we talk about Kanban systems specifically here. But I think there's a couple of things that happen when we put these in place. We can't manage the work that we can't see and the work we do as knowledge workers is a lot of the time invisible. It's not like we have, you know, components of a manufacturing system piling up in the corner of the warehouse. This knowledge work, unless we make it visual, is simply invisible. We can have as many initiatives or stories in flight. Technically, there's no limit on it; there's no holding cost in terms of actual warehouse space. So the first thing is just simply visualise the work.

 

Organisations are truly struggling to manage over-demand coming from all areas of the business. So the first step, visualising the work we find, is a great a-ha moment in terms of them now, then taking the second step, which is actually to manage that work. And that second step is the important piece, I think Em, so although, of course, the team working with this Kanban system day-to-day is finding it useful because they can see the work they need to do today and how it progresses to their next teammate. What it really allows is that flow coach, someone like the Scrum Master/Team Coach or maybe the RTE, to start to see where the system itself is under pressure.

 

The feedback I got last week on my customer visits was they've invested hugely in the development capacity, and they felt good about it because everyone's busy doing work. But what they're seeing once they put the Kanban system in place is it's the wrong type of work to be doing because that downstream step, the validation and testing, they have less capacity, and these developers are keeping busy working on other tasks and other stories just to make sure they have something to do. But it's not the tasks and stories that the developers and testers are moving through the system because they're still way, way behind in terms of the queue they have.