The importance of time boxing in SCRUM

In an Agile environment, in my experience people get enthusiastic. I think that is one of the good things of an Agile way of working. In my work experience I've seen that starting with an Agile way of working, in this case SCRUM, especially developers get happy.

This has several reasons, but the main things is: they can do their work. And the method respects the dynamics of IT development.

But every methodology has some anchor points, which should guide you in the right direction. Important in SCRUM are these meetings:

• The daily SCRUM (stand up)
• The SCRUM of SCRUMs
• The Sprint Planning
• The Sprint Demo or Review
• The Retrospective

There are several variants of the SCRUM implementation in an organization. Probably the company will not start entirely Agile, but start a transition from Waterfall methodology onto pure Agile. Each company has to handle the touch points with other parts of the organization which still practices Waterfall methodology and how to translate that to the part that is Agile.

It is important to keep evaluating things and see how they can be improved. 

I think an important thing is to look at how much time you need for those meetings, and time box them properly. This takes care of the fact that meetings are going to take to much time, and that the meetings will be used for what they're are meant for. Sometimes people tend to use those meetings to talk about a lot of things, maybe also about how to improve the process.

A good moment to look at how you do things, would be the retrospective. But keep in mind that that meeting is time boxed too. Although I do think that during the process of making your organisation more Agile, you might need some more time for the retrospective. On a different level, this goes for the SCRUM of SCRUMS as well.

The positive effect of sticking to this, that is a) time boxing and b) stay to the purpose of the meetings -although it sounds a bit bureaucratic- is that you will have a clear view on how much time it takes to do those meetings and how much time there''s left to do the actual development during sprint. I still believe there's enough dynamics outside these time boxes to keep the process lean - and mean.