Escalators & Flow
As I was working at an organization that was looking to improve their outcomes, we looked at the benefits that a solid, accurate, visual management board might offer. The idea is to make transparent all of the work that’s being done, or being considered. Some of this work was repetitive, business-as-usual, keep-the-lights-on sort of work; some was new projects; some of it were minor (and sometimes not-so-minor) enhancements; and some of it was ad hoc work, seemingly to come out of nowhere. And some of it was “urgent” work that required us to stop our current in-progress work in order to address this emergent, unplanned, urgent work.
We were able to represent it all. But why?
Great question. We wanted to understand how work flows through our teams, from the moment it hits our backlog, to the moment we deliver it to our customer and receive a return on our efforts. Most of our work was invisible (and by this I mean that it’s not like an assembly plant or factory where we have physical things that we can see). Most of the work done in software development, user experience and user research, and data science work is work we can’t see. So visual management is one way to see, measure, and improve our system.
There will be things we can do in our teams to help improve our flow of work. And there will also be things that we can’t do – they’re outside what we can control. This is where we need to rely on our managers and leaders to fix our system. Through regular Retrospectives (one of the key aspects to finding improvements) or conducting an effective Study step in a PDSA cycle, we’ll likely start by finding easy experiments for us to try as a team to find improvements and ways of working better together. It’s likely that it won’t be long before the big rocks in our way are outside of the team’s control.
Take escalators, for example. The conventional wisdom is that we stand on the right, and walk on the left. I say conventional wisdom because it turns out that there might be a better alternative. If you visit Hong Kong, you’ll see folks standing on both the right and the left sides of the escalator.
Ludicrous, you likely think. But maybe not…
The theory, if counterintuitive, is also pretty compelling. Think about it. It’s all very well keeping one side of the escalator clear for people in a rush. But a 2002 study of escalator capacity on the Underground found only 40% would even contemplate it walking up the escalator. This effectively halves the capacity of the escalator in question, and creates significantly more crowding below, slowing everyone down. When you allow for the typical demands for a halo of personal space that persist in even the most disinhibited of commuters – a phenomenon described by crowd control guru Dr John J Fruin as “the human ellipse”, which means that they are largely unwilling to stand with someone directly adjacent to them or on the first step in front or behind - the theoretical capacity of the escalator halves again. Surely it was worth trying to haul back a bit of that wasted space.
So, at Holborn station, after seeing how the Hong Kong system worked, they tried an experiment at this one stop, for just three weeks.
And what happened? Well, flow improved during the experiment. They were able to move an extra 31 people per minute, and overall everyone got up faster. Not everyone was happy about change, and after the experiment things went back to the way they were. But flow was improved for everyone.
Yes, a couple of people - those who wanted to walk - got up slightly slower. But when everyone gets where they wanted to get faster, and more than 30 people per minute? We’re not talking about small impacts with a very simple (yet very counterintuitive) change. Understanding the system (the escalator) and then how work flows through it (the people)… It doesn’t take much to envision a possible solution.
What might a future flow improvement experiment look like? How about having a staircase next to the escalator for the smaller percentage of folks that are willing to climb a steep staircase?
I originally wrote this when I was working at a building in North York. This building has an escalator which was frequently under some kind of repair, which and there isn’t a staircase anywhere in the area! Yet, there’s all sorts of space between the two narrow moving staircases (one up, one down), where a perfectly good, regular staircase should be. It was a regular occurrence to have a crowded mess caused by a high volume of people all trying to go up and down using the single stopped escalator – narrow and with too-tall steps
Let’s bring that back to the flow of work in our teams and our organization. We have the ability to change how work flows through our system, getting from our backlog to done (standing on the left & right sides of the escalator). Exceptions to our regular workflow cadence may give the illusion of speeding things up, but only that one thing, and often at the expense of everything else. Building a staircase (for expedited items that genuinely need our immediate focus to get through our system)? That sounds like it might be something we need to enlist the help of our managers – it’s outside of our system that we control, but impacting the flow of our work. And, when urgent or expedited work emerges, an interesting couple of questions to consider… Is this work so important it should cause us to stop and delay our existing in-progress work? What’s the impact of that on our existing commitment? And, what can be done so we’re never blindsided by this sort of expedited work in the future, so we can have a solid flow of delivery? It’s important to note that a good Visual Management system won’t tell you what to do improve the flow of your system. But it should show you where things aren’t flowing for some reason. It’s then up to you to figure out what, if anything, you want to do about it!
Tracking all our work through a visual management board can help make the flow of all our work visible, and help us understand where we can make enhancements to getting our work done.
The full article I’ve heavily borrowed from, including the graphics, can be found here:
http://www.theguardian.com/uk-news/2016/jan/16/the-tube-at-a-standstill-why-tfl-stopped-people-walking-up-the-escalators
This was too good not to share. But I’ve tried to reduce the length as the original article is pretty long.
Effective Retrospectives
As with just about everything I find I’m writing, or being asked these days, there is no one right answer. This is also the case with running an effective retrospective.
But, there are some good practices that will help you get started. As with everything in the Agile world, I hope you’ll use these as starting points, and learn what work for you and what doesn’t. And figure out ways to make it more meaningful, and more valuable, for your teammates.
So first of all, let’s review why we do retrospectives?
We do them to find better ways of getting our work done. That’s pretty much it. This isn’t really the time for us to talk about our work itself, but rather about how we’re doing our work. That may seem odd. But we have demos (or sprint reviews) where we review the work we’ve done. The retrospective is our time to review how we’re working. You’ll see why this is the first point I’m going to make in a moment.
But before we get into a retrospective, it’s important to decide who gets to attend. Often, it’s the people actually doing the work. I tend to recommend that managers not be a part, because it can often cause people to not talk as freely. It’s also important to remember who the retrospective is for. It’s for the team.
Now, the team may need to rely on others to accomplish some of the things that come out of a retrospective. It’s okay to share action plans that come out, but not such a good idea to share individual comments. If you want me to speak freely, it’s got to be a safe environment where I can say what’s on my mind. If I’m concerned that what I say will make it to people outside my team, I’m going to be less likely to say what’s on my mind, and that may prevent us from figuring out what’s really going to help our team improve.
And one more thing. There’s a Retrospective Prime Directive. Even though I am a Star Trek fan, I didn’t come up with it. And unlike Kirk, it’s not something that you can violate without impacting the trust of your teammates. One of the most obvious fears people have when first trying a retrospective is that the ritual will become a negative gripe session, interspersed with blame and counter blame.
Clearly such an event will not contribute to very much learning.
The key to a constructive successful ritual is assuring that all the participants adhere to the Retrospective Prime Directive. It says:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, an the situation at hand.
At the end of a project, or period of time, everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass.
This comes from Norm Kerth, and is found in his Project Retrospectives book.
A retrospective is a key part of any improvement cycle. It’s in Scrum (Inspect & Adapt). It’s part of Kanban (Improve & Evolve; Agree to pursue improvement through evolutionary change). It’s in the Agile Manifesto (“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”). And it’s part of the PDCA-cycle (it’s explicitly in the Check section, but informs everything else in that cycle!).
It’s important. Got it. But how does someone actually run an effective one?
There are lots of options. But all of them tend to follow the following steps:
1. Set the Stage > 2. Review previous actions > 3. Gather Data > 4. Generate Insights > 5. Decide What to Do > 6. Close the Retrospective
Setting the stage is very much like laying out an agenda. Why are you there? How long will you be there? What are you hoping to get out of the time you’re together?
Review action items from the previous retrospective. This is where you close the loop from your previous retro, but reviewing the progress you’ve made and the impact it’s had on your team. It’s a chance to celebrate the improvement you made. It’s a check that what you planned to do got done, and made a difference. If it didn’t make a difference, is it still something you’d like to work on? Don’t just assume that because it was something you wanted to work on a week or two ago that it’s still the thing you want to work on. We hate to leave work unfinished – make sure you’re not falling victim to the sunk cost fallacy. If it’s not done, or didn’t have the impact you hoped, use that as an input to the next steps, to determine what your priority will be.
Gathering data can often start with hard data. What milestones or objectives were achieved, or not. What decision point were made along the way? Depending on your team, you’ll have different metrics you can use, but this is only part of the story. Feelings and emotions make up the other half, or often more than half! It’s important to capture this, and often the “soft” data will drive some amazing insights and conversations. While many of us shy away from the f-word, there are lots of ways to understand the emotions. And they’re important to helping uncover ways for your team to improve their way of working together.
In generating insights, we want to ask “why?”. We can use tools, like 5Ys, Ishikawa diagrams, root-cause analysis… There are lots of ways to use the data that’s been collected to try to hone in on opportunities for improvements. But be careful about jumping to solutions too fast! A solution to solve a problem too early in the process is often like a band-aid – it’s not actually fixing the source of the problem. It’s important to explore how events, behaviours, and circumstances contributed to whatever it is you’ve identified.
When you’re deciding what to do, you’ll want to come up with a number of possible experiments and improvements. We’re finally at the time when we’re going to narrow our scope to one, maybe two items. Any more than that and it’s unlikely you’ll make traction on any of them. Whatever you decide to do should be made nice and visible for any and all to see in a Continuous Improvement section of your visual management board. This allows you to make sure that work isn’t getting lost while you’re delivering your other work, and allows others to see what it is you’re working on improving. It never ceases to amaze me the number of times someone else is walking by a board, sees what another team is working on trying to improve, and either (a) is trying to improve the same thing, or (b) has already solved it, and can help that team.
When it comes time to close the retrospective, make sure you have a clear way to measure if your improvement experiment is successful at your next retrospective. You’ll want to start by there next time. The learning and action items that have been generated belong to the team. Not the manager. Not the coach. It’s up to the team to own the improvement for their own working environment. And sometimes, yes, that will mean getting help from others. Remember, only the improvement experiment, not the information as to how you got there, needs to be shared beyond the participants. And remember, you can (and should) make improvements to your retrospective, too.
A lot of this material comes from Esther Derby and Diana Larsen, and their “Agile Retrospectives” book. Really worth picking up, IMHO.
There are lots of tools available for retrospective formats. I’d encourage you to look at ways to make them different, so they don’t become boring and routine. Here are just a few of the many, many available:
How Can I Start to be Agile?
There’s a lot of interest in getting started. In being Agile. In doing the cool stuff you’ve heard about from others. But how might you get started?
Well, no matter what department or team you’re currently a part of, there are things you can do. And none of this is hard. It just takes time and effort. What follows is one step-by-step way to start. This certainly isn’t the only way, but it’s an option. Take what follows with a grain of salt – this is a very generic approach.
Before you start anything, make sure you know why you’re about to embark on this journey. I’m going to assume, since you’re still reading this post that you know there’s something you want to improve. It might be worth having a look at what Agile has to offer. Here’s a link to one perspective of the value proposition of what Agile has to offer. And it’s also worth looking at the Values outlined in the Agile Manifesto , as well as the Twelve Principles behind the Agile Manifesto . While the Agile Manifesto was written by software developers, you can apply it to your domain by replacing “working software” with “business value”.
Finally, before I get to some steps you can try, I need to remind you that the goal isn’t to be agile.
And it’s even more important that we remember that we’re not trying to be agile for the sake of agile. We’re trying to make it a better place to work, for both us as employees, and with better products, services, and experiences for our customers.
The real answer to the question “How do I start to be Agile” is to live the values and principles outlined in the above links.
Now that we’ve got all that out of the way, if you’re looking for something actionable to get going, here’s a place to start:
Start with what you do now. Seriously. This isn’t about a massive change. The change part comes in when you identify reasons to change!
Understand why you & your team exist:
What service do you provide to others?
Who do you provide your services to?
Who provides services to you that you’re dependent on?
Make your work visible.
Here are a couple of links to examples:
The key is to build your board so it matches the flow of work. Don’t copy what someone else has done! The board needs to map directly to your workflow. And don’t worry if you get it wrong. I tell every team I coach & work with that if their board looks the same in a month from now, they’re doing it wrong. It’s supposed to evolve, so just get it started now.
One suggestion is to start by drawing out how your work flow, as you understand it today, from the original idea until it’s in the customer’s hands. A whiteboard, or on a larger sheet of paper which you can hang in your work area, is a pretty good place to start. And start with done, and work backwards.
And along the way (and this often gets overlooked), make sure you’re building the right thing! Make sure you’re solving a real problem, for a real customer, at the right time. There are lots of blog posts, articles, videos, and approaches that discuss this. It’s really important. There’s nothing worse than producing something on time, on scope, and on budget, that should never have been built in the first place.
In the following days, weeks, and months, review your work:
Does it make sense?
What steps or phases are missing?
What patterns are you seeing?
Is there something you can change that you think might help?
These four ideas are just places to start. They seem simple, and maybe they are. In most cases, my experience has been that they’re not as simple as they look.
Don’t rush through this! In my experience, getting to a stable place when considering the questions in step four is months. Maybe even quarters.
Let’s say you’ve done that. What might be next?
There’s a lot you can do next. Here are just a few ideas. But before you jump into this section, I’m really going to strongly encourage you to not to try to get to this too fast. Go back and look at point #4 in the last section. Really think about that, and explore it with your full team. Has anything change with your answers to the questions in #2 from the first section above? Have you learnt anything new that you should consider? Are you really ready to move on? If so…
Agree to pursue improvement through evolutionary change. That means that everyone on the team needs to agree that you’re going to find ways to improve what you’re doing, in a way that works for you. It won’t be the same as someone else, but it might be. Just don’t copy for the sake of copying!
Does everyone understand what’s required to move an item from one stage of your workflow to the next? Not just those on your team, but those who you depend on, and those who depend on you? Make the policies explicit & visible.
Now that your work is visible, limit your Work In Progress (WIP). Try to get things through your flow faster. It’s not about starting work, but about completing it.
How long is it taking from the time you start working on one item until it’s done?
How might you reduce that time?
Do you have the right people, with the right skills, on your team?
Where in your workflow are things getting stuck? What’s causing that?
Review your workflow:
Does it make sense?
What steps or phases are missing?
What patterns are you seeing?
Is there something you can change that you think might help?
That’s hard. Again, I know it sounds simple. But it’s really quite hard to do well. I know those steps, and questions, can be really, really tough if you’re really reflecting and putting the effort to improve and evolve.
Again, don’t rush. It’s more important to explore what’s working and what isn’t. Any Agile framework isn’t a methodology – it’s just a framework designed to expose opportunities for improvements. But actually doing the improvements is where the real value comes in, and where the real benefits are. There’s no magical time for these items. I’d suggest you think about timelines for this section in terms of quarters (as in multiple quarters!), possibly years. In fact, if you’re doing all of the above things, you should continue finding improvements…
There’s a little more though. But don’t start here. Maybe look at this a little later, perhaps.
How long is work waiting until you start working on it? What can you do to reduce this lead time?
Encourage acts of leadership at every level. Do you do this?
Is everyone empowered and encouraged to try something different from what you’re doing now, to help you improve?
Wait a second. Improve what? Everything. Put everything on the table, including those things that you hold to be absolute truths. This is where real change and real improvements can come through. If you let them.
Do you have an explicit feedback loop to get input on what’s working well, and what isn’t?
Does everyone on your team know what they are?
What are you doing about them?
And yes, there’s more beyond this, too. But this should give you an idea of the journey you may want to go on. Notice how the questions and steps all build on each other?
The key message throughout is one of continuous learning, and being open to the possibilities of changing and improving.