Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How to Get Into Flow

DZone's Guide to

How to Get Into Flow

We always hear about athletes being 'in the zone' during a particularly stunning performance. Learn how Scrum can get a dev team into this same state of 'flow.'

· Agile Zone
Free Resource

Download this white paper to learn about the ways to make a Scrum Team great, brought to you in partnership with Scrum.org

Do you recognize this? You’re working for a while on something you like working on. It’s challenging work, but you know you can do it. You have lost track of time. Weren’t you supposed to eat 2 hours ago? And now that you mention it, you really need to go to the bathroom. You look at the clock and four hours have passed since the last time you consciously noticed the time. You have been in flow.

Flow, or Being in the Zone

The other day I was listening to an interesting episode of the James Altucher podcast (if you’re into podcasts, check out my post about the 5 business/lifestyle podcasts I like most). In it, researcher Steven Kotler talked about the concept of Flow. Not flow as in the way work flows through a process (like described in the seminal book “The Principles of Product Development Flow” by Donald Reinertsen); but flow as in “being in the zone,” the feeling of utter concentration, where there’s no sense of time and creativity is optimal. This phenomenon is popularized by psychologist Mihaly Csikszentmihalyi (don’t ask me to pronounce).

Kotler argues that to get into flow, it helps to work on something that is socially risky. Meaning that you have to show what you’ve been working on, probably on a deadline, and therefore running the risk of being criticized. Having this (perceived) pressure to perform seems to help you get into the zone more easily.

Scrum Helps You Get Into Flow

So I argue that Scrum helps you to get in that state of flow for two reasons. First, working in Sprints imposes a sort of deadline on the work you have planned. So, there is social risk involved. The planning of the Sprint is shared with stakeholders, and though we don’t speak of a commitment towards the Sprint planning (it’s a best effort forecast), the Scrum team is committed to putting their back behind it and working together to reach their agreed upon Sprint goal. As a team member, you will perceive some (self-imposed) pressure of the looming deadline.

Second, the Scrum team shows the result of the Sprint, the increment, in the Sprint Review to gather feedback from stakeholders. This also is a factor contributing to the social risk. In the Sprint Review, the team demonstrates their actual result. It is very transparent what the outcome of the Sprint is.

For this to work, team members should be able to focus on their tasks once they have planned their work. Disruptions should be kept to a minimum. Csikszentmihalyi explains the conscious mind can process 120 bits per second. Listening to a person talking takes about 60 bits/s, so you can effectively follow 2 conversations simultaneously and you are at 100% utilization, the limit. Nothing else you can do. Putting the full processing power of your conscious mind to work on something you’re passionate about, and nothing else gets noticed, not conversations or even your bodily experiences (like a full bladder). So minimize distracting conversations and focus on the task at hand.

But What About All Those Scrum Meetings?

An argument often made against Scrum is that it is meeting dense (read Barry Overeem's advice on how to parry this) and keeps people out of their flow. The image that is presented is that of spending a day every two weeks in a meeting room, getting no work done, and a daily interruption with the Daily Scrum. My counterargument is that first, the Scrum events (they are called events for a reason) replace a lot of meetings that are now unnecessary. So stop doing those! Second, the rhythm of these events decrease complexity: you now know exactly when you are going to review, retrospect, and plan. No more random ad-hoc meeting requests that really devastate flow. Third, regarding the Daily Scrum: I would argue that the Daily Scrum introduces a mini deadline (each Development Team member forecasts what he or she will complete in the coming 24 hours). This again introduces social risk within the team, helps team members focus on the tasks at hand, and helps them get into flow. I have seen this in reality after the Daily Scrum in the morning: a silent team room; focused, concentrated people; someone makes a remark: “hey, weren’t we going to lunch an hour ago?”

What Now?

Now, what to do? Make sure your team is getting the most out of Scrum. Remove all unnecessary meetings, let them set a goldilocks goal (not too simple, not too hard) and get out of their way. And make sure others get out of their way as well. Scrum on!

Discover what Scrum Teams do to make themselves great, brought to you in partnership with Scrum.org.

Topics:
flow ,scrum ,agile ,productivity

Published at DZone with permission of Martijn van Asseldonk. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}