When I worked with Industrial Logic back in 2006-2007, I was introduced to a hidden practice of Agile called Core Hours.
Many teams I've worked with over the years have had an agreement that all team members would be together for a certain portion of the day, possibly even working in the same physical area. This is good, but the Core Hours concept to which I was introduced takes the practice one step further.
During Core Hours, team members work on their primary project only from, for example, 9 am to 3 pm, with an hour for lunch. Yes, that’s only five hours per day. It’s also realistically how much people work in terms of actual time when you account for administrative tasks, dealing with family matters, working outside their main project, and so forth. We already know that multitasking is a fool’s errand, so why not allow people to focus for a set period of time in order to maximize their productivity? When you achieve that level of focus, you are in a a state of Flow according to Mihály Csíkszentmihályi. This state is also known as being in the zone or on fire.
Of course, there are always occasions where a critical production problem may have to be dealt with immediately. That’s fine, but there needs to be a mechanism to shield the team from as many disruptions as possible. Does a problem really need to be dealt with right this minute? Can it wait an hour or two until outside of core hours? This is where education of help desk people can have a tremendous impact. They need to be able to properly triage issues as they arrive, and not just pass them along to the development or maintenance teams. This means that they must be involved in some way during the development of any given system - another reminder that the project community is always larger than we think.
Adhering to core hours takes a little discipline initially. Often, there is pressure from managers to "increase the hours a little", but again the concept is a reflection of the reality of all the work that people actually do during the day. Management also has a role in making it acceptable for team members to say, "I can look at that in a couple of hours" when an issue presents itself and is not critical. While the business may not initially like the change from an immediate response, the rewards for doing so are enormous.
This practice should be self-policing within the team. For example, if someone is surfing during Core Hours, other team members can and should question it. The practice should is also representative of the self-organization aspect of Agile - managers don't impose the boundaries and length of Core Hours, that's up to the team.
Outside of Core Hours, team members are literally free to do whatever they want (within reason!). If they want to chat on Twitter or lose their privacy on Facebook, then have at it! This is also the time that people from outside the team can ask questions. This is when a team member can look into a non-critical problem. This is when team members can attend other meetings as necessary. This is when people deal with e-mail and other administrivia related to their job.
I'll be speaking more about Core Hours as part of my Confessions of a Flow Junkie talk at Agile 2010 in Orlando in August.
Many teams I've worked with over the years have had an agreement that all team members would be together for a certain portion of the day, possibly even working in the same physical area. This is good, but the Core Hours concept to which I was introduced takes the practice one step further.
During Core Hours, team members work on their primary project only from, for example, 9 am to 3 pm, with an hour for lunch. Yes, that’s only five hours per day. It’s also realistically how much people work in terms of actual time when you account for administrative tasks, dealing with family matters, working outside their main project, and so forth. We already know that multitasking is a fool’s errand, so why not allow people to focus for a set period of time in order to maximize their productivity? When you achieve that level of focus, you are in a a state of Flow according to Mihály Csíkszentmihályi. This state is also known as being in the zone or on fire.
Of course, there are always occasions where a critical production problem may have to be dealt with immediately. That’s fine, but there needs to be a mechanism to shield the team from as many disruptions as possible. Does a problem really need to be dealt with right this minute? Can it wait an hour or two until outside of core hours? This is where education of help desk people can have a tremendous impact. They need to be able to properly triage issues as they arrive, and not just pass them along to the development or maintenance teams. This means that they must be involved in some way during the development of any given system - another reminder that the project community is always larger than we think.
Adhering to core hours takes a little discipline initially. Often, there is pressure from managers to "increase the hours a little", but again the concept is a reflection of the reality of all the work that people actually do during the day. Management also has a role in making it acceptable for team members to say, "I can look at that in a couple of hours" when an issue presents itself and is not critical. While the business may not initially like the change from an immediate response, the rewards for doing so are enormous.
This practice should be self-policing within the team. For example, if someone is surfing during Core Hours, other team members can and should question it. The practice should is also representative of the self-organization aspect of Agile - managers don't impose the boundaries and length of Core Hours, that's up to the team.
Outside of Core Hours, team members are literally free to do whatever they want (within reason!). If they want to chat on Twitter or lose their privacy on Facebook, then have at it! This is also the time that people from outside the team can ask questions. This is when a team member can look into a non-critical problem. This is when team members can attend other meetings as necessary. This is when people deal with e-mail and other administrivia related to their job.
I'll be speaking more about Core Hours as part of my Confessions of a Flow Junkie talk at Agile 2010 in Orlando in August.
Comments
Thanks for the comment!
Yes, that's the term we used and yes, I heard your definition as well.
Effectively we 'overloaded' the core hours 'method' to mean our definition, but you could use a term like quiet hours or team hours if you like.
I've enjoyed reading through your blog. I think you'd be a great addition to DZone's MVB program (see dzone.com/aboutmvb for more details).
If you'd be interested in joining up, just send me an email (james at dzone dot com) and we can discuss further.
Regards
James