Wednesday, October 5, 2011

Time boxing

Time boxing is quite a simple concept. You specify an activity and duration and you’re done. The only basic rule is that you do not perform the activity longer than the specified duration.
In agile teams, time boxes are used everywhere. In Scrum, stand-up meetings are restricted to 15 minutes, sprints are time boxed, just as the planning meeting or the sprint review. When using planning poker, discussions are usually limited to a few minutes at a time and programming pairs switch roles or even programming partners after some predefined period. I’m sure you can add a few more examples yourself.
So what is the reasoning behind all of this? Why are time boxes useful?

One reason is the ability to focus. If you’re anything like me, you sometimes are easily distracted by an incoming email, a question from a colleague, the sudden urge to use the washroom or anything else that is not directly related to the task at hand. In many cases, the task is interrupted and we give in to those distractions. The reasons are obvious, just look at the example with the incoming email. We don’t want to forget reading this email, what if it’s important and urgent and needs immediate attention? Alternatively, not dealing with this email will keep it in the back of our minds, to remind ourselves that it still needs to be done, and that way continuously shifting our focus between the task at hand and the reminder that we need to deal with that potentially important email. Time boxing can help in this case. When you know when the current time box finishes, you know when you can deal with that email, so there is less anxiety to forget about it or deal with it in time. A quick note on your to-do-list or a sticky note on the wall is all that is required before you can go back to focussing on what you were working on. The Pomodoro Technique is a great example of how to use time boxes to improve your focus.

Time boxes also prevent us from going down a rabbithole once in a while. Have you ever been working on e.g. a design that you were never quite happy with? The design worked, supported all features we needed at the time, but something wasn’t quite right? How many times have you continued working on that design to, a couple of hours or even weeks later, end up with a design that was only slightly better or not better at all than the first one? How much value did you actually get from spending that extra time? Especially with activities like planning or designing, we tend to want to make things perfect before we continue with the next task. The problem is that we usually can’t make things perfect because we don’t have all the information we need. In fact, we usually can only get that information by making the abstract concrete: execute the plan or implement the design. Time boxes force us to accept the version of the design we come up with within the time available as the best version at the time. Not only does this allow us to implement the design faster, it also allows us to get feedback faster and to improve the design.

There are more benefits to time boxes, but I wanted to stick with the most concrete ones for now. Also, you might get benefits from using time boxing other people haven’t even thought about, so feel free to add some suggestions in the comments!

Wednesday, January 26, 2011

Do you collaborate or cooperate?

A group of individuals only becomes a high performing team when the potential of the whole is more than the sum of the potential of its individual parts, a lot more, actually. Putting people in the same room, however, is not enough for this to happen, an important lesson that was again confirmed at XPDays Benelux last November.

Inspired by an important part of the McCarthy Bootcamp, art creation, Christophe Thibaut – a friend and colleague from France – and I organized a collaborative art creation workshop. The result was impressive. While most of participants had not held a paintbrush since they last sat at a school desk, the collaborative piece exceeded any of the individual pieces in all possible ways. Clearly, pasting the individual pieces together would never have resulted in anything comparable to what the team came up with.

Making people work together on a project does not necessarily make them a team, in many cases they will only be people working together on a project. While they will cooperate with one another to get the work done, there most likely will be little collaboration. Collaboration requires openness and trust, willingness to give up ones own ideas and courage to provide a better idea when necessary, no matter whose idea the current one is. Until this is present, the 'team' capacity will never exceed that of all individuals together.

When people cooperate on a project, they tend to merely fill in the gaps, ensuring that their part is done, while not claiming accountability for the whole project. This is a lot easier to achieve, does not nearly generate as much conflict – especially on a new team – and requires less communication. But it sadly enough will barely result in something that exceeds what the individuals are capable of; it will barely reflect the team’s potential.

Detail from collaborative painting - acrylics on canvas, Toronto - January 22, 2011

At Thoughtcorp, we strongly believe in team potential. Now we are in the middle of moving to new offices, we thought it was a good idea to somehow practice what we preach and use that collective force. With a fair amount of colleagues and their families, we collaboratively created a couple of paintings that will soon decorate the walls of the Thoughtcorp offices, paintings that symbolize the company’s true DNA, both the people and the collaboration, something to be proud of! We collaborate.