X
A lot of the reasons we have inaccurate estimates is because we're not using Lean product development approaches. And that's the topic of this particular talk.
Introducing Janie and her teams (0:20 to 5:40)
Let me introduce you to Jeanie. Jeanie arrived as the new CIO. She has teams doing what they call Agile. It's Agile really in quotes. They're using the words of Scrum but any Scrum Master would really not recognize it as Scrum. They were not getting anything through their system. They could only release a feature about once every week or two, the teams had a lot of interdependencies, everything was "late" compared to what the organization wanted.
And inside the teams, people didn't collaborate. So they had developers and testers and some UI people in the teams, but they were not collaborating inside the teams. And the managers did not collaborate at all. Often that was because of the reward system. So they were rewarded for their stuff but not rewarded for the entire product, and the project portfolio decisions. So people were too nice to each other to actually yell and scream in the meetings, but they certainly did a lot of complaining outside the meetings and making the decisions was horribly difficult.
So, this is what her organization looked like. She was at the top as the CIO and you'll notice that there were people by function. We have the Development Director Front-end, Middleware, Back-end, Platform / Engine, QA and then Tech P ubs. So, everybody had their own function and people were matrixed into the teams.
Management belief #1: 100% Utilization
The problem is, everybody had a whole bunch of management beliefs that prevented them from actually getting the work done. So if I look at it, they had a belief that 100% utilization and resource efficiency was very important. If every single person was fully utilized every single time, every moment of the day, then they would make progress. Except, that's about divide and conquer for knowledge work and that does not really work for knowledge work. It works for manufacturing. It works for when you have the same thing that you're producing all the time. It does not work for collaboration. It works for children, when you wanna separate the children when they're screaming at each other. But it does not work for people to work together.
Management belief #2: People work alone
They had the belief that people worked alone on knowledge work projects. I'm from the IT and engineering software part of the world and in IT and engineering, people have to learn together to actually get the work done. So, one of the problems is that school taught us we needed to work alone. Well, maybe you folks are a lot younger than I am. I only had one group project in school. But I suspect that many of you had many more group projects. But cost accounting reinforces that belief that people worked alone to be the best people that they can.
Management belief #3: Reinforce one person’s expertise
And if you reinforce one person's expertise, like the UI (User Interface) people always work on the UI and nobody else works on it. Then, that's come from the belief that the work would go faster. It turns out not to be the case.
Management belief #4: Someone needs to tell people what to do and how to do it
And if you have people working on several projects because they are totally utilized, that goes back to the belief that people need to be told what to do and how and when to do it.
The problem of hierarchical-based approaches
So, the organization was kind of... It wasn't non-functional, 'cause they actually got some stuff done but it was not very functional. It didn't work for them.
When you think about divide and conquer and I've been thinking about this a lot lately. The problem is all of the issues have to go to a middle man. Often, a manager. So, people all do their own things and then somehow, the manager has to beto say, "OK do this, OK do that." So, you end up with a lot more management layers.
So if you've ever seen an Agile approach that says, "We do Scrum." – which is perfectly good at the team level – and then we do a Scrumer Scrums, And then we have Scrum of Scrum of Scrums. And then we have "Scrum of Scrum of Scrum of Scrums". At infinitum.
Those kinds of hierarchical-based approaches don't really work for knowledge work. It slows everything down.
What is Flow Efficiency? How does it compare to Resource Efficiency (5:40 to 9:16)
So, let me introduce you to the ideas of resource efficiency versus flow efficiency.
Resource efficiency says, "I work because I am the best at this thing." And then I hand off the work to the next person. And then that person does their work, they hand off their work to yet the next person. And so on and so on.
In fact, we used to think that phase-gate for knowledge work was best done this way. So if you have a bunch of phases, then we have all the architects work at the beginning. And all the designers work next. And all the developers write functional specs and probably some code. And then the testers at the end finally got it.
But with a phase-gate, we always have loopbacks. Because we did not get it right the first time. Sometimes, we didn't get it right the second time. Or the 37th time. Or the 155th time.
So, resource efficiency for knowledge work does not work that well. Unless you have a really short project with very clear requirements that are not going to change. In which case, it works wonderfully.
But most of us work on projects or programs that are much longer than a month long. And that's why we really wanna think in flow efficiency.
Flow efficiency says, "Let's take the problem to a team of cross-functional people and everyone will work on it together."
So, I don't know if you've heard about the ideas of pairing, swarming and mobbing. But all of those ideas are people working together.
Pairing is when two people work together on the same item with one keyboard.
Swarming is when the entire team takes one item and goes off and does their own thing and checks back periodically, every hour or so.
Mobbing is when the entire team works together, one keyboard with a giant screen. And the first time I heard about mobbing, I thought, "These people are nuts." Why would it make sense for every single person on a team to work on this one thing? Well it turns out that when you work in very short timeboxes of four or five minutes and you rotate who is at the keyboard, the entire team learns very, very quickly. I've seen mobbing work for any kind of design work where you might have to collaborate on the design and then figure out what to do as you continue. It certainly works really well for software.
"This is Lean" is the book I've learned it from. It's an excellent book, you might wanna pick it up.
So, when we think about resource efficiency, we reinforce the silos that already exist in the organization. We think is so efficient but it turns out not to be efficient. When we think in flow efficiency, we reduce the need for experts. We actually have a flow of work through the team. We optimize for flow as opposed to optimizing for resource utilization. It's a different way to think about things.
How do you measure Flow efficiency? (9:16 to 11:06)
Now, the nice thing about flow efficiency is it totally changes the measures on the results that you might have.
We don't need to measure a person's output, we measure the features that are completed and done and still in progress. That's the feature chart.
And what's really nice, especially in software, is if you look at the features that are completed, you can say, "Oh, we can look at these various feature sets!" I'm not familiar enough with Planisware to tell you which module it is, but if you say, "We can see that we're done by about 1/3 here... A little bit more... By half... About 80% done... Nuh, the dangerous 90% done... Then, we can see that we will finish what we expect to finish. And we can also see when we have not started a given feature set it all.
So the interesting thing about flow efficiency is you start to look at the outcomes, not the outputs. So if we say, "Yes, I worked all day today. I had an output of eight hours" or something like that. But if I say, "With my team, we finished a feature. Our customers can actually use this." Now, we have a possibility of actually managing the project portfolio where everybody can agree, for now, on what is really going on.
So, it's really important to think about, "What do we want to measure? And how do we want to measure it?"
How to work as a team (11:06 to 12:35)
So, Jeanie made a bunch of changes. She asked the managers to work as a team to complete the products. They had never worked as a team before, they've always competed with each other. So this was a really different way to think about working. She said to them, "I will protect your salary and your bonuses for the next six months."
Because one of the problems if you have MBOs (Management By Objectives) and you have objectives that reinforce your silo and not collaborating across the organization, you have to do something for the managers. Otherwise, why would they bother collaborating with each other? Not everybody is that altruistic.
They measured the throughput. The cycle time and the lead time. And they retrospected; they did an Inspect & Adapt every single week to say, "How are we doing as a team? How are we succeeding or not succeeding as a team?" And she did not say, "You have to believe this." There was no drinking the Agile Kool-Aid. There was no drinking the Lean Kool-Aid. There was always this is notion of, "I want you to change your behaviors and see if that leads to changing your beliefs."
Introducing the Value Stream Map (12:35 to 17:48)
The original Value Stream Map
So, here's an original value stream map for what things looked like in their organization. They would start with the UI in the platform working separately but on the same feature. That took a day. Then there was a half a day of delay because people were working on something else. They were trying to interweave their tasks, their work. And then the Middleware and the Back-end, they worked separately. Another half day of delay. Test and Tech Pubs: this was a full day because this is the first place the feature actually looked like a feature. And then, there was half a day of delay before the Product Owner could review and accept the feature.
So everything took a long time. The total cycle time for one feature was five days. Now when people estimated it, they estimated it at two to three days. But this thing took five days, twice what they had estimated.
Another way to look at this... This is why it happened. See these feedback loops from the first people to work on it handed off to the people at T3 and there was a feedback loop because things didn't quite work. And then there were more feedback loops, and more feedback loops and finally, everybody decided it was done.
So what's really important to understand, if your estimates don't account for feedback loops in the work itself, the estimates may not accurate. And if you have people multi-tasking on several projects at one time, there is a delay before they can get to the next piece of work. So multitasking nullifies estimates totally. If you have people multitasking, they cannot possibly give you an accurate estimate.
The Value Stream Map when focus is on flow
So, if you focus on flow, this is the value stream. All of a sudden, people met as a team, they asked the people to divide into teams, they didn't tell them, "You, you, you and you, you're in one team." They just said, "Please organize yourselves as total cross-functional teams. And we'll figure out what to do about how we manage you, and help you get your work done."
The team members worked as a swarm, so they decided what to do and how to do it, they would go off, they worked for an hour and then they came back and talked to each other as a team for five minutes, went off, came back, went off and came back.
It turns out that doing that, they were actually able to finish that one feature in one day. Totally done. Because they worked on it all together. Now, the Product Owner was still not available. So, they was still a wait for him. But it turns out that the cycle time was much, much less. This was the two to three days that they had expected. So once you started thinking about how do I get the flow of work through my group? Through my organization? It changes how we think about all of our product development.
Their feedback loops were much smaller. So, the team might agree that it was done, But the Product Owner had feedback. But they actually were able to finish and agree on what was going on.
So, one of the things that's interesting about flow efficiency is [that] it makes the project portfolio discussions much, much easier. 'Cause you're not multitasking people in and out of various teams. So when you flow work through teams, the project portfolio discussions change. You still have a ton of difficult decisions. You still have to say, "Is this project right for our strategy? Is this project or program right for now? Which one is first, second, third? Maybe even never? So, can we commit to this project?" We still have all of those really, really tough decisions.
But when you start flowing work through the team, now you no longer have to contend with multitasking. Your resource management becomes much, much easier. 'Cause you're assigning teams, not people, to work.
The project portfolio flow (17:48 to 18:44)
This picture is a project portfolio flow that I happen to really like. You have the collected work in rank order. And yes, I know that rank ordering is one of the most difficult things. You then say, well we commit, kill or transform. [And] if we commit, we commit to a team. If we kill it – and some of you are nicer than I am, you will only put it on a parking lot as opposed to actually kill the project or the program. I always wonder how many people actually kill based on insufficient estimation or inaccurate estimation.
And then sometimes, you realize you have to transform a project. You might not realize that this project actually spawns many, many other projects and it's a program. So, think about what it needs to be.
Changing the culture (18:44 to 21:48)
Changing the management mindset
So, Jeanie's Agile management team changed over the course of time. They decided to have a goal of serving the people who did the actual work. They collaborated an inter-dependent work so they could eliminate delayed states.
One of the problems with management decisions is that they often take a very long time. Managers start to think about a decision at a specific time and then they don't have all the details. They have to go out and get the details or they don't have the right people in the meeting. So the decision takes a longer and longer time. If you can reduce or eliminate that decision-making time, you're in much better shape.
This particular team was small enough that they could really work together so that they could cover the work. And the team owns all of its own work. So, not only do the Agile teams own their work, the management teams own their work. And they reflected and refined.
When we think about culture changes, there's a whole bunch of various culture changes that happen when you stop thinking in resource efficiency and move to flow efficiency. A lot of the big ones are "Individual to collaborative work". When we think about, "What do we really need to finish this feature or this project? How do we make this happen?" All of that collaboration and teams working as teams, being able to do what they need to do. The managers move to facilitators, servant leaders. They make the really hard decisions but they don't solve the problems for the team. The team solves the problems itself.
Optimizing the mindset so that the organization wins
And one of the other things I really like is understanding quality as the project proceeds. How do we understand where we really are? How do we make it possible for everybody to succeed? Our customers included? How can we make quality, what our customers want it to be?
So, there is this notion of, Jeanie said, "Well, we have to change the mindset." And all too often in the previous organization, it was either nobody wins or I win. But she said, "How can we optimize for the organization winning? How can we make that be how we work as we proceed?
Flow efficiency really changes how we think about the organization. How can we collaborate more? How can we make this work for everybody?
5 steps to free your Agile management team (21:48 to end)
So, if you wanna free your Agile management team, you might consider these five steps.
Create a management team with organization-wide goals. Not silo-based goals but goals that span the organization.
How can you visualize your work and your bottlenecks as a management team? Most of us don't think of our work and bottlenecks as a management team but we have them.
How can you measure the throughput? The flow of work through your organization. And sometimes with managers, this is about decisions. Not about features. Teams are going to deliver features. But how can we make the throughput, especially though the management team possible?
When do you need to retrospect and improve?
And how can you model this culture for everybody else?
This is not easy. This is a total culture change. And it's possibly a whole thinking change for how we think about organizations and what really makes sense.
So, if we change our approach to knowledge work, we can say, "Lean for knowledge work is not about repeatable process that Lean for manufacturing is." It is removing waste but the waste is in the time, not in the steps that the people do.
So, how can teams create their own process? How can we optimize for everybody's flow and throughput? And then how do we amplify the learning as we go? How do we create smaller feedback loops that give us more learning as we proceed?
If you really manage your project portfolio and flow work through teams, you can create a lean development approach. And if you have a lean development approach, your project portfolio management is much, much easier.
Thank you very much.
