Having been a part of a number of SCRUM teams, and a SCRUM master many times, I'm surprised that it's taken me so long to realize that asking "Are you blocked?" isn't really the right question. Everyone once in a while, someone will answer "Yes!", but more often than not, everyone says "No. Not blocked.".
That would be fantastic, if it were only true.
Of course, people who claim not to be blocked aren't lying... they're almost always able to make some kind of progress: however painful and slow that may be. Therefore, they aren't blocked, and will always say "no" when asked the question. The problem, though, is that you really don't want them to struggle along with whatever difficult/laborious/ineffective behavior they're engaging in. And, unless it happens to come up in the other two SCRUM questions ("What did you do in the last 24 hours?" and "What will you do in the next 24 hours?"), you simply won't find out until several days have passed with the person making poor progress and wasting a lot of time.
So, what to do?
Perhaps a better question to ask is "How's it going?" When faced with a sympathetic ear, most people are happy to tell you all about the things they're struggling with, and what difficulties they're facing. So, if they're blocked, it will be very likely to come up. However, if they're merely struggling, that will come up too, and that's what you really wanted to know.
August 21, 2010
April 12, 2010
Makers vs. Managers
[[ It's been a while since I posted, and to a small extent that's because I've changed jobs. Now I'm a Development Lead (a manager of software developers), and so the things I tend to spend a lot of time thinking about have changed. This topic is a reflection of that. ]]
I recently read an article about the sharp divide between how different people use their time. It divided people into two general camps: the "maker" and the "manager". People who fall into the former camp have work which requires large blocks of time which they can dedicate to a single concentrated task. Engineers, authors, designers and the like all fall into this camp. On the other hand, people in the "manager" group have work which requires them to constantly shift their focus from one task to another fairly quickly. Program managers are the quintessential profession here in the software industry, but supervisors in nearly any field, people managers, and executives all of this pattern of work.
Unfortunately, makers and managers often need to work closely together, and don't really respect (or possibly even understand) the differences in each other's mode of operation. Managers will disrupt makers by scheduling meetings at whatever time works best to get the meeting scheduled soonest, without regard for leaving two funny 30min chunks on either side of the meeting (which does a lot to kill the maker's productivity). On the other hand, makers will frequently drive managers right up the wall by failing to respond to a requests in a timely manner, or getting buried in one task and letting the schedule on another one slip.
There are two specific practices I've used which work well to smooth things out between these two groups: "Daily/Weekly War Team Meetings" and "Maker Time".
A war team meeting is a routine standing meeting which the decision-makers of the team are required to attend, and which everyone is invited to attend. The agenda for the meeting is decided in the first few minutes of the meeting. Everyone present is welcome to add an item to the agenda, and request a certain amount of time for it (e.g., 5 minutes for a fast time, and up to 15 minutes for a long one). The facilitator will put it up on the whiteboard. Once the agenda is set (i.e., no one has any further items to suggest, or the duration of the meeting is spoken for), the facilitator starts walking through the items on the list. His job is primarily to keep the discussion on topic, capture items for future discussion, and keep things running on schedule. If an issue cannot be resolved within the allotted time, it can either be settled privately between a few individuals who become empowered to settle the issue, or it can be brought back to the next meeting. Once all of the items which interest a person have been discussed, that person is welcome to leave.
This technique works fantastically well when coming up to a release, but is generally a good practice at any time (the closer to release, the more often you generally want to have the meeting). The first positive effect is that it gives everyone on the team a forum and a voice on how decisions are made. They don't get to make the decision, but they can be part of the process. That goes a long way toward improving morale on the team (especially one with really passionate, dedicated people). The second effect is that it tends to consolidate hours of meetings into a much shorter span. The vast majority of meetings take much longer than is required because they don't have a really tight agenda, and because there is no strict timekeeper to keep things on track. The third effect, and most important to makers, is that it makes the time of meetings *PREDICTABLE* and *CONSOLIDATED*. This technique virtually eliminates the need for most other meetings, and therefore gets rid of those odd little chunks of time which are hard for makers to use effectively. Finally, and this is most important to managers, it creates a forum in which blocking issues can be resolved *QUICKLY* and *OFTEN*. If your team does this daily, then the majority of issues which require a meeting can wait until the already-scheduled meeting the next day.
The second technique I've used for this kind of issue is "Maker Time". This is where makers are invited to block their calendars, reject meeting invites, close their doors, put on headphones or whatever else they need to do to put the world on hold for a few contiguous hours each day. On one team I ran, we decided that we would prohibit meetings after 14:00. In other situations, the team would pick a "meeting-free" day of the week (i.e., no meetings at all on Thursdays every week). Whichever way, the leadership of the group made it clear to makers and managers alike that this time was to be set aside for makers to get their jobs done, and no one was to interrupt them (except for clearly defined emergencies). This allows makers to have their dedicated time without completely blocking out managers for long periods of time.
What other examples of makers and managers working together have you seen? What other ways have you dealt with the maker/manager divide?
I recently read an article about the sharp divide between how different people use their time. It divided people into two general camps: the "maker" and the "manager". People who fall into the former camp have work which requires large blocks of time which they can dedicate to a single concentrated task. Engineers, authors, designers and the like all fall into this camp. On the other hand, people in the "manager" group have work which requires them to constantly shift their focus from one task to another fairly quickly. Program managers are the quintessential profession here in the software industry, but supervisors in nearly any field, people managers, and executives all of this pattern of work.
Unfortunately, makers and managers often need to work closely together, and don't really respect (or possibly even understand) the differences in each other's mode of operation. Managers will disrupt makers by scheduling meetings at whatever time works best to get the meeting scheduled soonest, without regard for leaving two funny 30min chunks on either side of the meeting (which does a lot to kill the maker's productivity). On the other hand, makers will frequently drive managers right up the wall by failing to respond to a requests in a timely manner, or getting buried in one task and letting the schedule on another one slip.
There are two specific practices I've used which work well to smooth things out between these two groups: "Daily/Weekly War Team Meetings" and "Maker Time".
A war team meeting is a routine standing meeting which the decision-makers of the team are required to attend, and which everyone is invited to attend. The agenda for the meeting is decided in the first few minutes of the meeting. Everyone present is welcome to add an item to the agenda, and request a certain amount of time for it (e.g., 5 minutes for a fast time, and up to 15 minutes for a long one). The facilitator will put it up on the whiteboard. Once the agenda is set (i.e., no one has any further items to suggest, or the duration of the meeting is spoken for), the facilitator starts walking through the items on the list. His job is primarily to keep the discussion on topic, capture items for future discussion, and keep things running on schedule. If an issue cannot be resolved within the allotted time, it can either be settled privately between a few individuals who become empowered to settle the issue, or it can be brought back to the next meeting. Once all of the items which interest a person have been discussed, that person is welcome to leave.
This technique works fantastically well when coming up to a release, but is generally a good practice at any time (the closer to release, the more often you generally want to have the meeting). The first positive effect is that it gives everyone on the team a forum and a voice on how decisions are made. They don't get to make the decision, but they can be part of the process. That goes a long way toward improving morale on the team (especially one with really passionate, dedicated people). The second effect is that it tends to consolidate hours of meetings into a much shorter span. The vast majority of meetings take much longer than is required because they don't have a really tight agenda, and because there is no strict timekeeper to keep things on track. The third effect, and most important to makers, is that it makes the time of meetings *PREDICTABLE* and *CONSOLIDATED*. This technique virtually eliminates the need for most other meetings, and therefore gets rid of those odd little chunks of time which are hard for makers to use effectively. Finally, and this is most important to managers, it creates a forum in which blocking issues can be resolved *QUICKLY* and *OFTEN*. If your team does this daily, then the majority of issues which require a meeting can wait until the already-scheduled meeting the next day.
The second technique I've used for this kind of issue is "Maker Time". This is where makers are invited to block their calendars, reject meeting invites, close their doors, put on headphones or whatever else they need to do to put the world on hold for a few contiguous hours each day. On one team I ran, we decided that we would prohibit meetings after 14:00. In other situations, the team would pick a "meeting-free" day of the week (i.e., no meetings at all on Thursdays every week). Whichever way, the leadership of the group made it clear to makers and managers alike that this time was to be set aside for makers to get their jobs done, and no one was to interrupt them (except for clearly defined emergencies). This allows makers to have their dedicated time without completely blocking out managers for long periods of time.
What other examples of makers and managers working together have you seen? What other ways have you dealt with the maker/manager divide?
Subscribe to:
Posts (Atom)
