Getting New Agile Teams into Flow

[article]
Summary:

Jean Tabaka considers "flow," a term borrowed from the lean thinking world, to be a core discipline for guiding new agile teams. In this week's column, Jean reveals the characteristics of agile teams in flow, the roadblocks they may have to overcome, and the benefits they will derive from their successful flow adoption.

"Flow," as defined by lean thinking, describes a mode of work in which there is a smooth, non-turbulent delivery of valuable product features. When practicing flow, a team constantly pays attention to tweaking, massaging, and increasing unimpeded value delivery. So, flow translates into rhythm that guides teams in delivering consistently good product without overburdening their work flow.

To understand flow and how new agile teams can apply it, I want to cover some characteristics of agile teams in flow, the roadblocks that teams may encounter when attempting flow, and the rewards that teams can expect should their unyielding dedication to flow succeed.

Characteristics of a Team in Flow
Some new agile teams may skip over some fundamental flow disciplines, focusing instead on specific engineering practices. But without these flow disciplines supporting those practices, such teams may find themselves struggling to maintain, mature, or scale their agile initiative.

Time-boxed Rhythm of High-quality Value Delivery

New Agile teams often concentrate on a practice of time boxes without applying the flow. Think of flow as the drumbeat that maintains a constant rhythm of value delivery from time box to time box. Team work begins and ends on the same day with every time box. And in that time box, the agile team commits to high-quality value delivery every time. That is, the items completed are the product representative's highest-value items the team can possibly deliver with the highest quality.

Empowered, Collaborative Decision-making

Agile initiatives that come from "above" often suffer a "business as usual" syndrome. This may result in new agile teams that remain un-empowered to make their decisions. In contrast, a team in flow aggressively collaborates to derive informed decisions. Together, team members create participatory commitment events at the start and end of each time box as well as each day. They take ownership of their task definitions, task estimates, and the quality of the work done, and they invite the engagement of a facilitative leader to guide their collaboration.

Amplifying Learning through Inspect & Adapt Processes
In my article " 11 Ways Agile Adoptions Fail ," I mention that lack of retrospection may be my number one characteristic of a failure mode. Teams in flow are constantly working to create smoother, less turbulent flow. That means they inspect and adapt practices about planning that don't overburden their systems (schedules and work). They look for practices in their agile adoption that increase high-quality value delivery. They pay attention to how they collaborate in order to make decisions.

Roadblocks to Team Flow
It's not easy being the new agile kid on the block. A number of organizational bullies may decide to trip up your team with some classic, nasty, seemingly insurmountable roadblocks. At the very least, these roadblocks create great turbulence and impedance around a new agile team's adoption success.

Resource Constraints
Flow is quite a challenge when, organizationally, the policy is to share resources across teams. We can't get better at estimating our work, nor can we get better at estimating our value delivery. And when the shared resources are from QA, we can't create a flow of high-quality delivery of items within a time box.

Command and Control
Associated with the empowered, collaborative, decision-making characteristic above, new agile teams may find themselves stuck in an environment that still relies on command-and-control leadership. This roadblock deteriorates flow by squelching useful information from the team. It ultimately erodes the team's ability to effectively improve planning and thus not overstuff time box workloads. An overburdened system cannot move into flow.

Fixed Scope, Schedule & Resources
And speaking of overburdening the system, this combination of

User Comments

1 comment
Sameh Zeid's picture
Sameh Zeid

Jean,

I enjoyed reading your article. I am just wondering whether a team can achieve the state of Flow without operating in time-boxes. For me, time-box implies that the team commits on certain value (fixed scope) to be delivered at the end of time-box (fixed-schedule). Does that commitment lend itself to the roadblock in the way of Flow?

Sameh

January 11, 2012 - 1:51pm

About the author

Jean Tabaka's picture Jean Tabaka

An agile coach with Rally Software Jean Tabaka specializes in creating and mentoring agile software teams. Bringing more than twenty-five years of experience in software development to the agile plate, Jean is a Certified ScrumMaster, Certified Scrum Trainer, Certified Professional Facilitator, and author of Collaboration Explained: Facilitation Skills for Software Project Leaders.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!