Matthew Philip
Transcript
Bonjour à tous. Merci beaucoup.
I'm sorry, I would do my entire talk in French. My high school French teacher would probably be appalled at me. And you would too. After a couple of slides, I would not have anything to say. But actually, you might prefer it that way after you see the slides.
Anyway, it's wonderful to be here with you. This is a great conference. It's very exciting for me to come from the United States and to hear all the different points of view, people doing different things across the world. And so this conference is no exception. My talk might be an exception, but there's plenty of good ideas going around. So my talk is going to be just that, some ideas, some experiments that we've tried at my organization. So not very much theory, more practical experience. So hopefully it can be helpful to you as well.
So I'll be dividing the talk into a few different parts. So I'd like to encourage you to ask questions throughout part two. And so feel free to stop or raise your hand, and I'll try to answer your questions.
So I'm from St. Louis in the United States.
Basically, my job is helping people improve, helping people enjoy their work more. That's what I like to do.
So this report is about how we are doing things in my organization to try to take things a little deeper with Kanban.
So St. Louis is named for Louis Neuf. And so it's actually interesting. In the United States, we have more than the typical number of streets and neighborhoods and places named after French things or with French names. But we have our own particular way of speaking these French names. So I thought it would be kind of fun, before we get started, to ask all of you who know French how we should be pronouncing these names. All right, so it's a French lesson, and you can help me as I go back home. So I'm going to give you the name of the place or the street in St. Louis, and I'd like you to tell me. How it's properly pronounced, all right? And then I'll tell you how we pronounce it. Okay, so first one.
Okay, de Belviere. All right, no, you're incorrect. The answer is de Baliver. Okay, all right. I thought you'd get that one, but anyway. Okay, this one.
Gravois.
Yeah. It's Gravois.
Okay, Gravois, right. Okay, this one.
Shoto? Shoto?
No.
It's Shoto. OK. Next one.
Gracia?
Any other options? Gracia?
It's Grashit.
Okay, this one? It's very easy, right? Right, it sounds so beautiful when you say it.
No, it's Creve Coeur.
Okay, and finally?
Sula. Actually, this is the one we pronounce correctly, and obviously it means drunkard, right? This is where we celebrate Mardi Gras every year. Anyway, thank you for that. I'll be sure to tell everybody back home the proper way to pronounce these names. This is what happens when you have Germans come in after the French have settled the city, you know, and kind of change it. Germans, Italians, Irish. Anyway, so thank you. So we have a structure of our own in St. Louis. It's a little bit shorter than the Eiffel Tower, but this is our arch. And so as a structure for the talk, I'd like to just give you a context. It's really important when you're doing experiments and as you listen to our experience reports to consider the context. So things that we try may work for you, they may not. You'll have to consider the context. So I'll give you that. first. So I'll go into a little bit of detail about our experiment with our depth of Kanban assessments, what those were like.
And then we're doing an experiment with a flow manager role. So I'll talk about that a little bit. And then just review the three main feedback loops that we think about in Kanban method.
Okay, so context. So as David Anderson likes to ask, what business are you in? You have to know what business you're in. So I'll tell you what I think we're in. We're in the business of custom software delivery for a variety of different customers. So rather than having a single division or an IT that supports a corporate structure, we are doing projects and products for lots of different customers. So David also asked, what makes people choose your product or service over others? So one of our differentiators is that we are able to do things very quickly. We have a wide experience in mobile apps and different kinds of technology. So we are able to do hard-pressing problems where others have failed. So we have a lot of small teams. Excuse me. Generally, our teams are six to ten people. We have an environment that's relatively open, as you can probably see from the picture here. So as I mentioned, we have a variety of customers. And so All these different teams are operating mostly autonomously.
Okay, so I started with the company back in 2000. We were a relatively small company, and back then we had an idea for what we would call today a lean startup. Back then we called it a dot-com. And so the dot-com didn't do as well as we thought it would, and so we pivoted, and we became a software delivery firm for different customers. So over the years we grew and from the early days though I would consider our structure, our DNA if you will, to be proto-agile, kind of pre-agile before we even knew that there was such a thing as agile. Heavily rooted in XP, extreme programming practices, we're a very dev-oriented place.
Really highly consider engineering practices. And so we adopted Agile XP formally, and then a few years later developed what David mentioned this morning would be considered proto-Kanban. So putting cards on a wall, visualizing work, that visual management part of Kanban.
And then I went away for a few years, and I don't know if it's a coincidence that when I went away, the company grew even more.
But I went away for three years. I worked at a different place. I came back just this past summer, and lots of things had changed. We were doing mobile apps, lots of cool technology, some new people, interesting new faces. So that was great. We'd grown, obviously. When I had left, we were 100 people, and since coming back, we're over 200 now. So a lot of new people, people who have been at the company less than two years.
So even though we had grown in lots of ways, our number of employees, the different types of technology we were doing, different customers, our state of the practice of Kanban had really plateaued. So I realize I'm going to be giving you a few different geological concepts today. It's unintentional. So the iceberg, plateau, I'll talk about mountains.
But we hadn't really gotten beyond the visualization practice of Kanban. So that proto-Kanban. There was some work in progress limiting going on, some cycle time, some different kind of metrics, but really for the most part we had plateaued at the stage of visualizing work.
And I think a couple of the reasons for that, we had grown so rapidly that we were really focused on delivery, which is always a good thing. So we were focusing on helping our customers.
The other thing was that we adopted Kanban like we adopted other XP and Agile practices. It was just one of many things that seemed to work for us. Without really considering the depth or the promise that David talked about this morning in what Kanban can do for your organization. So it was just another tool for us, if you will.
So Kanban was ubiquitous in our company at a very shallow scale, however. We do card walls really well.
So, but it's only the tip of the iceberg. Again, there's, if you think about an iceberg, what's the distinguishing attribute of an iceberg?
Right. How much of the iceberg is underwater? Most of it. Most of it? Any numbers? 90%. 80%? Okay, yeah. 90% is what I read, yeah. So the mass of the system is below the surface, unseen. The easy thing to see is the very smallest part.
So actually, it's interesting. If you're familiar with Pavel Brzezinski, he's come to another idea of Kanban as iceberg as well. I don't know if I stole it from him. I probably stole it from him without realizing. But we also, he has a talk that he uses the Kanban iceberg as well.
His is more colorful than mine, actually. Okay, so if we think about the practices as being the top of the iceberg, and even just then the visualization part of that at the very top, these are all very important things, obviously. These are kind of the actual how we implement in a practical way.
The more we get abstracted from those things, it's easier to forget why we're doing them. And we had not really considered all these things as we started doing visualization of our work. It was easy to put our work on a wall. But like I said, we're treating it basically as just another practice, another thing to do to help us deliver work.
So David mentioned Mike Burrows this morning, and in Mike's book, he asked some questions that are very relevant to my organization.
Some of the questions he asked, could Kanban-style transparency and balance provide some relief where people are still overburdened?
Is your collaboration focused mainly inwardly? So team oriented. Does your customer focus suffer as a result of overprotective intermediation around the team or excessive internal focus on the technology, product, or team? And so I think that was something that was probably happening for us as well.
Our developers really love technology, love geeking out on technology, which is great. It's a very helpful thing for our customers, but there wasn't the same level of customer focus.
Our team-centric approach is failing to deliver gains in end-to-end flow. So seeing the system at large rather than the team.
Our leadership understanding and agreement underappreciated. Is respect too easily forgotten when big decisions are made? So these are really much more important questions for me that I thought we needed to consider. And as we thought about the promise of Kanban and our practice of it, We should. consider these questions.
So in addition to starting at the top in terms of the practices, we wanted to also look from the bottom, starting with the values.
Again, rather than an alternative to Scrum or XP, Kanban, rather, was something that was going to allow us to improve whatever we were doing. So all of our teams operate in very different ways, but Kanban could be a commonality for us in terms of improving ourselves, getting the most out of those practices and processes.
If you're familiar with Simon Sinek's Golden Circle, he talks about starting with the why. And to me, starting with the values is a lot like starting with the why.
Okay, so David mentioned it this morning.
Kanban is a management system for cultural change and improving organizational maturity. We had kind of missed that. In our speed to practice the visualization, we had missed that reality, that great promise. So card walls are the means to that end. They're not the end of themselves. And indeed, they're not even particularly necessary.
Okay, so in our practice of visualizing our work, we had forgotten, or in many cases, simply not even known about the Kanban's purpose of driving evolutionary organizational change. So how do you help teams for whom Kanban is simply card walls?
Any thoughts? I can pause here for questions. Questions about the iceberg.
The context?
Yes. You said you were doing Agile XP first and then switched, but were you using Scrum and why did you switch?
that end. They're not the end of themselves. And indeed, they're not even particularly necessary.
Okay, so in our practice of visualizing our work, we had forgotten, or in many cases, simply not even known about the Kanban's purpose of driving evolutionary organizational change. So how do you help teams for whom Kanban is simply card walls?
Any thoughts? I can pause here for questions. Questions about the iceberg.
The context?
Yes. You said you were doing Agile XP first and then switched, but were you using Scrum and why did you switch?
Right. So the question was, we were using Agile XP, were we using Scrum, did we switch? We never formally adopted Scrum per se. It was more born out of XP, extreme programming practices. Some management type of things that Scrum talks about. We never had Scrum Masters or some of the formal roles that Scrum talks about. Does that answer your question?
So some of our customers use Scrum, and so we try to interact with them or have a commonality with them where that's the case.
Other questions on context?
Again, it's very important to consider context. This is something that's going to be valid in our environment. I'll try to abstract out some things as we go, though, for you. Questions? Continue? Okay.
So I had been watching and reading some of the discussions from David Pavel and Hocken Force about the depth of Kanban assessments that they had been using and that people were doing. And I particularly liked David's formulation of the question about Kanban not being whether whether you're doing it or not, but why you're doing it, the intentionality, that really resonated with me.
We were clearly doing Kanban at some level, but what was the why? Why we were doing Kanban?
So I mentioned Mike Burrows earlier.
I read his blog post. This is from his blog.
He talked about a values-based depth assessment. So this is asking questions about the why, about the values that undergird kind of the thinking and the practices and the principles.
So this is kind of what it looks like. You can get the spreadsheet from his blog. It's a series of questions and thoughts about
the reality of Kanban, how you practice it. Basically, he's arranging those nine values, and he's actually condensed them into six categories for the purpose of this assessment. And so we thought this might be something that would be useful for our teams to consider and actually use as an educational tool.
So we have anywhere averaging between 20, 25 teams going on at a time in our organization. Like I said, very different in lots of ways, all highly focused on the engineering practices, do a lot of great test-driven development, rapid delivery.
UX prototyping. All of them are operating in different ways in terms of where they are with Kanban. And so where do you start? Where do you start when you have that many teams and you'd like to get things
moving quickly.
We knew we couldn't do them all, not at once anyway. So we started with a handful.
So we asked around on our company IM system, talking to people in the hallways, just walking to people's teams, saying, hey, there's this depth of combine assessment. Would you be interested? And it was great because some people were, they kind of raised an eyebrow, some people were interested. But there were four teams that initially their team leads said, yes, they were interested in doing it. And these are teams of varying levels of maturity. One team in particular was delivering very well. A couple of the teams were kind of stagnated and they kind of lost their way somewhat.
But the thing that they required for us was that these assessments be lightweight. So they didn't want to take a whole lot of time. They wanted to focus on delivering still. And they didn't want to have a lot of meetings. And it had to be pragmatic for them. So rather than a lot of theory, they really wanted to be able to figure out things that they could take back and use immediately.
Yes, Ben.
Why did they want to participate? What was in it for them?
Right. What was in it for them? Why did they want to do this? That's a good question. So I think a couple of the people realized they had stagnated and they needed some kind of catalyst for improvement in their team.
One team was just curious to know how they were doing. They get some feedback about, well, here's this, these people are talking about depth of Kanban. Let's compare ourselves to what that is all about. So I think it was a combination of a couple of those different things.
Okay, so first of all, we decided, well, there's kind of a gap in terms of understanding. There's people who are visualizing their work, but really don't have an understanding properly of what Kanban is and what Kanban can do. And so we started by having just a brief introduction of Kanban method, starting with the values. And so we used the iceberg metaphor. And people were very interested, very surprised that there was more to Kanban than simply visualizing your work.
So then we introduced the rubric for the assessment, the scale of four measurement here. And so it was useful. It was interesting. It was some of our teams had been through a CMMI appraisal. Actually, David mentioned Hillel Glazer. He had done our appraisal.
So it was kind of similar. It was starting to feel similar to a CMMI appraisal. And didn't really want that right away. Because there was the concept of illusory superiority, where most people think that they're better than they are at something. I do that myself, obviously. We all have those tendencies. But it was very evident to me. I'd seen their card walls. I'd seen how they were operating. You're not really limiting your whip, or you're not really understanding and in control of your system. But people were tending to rate themselves fours and threes on things that seemed to me more like ones and twos, which is fine. But again, the idea of avoiding emotional resistance is very important here. And so David mentioned this morning, be like water and avoid the rocks. We could see quickly that there's this kind of antagonistic relationship of the teams that we were helping. We had a group of three or four of us. coming in and facilitating the assessments, that they were starting to kind of defend themselves and defend their practice and score themselves more highly than we thought. And so one of the quick learnings that we had was to say, we as facilitators, we're not going to assess you. We're all friends here. We work for the same company. And so we said, you guys assess yourselves. We'll help you understand the questions. We'll walk you through these things, answer your questions. But really, when it comes to voting and deciding, are you a one, are you two, are you three, we left that to the teams. And so that was kind of freeing initially, that rather than having this emotional resistance where there might not be the transparency,
that actually started helping. And so again, so we wanted to create an environment of transparency. That's obviously one of the values. And so even in doing these assessments, demonstrating the values.
And then we wanted to help the team own their own assessments. So it wasn't just some outside group saying, you need to do this to appease us, to appease management. There was no management request for this. It was just a group of us who were interested in helping teams and the teams themselves. And we said, we would not share this information with management. We would anonymize data if people wanted to see it beyond these teams, but really it was by the teams for the teams. So, right. And the ratings are subjective anyway.
You know, you could say, well, there's reason to have relative and objective scales, but really it was just a way to give the teams a benchmark or a place for starting in terms of what they wanted to work on and to give themselves kind of hold up a mirror for them to see what they were really doing.
So we did it like a lot of teams are familiar with estimating, a group estimate. So with thrown estimates, we'd do one, two, three, shoot, and then they'd give themselves an estimate. We'd help them work through that. Basically, it was very simple, a very quick process, a series of one-hour meetings.
So since we were doing four teams concurrently, we were able to try things and fail sometimes with some of these teams. One of the things we realized early on was that we didn't, as a group of facilitators, we didn't know the values as well as we should have ourselves. So it really drove us to educate ourselves as well.
Another thing was that because there was this knowledge gap or this understanding gap, Mike's, the wording in Mike's assessment was different for us. We, you know, the English speak a little different English than we Americans do. And so we had to kind of translate some of the wording of his questions into something that was more intelligible or applicable in our environment. So we came up with some different examples that applied to our context.
So I mentioned Mike's book, but actually it couldn't come out at a better time because as soon as we got this, we were able to infuse our understanding a lot better. So those of us in the assessment team were really able to get a better grasp on what we were helping our teams to understand.
So even right away, the teams, just through the process of asking questions and learning, were able to start making changes. So one of the parts of the assessment talks about transparency and explicit policy. One of the teams that was using a tool, Mingle, which I like, it doesn't do everything you might want it to, but they said, well, our tool doesn't allow us to do explicit policy. And so I told them that just because your tool doesn't allow you to do something doesn't mean you shouldn't be doing it. And so they took that to heart, and immediately after our first meeting, they went up and just made some very simple, very basic, rudimentary cards that they attached to their electronic monitor.
So the very process of doing this elicited a lot of goodwill. People were happy that we were investing in them, and we were giving them a chance to take a breather from really laser-focused delivery and come up a little bit and look at the system for improvement purposes. And so this was a quote from one of the team members. Again, just the idea of caring about people, so values of respect, agreement, understanding. Just the very process of doing this was helpful in those ways. It also introduced a shared language for us. So I mentioned the knowledge gap, but being able to talk about Kanban with a shared language through the process of doing the assessments was very helpful.
What is cycle time? What is explicit policy? What does it mean to have customer focus? They're all really helpful conversations to have.
So each team graded itself differently, which we obviously expected. So I mentioned the six areas, the six value areas that the assessment groups things into. This is one team. So we left it up to the teams. Again, this is a learning that we made. After we finished with the assessments, I initially assumed that it would be whatever your lowest score was, that was the thing you would want to improve on. And that's not necessarily the case. You may want to play to your strengths. So work on or expand upon the things you're already doing well.
This team wanted to focus on flow. So we made for them a goal to increase their rating by one over the next month.
This is a different team. They were weakest in transparency, and so we talked about transparency and the actual questions that the assessment goes over, and that was their goal, improve transparency. And as you probably know, If you work to improve one of these things, there's going to be some spillover or knock-on effects in the other areas. So it's not like you're isolating one to begin with.
Transparency across the system. So, right, exactly right. Other stakeholders, people, again, keeping the system in balance, making capacity transparent to the people who are making demands on the system.
A lot of our teams are highly transparent within themselves. So a group of six people, they work in collaborative fashion. They're co-located. They have stand-up meetings, visualizing their work. A lot of things are transparent within the team, but beyond the team's borders, it's usually not quite as much the case. Yeah, good question.
So our initial set of teams were finished with their assessments. They all wanted to use this assessment to improve. You know, they'd gotten good feedback. They'd given themselves feedback, essentially. But the problem was that they were still too busy to invest the time to improve. And again, without radically changing their process, that wasn't going to be necessary. That's not what Kanban talks about. But there still needs to be a focus on improving, a desire to improve, and really just an understanding of where to start. They didn't know exactly where to start. So I'll pause here again for questions on the assessment. So our initial set of teams were finished with their assessments. They all wanted to use this assessment to improve. You know, they'd gotten good feedback. They'd given themselves feedback, essentially. But the problem was that they were still too busy to invest the time to improve. And again, without radically changing their process, that wasn't going to be necessary. That's not what Kanban talks about. But there still needs to be a focus on improving, a desire to improve, and really just an understanding of where to start. They didn't know exactly where to start. So I'll pause here again for questions on the assessment.
I have a question. Did you experience any sort of argument at some point?
Yeah, we did, actually. And that was good. It was good to have some dissent. You know, there was a lot of times when the team, there'd be three or four or five people thought they were doing this thing really well. Yeah, we're doing whip limits. Yeah, no problem. And then there'd be one person who would kind of be the lone voice, the courageous voice saying, guys. Let's be honest. We don't do this. We think we do whip limits, but we have a whip limit for development, but then there's this infinite queue of work that's piling up before QA.
Not really work limited or WIP limited in that system. So it was really good. And that's why it was great for us to use the group voting technique that people were already familiar with from XP and estimating. It allows people to, you get the cognitive diversity and you get the lone instances that are revealed. And people say, you know, as a group, everybody says four and there's one person who says one. And then it really leads to the good conversation. Our teams love to debate anyway, so it was going to be natural. Yeah, go ahead.
Right.
Not initially, no. We wanted to use the assessment to generate some of those things. Basically, our only goal was to help teams, again, have a mirror to see how they were doing. And my hope was that in doing so, it would actually catalyze some change thinking and some interest in improving.
No pressure, yeah. Again, it wasn't management driven, and I'll talk about that in a minute because we have a unique, perhaps unique, structure of our organization. There's no middle management layer. And so our executives weren't necessarily asking for this. They had kind of deputized me to help teams in a broad way improve. But other than that, there wasn't an initiative. Yeah, go ahead.
Absolutely not. Yeah, that's a really good point. It was basically for teams to improve against their own abilities. And so that was one of the reasons we wanted to create safety for these teams in the first place, emphasizing this is not a comparison thing. Again, any kind of information that management is interested in was going to be anonymized so that teams weren't going to be compared against each other. And we don't have that culture anyway, so I can see how that would be. Some of our customers we've worked with, that would be an issue. So again, context is key here. But yeah, part of safety was to not have the teams feel like they were being compared against each other. They were interested, though. They actually, the team leads asked each other about how they did, but it was more of a friendly rivalry and kind of just curiosity. Does that answer your question?
The last bit you just gave is great because creating a sort of friendly rivalry, that sort of, you know, intramural,
Right.
Then that should raise the standard everywhere. Right. That's the sort of approach that the military take to a little bit of rivalry between the regiments isn't a bad thing. Right.
Yeah, that's a great point. Yeah. Oh, sorry. Yeah.
The bug is up us this month. If you didn't have the courageous guy saying, oh, you seconded me back, would you try to challenge their scores or try to ask questions to see if the score were real?
I did a little bit. Yeah, it was hard for me because at first, like I said, I'd worked with some of these teams and I was... And I think it was partly just knowing what the answers or what the questions were about.
I initially challenged them a lot more than I did later. Because I could see that challenging them or trying to get them to change their score wasn't going to really help. We were focusing on the wrong thing. The focus should have been really understanding.
And figuring out how to improve that rather than the actual score. The score was a means to an end.
I'm going to raise the questions so that people start thinking more in here.
Right, exactly. So that was one of my own faults. I was a little bit too aggressive in challenging them. And so I kind of stepped back after a little bit. Let them learn for themselves. I occasionally would ask them, are you sure about this, guys? You know, this is what this is about. I'll give you one more try. But anyway, yeah, give it a try.
You said that this assessment was not targeted for consumption by the...
But my question is, in the two years when the teams practiced Dunbar, probably they collected some metrics that were used or are used, being used even today by the top management. Is there something like non-metric at all?
No, no. Not as much as you might expect.
We do have some team metrics that we use that the management is concerned with.
I mean, to compare teams with teams.
Oh.
Really not quite so much in our environment. There is interest from some of our customers. So we have a particular customer who has several teams that we work on projects for them for. And they are interested in saying, how well is this team producing relative to the other teams? And so for their benefit, we'll provide some
normalized style, whether it's stories per week, kind of a data point for them. But really, there's not a lot of team-to-team comparison. That's one thing we get pretty well. Other than trying to help all of our teams improve and identify teams that are not performing as well, there's not a lot of apples-to-orange kind of comparison. Does that answer your question?
Okay, any other questions on the assessments?
So David talked about Kanban building evolutionary DNA into your organization. And so I mentioned earlier, Kanban isn't really a matter of whether you're doing it or not, but what your intent is. And so it might have been a question, did we have this DNA already, or did we need to do some genetic modification of ourselves? How would we get this DNA if we were really focused on delivery and not really thinking about how to use... Kanban to improve ourselves. Where would this DNA come from?
I mentioned our organizational structure. It's very flat, so there's really two levels. There's our founding principles, the three people, we have four at the C level, and then there's everybody else. And these guys are pretty good about empowering the teams. And so there's no middle management level in our organization. And so one of the great things about Kanban is it's designed to be led from the middle out, up and down. But we don't have that. So what would we do? We didn't want to create a middle management layer just for that purpose. That's not what works in our environment anyway. And so, but we still needed someone to catalyze that change. Someone who was really keen to do it and to see it happening, to invest in the teams, to give the teams a chance to... Own the improvement still. So this is where we tried the experiment. So, uh, Anshuans, he wrote about this earlier this year in InfoQ, actually, the idea of a flow manager. And our teams are reticent to have really distinct role titles as it is. I mentioned that we don't use scrum masters.
Even our team leads are basically just kind of promoted technical leads who have some management responsibilities. So we thought of the flow manager role as a possible way to catalyze the change within our teams that had kind of plateaued and were doing things more business as usual.
So it's really important when you hear the idea of agree to pursue change. That's a really important part of Kanban. But to me, when you agree to pursue change, you agree to see improving as part of your job, not just coding, not just doing QA, not just design, but that you see improving as part of your job as well. And that's what this agree to pursue change is to me. So what would you say a flow manager does? That's a good question. Actually, the executives were interested in this. I was pitching this idea. Even just a lightweight experiment, I wanted to get their thoughts and their agreement, their understanding as well. So the way that Chris described it in his article is that there's a need for someone within the team to take charge for the implementation to stick. The role has some similarities to Scrum Master. Once it's removed, from the project management aspects it's often loaded with. So really it's someone whose sole purpose is to help the team improve and focus on giving metrics, asking good questions about how the team is doing, to help the team reflect and act. So follow the policies it set for itself, identify new policies, amend the existing ones, conduct experiments and do them scientifically. A lot of our teams do make changes, obviously, but they don't really necessarily conduct their changes or their improvements as experiments. So ultimately the flow manager inspires, coaches, and challenges the team.
So Mike describes leadership as being as simple as looking at the work board and asking, what is stuck today? Are you seeing flow? Where are our blockages repeatedly occurring and why is that? Our teams are relatively good at asking the first question. So we have regular stand-up meetings. Teams are really good at saying, what's blocked? Let's fix it and move on. But we didn't have that second level of understanding or the kind of root cause analysis oriented way of thinking about our problems. Again, focus on delivery. That's great. Focus on removing things and making systematic and systemic changes often goes by the wayside.
So Mike also asked, what if this kind of leadership doesn't come naturally to your organization? And that's why we thought that a flow manager injecting that kind of attitude would help.
You guys have probably seen this picture before, right?
Okay, I know the guy in the back has.
Okay, so beyond asking the important questions on kind of a daily basis, the flow manager helps the team do experiments with data to be present where the work is occurring. So the idea of GembaWalk. It's actually not someone who can just kind of drop in for the stand-up meeting and then leave. So that was one of the things we experienced. It wasn't going to be this really, really part-time role where you just kind of pop in. Say, what's your cycle time? What's going on today? And then send an email to someone. It really had to be someone. We have a great QA. Her name is Allison Hawk. She sees her role in a QA way of eavesdropping. That's like a big part of her role because she wants to be present for conversations when they're happening because that's what allows her to do her job well. And so eavesdropping is important for the flow manager as well in a Gemba kind of way.
So what kind of metrics does a flow manager care about? This again is highly contextual. It goes to the fitness for purpose. What's important for your organization? What do you guys care about? For us, we really care about delivery assurance and meeting quick time. And quality, speed, all those things are important to us. So we started with these kind of four general areas. So this may change depending on the team.
Some of these are easier to get than others. Can you guess which of these four things the data is hardest to get?
Return on investment, yeah. Yeah, this is the elusive one. It's really quite ironic. This should be the first thing, value over anything else. But it is the most notoriously hard thing to get.
For flow managers, this is kind of like a detective case. You're kind of figuring out, getting pieces of the puzzle, putting data together, and constructing this. David mentioned earlier, it's a lot easier to do this when you have digital tools.
To me, there's four different sources or locations of information in a team. There's kind of explicit things, so explicit on card walls. We have data there, both physical and digital. But then there's also implicit information. So this is stuff that's in people's heads. But there's also information that's out there that people don't even know. So what's the value of what we're building?
Someone has a notional idea. We want to do this. Why? And actually, I see Josh in the back. If you guys are able to come. to his session, he'll help you understand this quite well. But those are the things we started with. Those are things that were important to us.
So we really felt that with the visualizing work, that was great. And that actually leads to conversation, leads to understanding, and that leads to action and change. The critical part for us was what happens between the visibility and the conversation. We needed someone to ask the questions. To get that conversation started. And that's where we saw the flow manager.
Our teams, I mentioned, they'd kind of plateaued. They'd gotten used to habitually doing things to deliver, which is great. It keeps us in business. It keeps us improving. It keeps us getting more business. But we didn't have that eye toward improvement. And so psychologists will talk about the idea of rather than breaking habits, extinguishing habits. And David Mann talks about this in his book. The idea that we want to start doing things and repeatedly do things, more of a gradual process. So we talk about extinguishing some of our habits in our teams.
So some of the challenges. It wasn't as easy as it looked. I mentioned it required more time within the team. It wasn't going to be just something one person could serve 10 teams to do. The idea that information is very difficult to collect sometimes. putting these things together. We had disparate tools. We've probably got at least 10 different electronic tools that we use. And so being able to have some flexibility and understanding of all these different tools and how each individual team has created the board is a little bit of a challenge. But our goal was to initially help the teams increase one area at a time, and again, over a month period. Small, short, we could figure out, well, is this working for your team? Is it not working? Is this flow manager thing a total bust? We'll try something else. It's very low cost to the experiment. Any questions here about the flow manager experiment? Yes, David.
Obviously, for a long time, I resisted putting roles.
Right.
Because it's the stuff that you now made it. Yep. But I'm seeing increasing evidence, including one of our own clients just two weeks ago, literally this huge business unit of a really, really big tech company. So very profitable business unit, massively profitable company. No one in the business unit actually responsible for the outcome.
We could figure out, well, is this working for your team? Is it not working? Is this flow manager thing a total bust? We'll try something else. It's very low cost to the experiment.
Any questions here about the flow manager experiment? Yes, David.
I've got one observation. Obviously, for a long time, I resisted grouping rules into the camera.
Right.
Because it's the stuff that you know, man, that the rules are, what you've got. But I'm seeing increasing evidence, including one of our own clients just two weeks ago, literally this huge business unit of a really, really big tech company. So a very profitable business unit, massively profitable company. No one in the business unit actually responsible for the outcome.
And it was the head of the business unit, the senior director, and he said, so who's actually going to care about these metrics you're talking about and actually want to use them and drive the improvement? And I said, well, who's in charge of taking the customer's orders and delivering them to them? He said, oh, we don't have anyone to do that. I said, well, what do your scrum masters do? Because in business, you know, there are a lot of scrum masters.
And he said, well, they enforce the rules of scrum.
And we actually had to have a discussion about, are you telling me you need to hire six, I need to hire six new managers?
So again, I said, what do your scrum masters do? Well, maybe we need to get rid of them.
So it had never occurred to me that there would be organizations where there was actually no one responsible for the delivery to the customer. And I'm thinking that actually maybe it is true. And that we do need to specify a role, but with this caveat on it that says, only if you have no one who's currently responsible to collaborate, install this role. If you do have it, then don't go changing things around.
Yeah, that's a great point. And this has led to some greater discussion along those lines. Who's responsible for delivery? You know, we always say the team is. Okay, that's great. There isn't quite the level of accountability and, you know, caring about the, who ultimately does care about these things. And so, Part of it for us is going to be, is this a person role or is it a hat that someone on the team wears? It does appear to be something that will require more time than just simply another activity that a person does. And actually, we outlined the role based on standard work. So we went through and did an activity where we enumerated all the different things that the flow manager should be doing on a daily basis, on a weekly basis, on a monthly basis, quarterly basis. And so I actually put that on my blog, which I have a link to at the end of the presentation. But it's an emerging conversation for us. And then you have the increased difficulty of saying, of building this into statement of work, saying, what is this flow? We've heard of scrum masters. We get that. Some of our customers are at that level. They understand the language of scrum. Flow manager, this is, what is this thing? This is weird. I don't understand. And so helping teams use this role without necessarily, again, finding the resistance when you're pitching this to customers or creating contracts.
I thought, yeah, go ahead.
You talked about your organization without managers. Is it something you already have, or is it something you implement over the years?
So the managers, you said? Yes. We don't really have managers.
We're an organization without managers.
We don't have that formal role. We have our executive leaders. And then we have teams, and then we have team leads.
Is this something you are from the beginning?
Yes, from the very beginning it was like that.
How big is your organization?
So we have over 200 people now. So it might be a function of just our organization size and the natural growth cycle for organizations of that size.
When you get that level, you start building in some middle layer. But for us, again, that's not our culture. And so coming up with something like a flow map. manager who works alongside and inside teams is probably going to be a better model for us.
Our teams are highly empowered, and so we want to keep that. We don't want to create friction there. So really quickly, I'll keep going. Thank you. Merci. So you've heard of the three main feedback loops. This is what we call them, stand-up meetings. This is a daily meeting for all of our teams. And then we have retrospectives. We've been practicing retrospectives for several years now. And over the last year, we implemented the operations review. And again, this is a different context for us because we've got all these different autonomous, loosely linked teams getting together for an operations review, which you might normally think of as being a divisional thing.
Okay, so I mentioned we're doing the first two things pretty well. There's a, I don't know if you can see it from here, there's multiple stand-ups happening. This is about 9.30 in the morning. This is a regular part of life for us.
And we have retrospectives, usually weekly or biweekly. We've created a group of kind of voluntary facilitators, people who go from other teams to help other teams facilitate the retrospectives, which is a really great practice for us. We've helped them learn how to be better facilitators. I mentioned, though, that some of these things have gotten stale, and our teams, though they do identify improvements, they don't necessarily manage. their improvements as experiments. So it's kind of like, yeah, it feels good, feels like it's improving, not really using data to understand properly if they actually have improved, setting target conditions, et cetera. Okay, I mentioned the operations review. This is what it looks like. People get together. It does focus people on managing with data. And so if you come to this meeting, you have to have some kind of data-driven
experiment that you're working on. So what's good about this? It's a venue for sharing these practices and judging how well they did. So there's some lightweight accountability, peer accountability in these meetings. But really it's more like people on different mountains shouting to each other across the mountains. They're about halfway up and they're saying, hey, how are things on your mountain? And they don't really necessarily have an ability to
remove the hurdles or remove the blockages to get to the summit. And so there's no real problem-solving orientation in these meetings. There's no higher level feedback closure. And so
We want to make those more oriented toward problem solving and accountability at the highest level. So there are some projects that are related to single customers, and so that's where we see our operations review moving. So there would be a way for teams to understand and benefit from what other teams are doing, but really this would be the next level of having project sponsor work with customers to remove the blockages that teams can't do just in their own retrospectives.
Right. So things going well at stand up. We're kind of ticking the box for retrospectives. And then we're still thinking through what operations review looks like in our world.
OK, so that's our next experiment.
So really quickly, takeaways. So I mentioned I'm primarily interested in people enjoying their jobs. And so people being happy is what makes me happy. So people are already satisfied, already more satisfied with their teamwork. Even just in one team, we had a team of six people. They had around 45 items in progress. Which they couldn't see because they had it all tacked up behind one single sticky. And so making that visible within a week, they reduced that to 12 items in progress. One team has already reduced cycle time.
And it's just generally at this point creating a greater sensitivity to their system, seeing their system as a whole, an awareness of what's going on, what changes they can make. I mentioned the idea that we have a very collaborative workspace, the idea of virality. People in other teams now are coming to me and saying, hey, I heard what you did, and this is kind of what David was mentioning. I heard what you did with that team. Do you think you could talk to my team about it? And so there's people who are talking about the idea of uncovering sources of dissatisfaction in the system. People are saying, we're doing great, we're delivering, but we could be better. And so it's sparking this kind of conversation in our organization. The idea is that we're catalyzing change one team at a time. So the way you scale Kanban isn't to scale it in a traditional sense, but it feels like what we're doing here is a really helpful way. And again, within just a few months, being able to get many teams exposed to this kind of thinking. So context is important. Education, we found, is very low friction. So just helping people understand things is really helpful. And there's not a lot of emotional resistance to that.
So anyway, so that's, I know we're about out of time.