Getting Developers Into the Team Flow State
Will your team of software superheroes be able to defeat the productivity blockers known as The Distractions??
Join the DZone community and get the full member experience.Join For Free
The past few years, there has been a lot of discussion around programmer flow. This concept combines the realization that while programmers are technicians, in many ways they are also artists. Programmer flow is that state when the muse arrives, concentration and innovation ensue, and the combination results in maximum productivity and creativity. The programmer is in the zone.
How does a programmer achieve this state? This is one of those “I know it when I see it” situations, but it often involves talent, high motivation, clear direction, confidence, and time. How does a programmer fall out of this state? This one is easier: distractions. Even a trivial tap on the shoulder breaks the spell and resets the timer to get back into the flow.
What if we took this concept and extended it to an entire team?
How to Achieve Team Flow
How can we build an environment that would lead to team flow, a state where the team, operating as a unit, is in the zone of maximum productivity and creativity?
Achieving team flow certainly incorporates the same factors necessary for individual programmer flow, but it also involves some degree of extreme team synergy:
- Swarm on as many adjacent stories as possible without introducing blocking.
- Share ideas and assets so the work of every team member furthers the team flow.
- Incorporate a feedback loop to keep team motivation high.
We can try to enable these activities on our own, but it would be much easier, more efficient and more stable if we could support team flow with technology designed to empower community and productivity. Without that, it’s going to be much easier to lose your team flow once you achieve it.
How to Lose Team Flow
Like achieving team flow, losing it is similar to how an individual programmer loses their flow: distractions. Not only physical interruptions but also environmental distractions.
Evolving stories are fine and a natural step in the Agile process, but clarity is a key ingredient to flow. Creating assets like launch configurations is often trivial, but they take the developer out of the zone and, hence, affect the overall team flow.
Better if assets are there, available as and when needed—another instance where technology could be crucial.
Is This What Team Flow Feels Like?
Like a runner’s high, you’ll know it when you feel it. But if you’re looking for some real evidence, knowing whether your team has achieved a flow state should really come out in the sprint retrospective. It should find its way into the “What did we do well?” category. And conversely, the distractions that interrupted the possibility of team flow should become apparent in the “What needs improvement?” category.
One interesting anecdote would be for the team to give some thoughts on distractions throughout the day. How many? Who or what is the distraction? If it’s a physical interruption, who is the main distractor? If it’s an environmental interruption, what was missing at the moment it was necessary? And, most importantly, how can we aspire to remove these friction points?
While we want each individual programmer to be as productive as possible, output really comes from the team. Taking steps to seed the environment to encourage the growth of team flow could greatly improve the throughput of everyone and enable them to more quickly convert ideas into customer value.
Published at DZone with permission of , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.