RallyDev.com
Mon 21 Sep 2009
What’s So Great About Flow?
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 Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.
I think the info about flow is good, but Walter is looking like a bit of a “straw man.” There is much he doesn’t “get” about Agile which may be understandable. But there is also much he doesn’t seem to “get” about even reasonable non-Agile development.
On the other hand, Sarah is coming across as a tad supercilious. I’d like the exchanges to seem a bit more realistic. I think most Walters would be a bit more “careful in how they phrase what they do. And Sarah, as a consultant coming from the outside, should likely not immediately tell the person she has to work most with that they misunderstand and need “a long talk.”
Thanks Scott,
Yeh, it is tricky figuring personas when trying to be “funny” and also give useful information. So, thanks for taking the time to express your view on the goodness of the “flow” stuff, and the potential hazard of going too far with the Walter and Sarah exchanges. It was their first trip out of the gate. I am hopeful they will get more settled! Thanks, Jean
I think the info about flow is good, but Walter is looking like a bit of a “straw man.” There is much he doesn’t “get” about Agile which may be understandable. But there is also much he doesn’t seem to “get” about even reasonable non-Agile development.
I think Walter (minus the irony, of course) is not too far off from Project Managers trying to adopt Agile just to go with the stream, which, IMO, is a big mistake.
Agile is getting bigger by the day right now, and the problem with it is that a lot of people have different understandings of what Agile really is.
I have had experience with a few skeptical/resistant Walters in my life as an Agile coach. I’ve dealt with this in organizations small, medium, and large. My attempt at a humorous portrayal may have gotten in the way of portraying my real life experiences with these Project Managers and Directors.
I honestly ran into a group just last year who told me that they had been “doing Agile” for a while. They had been taught by their CTO who had “done Agile” at a previous company. And this is the truth: they were required to be 100% allocated. Their Sprint plan and all the tasks and estimates in it had to account for 100% of everyone’s time in the Sprint timebox. This mindset was exacerbated by the team practice (dictated by the CTO) to therefore put in all their vacation time, holidays, and even book club meetings as part of their commitment in the Sprint.
I had a really really tough time talking with them about only committing to delivery of valued items as their Sprint commitment, AND that that should not equate to 100% of their available time within a Sprint’s timebox.
One other thing. This situation also indicated that a lot of command-and control still existed and that there were no retrospectives to inspect and adapt practices and team agreements.
I think the team could have really used a Sarah (though much nicer and less snotty than the one I thrust on Walter) I am hopeful that no one would view me as an Agile coach like Sarah :-)
Thanks for your comments.
Walter is why I shaved my mustache! A career counselor told me they don’t market test well :-)
LOL!!!! Should Sarah give Walter “Extreme Makeover” tips on his mustache as well as Agile adoption tips? Hope your market testing and Agile adoption are both now on terra firma :- )
Ok, I guess I don’t get the idea of ‘Flow’. We’re already scheduling only 5.5 hours of work per person. I though the idea of story points, spikes, and story decomposition was the recommended way to handle uncertainty and to build in some slack into stories. Are you saying that there needs to be additional slack built in? if so, then should we increase the amount of available time(say to 7 hrs/day), so that with slack built-in, we can get about 5 hours of work?
At this point in our Agile implementation we rely solely on story position for estimation and release plannig . Team pulls from the backlog during the sprint planning and there is no command and control on how much they pull, team know about the avreage velocity and more or less pulls the story points based on the velocity and if they wrap up story points during the Sprint period they take up additional tasks if it can be finsihed during the Sprint cycle.
We are defnietly following the 5 points you notes about , So how can you tell if your team has embraced Flow?
Do you think we should be looking the total hours for the resources and use those for estiamtion and release planning over story points and team velocity