Dominica DeGrandis

In my role as Principal Flow Advisor at Tasktop, now Planview, I work with and observe dozens of really big companies in retail, healthcare, finance, federal space, telecom, and they are all trying to transform. They are all trying to change how they work. No company or organization can operate the same way forever. Change is inevitable.

The spectrum of preparedness for people who have been delegated to lead transformations and initiatives often falls between not bad and not good. In this talk, I am going to present some of my observations and suggestions on how I think we can better equip people for success when it comes to optimizing workflow.

The problem that I see is that there is this gap between what is needed and the people delegated to make it happen. It usually goes something like this: an executive buys into a new way of working and then delegates the driving of that transformation and organizational change to a director, a manager, or a coach who does not always have the knowledge or the experience to implement that kind of change. Even when they do, they often do not have the capacity. They do not have the time or the support necessary to effect change, and it is really heartbreaking to observe that. It is not an easy win if you are not set up and organized for change.

Looking at this Kubler-Ross change curve, the genesis of this change curve was initially the five stages of grief, but it has been adapted and made applicable for business. What is represented here so well is the turning point. It is when experimentation starts happening. It is when people are able to come out of their frustration and depression and updating the resume and getting ready to move on, to the point where they can start experimenting, that we start to see a change for the better.

When there is a sense of urgency for optimizing workflow and changing how organizations measure success, then focusing on reducing the cost of this change is useful. I think it is essential. How do we get through this change curve quickly? How do we get to experiments as soon as possible, so that you can build the knowledge and experience for people who are trying to implement, trying to innovate in their organizations?

I think it is teach people how to experiment. That is what is needed right now: to help people learn and feel comfortable with experimenting and presenting their experiments.

I teach people how to experiment quite a bit. The first thing we address is pain: what hurts? I ask people this question: what prevents you from getting your work done? What randomizes your day? This is a real example from a workshop I just did last week. I have found that I have done this exercise hundreds of times and people have no qualms identifying their pain points.

A common pattern here is too many meetings, conflicting priorities, lack of processes and standards. On the team side, I ask people what prevents them from getting their work done. That is team pain on the left. On the right-hand side is business pain. These are your internal customers who ask the team to do stuff. They make their requests, and that is why I ask, what are they grumbling about? They are grumbling that things take too long. They are grumbling that they do not understand the roles and who they are supposed to go ask to get their questions answered or to submit the request to.

It is pretty even-sided here, or there are probably more dislikes on the left-hand side, and most of those have to do with too many meetings and conflicting priorities. On the business side, it is things take too long, and we do not know where a thing is, and we do not really even know who to go ask for where our thing is.

The second thing that we do is try to understand the causes of pain. What is causing these pain points? In this session we had about 18 people. They were thoughtfully engaged in identifying these causes. Some of the things that came up were lack of self-service scalability, and that was impacting their capacity expansion and their ability to scale. Lack of alignment on priorities and processes contributed to too much WIP. Too many meetings is too much work.

Next up was, what is the goal? For this I want to show you a real experiment that my awesome colleague Chris Gallivan is working with his organization. Chris Gallivan is another Flow Advisor that I work with on our team. He is doing an experiment with a team. Can you guess what their pain point is? The experiment is called Get Home by 5 PM.

They are currently in this situation where there is very little confidence on the business side that they can actually get a release out the door smoothly. Their pain point is that they are only allowed to deploy once every two weeks, after hours, and often they do not get home until after 9:00 PM. So this is the goal: get home by 5 PM. They also want to improve the confidence that the business has in their ability to perform, and they want to improve their flow.

This is an A3, and we are using experiments which use data to quantify the outcomes. Basically, we are saying: here is the current state, here is what we are going to do or what we did, and here are the metrics. Here is how we are going to show the improvements to our flow time. If customers are grumbling that things take too long, then we need to measure how long things actually take.

To equip people for success, we need to learn how to measure what matters to business partners, especially when it comes to optimizing workflow, because so often the complaint from business partners is that things take too long.

Number four is, what steps will you take? What activities will you do? What is your action plan? Here the action plan is really to lower batch size each week, reduce their WIP, and try to automate part of the deployment process along the way. Their time frame: all experiments should include a time frame. It should not be open-ended. Here they are going to do a three-week experiment with weekly deployments.

Lastly, number five is how to quantify the outcomes. What are the results? What are the outcomes? In this experiment, the release team ended up getting home by 5 PM, which was helped by their reduction in WIP, their lower batch size, lowering WIP through smaller batch size, and automation. It is so powerful. Their flow velocity improved by 30%. Their flow time improved by 10%. Employee happiness went up largely because they got to be home in time for dinner. The business partners became more confident in its ability to deliver what they said they were going to deliver when they said they were going to deliver it, which was huge.

Let us bring back the change curve here. How do we integrate these lessons learned from these experiments and metrics across the organization? How do we expand this one pocket of greatness or goodness that we have now existing in the organization so that it can help drive other changes, drive systemic improvements across the organization? I think a really good way to do that is to have a forum to present experiment learnings and data.

We will need to ask people to present their experiment learnings and outcomes. I would suggest using an existing forum that you already have in place, so you do not have to add yet another meeting onto people's calendar. For example, if you have an Agile Center of Excellence, that could be a really great forum to share people's experiments.

When it comes to experiments that need data, I find these three fundamental flow metrics very helpful because these are things that customers care about, especially how long things take. The speed metric we would call flow time: how long things take end to end from the point where a request was made and you decided to do it, to the point where it is available for the person who asked for it to use it. Then we want to measure WIP, your work in progress, your flow load, and also throughput, which we call flow velocity.

I like to start measuring WIP first. Why flow load? Because it is hard to effect change with cognitively overloaded people.

I am currently working with about a hundred teams from a large retail organization. Not all at the same time, but last week was the infrastructure networking team. This is their flow load. This team has about 13 people in it, and they have altogether a total WIP of 117. That is an average of nine per person. I asked them, how do you juggle nine things at a time? It turns out they do not really. They set aside other work to work on the most urgent requests. So 40% of their WIP is sitting idle.

This is just looking at their feature-type work in green. We can show how much of the work is in a wait state and how much is in an active state. In September, with that much average WIP per story, they basically had 66 of them. On the vertical column we are looking at, they have a flow load of 62, 25 of which are in a wait state and 37 are in an active state. Work is sitting in a wait state because they are supporting a new data center build-out and they get sucked into development projects doing firewall changes. They cannot finish the work.

This shows that there is an average age of 17 days in a wait state and 28.5 days per item. The slide on the right is just feature-type work. These are primarily their stories that they are working on to deliver business value, so revenue-generation type work and not so much revenue-protection type work.

When it comes to speed, a key decision that needs clarity is when to start and stop the clock. There are different levels of work-item types. In a value stream, it depends on what view you want. If you are measuring at the epic level, then start the clock when the epic starts. If you are measuring at the feature level, start the clock when the feature starts and ends. Here at the story level, that is when the clock gets started. Their average flow time for their stories is 35.8 days.

The main point here is configure your flow-time metrics to capture what view you need to improve your decisions, and not just decisions that impact your team, but decisions that impact your business partners, your organization as a whole.

Most companies we work with measure thousands of product value streams, and most of the companies that we work with have an average end-to-end flow time that goes way beyond the development flow time. Typically, development flow time is only 2% to 12% in that development state, and the end-to-end time is much greater than that, especially up front with a lot of heavy planning and budgeting and approvals and triage. That part is often left out of the speed equation, but when we are looking end to end at a product value stream, we need to capture that upfront time too.

Downstream, if build and deployment, if DevOps is not happening on the release side, then we see a lot of wait time and lengthy cycle times on the end too. We call this water-scrum-fall. The constraint is not development. The constraint is upstream or downstream.

I want to wrap up this metrics part by describing Little's Law for you a bit so that you can become more predictable in how long things are going to take and, more importantly, how much WIP you should have or not have. There is a relationship between flow load, WIP, and flow time. It is called Little's Law, where WIP is a primary factor in the equation.

It is obvious when you think about it. When you get on a freeway, your commute home is going to be pretty fast if there is no traffic. But if the freeway is backed up and it is stop-and-go, your commute is going to be longer. That is why WIP is so great. It is a leading indicator, unlike flow time. You do not really know how long things take until it is done. You cannot stop the clock until it is done and then measure that.

Little's Law is a relationship of averages. The gist of Little's Law is that on average, the more items that are worked on during the same time interval, the longer it is going to take to finish those items on average. The equation is average flow time equals average WIP divided by average flow velocity.

What you can do here, which I think is kind of fun because math is, you can calculate what WIP probably ought to be, or at least it could be your North Star to shoot for. This is the networking team, and we are just looking at their stories in green. This currently does not include technical debt or risks or defects.

We can look at solving for WIP in this equation, a little bit of algebra. If we rearrange, if we solve for WIP, average WIP is going to equal average flow time times average flow velocity. There are some requirements for this to work and to make sense. One of them is that we have to use the same units of measurement. Because flow time is measuring days, we need to put flow velocity into days also. This is 30 days, an average of 24 over 30 days. That is about one thing a day. We delivered one story a day.

Each story took on average about 36 days. What should their WIP probably be using this equation? If their flow velocity is one, and their flow time is 36, one times 36 equals 36. So they should probably bring this WIP down to 36, and that is likely going to improve their flow time. They are going to have less idle work in here. They are going to have fewer conflicting priorities, fewer dependencies, less neglected work, all the time thieves that impact the team's ability to deliver.

The 36 is really the best-case scenario because Little's Law has assumptions that go along with it: basically that the average arrival rate should equal the average departure rate, that all the work that is started will eventually be completed, and that the average WIP is neither increasing nor decreasing. Those rarely ever happen. So 36 would be considered best-case scenario on the WIP, but it is a lot better than 66. I would suggest gradually letting this number lower down to 36, or to whatever number where you will see smooth flow.

In conclusion, I think that one of the best ways to help people become more effective at driving change is to teach them how to experiment: learn the pain points, understand the causes of the pain points, and then identify a goal. If teams or people are reluctant, it might be useful to begin your first experiment with a small goal that is within the team's control, because if it has dependencies across the larger organization, then you are going to need buy-in from leaders of those other teams.

If you have a lot of experience and you have seniority, social capital and trust and budget, and you have influence to budget, that is one thing that will help you experiment with upstream and downstream partners to really get the biggest bang out of your experiment. But if you do not have that, if you are in organizations where your initiative or your transformation is delegated to people who do not have that kind of experience, then a good place for them to start would be with something within their control, one of the pain points that is within the team's control.

Build a coalition of the willing. This is one area where transformations can fail terribly. My observation is that there needs to be a large enough group of people who actually want to change. It is not a one-person job. It is not a one-person job no matter how competent they are. We need a group of early adopters to help communicate and guide change, versus a junior scrum master getting volunteered to implement a huge change initiative.

Here are the takeaways for you, the list of things I think will provide your teams, your people, with the capability to effect change: learn how to experiment; allocate capacity for experimentation, because even if you do have really great senior people who can make things happen and have been there for a long time and people trust them and they have psychological safety and influence over budget, if they do not have the time, they do not have the capacity to experiment, then that is going to hinder the progress, like we talked about in the five ideals of The Unicorn Project, ideal number three, daily practice. These experiments require daily practice.

Understand and measure key flow metrics: flow time, WIP, throughput, flow velocity. Work to build a coalition of the willing. Connect with business partners because they have influence over prioritization and budget. If you can find one business partner who understands the pain points, because they are going to have pain points on their side too, that is a huge help. Lastly, be conscious of change-curve states and psychological safety, and people who might be frustrated or depressed and maybe have fear of speaking or presenting their experiments. We can measure all we want, but if people are afraid to get up there and present their experiment and their data, then the change is probably not happening.

I am going to leave you with a few resources. The book I am reading right now is The Value Flywheel Effect by David Anderson. It is such a fabulous book, and I highly recommend it. It is all about how to effect change going to a serverless environment. Then Project to Product, all about change, moving from project to product; my work on Making Work Visible, all about change; and then two Forum papers that are fabulous. One is Expanding Pockets of Greatness from 2017. It is how to connect the pockets of success that may already exist in your organization so you can harness them to drive systemic improvements, not just individual team delivery metrics. Then Winning Together from 2021, which is setting the stage for partnership. It is a playbook for aligning technical and business leaders, and ideas for connecting business partners to influence prioritization and budget.

Lastly, there is the Flow Framework Community where you can connect with other technology leaders. I hope you are able to take a few things away from this talk. Please connect with me and let me know. Thank you.