How to proceed my experiments with the Flow State?

[RAM]

Hi,

I am struggling with one specific subject mentioned in the GTD book.
In chapter 14, David Allen explains the ‘Flow Theory’.

The main points in this chapter are:
- Flow is a mental state in which a person performs optimally and is completely absorbed by his or her activities
- Flow and GTD are strongly connected
- The idea of flow is comparable with the idea of mind like water

As the idea of flow promises an optimal performance, I decided to do an experiment.
The idea of my experiment was to prepare a speech, while being in the flow state. I started on a Sunday morning and stopped during this day when the preparation of the speech was completely done. In other words, I did it in ‘one single flow’. Chasing one single clear goal, having a challenging task and the absence of interruption made it indeed easy to reach the flow state for me.

I experienced one big advantage:
- the absence of procrastination.

But I perceived also some serious disadvantages:
- Reduced self-reflection (due to chasing one goal), which can easily lead to tunnel vision
- Increased introvert behavior (due to high focus on one task and prevention of interruption), I experienced difficulties with both speaking and listening.

As a conclusion: I experienced the flow state as far from optimal.
What did I do wrong? How can I do a better experiment? Do you have experiences with the flow state?

For the rest, I really enjoy the GTD-method in my daily life.

Thanks.

 

[ArcCaster]

Mihaly Csikszentmihalyi is the author of 'the book' on flow. My attempted summary of such a state: you are so totally absorbed in what you are doing that you can be startled when somebody interrupts you for lunch What you are doing can be anything, from a relatively introverted activity such as speech writing to a relatively extroverted conversation or group activity. Some things take you more naturally into flow than others -- skiing a challenging mountain can take you into flow without any effort on your part.

It is NOT flow if you are distracted by things you are NOT doing -- errands you are trying to remember, loose ends that need tying up, the upcoming meeting you are not quite ready for.

Goal is to be totally present in whatever you perceive to be THE activity most worthy of your time right now.

 

[TesTeq]

But I perceived also some serious disadvantages:
- Reduced self-reflection (due to chasing one goal), which can easily lead to tunnel vision
- Increased introvert behavior (due to high focus on one task and prevention of interruption), I experienced difficulties with both speaking and listening.

I would perceive them as ADVANTAGES. I don't need any self-reflection, or speaking, or listening when I'm writing a speech!

 

[Gardener]

I, too, see those disadvantages as advantages. Your effort to get yourself into a flow state prevented you from multitasking. And that's a good, not a bad, thing. I suspect that at some point you were persuaded that constant multitasking is good, but it's not.

There's nothing wrong with being focused on one task, and isolating oneself from other ideas and thoughts and distractions, for a period of time. It's essentially impossible to get any deep, detailed work done without that focus.

And if you're working on a focused task, you shouldn't be expected to simultaneously interact with others. I do realize that the average workspace does involve constant interruptions from other people, but that fact, and the fact that those interruptions make flow almost impossible, is a bad thing, not a good thing.

I've finished typing this post, but I'm pausing because I'm so very puzzled as to why you found focus to be a non-optimal thing. Can you explain any further?

 

[Oogiem]

But I perceived also some serious disadvantages:
- Reduced self-reflection (due to chasing one goal), which can easily lead to tunnel vision
- Increased introvert behavior (due to high focus on one task and prevention of interruption), I experienced difficulties with both speaking and listening.

As a conclusion: I experienced the flow state as far from optimal.
What did I do wrong? How can I do a better experiment? Do you have experiences with the flow state?

I'm with most of the other posters, what you cite as disadvantages I see as advantages of the flow state.

Why do you need to do self-reflection when you are trying to get a speech written? Why do you need to interact with people when they break your train of thought?

I think you expect flow to come while still allowing for interruptions and IMO those are mutually exclusive things. Flow by necessity means ignoring other tasks because you have decided that what you are working on is the most important thing to be doing right now.

My idea on a better experiment is not to do such a large project or task that it takes the entire day. Look for places to get into the flow mindset for shorter periods of time.

Yes, I often get into the flow, coding is one task that generally does need that fully engaged mind state and when I am really rocking the code I don't even realize when I am thirsty, need to use the restroom nor do I hear anything around me even my husband talking to me or the phone ringing. I can be working on something and only after several hours do I surface long enough for the external environment to intrude. It is in these intense sessions that the best most creative work of implementing new features, designing new database tables and queries, and fixing particularly thorny bugs tends to happen.

 

[Gardener]

This is suddenly reminding me of the book Quiet, by Susan Cain. A quote:

"The New Groupthink is also practiced in our schools, via an increasingly popular method of instruction called “cooperative” or “small group” learning. In many elementary schools, the traditional rows of seats facing the teacher have been replaced with “pods” of four or more desks pushed together to facilitate countless group learning activities. Even subjects like math and creative writing, which would seem to depend on solo flights of thought, are often taught as group projects."

Are we becoming a society where focus and individual accomplishment are regarded as dysfunction?

 

[Gardener]

Increased introvert behavior

I missed this, so I have one more comment: "Introvert" is not a bad thing. It's interesting that you state it this way, as if it is, and as if you expect general agreement that it is.

I really recommend the Susan Cain book.

 

[bcmyers2112]

Like other posters, I'm unsure why you feel your "flow" was "far from optimal. If you don't mind, I have a couple of questions for you:

Reduced self-reflection (due to chasing one goal), which can easily lead to tunnel vision

Some self-reflection is a good thing, but eventually there comes a time when you need to get something done. Which is why I wonder: why do you feel this is a problem? Do you feel that "reduced self-reflection" led to drafting an unsatisfactory speech? What would you have gained from more self-reflection at the point of actually drafting the speech?

Increased introvert behavior (due to high focus on one task and prevention of interruption), I experienced difficulties with both speaking and listening.

Aren't some tasks inherently solitary? Do you somehow feel more ability to interact would have improved the speech you prepared? If so, how?

 

[RAM]

It took me some time but I have read the suggested book ‘Quiet’ of Suzan Cain. Thanks a lot for this suggestion. After this I read the book ‘Peopleware’ from Tom DeMarco and Tim Lister, also known as the ‘coding war games’ book. This book details a lot about the flow state in offices.

In ‘Quiet’, Suzan recalls the following statement from Csikszentmihalyi: ‘in flow, a person could work around the clock for days on end, for no better reasons than to keep on working.’. I wish to discuss this characteristic aspect of flow.

I fully agree with Ogiem’s idea:

My idea on a better experiment is not to do such a large project or task that it takes the entire day. Look for places to get into the flow mindset for shorter periods of time.

This is consistent what is often said to pupils who wish to learn to play a music instrument: ‘practice frequently but not too long each time’. Matt McGarrity also shows how to prepare a speech in several iterations in his MOOC-courses on public speaking. These ideas are not consistent with the theory of flow. This is exactly what I would like to know more about. When I did ‘my experiment’, I wanted to know what happens when doing something in one long big flow.

What I would like to know when David Allen tells us about flow and ‘mind like water’, does he really mean that we should go for doing things in long flows?

There is another aspect of flow that I would like to discuss. ‘The new groupthink’ is related to flow. This is covered in the chapter ‘How collaboration kills creativity’ in Suzan’s ‘Quiet’. A part of the answer is absence of flow.

But, as software developer I started to work in Scrum teams several years ago. A Scrum team is really much like the new groupthink. As many other developers nowadays, I am a Scrum enthusiast and would not even think about going back to the old days of working ‘alone’. This is strange, knowing that according to the theory an introvert should react the opposite way. Scrum fosters interaction between the team member, which indeed causes a lot of interruptions. But productivity is higher than in the old days. In the old days you could have a creative idea but no one listened. In scrum you have now team members who listen, and also you hear the creative ideas from other team members. Because you know each other so well, the ideas tend to converge.

In my opinion this kind of new group think is especially for introverts an improvement. What do you think?

 

[Gardener]

I'm feeling the need for more detail about your implementation of Scrum. It sounds like you're saying that Scrum involves constant interruptions, but I don't see that as an inherent characteristic of Scrum at all. Where are the inherent interruptions?

There's the daily standup, but that's not an interruption--that's scheduled, and it's supposed to be as short as possible. (Hence the standing up.)

There is pair programming but I don't see that as an "interruption", and in fact I'm inclined to think that it would be possible to achieve "flow" in pair programming. And, pair programming isn't a mandatory part of Agile or Scrum.

A Kanban board is a silent, interruption-free offering of status and tasks to pick up. Edited to add: In fact, the board could be used to communicate problems--if something is stalled, that could be communicated by the board, and anyone in a natural pause who gets up to look at the board, or connects to an online board, could try to find a way to help. Or the stall could be discussed at the standup.

Code is likely to be stored communally, in Git or something of that sort, but that also doesn't require interruptions.

So I'm not seeing how Scrum eliminates working alone. Sure, after you've spent several hours in blissful solitary flow and created a nice chunk of code, you will make that code available to your team members, so there is collaboration, but it's not constant, face-to-face, interruption-driven, collaboration.

 

[RAM]

According to authors of ‘Peopleware’ a question from a colleague is sufficient to break the flow. Also a workplace that is a mixture of people working alone and people working together, will break flows.

In a scrum team there are typically a lot of small interruptions:

• Teammates ask each other a lot of questions like ‘I think we should rename that identifier. Do you agree? What would be a good name?’
• Teammates write messages on the chat channel
• A teammate asks you for pairing because of your specific expertise
• A teammate asks you to review his code changes for story xyz
• A teammate reviews your code and asks for explanation and motivation of your choices
• The agile tester reports a possible bug in a story you worked on, and wants you to investigate that first
• The build server reports ‘build failed’
• In devops teams a monitor channel might alert you with alarms , which often are false alarms
• A teammate makes a joke.

In the biweekly retrospective these interruptions are often enforced. This leads to a rule like ‘if a team member ask you to review a story you must stop with your story you are busy with, in order to minimize the work in progress’ or after someone complained that he/she had to wait a long until someone responded to his/her question on the team’s chat channel, a rule that obliges to monitor that chat channel more actively.

Of course a team may also decide to allow to have more work in progress, and permit someone to finish a story or task first. Finding a balance between flow and interaction is needed. This is reason for a good understanding of flow. On the other hand, cherry picking a task or story depending on your mood is a good idea in GTD but not in Scrum teams.

Even with all these interruptions, I really prefer Scrum above development doing a 6-month-project alone. Often done without any code review. I think that Suzan Cain would prefer the 6-month- project and not giving up that privacy.

Thanks a lot for the reply. Asking me for summing up those interruptions gave me more insight.

 

[Gardener]

According to authors of ‘Peopleware’ a question from a colleague is sufficient to break the flow. Also a workplace that is a mixture of people working alone and people working together, will break flows.

Well, not necessarily. If Joe is working alone, Jane is working alone, and Josie and Jessie are pair programming, they can all be in flow. There's no rule that requires that they interrupt each other.

In a scrum team there are typically a lot of small interruptions:

I feel like we may be using a different definition of interruption. Most of the below can happen with an email, a chat message, or some other communication that the recipient can get when they check that communications medium on a natural break. That means that it's not an interruption.

• Teammates ask each other a lot of questions like ‘I think we should rename that identifier. Do you agree? What would be a good name?’
• Teammates write messages on the chat channel
• A teammate asks you for pairing because of your specific expertise
• A teammate asks you to review his code changes for story xyz
• A teammate reviews your code and asks for explanation and motivation of your choices
• The agile tester reports a possible bug in a story you worked on, and wants you to investigate that first
• The build server reports ‘build failed’
• In devops teams a monitor channel might alert you with alarms , which often are false alarms
• A teammate makes a joke.

In the biweekly retrospective these interruptions are often enforced. This leads to a rule like ‘if a team member ask you to review a story you must stop with your story you are busy with, in order to minimize the work in progress’ or after someone complained that he/she had to wait a long until someone responded to his/her question on the team’s chat channel, a rule that obliges to monitor that chat channel more actively.

This sounds like a culture that maximizes interruptions, minimizes flow, minimizes creativity, minimizes productivity, and maximizes possibility of error. You can probably tell from that description that I disapprove.

But none of this is a mandatory aspect of Scrum.

Edited to add: I agree that the build and other alarms may require prompt attention, but I'd still structure this to minimize the total interruptions. In this case, a specific team member could be in charge of investigating any alarms--maybe Jane on Monday, John on Tuesday, etc.--so that other team members can work un-interrupted, at the expense of reduced productivity for the "monitor of the day".

Even with all these interruptions, I really prefer Scrum above development doing a 6-month-project alone. Often done without any code review. I think that Suzan Cain would prefer the 6-month- project and not giving up that privacy.

I think that you're looking at two extremes--one extreme where you are constantly interrupted and can never hope for flow, and one extreme where you never interact with another human being. I definitely think that you're incorrect about Susan Cain's preference. She didn't say that collaboration is NEVER a good idea; her issue is with the idea that collaboration is always the best work style.