Monday, March 14, 2011
IT worker with a mind like water
Introduction
In this entry, I'll be proselytizing about my interpretation of Getting Things Done (GTD) by David Allen, mindfulness and my implementation of Agile principles.
All of this culminates in a project portfolio, for a high-level view of the project status.
GTD principles and mindfulness
In order to work at maximum efficiency in bursts during the day, one must maintain a mind which flows like water. IT-workers, like physical athletes, chess champions etc. must keep their cool and maintain a certain level-headedness to perform at the top of their game. An IT-worker can get to this state by practicing mindfulness excercises during down-time and implement GTD in their personal and professional lives.
Why GTD? Because it is a means to cast away projects and tasks and entrust them to a externalized system, so there would be no need to retain excess information in the mind. So your mind is free to react to or observe the situation. I'll write up a blog entry to illustrate some points made by cognitive studies which support the beneficial effects of the GTD system.
Why mindfulness? Because it's the new fad. No, not really, meditation has been with us for a long time, but meditation is only a means to an end.
Mindfulness can potentially relieve (not a 100% cure) certain physical manifestations of mental blockages (I'm not a dualist in the cartesian tradition). Like all other things in life, you need a time and a place to do this and practice. So that's taking care of the body/mind. Regular physical conditioning/exercise is also a good idea. I won't cite the hundreds of research papers which confirm the relation between being mentally fit and physical exercise.
A common goal mindfulness and GTD is to empty the mind of all baggage and to get in a relaxed control of the task at hand, with minimum interference from other senses. Even if you think it's all weird esoteric unscientific crap, there's always a possibility of a positive placebo effect on your mind. So try it.
David Allen also stresses the importance of setting positive goals. This creates a positive feedback loop, when things actually don't turn out like the worst-case scenario you initially envisioned.
Teams and Agile and GTD
I could imagine that the other team members might not fully appreciate your fascination with GTD or mindfulness. So lead by example.
So, how does one share a mind-like-water epiphenomenal state with your colleagues? Grab adhesive pieces of paper (e.g. stick-it), get a large sheet of paper or a whiteboard, start writing down all of the project details as a group. Group together similar tasks / details. Find a comfortable granularity i.e. level of description for the tasks for the whole team. Not too abstract and not too detailed. Unload your team's collective mind. This is a free-flowing brainstorm / brain unload state. The unloading state can be done over a week or in 5 minutes. Depending on the size of the project. I personally did a drive-by braindump with my team once.
Get together with your team. Your role is to provide the constraints of the project. Per task, sort the precedence of certain tasks depending on the priority of the task. This is a filtering state. Make a plan in iterations for the coming x weeks. Every iteration should be no longer than 2 weeks. For every task, subproject, try to make a informed guess how long that task would take to accomplish. Also try to define the priority of that feature with the client and your teammates. It's important to make a clear seperation between the "unloading" state and the filtering / analytical / censor state.
If management insists on disrupting you or team members to do multi-project multi-tasking, use GTD on a lower-level for each disruptable team member. Use your project portfolio and project backlog to defend your team member, against unwelcome intrusions like these, for example make your point clear to "intruders" that your project has no time to spare etc. In any case a project portfolio is a common base you can use to negotiate, within the team or with upper-management.
Another method to maintain a team's commitment during a barrage of incidental crap, use a kanban to keep the focus on the project at hand. Also, use commitment and consistency. Let the person(s) who is or are going to be responsible for the task write down her name on the piece of paper.
For software developers you might want to describe the following states on the kanban (per feature) for an iteration:
Depending on the size of the team, do standups. Do project backlogs, so you can make a project portfolio, do a velocity charts. But in any case never plan alone, always use the data provided by the whole team.
My software idea
I envision a drag and drop interface to create an online kanban system, where states can be defined. Using xmpp and bosh to give project members updates in changes within the kanban system. Integration with XMPP-based chat systems. All of this integrated with a calendar (gcalendar?) and a GTD based system where tasks can be delegated to people and be inserted to the wait list or the calendar. Ad hoc commands are in the protocol to deliver the data payload.
Conclusion
There is a common thread between agile and GTD. If you include team members and let them actively participate, you can leverage the group's wisdom to improve commitment to the project and also improve the way it is going to be developed. This is a way for your team to get into the zone.
In this entry, I'll be proselytizing about my interpretation of Getting Things Done (GTD) by David Allen, mindfulness and my implementation of Agile principles.
All of this culminates in a project portfolio, for a high-level view of the project status.
 |
| Quick reference to GTD |
GTD principles and mindfulness
In order to work at maximum efficiency in bursts during the day, one must maintain a mind which flows like water. IT-workers, like physical athletes, chess champions etc. must keep their cool and maintain a certain level-headedness to perform at the top of their game. An IT-worker can get to this state by practicing mindfulness excercises during down-time and implement GTD in their personal and professional lives.
Why GTD? Because it is a means to cast away projects and tasks and entrust them to a externalized system, so there would be no need to retain excess information in the mind. So your mind is free to react to or observe the situation. I'll write up a blog entry to illustrate some points made by cognitive studies which support the beneficial effects of the GTD system.
Why mindfulness? Because it's the new fad. No, not really, meditation has been with us for a long time, but meditation is only a means to an end.
Mindfulness can potentially relieve (not a 100% cure) certain physical manifestations of mental blockages (I'm not a dualist in the cartesian tradition). Like all other things in life, you need a time and a place to do this and practice. So that's taking care of the body/mind. Regular physical conditioning/exercise is also a good idea. I won't cite the hundreds of research papers which confirm the relation between being mentally fit and physical exercise.
 |
| Meditating Lotus |
A common goal mindfulness and GTD is to empty the mind of all baggage and to get in a relaxed control of the task at hand, with minimum interference from other senses. Even if you think it's all weird esoteric unscientific crap, there's always a possibility of a positive placebo effect on your mind. So try it.
David Allen also stresses the importance of setting positive goals. This creates a positive feedback loop, when things actually don't turn out like the worst-case scenario you initially envisioned.
Teams and Agile and GTD
I could imagine that the other team members might not fully appreciate your fascination with GTD or mindfulness. So lead by example.
So, how does one share a mind-like-water epiphenomenal state with your colleagues? Grab adhesive pieces of paper (e.g. stick-it), get a large sheet of paper or a whiteboard, start writing down all of the project details as a group. Group together similar tasks / details. Find a comfortable granularity i.e. level of description for the tasks for the whole team. Not too abstract and not too detailed. Unload your team's collective mind. This is a free-flowing brainstorm / brain unload state. The unloading state can be done over a week or in 5 minutes. Depending on the size of the project. I personally did a drive-by braindump with my team once.
 |
| Braindump / fun with stick-its |
 |
| The whiteboard |
Get together with your team. Your role is to provide the constraints of the project. Per task, sort the precedence of certain tasks depending on the priority of the task. This is a filtering state. Make a plan in iterations for the coming x weeks. Every iteration should be no longer than 2 weeks. For every task, subproject, try to make a informed guess how long that task would take to accomplish. Also try to define the priority of that feature with the client and your teammates. It's important to make a clear seperation between the "unloading" state and the filtering / analytical / censor state.
If management insists on disrupting you or team members to do multi-project multi-tasking, use GTD on a lower-level for each disruptable team member. Use your project portfolio and project backlog to defend your team member, against unwelcome intrusions like these, for example make your point clear to "intruders" that your project has no time to spare etc. In any case a project portfolio is a common base you can use to negotiate, within the team or with upper-management.
 |
| Spreadsheet based project portfolio, left: monthly plan, right: weekly plan. |
Another method to maintain a team's commitment during a barrage of incidental crap, use a kanban to keep the focus on the project at hand. Also, use commitment and consistency. Let the person(s) who is or are going to be responsible for the task write down her name on the piece of paper.
 |
| Simple KanBan: wait, active, finished. |
For software developers you might want to describe the following states on the kanban (per feature) for an iteration:
- Develop
- Test
- Refactor
- Merge
- Commit to version control
- Integration Test
- Deploy
Depending on the size of the team, do standups. Do project backlogs, so you can make a project portfolio, do a velocity charts. But in any case never plan alone, always use the data provided by the whole team.
My software idea
I envision a drag and drop interface to create an online kanban system, where states can be defined. Using xmpp and bosh to give project members updates in changes within the kanban system. Integration with XMPP-based chat systems. All of this integrated with a calendar (gcalendar?) and a GTD based system where tasks can be delegated to people and be inserted to the wait list or the calendar. Ad hoc commands are in the protocol to deliver the data payload.
Conclusion
There is a common thread between agile and GTD. If you include team members and let them actively participate, you can leverage the group's wisdom to improve commitment to the project and also improve the way it is going to be developed. This is a way for your team to get into the zone.
Subscribe to:
Posts (Atom)