Timeboxing needs some getting used to - and is a huge driver for innovation

One important concept of agile work practices is the notion of timeboxing. It means that the work that needs to get done - ideally a finished product or product increment that can be delivered to a client - needs to be finished within a specific time frame using a limited set of resources. Usually, those timeboxes are quite short. In many cases they only last days, sometimes two weeks, and in extreme cases even hours.

There are a number of benefits from this practice, and many of them have something to do with innovation.

First of all, timeboxing obviously creates a result faster. The team working on the product is under a positive pressure to create results and due to that pressure gets into better flow. Needless to say that this only works when also other agile principles are respected, such as a clear briefing, open communication channels, self-organisation in teams and others. If those elements are in place, the time pressure creates a positive flow.

Secondly, timeboxing helps get feedback from the client faster. If the team spends a few days on the creation of a product which is then shown to the customer, the product can then be adapted to the feedback to the client in following work cycles. This leads, over several cycles, to a better outcome that will be accepted better by the market. And this is, ultimately, better innovation.

Thirdly, and this is one of the most important benefits from my perspective, the team needs to take difficult decisions due to the limited time and resources and therefore need to have high quality conversations to reach conclusions. The trade-offs that are made should always be made in respect of customer value. What will truly add value to the customer, and what are merely sidetracks that the team can easily neglect?  This leads to high customer focus and, again, to better innovation.

And the last point is quite cool, really: Managing projects like that avoids tons of overtime, saves money and keeps everyone on the team in a nice work-life-balance.

Working with highly productive teams who are comfortable with the idea of timeboxing is a pleasure. But it is the teams that are new to the thought of timeboxing and feel uncomfortable and bewildered by it who really are the most interesting to me.

What usually happens in teams that are new to the process or where a majority is new is that the thought of timeboxing is so new that they filter it out and just ignore it, accumulate overtime and complain a lot about the limited time they have. When at the end of the work cycle the agreement they had committed to (finish the work in the agreed amount of time, with the allocated resources) is reviewed there can be quite long faces when this commitment is addressed. The nice thing is: It mostly only happens once, teams learn to deal with timeboxes very fast in the following cycles, sometimes they have to learn it "the hard way".

We are working with ad-hoc teams a lot, so they have to get used to the principles and the way of working in quite a short amount of time. We try to balance that by always adding people to the team who are more experienced in the practice and can help the team in the capacity of facilitator. Still, new teams have a hard time accepting the idea of delivering results in a set amount of time.

What comes into the picture at this time is the concept of scope. Managing scope is very important when you have limited time. Yet managing scope is again a complex idea that needs to be experienced over and over again to sink in. You can, actually, get almost anything done in a specific timeframe and at good quality if the scope is flexible. It means that you have to decide how you can fulfill the task in a good way but without all the frills and extras that you would normally add if you had no clear constraints.

I will need to write about scope in another post because we have had some pretty impressive findings, but this post is really dedicated to the idea of timeboxing.

In our journey into agile we have had more than one frustration moment with timeboxing at the beginning, because all people involved need to pay attention to the idea of the timebox when dealing with the project:

- The champ (we use this expression for the person who interacts with the customer and finds out what he really needs and then creates the backlog to create the product for the customer - in other agile practices this is called a product owner) needs to pay great attention when creating the briefing for the team and when choosing the work items for a work cycle. The items must be crystal clear, self explanatory, achievable and challenging at the same time.

- The team needs to pay attention what they commit to. They cannot enter that commitment lightly. They have to ask the champ a lot of questions and need to be sure that they know what they are committing to. This can take quite some time.

- The team needs to self organize and assume the responsibility for the outcome. There is no one coming in every day asking them how they are doing. They can tackle the workload in any way that they agree is best, using the allocated resources and time, without having to get approval for every step they are taking.

- It is very important that the team has access to a facilitator who makes sure that the team can work uninterrupted, makes good use of time and has the conversations that are necessary to take the tough decisions they need to take. In our version of agile the facilitator is chosen within the team, from the team, by the team. The role of facilitator can also change during the project.

To help the team accomplish their task they again use different tools, whether it be a simple tasklist or (preferred) a kanban board (we like www.kanbanery.com as well as www.kanbantool.com) is not so important. But visualizing the work in some way is. It must be clear for the team what the progress of each task is, who has pulled it and what it's status is.

When a team has gotten the hang of the idea of timeboxing, scope and self organisation, it is amazing what they can achieve in the time they are given.

My transition into agile land...

This is not going to be a very structured and well-rehearsed post. Infact, I am starting this blog to bring some order into my own confusion. If, along the way, I manage to convince some of my readers (hopefully, there will be some :-) ) this will be like a nice dessert for a good meal. But the main goal of this is to reflect and get some perspective about what is happening right now in my professional life. So why don't we start at the beginning?

I am one of the founders of a company called BrainStore. We are based in Switzerland and have been in business for 21 years. We are an Idea Factory, and we help companies come up with better innovation, build innovation teams and use processes and frameworks to make their innovation initiatives more successful.

We grew from 3 founders to more than 80 people and then downsized to roughly 25 over a period of two years because of the economic challenges we faced in the last 24 months. So far, we have been structured quite hierarchically with one of the founders being the CEO but also mainly leading all innovation, most of sales and most of operations. Though we knew that there are risks involved with this, we just never managed to organise ourselves in a diffferent way, mainly, probably, because we made the usual mistakes founders make when they cannot let go of their "baby".

This year, however, we realized that we need drastic change in order to prepare ourselves for a (hopefully) successful future. And we went looking for solutions. How should we re-organise so that the responsibility for the company, it's products, the interaction with clients and so on were in the hands of many instead of one or two decision makers?

I am documenting this process mainly for us, but also for others who are going through similar transitions and want to learn from us. 

10 drastic changes in the world of work in the next 10 years

1. De-routinization of WorkThe core value that people add is not in the processes that can be automated, but in non-routine processes, uniquely human, analytical or interactive contributions that result in words such as discovery, innovation, teaming, leading, selling and learning. Non-routine skills are those we cannot automate. For example, we cannot automate the process of selling a life insurance policy to a skeptical buyer, but we can use automation tools to augment the selling process.

2. Work SwarmsSwarming is a work style characterized by a flurry of collective activity by anyone and everyone conceivably available and able to add value. Gartner identifies two phenomena within the collective activity; Teaming (instead of solo performances) will be valued and rewarded more and occur more frequently and a new form of teaming, which Gartner calls swarming, to distinguish it from more historical teaming models, is emerging. Teams have historically consisted of people who have worked together before and who know each other reasonably well, often working in the same organization and for the same manager. Swarms form quickly, attacking a problem or opportunity and then quickly dissipating. Swarming is an agile response to an observed increase in ad hoc action requirements, as ad hoc activities continue to displace structured, bureaucratic situations.

3. Weak LinksIn swarms, if individuals know each other at all, it may be just barely, via weak links. Weak links are the cues people can pick up from people who know the people they have to work with. They are indirect indicators and rely, in part, on the confidence others have in their knowledge of people. Navigating one's own personal, professional and social networks helps people develop and exploit both strong and weak links and that, in turn, will be crucial to surviving and exploiting swarms for business benefit.

4. Working With the CollectiveThere are informal groups of people, outside the direct control of the organization, who can impact the success or failure of the organization. These informal groups are bound together by a common interest, a fad or a historical accident, as described by Gartner as “the collective.” Smart business executives discern how to live in a business ecosystem they cannot control; one they can only influence. The influence process requires understanding the collectives that potentially influence their organization, as well as the key people in those external groups. Gathering market intelligence via the collective is crucial. Equally important is figuring out how to use the collective to define segments, markets, products and various business strategies.

5. Work Sketch-UpsMost non-routine processes will also be highly informal. It is very important that organizations try to capture the criteria used in making decisions but, at least for now, Gartner does not expect most non-routine processes to follow meaningful standard patterns. Over time, we believe that work patterns for more non-routine work will emerge, justifying a light-handed approach to collecting activity information, but it will take years before a real return on investment for this effort is visible. In the meantime, the process models for most non-routine processes will remain simple "sketch-ups," created on the fly.

6. Spontaneous WorkThis property is also implied in Gartner’s description of work swarms. Spontaneity implies more than reactive activity, for example, to the emergence of new patterns. It also contains proactive work such as seeking out new opportunities and creating new designs and models.

7. Simulation and ExperimentationActive engagement with simulated environments (virtual environments), which are similar to technologies depicted in the film Minority Report, will come to replace drilling into cells in spreadsheets. This suggests the use of n-dimensional virtual representations of all different sorts of data. The contents of the simulated environment will be assembled by agent technologies that determine what materials go together based on watching people work with this content. People will interact with the data and actively manipulate various parameters reshaping the world they’re looking at.

8. Pattern SensitivityGartner has published a major line of research on Pattern-Based Strategy. The business world is becoming more volatile, affording people working off of linear models based on past performance far less visibility into the future than ever before. Gartner expects to see a significant growth in the number of organizations that create groups specifically charged with detecting divergent emerging patterns, evaluating those patterns, developing various scenarios for how the disruption might play out and proposing to senior executives new ways of exploiting (or protecting the organization from) the changes to which they are now more sensitive.

9. HyperconnectedHyperconnectedness is a property of most organizations, existing within networks of networks, unable to completely control any of them. While key supply chain elements, for example, may be "under contract," there is no guarantee it will perform properly, not even if the supply chain is in-house. Hyperconnectedness will lead to a push for more work to occur in both formal and informal relationships across enterprise boundaries, and that has implications for how people work and how IT supports or augments that work.

10. My PlaceThe workplace is becoming more and more virtual, with meetings occurring across time zones and organizations and with participants who barely know each other, working on swarms attacking rapidly emerging problems. But the employee will still have a "place" where they work. Many will have neither a company-provided physical office nor a desk, and their work will increasingly happen 24 hours a day, seven days a week. In this work environment, the lines between personal, professional, social and family matters, along with organization subjects, will disappear. Individuals, of course, need to manage the complexity created by overlapping demands, whether from the new world of work or from external (non-work-related) phenomena. Those that cannot manage the underlying "expectation and interrupt overloads" will suffer performance deficits as these overloads force individuals to operate in an over-stimulated (information-overload) state.

Additional information is available in the Gartner report "Watchlist: Continuing Changes in the Nature of Work, 2010-2020." The report is available on Gartner's website at http://www.gartner.com/resId=1331623.

is this really something for teamwork?

When you begin to work in an agile way, you work much more in a team than before. Things you did alone before are now done in a team, and you rely on each other to get things done. While I find teamwork something very helpful in 80% of all cases, in some cases I can not help to think - before we start working in a cycle - "well, is this now really something for teamwork? Wouldn't it be easier if someone sat down and just figured this out?"

Today I had such a moment again. We were asked by todays product champ to come up with a system that would allow all people working for the company to sell our products and to make it in a way that would be transparent and corresponding to the agile principles (so, for instance, to make it in a way that would allow different people to work on the same client account and sharing responsibility).

My immediate response was: "Well, I know a lot about sales and about systems, so shouldn't I just sit down and write the concept?" But the other team members convinced me that it was a good thing to do this task as a team and so we started deciding on the best way to do this.

The other team members started by brainstorming on all the questions they might have about selling our products, while I came up with a basic suggestion of the structure and system. Then, we swapped the results, and the team members started to improve my system (they actually changed it completely, which was totally beneficial to the result :-) ) and I started taking their questions and formulating "how to's" and checklists to answer all the questions.

After only half a day we had a basic system in place with all the manual and checklists to go with it. In the afternon we then started testing our system together and improved it a great deal  over the course of the next three hours.

At 4.15 we had a review with our product champ and presented him the results. At 5, we all went home, feeling a great sense of accomplishment. Wow. I am starting to become a true believer in teamwork (needless to say, I am already a fervent advocate for agile).

The role of google docs in our agile structure

One of the principles of agile working is to make all your content public to all people involved. As we needed something that would work from the onset and would cost virtually nothing, we decided to go with google docs.

Although this decision has had it's disadvantages, the advantages are way more important in my opinion. The downside of google docs is, of course, that we could not use our fonts and basically our Corportate Identity became inexistent with google docs, or, to put it differently, we will need to work a lot on our design to make it work with google docs. But as our focus at the moment is not on creating beautiful things but rather things that work (agile principle again) we just chose to ignore this.

The advantages of google docs are many:

• Working in the same document at the same time by as many people as you choose to invite
• No endless search for document versions - everything is in one document and can be accessed by exactly the people you want to
• No mailbox full of attachments
• Realtime editing in groups
• Easy structuring thanks to shared folders
• sharing inside and outside the organisation 
• Changes are available everywhere in real time
• etc.

Before using google docs and before working in an agile way, we already had used information sharing and knowledge management tools, for instance an intranet or a company wiki. These were much less easy to use and to maintain than what we have now and I feel that google docs has already helped us a great deal in our journey of becoming an agile company (a journey which has only recently started).

The setbacks

So we have been agile for about two months now and in general I would say that it goes really well. We get much more done than before and in general I think we focus on the things that are really important. But there are setbacks and bad days as in any adventure.

Today, I am just not in the mood of being either product champ, team member or facilitator. I just want to be left well alone. I want to sit in front of my computer and do nothing at all.

Of course everyone has these days, and before agile we used to cope with them in a different way; we just sat in front of our computers doing nothing and then had to catch up on the work later, let's say, in the evening or on the weekend, which was not great, but, well, we knew that we had to.

There is no hiding in agile. In that sense, it's extremely brutal. You have to be very present and very focused every moment of the day or at least during the times when you are involved in cycles, which in our case is from 8 to 12 and 1 to 5. Also, all your flaws and your bad moods are part of the experience. You have to learn to communicate better with others and to work on your shortcomings.

The good thing, though, is that outside of these times, no one expects anything from you. You are not expected to perform. And, most of the time, you can't, firstly because you are utterly and totally exhausted from the days hard work, and then also because you get so used to working in a team that it seems plain silly to "do it alone" again.

At times, of course, you wish the old times back. But most of the time, agile is just pretty amazing.

We've come a long way!

A few weeks ago, we started our journey into agile land. The price for this decision was very high. We had lots of people who did not agree that this was the way to go. They left the team. Those who stayed, though, have risen to the task beautifully and are now already more used to agile practices. Working in cycles with mixed teams instead of just doing your own tasks has become a habit. Being sometimes a champ (the person who interacts with the client), sometimes a facilitator for the team and sometimes a team member has become a rhythm.

I am not saying it's easy. On the contrary, it is very hard. But the team members are trusting each other, and we are getting much more done with less people than we ever did before with lots of people.