Sarah: “Whoa, whoa, whoa, Walter. Where are you going in such a hurry with that look on your face? You look like you’re chasing that guy who stole Christmas.” Walter: “Grinch.”
Sarah: “What?” Walter: “It was the Grinch that stole Christmas.”
Sarah: “Stop changing the subject, Walter! Where are you going?” Walter: “I’m going to the Frboz 2.0 Project Post Mortem, and it’s gonna be pure hell. It was over 100% late, bad quality, angry customer. It’s a classic. And I wasn’t even on it. I’m supposed to be there to criticize the project leader.”
Sarah: “How did that happen? I thought they went through all of that on 1.0, didn’t they?
Walter: “Yes they did, and they had a post mortem and they made changes and it seems to have made things worse. They blamed a few people and then left them to work on the 2.0 project because they learned something by being blamed, so they were pretty demoralized to start with. The post mortem decided to be more rigorous on signatures, so the Requirements phase took twice as long as planned. Every time they tried to get all 12 people to sign, one of them had a change to make. Same thing happened during System Test. They were supposed to get CTO approval for every push to pre-production, but the CTO was never around and she had to be completely briefed on everything that had happened in that build when they finally found her before she would sign. Everything took ages! In the end, everything they did made things worse. I don’t know what to do. This meeting is going to rip some people up, and for no reason that I can see.”
Sarah: “Hey Walter, I have an idea! What if you tried to get them to look at root causes instead of concentrating on blame for surface symptoms? Maybe they would discover some useful ways to actually improve things. What do you think?”
Walter: “You know, Sarah, it’s crazy enough that it just might work. Remind me of some easy ways to do root cause analysis. I’ll only get maybe one or two chances to make my point.”
Sarah: “Try the 5 Whys. It’s a technique from Lean Manufacturing, but it works really well. Start with a symptom and ask ‘Why is that?’ Then when you get an answer, ask ‘Well, why is that?’ When you get that answer, ask it again. Do it a bunch of times and you’ll eventually drill down to a root cause. Ask ‘Why?’ five times. Get it?
Walter: “OK, let me see if I got it right. I pick a symptom, like ‘requirements not agreed on time’ and ask “Why?”. Then they say ‘…because it was too hard to get all 12 signatures.’ So then I say ‘Why was that?’ And they say ‘…because every time we made a change and went to get the signatures, one of the people would have another change to make.’ So then I ask ‘Well, why did that happen?’ And they say ‘Because everybody kept learning more about what the product should be.’ And on and on until eventually we find out something like ‘Oh. It’s impossible to get all the requirements right up front.’ Or whatever. Then we can figure out how to address that root cause. Is that it?
Sarah: That’s it, you’ve got it.
Walter: Gimme five, Sarah! Thanks for the help!
About the Author: Alan Atlasis a poker player, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.
Walter: “So Sarah, I am trying to get started with this Agile stuff.” Sarah: “Great, I am here to help. What have you done so far?”
Walter: “Well, I get that we deliver something every two weeks. Agile makes us hyper-productive. And to do that, my job is to make sure everyone is busy all the time, right? We’ll get the most features if I get people to sign up for the maximum amount of work at the start of the two weeks. This is easy!”
Sarah: “Hmm, I think we better take a step back. You may be misunderstanding something about productivity. Have you ever heard about Slack or Done or Flow?”
Walter: “You mean like Slackers who just blow off work? Sure! And done means its coded, right? And Flow must have something to do with how you hide under the radar to get away with slacking how much you code. Gee, this Agile stuff doesn’t sound very productive after all!”
Sarah: “Well, Walter, I think we need to have a long talk. Coffee or martinis? Pick your poison.”
So What’s so great about Flow?
Walter is stumbling on how to get his teams started with Agile. He holds the notion that it is HIS job to make sure everyone is fully allocated, super-productive. And for him, productivity is measured in lots of features coded.
Sarah has some great advice here guided by the Lean principle of Flow. Productivity is not about filling our plates to maximum capacity during planning meetings. Rather, we encourage team members to build in “slack” in their commitments. They seek Flow of value delivery versus 100% allocation. That is: “Of our total time at work in this 2 weeks, we really only have this much time available (e.g. X hours). And because we need to allow room for discovering what we can’t know, we are only going to sign up for and commit to this much (e.g. 80% of X) work.” As for “done”, a team commits to a certain, attainable level of doneness that includes more than code: testing, documentation, code review, acceptance, etc.
When teams pull these two fundamental Agile practices together, they are invoking the Lean Principle of Flow as guidance.
This is important to understand. Agile teams paying attention to Flow do not bloat estimates in order to manage uncertainty. Nor do they use bloated estimates to artificially create 100% allocation within a timebox. Rather, teams give their most accurate estimates for the work. These estimates include what work it will take to adhere to their definition of “done”. Embedding slack in team capacity absorbs the uncertainty and doubt incumbent in new work. And, at the end of the timebox, a team truly committed to Flow checks in on how it delivered value. It then inspects and adapts how it can continue this smooth value delivery.
Sarah, gets this. New Agile teams that concentrate on Flow before moving to other rigors create a sturdy foundation for continuous improvement.
To be clear, here is what we mean by Flow.
A team commits to only taking on as much work as they can deliver consistently over time. Think of Flow as the work that can smoothly move through a pipe that delivers value to customers. If we fill the pipe to 100% capacity (as Walter is eager to do), we create at the very least turbulence. At its worst, value delivery stops entirely. When Flow becomes this turbulent, work becomes sloppy and quality suffers.
So how can you tell if your team has embraced Flow?
There are a few basic tell-tale practices you should see. Teams in Flow:
Are empowered and collaborative in decision making
Don’t over commit to what they can deliver
Declare a definition of “done” for how they make commitments to value delivery
Use a time-boxed rhythm with slack for high-quality product delivery
Engage in inspection and adaption practices that amplify their learning about team agreements, process and their definition of “done”
Most importantly, teams in Flow have a smooth reliable rhythm of delivery. They can be seen making and meeting their iteration commitments and thus have a stable iterative and incremental process. This is the key first stepping stone to Agile adoption.
Sarah will stick with Walter and his team in their adoption of these Agile practices of Flow. She’ll check in with them for a couple of iterations to help them inspect and adapt while adhering to Flow. Sarah knows there are tons of quick wins to find when teams move to true Flow. And she’ll be there to guide Walter and his team even when the roadblocks to those wins seem insurmountable.
About the Author: Jean Tabakais a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by emailor RSS.
RallyDev.com
