How to make good teams great, part one

As we are implementing new development processes in the department I work for teams are going through a lot of changes. Attending Sven Peters’ (@svenpet) talk on 7 things: how to make good teams great at Jfokus was an obvious decision and I’m glad I went. It was really nice to hear that some of the actions we are taking right now have proven to be successful and appreciated by teams in other companies.

I’m not going to write about the 7 things at once but will break them down in two posts. Let’s start with It’s flow time and Report robot.

It’s flow time

Ever heard of context switching? It is probably one of the biggest problem of so called knowledge workers who - according to various studies - waste 20% to 30% of their time switching from one context to another. And that problem is even more important in an open space where one can easily be disturbed: a colleague or a manager stopping by your desk for a quick question (notice the quick there: sounds familiar?), someone just walking by, …

Unfortunately there is no quick question or task and you will always waste those 20% to 30% of your time (that’s almost 3 hours of a normal day at the office) switching context.

Do Not Disturb!

In such work environments it is therefore all about finding the right balance between productivity and collaboration. Collaboration is the idea behind open offices but productivity is not and you need to build virtual fences in order to secure high productivity periods - as if you were working in a closed office - over the day or week.

Andy Hunt dedicates a whole chapter on the subject - Manage Focus - in Pragmatic Thinking and Learning: Refactor Your Wetware and suggests team to establish rules of engagement to manage interruptions.

Report robot

Constant feedback is one of the key factor of successful agile teams and there are a great deal of tools that can help feeding the team with relevant information.

In your day to day activities you probably use a wiki to share documentation and knowledge. You probably (and you better do) use a bug tracking system to manage defects in the code your write. You also might use a build system to automate builds and deployments.

When you think about it the list is much longer than that and it is almost impossible for a single person to keep track of all the data the different tools provide. If your company (read manager) understands the issue and is willing to invest some money in it maybe it’s time to build information radiators!

Information radiators are central locations (a web page, a flat screen TV close to the team) where the feedback from all those tools can be presented in a concise and visual manner: charts, green and red lights, numbers, … for anything that adds value to the team productivity and spirit.