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