Part 4 of 6 in the “Double the Value in Half the Time” series based on David Hawks’ presentation from Keep Austin Agile 2015. Stay tuned for subsequent posts…
So we’ve got all of these challenges…. and one of them is a problem I call Drowning in a Sea of Opportunity. For most companies, this is their #1 problem.
When we go into an organization, we learn everything is a high priority. Everything’s urgent. It all has to get done. The VP of Sales has already promised it, so we just need you to do it. It’s like shoving more paper into a printer—is it going to come out faster on the other side? No! It’s just going to jam up. The goal is not 100% utilization, despite what some managers think. What’s 100% utilization of the main highway on Friday at 5:00 pm? A parking lot. Is anything moving? No, but it’s 100% utilized. When all resources are 100% utilized, they’re running around crazy and unfocused, but they’re busy!
Focus on the Work, not the Worker
We have this saying: Watch the baton, not the runner. The runners are the people doing the work; the baton IS the work. And in most of our organizations what’s happening is a baton, a new idea, comes in and it sits in a queue until it gets enough priority and then an analyst or Product Owner picks it up and gives it some definition. Then it sits in a queue until a developer picks it up, then it sits in a queue until QA picks it up sometime later. And in a perfect world, it would go sit in another queue until it gets deployed.
But there’s a reason why QA exists, right? At a happy hour, we had a quality coach who once said, “I want to make a toast.” She looked at the developers and continued, “I want to thank you guys. I have a job because you suck.” Funny, but true. Once an item gets to QA, the reality is that it’s going to go back to Development because they don’t write perfect code. So, if we focus on the baton—not the runner—how long does it take for the baton to get through? In most organizations, there are batons all over the floor, with very few of them are in anybody’s hand and getting to the finish line.
For example, let’s look at juggling lots of batons at one time. We have 9 projects and 9 developers. It would seem to be more “efficient” to assign one project to each person. Say each project is about a month long and two weeks in, I ask “what percentage complete are you?” Two weeks into a month-long project, they would probably say, “About 50%.” But what happens if something changes? A new requirement? Something that’s now 3rd on the priority list. What are our options? What can we do?
We would probably tell Mark, who’s working on the 9th priority, to jump on this new project. And we might tell John, who’s working on the 8th priority, we need him on this new one too. But we’d tell them to remember where they were because, in two weeks, they’ll need to go back to it. So just comment out all that code? Or better yet, put a feature toggle on it? No, that’s not really a great option. What else can we do? Ignore the new priority? Say no? “We don’t have enough resources so we’ll just we’ll get to it later.” Those aren’t great answers for the business. Or we could just go with the Office Space example and say “I need you guys to work on Saturday… and maybe Sunday too.” None of these are good options.
When we work on a bunch of things at once it seems to be more efficient, but we’re not getting outcomes delivered. We’re not getting things done and we don’t have a good measure of progress.
But if we swarm and focus on one thing at a time, then when we ask the team, “what percentage complete are you?” we’d get a different answer. If they focus, then the team could say “we’ve finished four items and we’re about done with the fifth.” While we probably couldn’t put nine people on one project, maybe we’d work on two things concurrently.
This is one of those new skills Agile teams have to figure out—how to break work down. Not only how to break stories down, but how to break tasks down and share the work. If I just say I work on blue stuff, Mark works on the red stuff and I have a two-week blue task to do, Mark doesn’t know how to help me. But if I break the blue task down into database work, unit tests, development, UX work to design, etc, then Mark might say “I know how to do database stuff, I can help with that part.” Once we break work down, it forces the developers to think things through. That’s what we do in sprint planning. But the Product Owner also shares some responsibility by writing stories that meet the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable chunks of work. That’s what enables us to get to the potentially shippable product increment at the end of the sprint.
Next topic in the Double the Value in Half the Time series: Getting to Done