Enhance Scope

Constraints are a very important part of working in an agile or lean system.

I discussed timeboxing as one possible constraint at length in previous posts. The two other constraints that we use in our projects are fixed resources and "minimum scope".

Scope is one of the most crucial things to manage in an agile environment and that is a very tricky thing to do. If the scope of a set of items that need to be delivered in a cycle (sprint, in SCRUM language) is not flexible, there will be trouble because the team is not able to handle too many constraints and still deliver within the defined timebox, using the allocated resources.

Let's make an example. The team gets an assignment in a cycle (sprint) to deliver a mailing to 100 clients, and the backlog (see below) for this cycle (sprint) contains 5 items. Each item is described in a story from a client perspective and in "definition of done" the minimum scope is explained.

As you can see, the minimum scope defines what is needed for the champ (product owner) to ship the product to the customer, and the champ has also added ideas how scope could be expanded or enhanced if the team has more time. But the team will get a "done" for each item if they deliver the minimum scope, not the enhanced scope. The column "enhance scope" can also be left out and the team will decide for themselves how to expand scope if they have time and resources to do so.

The interesting thing about this idea is that teams get more motivated if they receive a basic scope goal and can then overachieve rather than getting a goal that is too high and then having to reduce the scope or worse, use more time to achieve the scope described. Overtime is not a concept that fits agile principles. On the contrary, the team has to constantly navigate the issues of time, resources and scope in order to get a good result and a "done" for every item. This means that tough choices have to be made, which means that ideally, good conversations happen.

This also means that the role of the facilitator is very important if the team wants to work well and without stress. Also, a team that works well will always balance customer value (the "story" part of the backlog) and team satisfaction and base all trade-offs on those two criteria.

Kanban as tasklist in timeboxed cycles

When training teams to work in timeboxed cycles for agile innovation projects, we so far mostly have used a very simple way of breaking down the tasks within a cycle based on google docs. Here is an example:

Basically, the team adds tasks based on the backlog tasks they get from the champ (product owner) and they then pull tasks. Who has started a task marks it yellow, if it's done it becomes green. It's a very useful way of managing the tasks.

Some teams, however, have started preferring kanban as a tool to monitor the tasks in their timeboxed cycles. They argue that is more visual and easier to follow. The same tasklist like above would then look different:

What is interesting is that many teams think that kanban visualizes the work better. While in the tasklist above you can see, of course, if a task is already pulled and started, here you can actually see where exactly it is in the process, who pulled it, you can go into a card and see details or links or comments.

By assigning different colors to the tasks you can distinguish between types or sizes of tasks or you can assign urgency (see next example)

It is not necessary, of course, for a team to use a digital kanban board. Often, the handmade version with Post-its or generic stickies is more than enough. The important thing is that the work is visualized and the team meets in front of their board often to check the status of their work.

We do not tell teams how to manage their tasks, but we tell them to keep a task list and explain them the two most common ways it can be done. Maybe you have other options, please share them!

How words shape our future

In their book "The Three Laws of Performance" Steve Zaffron and Dave Logan write - among many other exciting things - about the fact how our language, the words in our heads and the words we use, shape our future, and what happens once we start changing the language we use and the thoughts we think.

While reading this, I remembered this famous saying:

Watch your thoughts; they become words. Watch your words; they become actions. Watch your actions; they become habits. Watch your habits; they become your character. Watch your character; it becomes your destiny.

How important this is occurred to me this week while training a team in India in agile innovation management. The team is just starting their work within a very hierarchical telecom company, they are ten brilliant and capable individuals who have all that it takes to shape the future for their organization. They are infact hired to change the way the company innovates, and they are learning what it takes to do this with us.

We started by setting the ground rules of the team, and the team wholeheartedly agreed to phrases like "I will pull my jobs and responsibilities and not wait for anyone to tell me what to do" or "if I am unsure about something I will take it to the team" (and many other phrases that make up the framework of agile work).

The problem, as it occured yesterday is not that the team does not want to work like this, it is that they are terrified to death because their work experience so far has been all "command-and-control", "wait for approval", "my boss tells me what to do". Especially in Indian culture it is highly uncommon to do something without approval from the boss.

And this is where language comes into play. Phrases like "this is very hard" or "I don't know if people in the organization understand this" or "I think they hate us already" started being voiced after one week of training. All these statements and complaints are not facts, but just perceptions. They also serve as a "racket".

A racket has four elements:

1. A complaint that has persisted for some time

2. A pattern of behavior that goes along with the complaint

3. A payoff for having the complaint continue   

4.The cost of the behavior

What this came to mean for me: If I consciously or unconciously blame others for the things that don't work I do not have to face my own fears and try to make things happen, because I already delegated the potential failure to others (the ones that "don't let us work like that" etc.). Infact, doing this is very common for all of us and it stops us from performing as we could.

So, while on one hand moving forward as a team towards an agile structure and work practices that could set all the energy and the innovation capacity free in the organization, on the other hand the team uses language that will make it very difficult for them to make that future for them happen. The language they use defines the future they are perceiving or expecting.

So one of the key becomes to change the language you use or the thoughts (also language) that you think. This is a very long process that involves many conversations and discussions, slowly changing the perception of the team, analyze and let go of the rackets. Only if the team does that they can start shaping their own future and the future of the organization.

Asking questions - why is it so hard?

Image by http://cdn.ilovetypography.com/

I am a journalist by training, and so I like to ask a lot of questions. My clients benefit from that, because they really have to allow me to dig deeper and to find out what really is the issue they want to treat in an innovation project, and I am not so easily satisfied with superficial answers, which leads to richer discussions and therefore to better understanding on both sides.

Asking questions is vital to any great project. Only if the flow of information is maintained into all directions and if anyone can ask anyone else any question about the project can we be sure that the project can be successful. Asking questions is important, but being available to answer them is also crucial. This does not necessarily mean being present in person, but just available, open and even eager to answer questions that come up during the process.

In my last post on my company blog I wrote about pull systems and how they are better at innovation than push systems. The same is true for cultures that allow for questions and discussions and where people are trained in asking good questions.

Often, in structures that come from push/command-and-control and are transitioning into something more agile or pull-based, this shift is very difficult. In push cultures people are used to second-guessing, assuming and "filling in the blanks" for the people who assigned them a task. There is not much flow going on during the project and thus vital information is not shared. Even worse, by taking assumptions people often proceed into completely undesired areas and produce poor results.

What is very important is that asking questions is not about getting instructions or approval. It is about maintaining the relational flow between all people involved in a project, be it clients, stakeholders, managers or team members.

Even for me, the journalist, it is sometimes hard in a project to ask questions. It seems much easier to assume because it will at first glance produce less friction or hassle for me. Long term, though, it creates waste and products that cannot be delivered.

We have it down in our code of conduct that "If I do not understand something I will ask", and "if the team cannot find the information, they will ask people outside of the team" as well as "I will not say yes to something I do not understand".

But to be honest, we have still a very long way to go from the written words to the lived culture, and so do many of our customers. 

Beware of the "agile as a set of rules" trap

There is a fine line between being convinced of agile/lean concepts and principles and using them as a framework and using them religiously and as prescription. I think we must be aware of this when we try to bring in new people into teams or build up completely new agile teams. If we do not make it perfectly clear that what we are talking about is a set of principles (versus "rules") and a framework (versus "process") we risk to loose people before they can even grasp the beauty of the whole thing.

This, partly, is one of the reasons why I think that every team and organization must find their own style of agile rather than following a recipe like SCRUM. It is good to use practices like SCRUM or kanban, but they have to evolve into something that the team (or organization) owns and adapts over time. (I am speaking specifically from a perspective of someone using agile/lean principles in a setting outside software development, but I think it is probably also true for software development itself).

It is normal, perhaps, to have new people on teams say things like "agile is like communism - it works perfectly in theory" (actually I heard that one last week), and then it is crucial that we DO have a conversation (or, more likely, several conversations or an ongoing conversation) about why agile is not a theory stuffed with useless belief points abd dogma , but a system that everyone can navigate and use together to create amazing things like great customer value, team satisfaction and performance. The word conversation gives a hint that over time, the team will reach a common set of principles and maybe even "rules" that they feel comfortable with, but that THEY established and own, which again means that they will feel free to inspect and adapt when they see that rules are no longer helpful.

As with every framework, theory, principle and system, it is always just as good as the people who use it. And therefore, conversations with people on how to use the principles and to make them their own instead of following rules made by others is absolutely crucial, as is the fact that starting to work like this is coupled with scepticism, fear and failure, but if a team overcomes this it can truly start using the power of agile and will probably not want to work in any other way anymore.

Training, 100% "pull".

Since many years, we train clients to run successful innovation projects. We have a very good process to generate, assess and implement leading ideas, using different tools and communities to come up with a diverse set of ideas. All of this has been tested in thousands of projects and is very successful.

What was missing was the knowledge - both within our company (www.brainstore.com) and with our clients, how successful innovation projects are managed over a long period of time. I mean, it is all great if you use a wonderful process to come up with ideas and identify the leading initiatives, but the truth is, innovation is complex. So even if you have wonderful ideas that are tested and "might" work well, you need the right process to manage successful implementation. This was a kind of missing link for us for a long time, until we discovered agile principles and practices.

Agile allows clients to "implement" the ideas that they found in the BrainStore process (we call it "The Idea Machine 3.0) in a cyclical way, coming up with a "Version 1" very fast and adding features in future cycles. This is true whether they implement new products, services, software or even processes.

But should do we "teach" this agile way of working to teams who are thoroughly used to siloed organisations, command-and-control environments and "top-down" decision making? We first tried to teach them by explanation. That was total failure (and as we learned: Fail early, recover quickly, right? :-)).

One morning, just before such a client training was to happen again, we got quite frustrated and discussed within the teams how we could change the approach. Our Enterprise Champ (the person responsible for the top level enterprise backlog) suggested: "Why don't we do the whole training in a 100% agile way"? We resonded, somewhat exasperated: "Yes, yes, but HOW?".

We thought it through for a few minutes, and here is what we did, and are doing since:

Step 1: Trainees come to the training program with a "I will be tought something now" attitude. They get coffee, have a chat and are seated in a circle and then addressed by the training champ (person responsible for this training). The training champ will tell them that they are the clients and that they are getting to tell us exactly what they want to learn in this training. What do they expect? What do they want to know? What is te purpose of the whole training for them? These needs are noted in a briefing.


Step 2: Based on the purpose and the briefing (goals, expected results, criteria) the backlog for the training is established. The backlog contains different items that the participants want to learn, and each item is described with a short story (as a trainee, I want to xyz, in order to xyz) and gets a clear "definition of done". Each backlog item also gets an estimate of time or size by the participants. A time for the review (usually this is sometime in the afternoon at the end of the first day) is agreed upon.


Step 3: The training champ will now ask the participants whether they are ready to commit to this backlog and  to "produce" all the items on the backlog as a team until the time of the review. It is made clear that the team is responsible for the results and that they are to self-organize to reach the results. To do that, they choose a facilitator from within the team. If needed, the champ can become a team member for the time of the training, or alternatively, there are some experienced people in the team who can help the team reach the learning goals. The team commits, most of the time after asking additional questions, negotiating some terms, changing some backlog items.


Step 4: The team starts learning by working on each backlog item and exploring the issues. Learning material is provided in a "Knowledge Bureau" (Desk of drawers containing "how to's", checklists, exercises etc., both available on paper and online.


Step 5: The team presents the results of the cycle at the review. The trainig champ listens and asks questions. 


Step 6: The team has a retrospective where they discuss what went well, what did not and what they will change on the next training day. 


Step 7: Training champ provides feedback to the team, based on the results of the cycle and the retrospective findings.


The next day, the team meets again and goes into the next round of learning. In cases where training days are happening over a longer time span, teams might also commit to a backlog for in between training sessions, committing to exploring and learning some issues until the next training session happens.

This approach works so well because it is a 100% immersion. We do not need to explain a lot of the "how to do agile", "how to be agile" stuff, but can launch directly into the experience. A team that has experienced this will afterwards reflect on what they did and adapt their style of agile to their needs rather than having a theoretical knowledge about the whole thing that they will not be able to digest properly.

The role of the facilitator

Reflections on the role of the facilitator

The role of facilitator in an agile team is a role that we at BrainStore have still less experience with than the role of team member and champ. Although the team so far has always selected a facilitator for each cycle, the role has been more of a “manager” than a real facilitator in my opinion. 



Per definition in our agile principles, the facilitator
Helps the team move towards higher performance and greater personal satisfaction.

• By helping the team to discover barriers and help the team to remove them
• By promoting constant exchange of relevant information between team members
• By helping the team to have higher quality conversations
• By helping the team to optimally deal with time, resources and scope based on the allocated resources per backlog item
• By helping the team to decide on when and how to exchange information including stand up meetings and retrospectives

As long as cycles were short and team members knew each other well, the role of facilitator was a little bit easier and a little bit less crucial than now that we start working with remote teams and much longer cycles. Also, the role was never really taken as seriously as it should have been taken.



In short cycles and projects of low complexity, the facilitator also was or is able to take on team tasks in addition to his or her facilitation role. With larger projects, this becomes a conflict, because

• the facilitator cannot focus on the crucial role of facilitating when taking on tasks of his or her own.
• there are multiple moments of conflict when the facilitator is part of the team, because if the facilitator becomes part of the team he or she is part of the “we” and thus takes on the responsibility of the team. This means that he or she is no longer focusing optimally on the above mentioned elements that are crucial for making the team more productive.

In discussions with our agile coach I realized that the facilitator should focus mainly on the following activities during the facilitation of a team:

• 40% reflection (thinking about the role, learning more about it, improving self awareness, studying different techniques etc.)
• 30% observation (bringing the observations to the team in the form that seems best suitable at the moment)
• 20% inquiry (asking questions, being curious, mentioning things that are interesting etc.)
• 10% action (intervention, steering, removing impediments etc.)

I also realized that (mainly because of the fact that I was at the same time team member AND facilitator, the balance was much more on the action (more than 60% of the time).



What are examples of things that happen when the facilitator takes on too much action?

• the facilitator “thinks for the team” and thus does not give the team the opportunity to self organize and to grow
• the facilitator becomes part of the “we” and gives up his unique opportunity to observe, reflect and inquire.
• the facilitator becomes a negotiator for the team, e.g., speaking to the champ, communicating with the client etc. (tasks that need to remain in the team)

If the facilitator can focus on his/her facilitation role, numerous benefits arise for all:

• The team can focus on the task
• The team can start using the most of all resources
• There is not “someone” who thinks for the team, but the whole team
• There is always someone reflecting, observing and asking questions without providing the answers

Continuous improvement
Facilitation is not easy. The faciltator will always, also after many cycles, feel the urge and need to take action and intervene rather than observe and inquire. That is ok. The important thing is that gradually the facilitator learns to deal with this and to reflect, observe and inquire more



Examples
Examples of reflection

• Reading about facilitation techniques
• using agile resources
• reflecting about own behaviour
• writing learning materials for others, 
• coaching others etc.

Examples of observing
Listening to the team without intervention, from time to time offering an observation. Open remarks that start with words like

• “From what I hear,...”
• “It seems to me,...”
• “I get the impression,...”
• “I observe...”

It is specially important to voice observations of gaps, e.g. gaps between the goal and the status the team is in, information gaps etc.



Examples of inquiring
Questions that are open ended and help the team start a conversation, such as

• Actively problem solving: “What might help?” “What do you think will happen next?”
• Reflecting on experiences: “What would you do differently if you did this again?”
• Generating ideas and goals: “How could you figure out the answer to this problem?”  etc.

Examples of interventions

• Taking on a task from the team
• Researching something for the team
• Removing an impediment for the team
• Steering the team into a certain direction

Dealing with timeboxes, part II

After having written about timeboxing for inexperienced teams, an interesting incident came to my mind that can be helpful to understand the concept even better, and it is, coincidentally, also a great anecdote.

One team working on a complex project of building an innovation team for a client in India had committed to a cycle with 10 working days per person to get applications for the job, preselect on those applications and then conduct an assessment day for the client in India to select the best team for the client.

The team had 4 people on board. Three of them were totally new to the idea of agile and of timeboxing; one person (me) was more experienced. The team decided that I should therefore take on the role of facilitator, which I gladly did.

Along the way, the team worked and I inquired regularly how we are doing on time, myself assuming that it would be totally clear to everyone that our time allowance was 10 days each and that everyone else on the team knew exactly what that meant (false assumption, of course). I also tried to steer the team to have valuable discussions about the use of time and the trade-offs it involved. 

I had the nagging feeling that the team was acting in a "we will do whatever it takes" way instead of discussing the use of time and resources properly. But as I was a very inexperienced facilitator at the time (and I will share my findings about facilitating here, to, at some point), I did not quite know how to address the issue.

At the end of the cycle, shortly before the review, the team suddenly started to address the issue of overtime. I was quite astonished and asked them what kind of overtime they had accumulated (because I was aware of none). There were 2, 3 and 5 days overtime in the cycle, so a total of 9 extra days. Ouch. 

As a facilitator I realized that I had not fulfilled my role very well and told the team that we would need to take up the issue with the champ (product owner) who had initiated the cycle.

When we did this, there were two very interesting findings:

- In the briefing, it was not made 100% clear to the team what timeboxing meant

- One person of the four had commited to only 7 days instead of 10, but this fact was unknown to the team, so the team falsly assumed they had 3 days more. 

Here comes the interesting conclusion that we arrived to when discussing the issue between champ and team: The champ was NOT going to pay overtime (because that would be sending a false signal to other teams and it really was not in line with our agile principles and the concept of timeboxing), but the champ would pay a penalty for not making it 100% clear to the entire team what timeboxing meant and for not informing them that one person on the team was working 3 days less than the others.

The team discussed the amount of penalty that should be paid and how it should be distributed in the team (I, as a facilitator, did not want a share of the penalty because I felt partly responsible for the problem), and the champ agreed to the amount. 

I am quite sure that these particular team members will act very differently when working in a timeboxed cycle in the future.

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.

Scrum in other areas than software

This interesting article explains why Scrum is not (yet) widely used in areas outside software development

How people adapt to change

I just received this very interesting link from one of my colleagues. It describes the "Satir Model", a model for change management described by Virginia Satir, a family therapist. Her findings can also be used to explain and understand what a group or team goes through when facing drastic change. I very much like the way that it acknowledges that change affects every aspect of our lives: The way we think, feel, our physical performance and much more.

I could relate to every stage described in the post as we go through exactly the same stages at the moment. What impressed me most were the following findings:

• We cannot shortcut change. We have to go through all stages to end up in a better place
• The way to "better" leads through "chaos". It's calming to know that this is normal
• Resistance is a normal part of change
• Eventually, everything will be fine. I really believe that. 

So I am a product champ now

As of today, I am one of 6 product owners in our company. We currently have 3 roles in our agile environment: Product owners (we call them "champs"), Facilitators (in the agile world they are called agile coach or scrum master, depending on the method that is used) and team members. Before we started our transition to agile, all people in the team had to agree that they are willing to take on any of these roles depending on the needs of the company.

So far I have been a team member, and yesterday I took on the responsibility for one of 6 products. My job is to lead the backlog of this product, set the priorities and then brief the team on the increments (parts of the product) they need to deliver.

Being a champ (product owner) is both exciting and scary. As so far decisions in our organisation have been taken very centrally, it is new and unusual that decisions are now taken by different people and that there is no "boss" of the operation. It will mean taking decisions, and to base these decisions on evidence rom the market.

This afternoon, I will have my first workshop with potential clients, trying to find out what the market might need and then verifying this information over the next few days before I will start with my first cycle of product development, which will probably take place next week.

I will keep you posted, of course.

Nice explanation of kanban

I really like this explanation of kanban (one of different agile methods or tools) by Methods and Tools. It gives you all the information you need.

Our 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, services, software, finances etc.? How can we do this in a way that is truly fit for our culture and how can we make it happen without having to hire new people? These questions lead some of us to an interesting movement that is mainly used in software development today: agile / lean.

We discovered that agile pracices cover a lot of the things we were looking for and also some that we had not yet considered, but sounded sensible for our purpose. Some of these ideas involved self-organised teams, constant interaction wtih the customer, development of small parts of the project or product that are constantly shipped to the client instead of planning, then creating and then delivering the whole thing, limitation of work in progress, pulling of work instead of pushing and more.

Also, there were some values in the literature about agile that we, as a company, were sorely in need of, such as mutual respect, sustainable way of working, teambuilding, reaching our potential and many more.

And although, so far, we have found only a handful of companies that use agile working methods outside the software world or the industrial world, where agile or lean ways of working have been applied for a long time, we decided to embark on the journey of making our company agile.

I will be completely honest with you here: It's a rollercoster ride, with more of the typical "why did I join this ride"-feelings than the "wow, this is great!" ones. The journey has started in January with first discussions, reading of lots of materials, discussions with our board and some trial projects. We have started to work (or at least try to work) in an agile way about four weeks ago, including the whole team as recently as two weeks.

I will discuss some of the challenges we are having in becoming agile, the resistance, the fear, the learnings, trial and errors and more as this blog grows. And I am looking very much forward to hearing from others who have either started a similar journey or are thinking about it.