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!

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.

The undocumented agile practice

Many books are written about practices that help teams produce better software. No doubt many of you immediately think about pair programming, test driven development, retrospectives, planning and estimating, continual integration and many many more. I'm sure that a lot more can be written about these and other agile practices that hasn't been written before, related techniques that are applicable in a specific context, ideas that live in the heads of practitioners and coaches. Lots already has been written though, if not in a book, then surely in a blog post or scattered around Twitter or a plethora of other social media. But let's face it, however much is written about a specific practice, there will always be a situation that has not been described, a context in which the handbook practice doesn't just work.

However much we can disagree on the reasons why Brazil lost the soccer world cup quarter finals against the Dutch, I'm sure most of you will agree that it takes more than 11 skilled individuals to beat a gelled team, especially since qualification ensures the teams in the world cup finals are all good, to say the least. All teams study and memorize systems to setup an attack and score. But the opponent can - and will - change the environment in which the system was taught. If the team is not aligned, understands the philosophy behind the system and acts as one, it will not be able to adapt and tactics might fall apart.

The same is true for agile teams. However good the individuals are, if a team doesn't work as one towards the same goal, it misses out on a lot of productivity, quality and fun! Strong committed teams are the foundation of every successful implementation, agile or otherwise. Yet, not an awful lot is written or told about how we form these teams. We somehow trust they are just there.

The diversity in context and specificity of the challenges teams face, requires a strong foundation, a powerful committed and aligned team to benefit fully from the techniques they were taught. That is why I believe that the practices mentioned above merely come second. Sure, they help teams to reduce bugs in the software. Sure, they slowly increase the collaboration and result in better team work. Sure, they increase visibility and therefor make it harder for process failures or inefficiencies to remain unnoticed. But for them to be really successful, for them to reach their full potential quicker, we better start communicating - and learning - how to build these teams.

Yet, most agile literature, most discussions are all about the methodologies, about what's best: Scrum or Kanban, about what's next, about the processes and tools of the agile community. Are we forgetting the very first statement of the Agile Manifesto: "People and interactions over processes and tools"?

Imagine

Imagine an island with no roads, no infrastructure for our western luxury, and people who do what they have been doing for a long time. Sure, they have challenges, but they get by. One of those challenges is transportation, going from one place to another to find food and visit neighbouring tribes. What would happen if we would give each and every one of them a car - of course including the manual, even translated in their own local language -, would sit by their side while they started the engine and drove the first 100 meters along the pebbly beach, and would leave?
I personally can think of only two situations... Hopefully they get stuck in the sand just a few kilometres further down the beach and abandon the car right there. Hopefully they shout out some “wookoolooloo” - lucky us we don’t understand which curse we’re awaiting - and forever call us the stupid species. But some might be fooled by the respect for alien intelligence, the shiny coating on the brand new car and the promises of a better life, if they only tried hard enough. Some might be tricked into trying harder and, if that doesn’t work, even harder. Dangerous! That’s what it would be! Bloody dangerous, literally! No doubt someone would try to pull the car out of the sand and be hit in the face by it. And someone else would sooner or later realize that cars and cliffs don’t make good companions. But let’s hope that they would run out of petrol soon and not cause too much damage.
If we know all this, if we know the inevitable future in this story, why would we ever give cars to those people without properly guiding them or making sure the right infrastructure is in place? Why would we ever risk endangering them, while we only want to improve their means of transportation? Why would we, when we would come back later, take their food away if they wouldn’t use the cars exactly the way we showed them?

Let cars be processes, let roads be tools and for the sake of simplicity, let people be people. Why is it that I have seen this happening so many times in large enterprises?

Quadrants version 1.0

Last Monday, the Quadrants of Effectiveness game was officially introduced at XPDays Benelux. About 25 participants were brave enough to sit around five carefully designed game boards, digest version 1.0 of the game rules and try to become the most effective tribe member in a 15,000 BC setting. In three rounds, they learned to apply the Eisenhower method, around which the game has been designed.

After overcoming a fairly steep learning curve during the first 10 minute round, the teams really got into the game and gradually started becoming more effective, using the built in benefits, decreasing quadrant I activities. I was pleasantly surprised to find out that 4 teams out of five finished at least one full game, reaching the last field on the game board. The feedback was mainly positive.

When we played the game again during the games night on Monday evening, the discussions and additional feedback led to an idea for version 2.0, on which I will focus during the next couple of weeks. In an attempt to transform the delegate action to something that is more alike delegating in real life - i.e. giving less important work to someone who it is more important to - the point system will be redesigned to take into account five different scales, one for each player, without adding significant complexity to the game rules. While in version 1.0, gold, water, food, etc. have the same value for everyone, in the next version, each type of point will be more valuable to one specific player.

Although it adds a bit of complexity and needs a carefully redistributed set of cards, it will definitely bring some extra benefits to the game and the session. No doubt the most important feature is that it encourages team play. Instead of delegating crap to another player, you will actually be able to delegate useful activities to someone else, being a lot more aligned with the real world. This adds a collaborative aspect to the game, which it is currently lacking. It will also add to the possible game plays, and keep it interesting, even after many games. Not sure yet if the game can have fewer cards because of the redesigned point system, but if so, it will definitely contribute to how it advances.

All in all, I'm very happy with how the game was received, and even more with the valuable feedback that I soon hope to incorporate in an even better version. So stay tuned for more news on the Quadrants of Effectiveness.

Growing Agile Locally

For over 9 years now, XP Toronto has been organizing regular meetings with sessions much like those found at the conferences I attended in Europe and North America. When I arrived here a little bit over a year ago, I was glad to find this community I immediately felt part of. Today, we are proud to announce Agile Tour Toronto, in the Hyatt on King in downtown Toronto on October 20th.

Whether you're a novice with regard to agile software development, a practitioner or you're managing teams, no doubt you will find the conference valuable. Visit the website to submit a session proposal, register for this low-cost event or just to find out more about it.

Leading at the edge

I like to believe that people don't choose the books they read, but that books choose their readers. Leading at the Edge by Dennis Perkins is one of those books that arrived in my hands in the most unusual way. Bernard and I were walking to the subway when he suddenly stopped to take a picture of some random thing happening on the street. My disinterest in whatever it was he tried to photograph drew my attention to three books, lying on the side walk, seemingly dropped out of a purse, no sign of the owner, not even in them. But most striking was that only a few moments earlier, Bernard and I had prepared a workshop on leadership, and then this book fell out of the sky, to land on our path, exactly there where something interesting enough would happen to make Bernard want to eternalize it.

So I took this book with me, convinced that it would prove to be of value for my work. Dennis Perkins extracts 10 leadership strategies from the extraordinary saga of Shackleton's Antarctic expedition, in which he succeeded in the unimaginable, to bring home alive each and everyone of his crew after they were left shipwrecked on the ice.

1. Vision and quick victories
   Never lose sight of the ultimate goal, and focus energy on short-term objectives.
2. Symbolism and personal example
   Set a personal example with visible, memorable symbols and behaviors.
3. Optimism and reality
   Instill optimism and self-confidence, but stay grounded in reality.
4. Stamina
   Take care of yourself: Maintain your stamina and let go of guilt.
5. The team message
   Reinforce the team message constantly: "We are one - we live or die together."
6. Core team values
   Minimize status differences and insist on courtesy and mutual respect.
7. Conflict
   Master conflict - deal with anger in small doses, engage dissidents, and enjoy needless power struggles.
8. Lighten up!
   Find something to celebrate and something to laugh about.
9. Risk
   Be willing to take the Big Risk.
10. Tenacious creativity
    Never give up - there's always another move.

None of them come as a surprise, and many are elaborated upon in other books and courses about personal excellence and leadership, but nevertheless this list is quite a good summary of necessary qualities of a powerful leader.