|
|
Home
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.
CommentaryFlow RoomTop recommendation overall, but clearly high-effort. The place where real work is done is separate from the distractions of phones, mail, interruptions: everyone knows that work in the room is not to be interrupted.Structured InterruptionsThis means scheduling your time to avoid interruptions. So (for example) do your email first thing in the morning - then at lunchtime - then before going home, rather than responding to each email alert. Also if you're busy, don't answer the phone! Very powerful technique, sadly we're not good at ignoring interrupts...Schedule for flowMake sure that project schedules are not counter-productive. This is the macro-version of Structured 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.Acknowledge flow in othersQuite critical! this comes down to a culture of shared effort and respect (how often do we ask ourselves before phoning or walking over to Joe - does it look like he's busy?). A pre-requisite is being able to recognise it.Have a viewThis needs not to be just a view of another busy office. A picture on the wall can do.Set realistic goals/timescalesThe group decided that this was not the same as 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.Delete code religiouslyKeep things in the codebase uncluttered, just like Remove everything from your desk does for your physical environment.Turn off phones/wear earplugsOK, so this is two specific proposals! Both point to taking personal responsibility for limiting the opportunity for distraction in our environment - other mechanisms (for example, wearing headphones, whether listening to music or not) make it even more obvious that we're not to be interrupted.Have a whiteboardA flexible, expressive, shareable, semi-permanent medium on which individuals or groups can express thought unselfconsciously (brain-pen-board). I've had design sessions in front of a whiteboard in which we've solved the world in a couple of hours - and spent tedious afternoons with CASE tools in which nothing seemed to have been achieved.Remove everything from your desk...except that which you need to perform the task at hand :-). So no post-it notes or memos, no copies of documents to read before tomorrow's meeting - just what you need to do the job.Variety of environmentsAcknowledging that individuals vary in what they find helps flow. Some might like a view, some a darkened room...Work in isolationSome participants felt that flow was more likely to occur in isolation - others believed that it could happen in groups. Myself, I go for groups, but the suggestion was made, so here it is.Publish pre-entry to your zoneRelated to 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").Support networkVariant on 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.Links
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.
Contact Created 1 April 2000 Last modified 1 April 2000 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||