 |
« | Week of May 16 | < | Individual Entries | > | Week of Jun 20 | » |  |
 |
 |
Scheduling Tasks Collaboratively
processes & methodologies
May 29, 2004, 09:16 PM
Our capstone project has entered its second phase, where we're doing iterative testing and redesign work. The biggest change is that we're all working on the project full-time now, rather than around 12 hours a week as one class among many. The best part about this is that Bob got each project team it's own shared office space (ours has a window! Yay!). This constant proximity has proven extremely helpful for our team so far, and has allowed us to try out some collaboration techniques we weren't able to do before.
One problem we suffered from last semester was group task management. People would commit to tasks but wouldn't always follow through with them, not out of laziness but just because they'd fall by the wayside and nobody was really keeping track. People weren't always terribly aware of what everyone else was doing (including me, the project manager). This cost us a lot of time in meetings coordinating with each other. I kept a detailed schedule for a while, but gave up since it kept falling out of date and nobody ever really looked at it anyway.
Once we got our summer space, I had an idea for how to improve matters. I bought a roll of butcher's paper, some Post-It notes, and markers, drafted a much larger version of my linear schedule format, and posted it up on the wall. Here's some photos of the entire schedule and a close-up of the first couple of weeks:
Whenever someone takes on a task, they write it on a Post-It and stick it up on the date they think they'll complete it by. Project milestones and scheduled events such as client meetings and user tests are also put up on the board by the person who was in charge of scheduling them. During our morning check-in meeting, we go through the tasks that were scheduled for completion that day, check off those that actually were completed, and move those that weren't to a new deadline.
We use different colored Post-Its to represent milestones, events, and tasks assigned to different people. Some immutable events (such as team member absences) are written directly on the board itself.
This approach to group schedule management has several advantages:
- Everyone can always see the schedule. Because it's up on the wall staring at the entire team, anyone can just glance up and see both what tasks they've currently committed to as well as what tasks everyone else is working on. This is a huge benefit when many of your tasks depend on deliverables other teammates are currently working on (an extremely common scenario in interactive design projects).
- Team members must commit to deadlines. Because there is no space on the board that isn't situated in time, there are no "floating" tasks that someone is working on but hasn't committed to a deadline or deliverable. As soon as a task is defined and assigned, the assignee must make at least a rough estimate of when he or she expects to complete it.
- Schedule slips and dropped tasks become explicit decisions. Post-Its can be moved or removed, but the team member responsible for the task must consciously make that decision, probably in front of his or her teammates. Though the mobility of Post-Its might encourage overly flexible deadlines, I believe this is necessary for the schedule to stay in sync with reality (and there are other mechanisms for preventing schedule slip, such as the next one).
- The amount of time remaining before deadlines is immediately visually obvious. The project milestones and completion date (where the timeline itself ends) are plainly visible for all to see. Because days all take up the same amount of space, team members can quickly see how much time is left before the next approaching deadline and experience the appropriate emotional response.
- The team can get a rough sense of who is overcomitted and who has some time to spare. This is possibly the least useful feature, but because the tasks are all visible, the team can get a rough idea of everyone's level of comittment, past and present. Simply counting Post-Its won't work, of course, since some tasks may eat up only a little bit of time now and then whereas others may suck up the entire day. But the board at least provides a starting point for a conversation.
- Everyone owns the schedule. If only one person is charged with maintaining the schedule (usually this is the project manager's responsibility), then the rest of the team is encouraged to concern themselves only with their immediate tasks and not take a big picture view of the project. Tracking everyone's individual tasks can get quite tedious for the project manager while also giving everyone else the impression that he's micromanaging. Having the schedule accessible for viewing and updating by everyone encourages collaborative ownership of the long-term direction of the project (provided the board is truly owned by the team and not just a tool for the project manager to keep an eye on everyone). A schedule maintainer is still needed, of course, but now he or she must simply be there to make sure the board stays up-to-date and to direct the team's attention to long-term trends and future milestones.
The core benefit, of course, is much the same as that provided by affinity diagrams, that is it takes abstract concepts (time and tasks) and makes them visible and physical.
There are some drawbacks, as well as situations in which this approach might not work so well:
- The board requires a fair amount of permanent wall space. Teams that don't have dedicated project space (ideally shared by all members in a radical colocation style setup) can't use this approach. Even teams that do might have trouble finding enough space, especially if the board is introduced into an existing project room. Fortunately, we were setting up our space at the time that I had the idea, so this wasn't an issue, but if the team already has posters or whiteboards or whatever covering the wall, there might be pushback.
- The board may not scale to long-running projects. In the same vein as the previous point, long-running projects may require absurdly large boards. The one you see pictured above is for 12 weeks, and it wraps around to two walls. Projects that last a year or more can't put their whole timeline up, but perhaps it would be sufficient to stick up only the amount of time between project milestones, or enough for a three-month span. Longer-term planning can be done through other means; most teams are probably more concerned with what they're doing in the next three or four weeks than in the next four to six months anyway. However, this compromise might lose some of the long-term view of approaching deadlines that our board enjoys.
- The board may not scale to large numbers of people. We have five people in our team. If we had many more, the board might get cluttered with Post-Its and it might get harder to read and manage. Then again, if you have a team with many more people things will get unwieldy no matter what you do. But I could reasonably see a team with around 12 people wanting to use this, and that may be more than it can support.
Maybe I'll write a paper on this topic. I'll call it "A Cost-Effective Large Display for Collaborative Scheduling and Ambient Task Awareness using a Tangible Interface". I think it could totally get into CHI.
Email Rob:
Rob Log Episode IV: A New Server
announcements
May 23, 2004, 04:32 PM
In the interest of improving my uptime and throughput, I've moved Roblog and everything else on the loki.lokislabs.org subdomain to Dreamhost, meaning I'm no longer entirely rolling my own webhosting. The changes should be transparent. There were some issues with getting everything set up (Dreamhost doesn't seem to let you set up an existing site and thoroughly test it on their server before throwing the DNS switch to make it live...) but it should be running smoothly again now. If you find any leftover glitches, please email me about them and I'll fix them ASAP.
The Labs is still up and running and will remain so for the foreseeable future, but at least now if I need to take it down for a bit, it won't take my website with it. Here's to hoping the improvement in service makes up for the (small) extra cost and the (marginal, so far) loss of control.
Posted by Rob on May 24, 2004 at 01:53 PM
Incidentally, the comment subscriptions (the feature that emails you when someone posts a comment to a post you have commented on) were all lost in the move, since they are handled by a plugin and not Movable Type itself. I figured this wasn't a big deal. If anyone really really wants to be subscribed to an old discussion, email me and I can add you.
Email Rob:
Posted by krissy on June 07, 2004 at 04:53 AM
i like it!! =)