What to use for an Agile sprint/iteration calendar?

Question

So where I work we approach our projects using Scrum. Recently we have all been bumping heads and interrupting each others work too frequently because of competing role interests (developers, QA, product owners, scrum masters, business analysts...)

In order to fix this we want to implement a sprint "cadence" where blocks of time are designated to do specific types of work.

Example:

Monday

6am - 9am [Development] (Protected Time)
9am - 10am [Standup / Story Updates]
10am - 12pm [Development]
1pm - 2pm [New Story Research / Requirements Gathering]
2pm - 3pm [Future Technology Research]
3pm - 5pm [Development] (Protected Time)

What I would like to know is if anybody else is doing this, and if so what tools are you using to make this highly visible and available to the rest of the team?

I know I could use a shared calendar in Outlook, but the idea is to have every hour during the day go towards something. Using outlook events for this is pretty cumbersome, doesn't allow for flexibiltiy, and wasn't designed to be implemented for "uneven" time periods (tuesday week 1, thursday week 2, etc...)

Answer 1

Hav you considered specializing the team a bit more ? I'm especially thinking about the "New Story Research / Requirements Gathering" bit. I'm not really sure you're getting the proper focus for your development team ? If you're concerned about involving everyone you might just rotate people for each sprint instead ?

I know I'm not answering your question, but I'm not sure you really want to solve this problem ;)

Answer 2

This is going to be very subjective, and you will find a lot of people have tried, failed, and use different things. I guess you will have to cherry pick from the answers the ideas you think will fit where you are. So here are a few things that worked pretty well for us (also using scrum):

1. Headphonees/earphones on means you're busy and would prefer an email that you can pick up later.

2. I made a flag for certain people to have on their desks to indicate critical work being done. You have to police this to prevent it getting abused.

3. If you use laptops and have wireless in house, work somewhere people can't find you or have to go to lengths to get to you.

4. Technology like Outlook is not a good idea IMHO. Developers trying to focus should have Outlook closed (as well as any ICQ).

Hope this helps, good luck.

Answer 3

The main problems I see with the approach you are pursuing is that it still leads to a very fragemented work day, where people will have trouble getting into flow, and that it's unlikely that the fixed distribution of time is far from likely to be optimal for what you actually need.

What's additionally troubling me is the mentioning of "competing role interests" - this sounds like every role has a different goal for the sprint. That shouldn't be true for a Scrum - or actually any - team. All the team members should be commited to the same, prioritized team goals, and be held collaboratively accountable for them. So, when someone needs help to continue his task, he should be helped by someone with a lower priority task, or instead help someone with a higher priority task. And ideally, all those tasks would lead to the fullfilment of the same single goal. See http://leanagile.blogspot.com/2007/04/one-story-flow.html

Having said that, people from the team still might need to contribute to activities outside the team goal(s) - such as support to sales, contributions to company-wide activities etc. (note that I didn't include QA, which really should happen inside the team). We have found that for this, it actually pays to have a declared "focus time", where the team isn't to be disturbed from the outside and where no meetings are held. You don't need any elaborate tool for this, though - a simple statement like "we aren't available 10am-1pm every day" would suffice.

Answer 4

In my opinion, your schedule is in contrast with "collaboration as way to get the result". We used to had similar schedules, but people started to feel it very disruptive. Work has been to much fragmented.

We are using similar schedule, but it is based not on hour basis, but days instead. For example Friday is [Future technology day] or [Do your research] or [Internal workshop] day.

Another principle, we are using, is to let the people choose stories and to group to small teams (2-3 people, developers and testers) if it is good.

It is theirs goal to implement the story as whole (architecture, design, implementation, test). Some guys are "area principals" - technology or business area. So no big meetings for whole team on regular basis. Other team members will see the progress and can ask about details during the standup meeting or eye to eye on diferent time (lunch).