MaterialsDownload the presentation (zipped PowerPoint). This describes the process used to come up with the ranked recommendations below.
ProposalsThe think-tank process delivered 14 specific proposals to promote flow in the workplace. These were then voted on, each participant being asked to distribute 10 votes amongst the proposals, specifying both impact and effort for implementing the proposal at their workplace. The results are summarised below, firstly sorted across the ideas judged most valuable and easiest to implement, then by total number of votes cast.
CommentaryStructured Interruptions. Avoid overlapping phases and giving idividuals unrelated tasks. Clearly given that we need people to learn as well as to flow, make sure that research and training is also allowed for in schedules - again, often spoken of but rarely achieved. See also Set realistic goals. Schedule for flow, but a more fundamental observation that underlines the effect of anxiety on flow - it simply won't happen in the face of a challenge that can't be met. Remove everything from your desk does for your physical environment. Structured Interruptions, in that you make it clear to the rest of the world when you may be disturbed. Can be done in advance ("surgery hours are 9.00 to 10.00 and 16.30-17.30") or ad-hoc ("The doctor is OUT"). Structured Interruptions - team members take turns at running interference, taking all the support calls or requests for information while the rest of the team gets on with real work.
Some Reflection...(1 April 2000) Flow has an interesting if chequered reputation. The work of Csikszentmihalyi (who has built his career on propounding Flow as the secret of happiness in several popular books) has been criticised for it's methodology, and the description of the phenomenon itself is described by some writers as 'merely' a metaphor covering a host of underlying neurological events and processes. However, it's an experience with which many musicians, writers, sportsmen, climbers, and yes, software developers, immediately recognise. For me, I'm happy - for now - to work with the metaphor (go with the Flow - hehe).
Some participants raised two particular objections to flow in the software environment, namely that the flow experience is in some sense and along certain dimensions 'out of control', and that it is essentially a personal experience. Both of these were talked about, and surfaced in one of the how-to-promote-flow suggestions submitted - take drugs :-). Regardless of any personal views towards this proposal ;-| I think both objections can be answered by listening to - and watching - a string quartet or jazz combo performing.
Interestingly, one of the themes running through the many break-time and bar-time discussions was Distributed Cognition, an idea which resonates strongly with my experiences as both a musicion and a member of several successful software teams.
(9 April 2000) Having now written this up it's interesting to consider how (for example) Extreme Programming supports flow. I mentioned above that some present (including some of the pioneers of XP in the UK) felt flow was potentially dangerous, however several of the proposals are supported directly or indirectly by XP practices, in particular those which deal with setting aside a separate environment for development, those which stress clarity and acceptance of responsibility in planning and scheduling, and in one case (Delete Code) hooking straight into refactoring.
Clearly in the course of a 75-minute session there wasn't a huge amount
of time to refactor the proposals, so there is some overlap in the list
above which could be fixed by working to make them more specific. Could
be the seeds of a pattern language here too.
Created 1 April 2000
Last modified 1 April 2000