High Attention, Low Distraction
Truly paying attention can be one of the hardest things to do. Even when you are doing something you want to do, say solving an interesting problem, your mind flits about. In a five minute interval you might answer an IM, check your email, check twitter and oh yeah, think about that problem you are working on.
There is a lot of literature out there around “flow” and the efficiency of focusing your attention on just one task. If you are working as an engineer or implementer on a project, common ways to help reduce these distractions are to put up a red flag (physically or with a do not disturb online status) or put on your headphones. You can also try to increase your focus by self imposing time boxes on your schedule, a la the Pomodoro Technique of 25 minute bursts of concentrated activity.
That’s at an individual level. To keep a software team focused, I’ve learned by counter example that the key is for the team to be highly focused on the smallest number of tasks you can get away with. Again, this is not easy to accomplish, but Agile methodologies have a lot to say on this.
From agile in general, comes the phrase “done done.” Meaning work on a task until the code works, is documented, tested, builds and deploys smoothly. This requires extra discipline on the part of the developer as making the code work is the fun part, whereas the rest just seems like extra effort. This also requires discipline on the part of the team lead to allow this “extra” work to be completed when the developer could go on to make something else work. The benefit is you don’t have to backtrack as much or have a stressful big bang at the end of a cycle to do all your integration, building, testing and documenting.
“Done done” talks about how to work on a task, which doesn’t help if you are overloaded with too many. Scrum addresses this problem through sprint planning, where tasks are given estimates and only X amount of work is allowed into a sprint. This should result in fewer tasks per developer, but not always. Again, discipline is the key as the scrum master and product owner have to engage in a give and take to keep scope manageable. If the product owner says you have to do everything this sprint, no matter what, you aren’t doing agile anymore, you’re just fire fighting.
Kanban or lean methodologies, deriving from production environments, focus on limiting the number of tasks going on at once. Every task goes through distinct stages and a new task cannot be added until another task exits the last stage. Progress is tracked visually on a kanban board. So there are not really sprints, so much as a continuous low flow of focused activity. I haven’t done kanban myself, but like scrum, it implies a give and take between the team and the other stakeholders to understand that doing less at once, does mean doing less for the project lifecycle.
So while Agile is becoming mainstream, and the concept of flow is almost passé at this point, I don’t get the sense that it is mainstream to follow through on their convergence of focusing more on fewer items at a time. This seems to be a general trend, where we all like the idea of being Agile, but think a light process = a free and easy process. After a rather unsuccessful attempt at Scrum with that concept in my mind, I can assure you it is not the case. Good process is difficult, but when did difficulty ever stop us before?
--Relevant Links--
The Pomodoro Technique and tomato timers:
http://www.pomodorotechnique.com/
If you like “Done done”, check out:
http://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo_buffalo
More on “done done”:
http://blog.phpdeveloper.org/?p=148
InfoQ’s stuff is pretty good, haven’t read this yet myself, but looks promising:
http://www.infoq.com/minibooks/kanban-scrum-minibook
Agile is now mainstream:
http://www.computerworld.in/articles/agile-software-development-now-mainstream