Silent Hour - Experiences

Week ago I blogged about our new experiment - Silent Hour.

Our team has just one room, people sitting next to each other and even if you are discussing with only one team member, others are also easily distracted. Headphones do help a little, but we decided to try something different. Between 12:00 to 13:00 we close doors of our team rooms to avoid all unnecessary disturbances both from internal and external origins.

For customer contacts we fortunately have first tier customer support which can handle easy tasks independently. Complicated tasks and problems are forwarded to developers, but during Silent Hour we encourage them to try little bit harder before doing that. Or they can take request for callback if the issue is not too urgent. But rules are not absolute; if they really needed help they can ask advice from developers anytime. Common sense rules.

On the other hand managers and salespeople tend to rush to ask questions from developers at any time. And just fiver minutes later they come back to ask follow-up question. Face to face communication is good thing -no doubt about that- but just when you are getting back to flow for programming, there is already new distraction waiting... With Silent Hour closed-door-policy should encourage people to at least think do they need the answer right away or could they wait 30 minutes.

This have been working quite well. After little over week of experiment I did questionnaire to all stakeholders including developers, customer support, managers and salespeople. Almost all answered. Results were quite encouraging. Nobody thought that Silent Hour-policy had made his own work more difficult. Even that sometimes people did not remember the policy and have to turn away when they noticed closed door, they did not feel that additional waiting time for their communication needs did do any harm.  Everybody understood the need for developers to have some time when they can just concentrate task at the hand. And naturally developers were quite thrilled for the uninterrupted time. Sometimes we got visitors even during silent period, but always with good reason. 

Conclusion was that we end this as experiment and make it as permanent policy.

Silent Hour

Agile puts great value for interactions and communications but sometimes too much communication can turn to waste. Interactions should not be part of WIP and should not have their own sticky notes on board.

The Agile principles embrace

Co-Operation

Business people and developers must work together daily throughout the project.

Communication

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 

But also

Sustainable Development

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Simplicity

Simplicity--the art of maximizing the amount of work not done--is essential.

In order to put more emphasis and improve the latter two we now are in progress of testing the new practice we call Silent Hour. Between 12:00 to 13:00 we close doors of our team rooms to avoid all unnecessary disturbances. We urge everybody to think at least twice before distracting developers during Silent Hour. Average waiting time is 30 minutes anyway, so it should not be any problem. Also developers avoid any unnecessary chatter. Some developers are also going to test the Pomodoro Technique® since there is just enough time for two pomodoros.


This is just ongoing testing and rules will surely evolve, but it has received quite good acceptance with developers and also with other stakeholders.

Edit: There is also followup post with more information and experiences: http://ikettu.blogspot.com/2011/11/silent-hour-experiences.html

Performance = potential - interference (P=p-i). Tim Gallwey 

Pro waterfall?

<humor>

The customer knows what he wants; developers know how to build it and nothing will change along the way? If that’s your context you should take look on waterfall manifesto or attend some conferences.
</humor>

Otherwise agile manifesto is way to go.

But is there actually anything good on waterfall or v-model?

It seems that it easier to sell and buy projects with predefined focus and clear ending than “we just do what you want”-kind of deal. Are we bold enough to share the risk with customer and can customer participate enough for "Money for Nothing, Change For Free".

Or do auditors like so much the verification and validation that there's no way to use agile methods on certified quality management system?

Most of time we have to do some compromise between traditional and agile methods, but I think that's actually good thing. Isn't it actually more agile to use even waterfall if customer really wants that than selfishly trying to push scrum? 

Introduction

Several years I have been consuming open source projects and reading published text from other people. For some time I have been thinking how to do my own contribution. So I finally decided to start my own blog and try to give something back to community.

I am CTO at FastROI which is small software company based on Joensuu, Finland. We are making our own products which we are mostly selling by SaaS model. We are learning and implementing Lean and Kanban practices. Same time our quality management system is being prepared for ISO 9001:2008 compatibility. We are trying to sell customizations as agile contracts to quite “old-school” customers.

Definitely there is a lot learn on these areas and I hope I can share as much I can during the process.