One of the most challenging areas to address when working in an agile environment is managing overhead.
Anyone who has actually read the
agile manifesto can tell you that agile favors collaboration over process because process is expensive and time consuming, and in the end, nowhere near as valuable as collaboration. This doesn't mean that you don't follow a process in your organization, this simply points out that when one of these two elements has to give, it must always be process.
My preference in scrum is one week iterations, especially when the requirements for a project are vague. The reason for this is because vague requirements equals blurry vision and blurry vision usually equals frequent changes in direction. I was told recently that the problem with iterations that are too short is that the overhead is too high; by the time you get out of all those planning meetings and demos and scrums, you don't have any time left to do actual work.
The jury is in on shorter iterations, and the verdict is widely accepted. The obvious solution is to reduce your overhead...starting with much shorter meetings with fewer attendees. After that, collaboration then becomes a much more intimate, and in my opinion, a more effective experience.
I can tell a team is forming when I frequently see one or more developers standing over the shoulder of another developer looking at his or her screen with two or more sets of index fingers pointing at something on the screen. I like to refer to these sessions as a huddle; it is where the 'how the heck are we going to do this?' get's done.
I like to try and separate the 'what' from the 'how' during the development process. The
what involves the whole team. Everybody on the team needs to know
what is being done so that they can adjust their actions to best accomplish the goal. The
how is best determined by the ones that are actually doing the work...so long as it fits in with the bigger
what that the team is working on. Planning meetings that include the whole team should focus on
what and stay away from
how. In most if not all cases, 80% of the team will not need to know
how things are done, and if they do, then they can hook up with the right team members off line to work this out.
Every time I feel like a meeting is dragging on, it is usually because we have gone too deep into the
how portion of the topic or worse, complete digression into useless background information.
Aim for:
Daily Scrum - 10 minutes max
Demo - 30 minutes
Sprint planning - 30 minutes
Retrospective - 30 minutes
The tough one here is obviously the 30 minute planning session, some have said that the sprint planning meeting is time-boxed to 4 hours, suit yourself. Keep in mind that this meeting is to basically create the sprint contract, not solve all the problems that the sprint poses. Problem solving meetings are best done in the huddle and only with the team members that are actually implementing the solution. You may have a need to periodically have a more in-depth planning meeting, I suggest every four sprints perhaps do this.
Keep in mind that this is a guide, take as much time as you need, but remember to stick to
what and stay away from
how.
http://agilesoftwaredevelopment.com/files/Simple_Sprint_Template.pdf
http://www.mountaingoatsoftware.com/scrum/sprint-planning-meeting
http://www.slideshare.net/vickidhiman/what-is-a-sprint-planning-meeting
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_c.png?x-id=39692e7b-6fb5-425f-9bdc-7418a40765a6)