FlexFlow - Flexible Thoughts for a Complex World

Agile Self-Help through Communities of Practice

This is a short post to share the slides of the presentation I gave today at XP 2010 in Trondheim about how to implement a community of practice in your organisation to spread the experiences about agility among teams.

Here they are:

Agile Self Help Through Communities Of Practice

Most of the talk is actually coming from the following sources:

• Wenger, Etienne (1998). Communities of Practice: Learning, Meaning, and Identity. Cambridge: Cambridge University Press. ISBN 978-0-521-66363-2.
• Wenger, Etienne; McDermott, Richard; Snyder, William M. (2002). Cultivating Communities of Practice (Hardcover). Harvard Business Press; 1 edition. ISBN 978-1578513307.

Solution Focused presentation again: Mini XP Days 2010

Here's a short post to publish the slides and the handout for the third version of my Solution Focused approach to Agile Coaching presentation. This time I gave it at the Mini XP Days Benelux 2010, a one day conference with the presentations that were voted the best at the XPDays Benelux 2009.

It has been an honour for me to be invited and I always enjoy coming to Benelux, both because I like these countries and because the agile community is very mature and the quality of the interactions with the other participants is a very refreshing experience.

While the presentation was basically the same as what I delivered at Agile Central Europe, the smaller number of participants and their engagement promoted a completely different dynamic, definitely more challenging but also very satisfying. Here are the slides:

Solution focused approach to agile coaching for the Mini XP Days Benelux 2010

Also this time there was a handout, where I summarised the main concepts and techniques.

For this version of the presentation I kept the exercises in pairs instead of working in groups as the presentation was shorter than in 2009 plus there were a few minor changes in the slide deck.

The participants had fun trying the techniques hands on:
(I)

(II)

(III)

and many of them would have liked to have more practice time. Maybe an option for an open space session at the next Agile Open Holland...

After three times I gave this presentation, it's time to take a break and let the material sleep for a while: at the moment I have no plans to present it again in the near future (read: in 2010), but watch out for some new material based on these concepts. For example, the workshop together with Mike Sutton I will present at XP2010 will be still based on Solution Focused, but using Improvisation Techniques to allow the participants a full-immersion experience!

Agile Central Europe - Kraków - April 8th and 9th 2010

Last week I went to Kraków for the first edition of the Agile Central Europe conference. The news is that the conference was, IMO, a great success for the organisation led by Paul Klipp, so here's a short report about it.

The city

I was never in Kraków before (and, for what matters, I was in Poland only once to date) and, as we all have, I had a certain expectation on the city: I read it is considered the Silicon Valley of Poland as a lot of high tech international companies have opened a site here. As such, it is a marketplace full of opportunities for software specialists. I also read the city has a nice historic centre worthwhile visiting.

Though I left space in my beliefs for some surprises, I was blown out by what I saw: the city is amazingly beautiful, starting from the location on the Vistula river, to the vast number of very stylish historically buildings.

In the city there are several universities, so the overall impression is one of a very young and active city, where almost everybody I met had the skill of compensating my non-existent Polish talking to me in a very good English!

The Venue

The conference was held in the brand new Park Inn hotel, situated close to the centre, with a nice view over the Wavel Castle and the Vistula river.

The venue was perfectly suited for such an event and - attention you techies out there - even the wireless LAN was working amasingly well. In fact, it was the best wireless LAN connection I ever found at a conference!

Also the closeness of the venue to the city centre allowed for continuing discussing what we saw during the day over a nice dinner in the city centre - the type of atmosphere I miss in several similar events.

The Organisation

I could spend pages on describing what happened, but I'll probably summarise it in a two words and let you experience them in yourself: Awesomely flawless!

The Speakers

As the event was fairly small - two tracks - it was possible to interact with almost all the speakers. I didn't know several of them - several were, like me, quite new to the role - but I quickly learned to appreciate the expertise they brought to the event: For me, a very important value of a conference is what I learn by interacting with the people, and this team of speakers rocks!

I deliberately chose the word team: Andrea Provaglio called by email just a few hours before the conference for an informal meeting of the speakers for the evening before the conference and, after we got to know each other a bit, we started interacting almost as a team for the whole duration of the conference. I miss you guys!

The Participants

On average the audience was fairly young and very well prepared. The level of understanding of agile technologies seemed to me very mature, more mature than some Western European countries I've seen. I also got the impression that agile could really go mainstream here without the trivialisations that often go with it.

The only thing I missed a bit was the possibility of interacting more with the people: it seems culturally the audience was often a bit shy in interacting with the speakers, though IMO they have all the needed resources and knowledge to do that. My only message to the audience is: you guys rock too, bring your knowledge in and share your experiences, because they are first class ones and I'd love to hear more of what you have achieved already!

The conference content

Very strong program, with a lot of topics on the soft skills side of agility. I highly appreciate this because, as we know since the old waterfall times, projects fail because of people, not because of technology. Agile is fairly advanced in the technical practices, so IMO it is time of balancing the software technologies with the human side of agile. This is actually why my speech was dedicated to a topic that helps us to communicate better and more productively.

The highlights of an average very good conference (for the whole program see here) were, IMO:

• Gwyn Morfey and Laurie Young from New Bamboo showed us some practical and low-tech tips they adopted in their organisation. The presentation, with slides made by photographing what they drew on their whiteboard in the office, was based on the interaction of the two speakers acting the typical situations they found and describing how they solved them: a recipe that guaranteed constant uptime in the audience through a mix of very useful information and a lot of fun!
• Simon Roberts gave us some tips to properly and stably install Scrum in the enterprise
• Maria Diaconu and Alexandru Bolboacă made their case for software craftsmanship and described their experience in promoting it in Romania
• Robert Dempsey gave some very practical tips on how to run a distributed agile team despite all the cultural differences that you can find going this way
• Marc Löffler was a great surprise: he decided to give a lightning talk at the end of the first and started preparing the slides during another presentation (I saw him...). He came up with a lovely talk about how a team can drive the ScrumMaster crazy, that he delivered beautifully though it was his first time on stage! The day after he succeeded again in another lightning talk describing how a ScrumMaster can drive a team crazy (and even the score, I guess...)
• Thomas Sundberg told us about how to write clean code: simple tricks we should all know but, as his real life experience consulting companies show, we don't

I also heard good opinions on the following speeches, though I could not attend to them:

• Jens Korte with his ScrumFluenca
• Zuzana Sochova with Company Culture as the Key Agile Milestone
• Monika Konieczny with Coping with communication problems in agile projects
• Andrea Provaglio with Beyond Agility

The list is incomplete as, of course, I missed everything that was in the other track, so if you were there and have seen a great presentation from another speaker, please comment on this blog and share your view!

Overall a great first edition for a conference. I'm sure this event will, in a few years, become a "classic" in the world of the agile conferences. See you next years guys!

P.S. Here is another report about this conference by Robert Dempsey. He wrote also a blog post for every session he saw, thus documenting the conference much better than I could do on this page: I highly recommend you to look there for additional information on the event and the sessions.

Solution Focused approach to Agile Coaching at Agile Central Europe, Kraków, April 9th, 2010

As I had announced in my last post, I talked to day at Agile Central Europe, again presenting my Solution Focused approach to Agile Coaching workshop.

(Kraków, the "Wavel")

In Kraków I had less time available compared to the XPDays Benelux version, but I still managed to add a few more information on the subject, in particular clarifying my position on the roles of an Agile Coach. The Agile Coach is, in fact, a collection of many roles and, when in the role of the coach, there are indeed several techniques already available from the world of Business Coaching and Psychotherapy that can help us doing a better job, Solution Focused being one of them.

Here are the slides:

Solution focused approach to agile coaching at Agile Central Europe

And this time there was even a handout, where I summarised the main concepts and techniques, that can be downloaded from here.

The main change, however, was in the exercise part: as at AgileCE the audience was larger and the room organised for a frontal presentation more than a workshop, I had to change to exercises in pairs, giving up the concept of the independent observers I used in Belgium. This simplified the organisations of the "groups" as there was no need to move or reorganise chairs and allowed a faster pacing of the exercise rounds, thus allowing more time for the content.

As in my experience the observer plays an important role in learning these techniques, I reintroduced the concept "from the window" by proposing an open space session to continue practicing in a smaller setup and with observers.

I did my best to deliver the material and, as far as I was able to see, the audience accepted it well, but I'd like to get your feedback, so you're welcome to comment on these pages!

Update: Robert Dempsey wrote also a post about this presentation.

Coming attractions

This time I will use this space for some shameless self-promotion about the upcoming public speaking events I will be part of.

After the good resonance for the "Solution Focused Coaching in Agile" presentation I gave at XP Days Benelux, I will bring it again on tour during April:

• April 7th and 8th in Krakow during the Agile Central Europe conference. My presentation will be on the second day - unless the program changes - and, if possible, I will also schedule an Open Space session to further discuss the topic and answer questions. As the audience will be bigger than in the previous session, I will present a significantly rearranged version of what I showed in Belgium.
• April 26th in Eindhoven at the Mini XP Day Benelux. I will re-present what I showed in November last year in Belgium, though I will of course take into account the feedback I got there.

In the meantime I am also offering the content of this presentation as one-day in-house workshop/coaching, with extended theoretical information and a lot of space for supervised exercises. It can also be applied directly to a specific problem in order to determine new options and possible solutions. Target group for this workshop are ScrumMasters, Product Owners and Project Managers. While the information given is very relevant for agilists, the learning is very useful for every kind of project. It can also be targeted as a workshop to solve a particular project situation, i.e. to envision possible solutions to an existing problem.

Furthermore there will definitely be chances to talk about solution focused in agile at the Agile Coach Camp Germany, but if you haven't registered yet: too bad for you as the event is booked out already. We'll probably even close the waiting list soon as it is already too long.

Back to conferences: May 3rd I will present, together with Martin Heider, "Auf Diät" at the interactive agile track of the JAX 2010 conference in Mainz. The workshop, taken and adapted from the work of Pascal van Cauwenberghe and Portia Tung, shows how to optimise a production line using the principles of the Theory of Constraints and the 5 Focusing Steps by Eliyahu Goldratt. The concepts can be, of course, fully adapted to a software environment and, in fact, we'll use a software "production line" as example, though the participants will build paper boats and hats instead of Java code, and I promise it will be fun!

We presented this workshop already at the Java Users Group Erlangen-Nürnberg and I ran it already at a PMI local group meeting, but the version at the JAX will have several improvements to make it even more fun.

Next in line is XP 2010: In Trondheim I will be present in a workshop together with Mike Sutton. "Stuck in a rut? Improvise your solution" is a newly-created workshop that brings together the solution focused concepts with improvisation theatre methods to create a new learning experience. The idea behind the workshop is to explain the principles of solution focused through a learning-by-doing experience with a large usage of improvisation theatre techniques. Mike and I are exploring brand new territories while preparing this and we expect the results to be great!

I will also hold a Lightning Talk on how to set up a community of practice in your organisation to actively enable cross-learning among various teams. It will be just 10 minutes or so, but I'll pack as many useful information as possible and some references to keep learning about it.

Warning: Fear might twist your perception

I attended recently a meeting of project managers where "agile methods" was the subject of the evening. In fact, the whole evening was about Scrum, with three presentations trying to frame Scrum as a project management method.

On one side it was good to see Scrum getting visibile to an audience that normally reasons in terms of Gantt charts, earned value and hierarchies.

On the other side this focus on one method and the indirect equation Agile = Scrum is, in my opinion, a very naive and limited view on what agile makes possible.

But the subject on whether Scrum should be used alone or in conjunction with other agile methods is being discussed in so many other valuable contributions that I would rather prefer to focus on an interesting cultural aspect I noticed that evening: what do you fear about Scrum?

I'm referring in particular to one of the three presentations. The speaker claimed to have "14 years of experience as Project Manager, 14 days as a certified Scrum Master" - in fact this made me wonder why the heck was he actually talking there, especially considering he didn't seem to have ever used Scrum in a live project.

His presentation was focused on bringing Scrum concepts back in the project management dictionary, and in doing that he gave a lot of wrong information. One for all: he claimed the Burndown Chart is an Earned Value diagram upside down. Oh, well, he missed the fact the former is measuring tested software, the latter a completed task without considering whether the task created working software or any other artifact that is not really bringing value to the customer.

What struck me, though, was the amount of misinformation he included in his presentation: most of what he said was awfully incorrect and clearly with the purpose of demonstrating that Scrum is just another project management method, actually even more directive and prescriptive than the PMBOK and, as such less flexible. (I leave the counter arguments to you in this case...)

I thought he just missed the point, but then I started hearing aggression in his words. It seemed like the propaganda that any *ism - Project-Managementism in this case - does to nullify its enemies, where facts are tilted as needed to demonstrate what is wanted.

At that point I asked myself what exactly was he fearing? What aspects of Scrum are so damn worrying to bring him to present such a vehement pile of false statements?

This is, in fact, a central aspect that we agile coaches should always consider when working with a client. The fact that Scrum uses a completely different nomenclature than the "established" project management techniques is likely to increase the resistance in some people. (BTW, there is a very good reason for the name change: re-using existing names would keep many people re-using also the behavioural patterns associated to that name and this is exactly what Scrum does not want)

What happened in this case? What are his fears?

Though I have my hypotheses, I will not mention them here. I'd rather keep the post at a structural level: he has an opportunity to change the way he works and he is refusing it, trying to bring the "new" back into the "old" frame (he's a consultant, so I guess he cannot simply deny the new as he would probably like to).

I'd like to ask all of you 1. what are you fearing when resisting change and 2. whether this fear is actually twisting your perception, thus preventing a rational comparison of the alternatives.

Then watch carefully your colleagues when dealing with a change and check whether they are also falling in a similar pattern. In fact, we all unconsciously do most of the time. I promise it will be fun to observe them!

Finding bottlenecks in projects

Yesterday Martin Heider and I moderated a German version of The Bottleneck Game at the Java Users Group Erlangen-Nürnberg. The game simulates a production line that is improved by applying the 5 focussing steps from the Theory of Constraints by Eliyahu Goldratt.

Here are the slides from the session:

Auf Diaet, Nuernberg 11 March 2010

(The handout can be downloaded from here)

I like especially to watch the face of the participants when, during the explanation of the game, we tell them they will "build" paper boats and hats. What seems initially to be a childish game quickly turns out to be a very funny game where all the players enjoy themselves!

(More photos here)

The next opportunity to see the game will be May 3rd at the JAX 2010 conference in Mainz: hope to see you there!

A great thank you to Pascal van Cauwenberghe and Portia Tung for creating the game and Christine Neidhardt for the logistical support!

Posted at 17:45 | Permalink | Comments (0)

So the definition of done of a Scrum team is sick and you, dear agile coach, are intervening on the team to get them to fix it. Easy, isn't it? Either you tackle the issue during a retrospective or on in ad-hoc discussion, point out the symptoms, ask the team how they plan to fix it, let them define the goals and a plan to achieve them. Sure easy, if you have the team within reach!

As part of my coaching activities I sometimes have ScrumMasters and Product Owners as customers that come to me individually: one ScrumMaster came to me telling me the definition of done in his team was obviously not working since several sprints. Major symptom was a high number of stories coming back into the backlog in the form of bug reports.

He addressed the problem during the retrospectives, but the team either ignored him or proposed solutions that did not address the root cause of the problem. There was no conflict among them, in fact the team spirit was fairly high, but still my client was not able to "move" the team in the direction he deemed useful. On the contrary, they ended up layering more processes on the top of the previous ones, adding overhead and effectively decreasing the average velocity.

I had no jurisdiction on the team. In fact, they did not even know about me at all. I needed to trigger a change in the system's behaviour: what could I do?

The experience made in family therapy by the likes of Virginia Satir, Steve de Shazer and the Milwaukee's Brief Family Therapy Center is that, in fact, you don't need to have the actual subject showing the symptoms present in a therapy or coaching session in order to inspire changes in a system, it is sufficient to search for differences - new behavioural options that have the chance of breaking the spiral of cause-effects that brought the system to such a dysfunctional situation. So there I go...

Through the standard set of systemic questions I could not expose a relevant difference to work on. In fact, we worked on those topics a few times already. So I decided to use a systemic constellation instead.

A systemic constellation is a tool to create a view of the system - i.e. the people involved in the specific situation but also goals, impediments and any actual or abstract entity that might be relevant in the discussion - by using representatives - i.e. either objects or people. In this case, not having additional people available, we used my objects, in particular my coaching army:

The client is responsible for putting the representatives in the position his perception suggests, thus creating the so-called problem scenario:

[Note: TM is a team member, all developers in this case. The arrow points in the direction the representative is "looking"]

In this situation the representatives are asked appreciatively about their perceptions. In case the representatives are objects, as was the case in this example, the client is asked to put himself into the role of the representative and talk in its stead. This allows for a quick and efficient exploration of the point of views of all the relevant parts of the system, generating an insight that would be otherwise very difficult to gather.

From there, the coach, together with the client and - if they are persons and not objects - the representatives, transforms the represented system into a solution scenario, a situation where the problem is solved. The whole process is strictly solution-focused in order to let the client describe a solution that is compatible with the system's constraints.

It took almost two hours to reach this scenario:

What happened there? As an observer of such a constellation it is difficult to appreciate the full details of what the client perceived through this exercise, especially not knowing personally the members of the team. My reading of the situation is that the ScrumMaster was a bit too obsessively trying to make the team change the definition of done and, through this, the established testing habits. As a result the team unconsciously blocked his efforts, though remaining very nice and friendly with the ScrumMaster. So while there was no explicit conflict to be detected, the system shunned the ScrumMaster's opinions.

Using the things he learned during the session the ScrumMaster changed something in his approach to the team, mostly a different way to interact with them and being in general more supportive in all the Scrum Team's activities. This caused the team to become more receptive to the ScrumMaster's suggestions and, within a few days from the constellation work, brought the team to accept the idea of the definition of done not working properly. At the next retrospective the subject was finally on the agenda and changes were planned. Three 2-week sprints later the team is still improving its regression test system - technical root cause for the problems - and the amount of stories returning back is diminishing. At the same time they are removing from their processes all the useless procedures they added and the velocity is improving.

Here's a metaphor I use often when coaching people. It is called the lifetree and I use it as a tool to raise awareness of the resources of the past and the possible futures and to identify strengths and weaknesses and learning paths. It has a lot of applications in career coaching and in coaching in general. In agile it can be used with fresh Scrum Masters and Product Owners who need to understand how to cope with their new roles. This metaphor is intended to give the opportunity to the coach to ask solution-focused questions under a consistent umbrella, an overall framework for the session. Imagine you are a tree!

A tree has roots, that represent your past.

Each root is important: it is an experience you made in the past, contributing to your current situation and it is a resource you can use for your future. You might decide to build on it or not, but it is there. You cannot change it, but you can decide when and how to use it - if at all.

And you have a lot of different roots that are feeding you: parents and relatives, friends, educations, previous jobs and colleagues, ...: just stop and think for some minutes about them. You have collected a lifelong richness of experiences that brought you to where you are and can indeed help you in the future.

• How long are the roots?
• How thick? How solid?
• On what ground are they growing? Are they stable? Are they nutritious?

A tree has also a trunk: this is you now, with the strength given from your roots!

• How is the trunk? Small? Large? Stable? Flexible?
• How should it be different?
• What difference would you need in the roots to have the trunk you want?

A tree has branches and leaves: these are your possible futures and choices and directions you will choose.

As in any tree, what grows on top comes from what's on the bottom, and you're your own gardener:

• What could you grow from your roots?
• What other roots would you need to grow something different? And what would this something different be?
• Is there any branch bigger and richer than the others? What makes it so?
• Is there any branch that is dying? What is this branch missing?
• How are the leaves? How should they be instead?
• What fruits do you want? Are they already growing? If not, what's missing? What needs to be different?

There is an amazing amount of explorations you can do just looking at your roots and your branches!

In order to fix the learning, ask the client to draw herself as a tree!

Though this is a tool regularly used in systemic coaching in Germany, I curiously could not find any reference in English: if you have any you're welcome to post it here. For German speakers, here's a description of the method.

In the previous post I was mentioning that a company culture is anyway emergent and what emerges cannot really be predicted, but can be influenced in many different ways.

Here's one way to do that, which I found very useful when working with agile teams.

A big part of the agility is based on values and principles, be it the XP ones or the Agile Manifesto ones, or the lean ones. But how are values and principles playing together? How do they exactly help us?

Values, principles and beliefs are actually interworking together to define the identities of individuals, teams and organisations. As a change agent in an organisation, one of my objectives is to support a common identity in the teams (even better in the whole company) as this will create alignment, agreement and, in the end, teamwork.

So here are the driving questions your team should answer in this type of work:

1. What are the values and principles you want to promote in your team? There are a lot to choose from in all the agile practices!
2. What are the values and principles that give you most of the value in improving the team?
3. How do you set up a feedback mechanism to enable your self-organising teams to improve themselves based on those values? Hint: solution focused scales and retrospectives!
4. How do you set up a feedback mechanism to enable your self-organising teams to reflect on what values and principles they need to work next? Hint: retrospectives again!
5. What are the values that are instead damaging the team and should be dampened?

By raising awareness on values and principles, we are effectively stimulating an evolution of the emergent identity in a direction that will eventually support an effective agile implementation.

P.S. Be aware values work is not for the faint-hearted and it's not easy: consider that conflicts can be re-conducted to a values disagreement!

Coaching Teams, remotely

So the definition of done of a Scrum team is sick and you, dear agile coach, are intervening on the team to get them to fix it. Easy, isn't it? Either you tackle the issue during a retrospective or on in ad-hoc discussion, point out the symptoms, ask the team how they plan to fix it, let them define the goals and a plan to achieve them. Sure easy, if you have the team within reach!

As part of my coaching activities I sometimes have ScrumMasters and Product Owners as customers that come to me individually: one ScrumMaster came to me telling me the definition of done in his team was obviously not working since several sprints. Major symptom was a high number of stories coming back into the backlog in the form of bug reports.

He addressed the problem during the retrospectives, but the team either ignored him or proposed solutions that did not address the root cause of the problem. There was no conflict among them, in fact the team spirit was fairly high, but still my client was not able to "move" the team in the direction he deemed useful. On the contrary, they ended up layering more processes on the top of the previous ones, adding overhead and effectively decreasing the average velocity.

I had no jurisdiction on the team. In fact, they did not even know about me at all. I needed to trigger a change in the system's behaviour: what could I do?

The experience made in family therapy by the likes of Virginia Satir, Steve de Shazer and the Milwaukee's Brief Family Therapy Center is that, in fact, you don't need to have the actual subject showing the symptoms present in a therapy or coaching session in order to inspire changes in a system, it is sufficient to search for differences - new behavioural options that have the chance of breaking the spiral of cause-effects that brought the system to such a dysfunctional situation. So there I go...

Through the standard set of systemic questions I could not expose a relevant difference to work on. In fact, we worked on those topics a few times already. So I decided to use a systemic constellation instead.

A systemic constellation is a tool to create a view of the system - i.e. the people involved in the specific situation but also goals, impediments and any actual or abstract entity that might be relevant in the discussion - by using representatives - i.e. either objects or people. In this case, not having additional people available, we used my objects, in particular my coaching army:

The client is responsible for putting the representatives in the position his perception suggests, thus creating the so-called problem scenario:

[Note: TM is a team member, all developers in this case. The arrow points in the direction the representative is "looking"]

In this situation the representatives are asked appreciatively about their perceptions. In case the representatives are objects, as was the case in this example, the client is asked to put himself into the role of the representative and talk in its stead. This allows for a quick and efficient exploration of the point of views of all the relevant parts of the system, generating an insight that would be otherwise very difficult to gather.

From there, the coach, together with the client and - if they are persons and not objects - the representatives, transforms the represented system into a solution scenario, a situation where the problem is solved. The whole process is strictly solution-focused in order to let the client describe a solution that is compatible with the system's constraints.

It took almost two hours to reach this scenario:

What happened there? As an observer of such a constellation it is difficult to appreciate the full details of what the client perceived through this exercise, especially not knowing personally the members of the team. My reading of the situation is that the ScrumMaster was a bit too obsessively trying to make the team change the definition of done and, through this, the established testing habits. As a result the team unconsciously blocked his efforts, though remaining very nice and friendly with the ScrumMaster. So while there was no explicit conflict to be detected, the system shunned the ScrumMaster's opinions.

Using the things he learned during the session the ScrumMaster changed something in his approach to the team, mostly a different way to interact with them and being in general more supportive in all the Scrum Team's activities. This caused the team to become more receptive to the ScrumMaster's suggestions and, within a few days from the constellation work, brought the team to accept the idea of the definition of done not working properly. At the next retrospective the subject was finally on the agenda and changes were planned. Three 2-week sprints later the team is still improving its regression test system - technical root cause for the problems - and the amount of stories returning back is diminishing. At the same time they are removing from their processes all the useless procedures they added and the velocity is improving.

Lifetree

Here's a metaphor I use often when coaching people. It is called the lifetree and I use it as a tool to raise awareness of the resources of the past and the possible futures and to identify strengths and weaknesses and learning paths. It has a lot of applications in career coaching and in coaching in general. In agile it can be used with fresh Scrum Masters and Product Owners who need to understand how to cope with their new roles. This metaphor is intended to give the opportunity to the coach to ask solution-focused questions under a consistent umbrella, an overall framework for the session. Imagine you are a tree!

A tree has roots, that represent your past.

Each root is important: it is an experience you made in the past, contributing to your current situation and it is a resource you can use for your future. You might decide to build on it or not, but it is there. You cannot change it, but you can decide when and how to use it - if at all.

And you have a lot of different roots that are feeding you: parents and relatives, friends, educations, previous jobs and colleagues, ...: just stop and think for some minutes about them. You have collected a lifelong richness of experiences that brought you to where you are and can indeed help you in the future.

• How long are the roots?
• How thick? How solid?
• On what ground are they growing? Are they stable? Are they nutritious?

A tree has also a trunk: this is you now, with the strength given from your roots!

• How is the trunk? Small? Large? Stable? Flexible?
• How should it be different?
• What difference would you need in the roots to have the trunk you want?

A tree has branches and leaves: these are your possible futures and choices and directions you will choose.

As in any tree, what grows on top comes from what's on the bottom, and you're your own gardener:

• What could you grow from your roots?
• What other roots would you need to grow something different? And what would this something different be?
• Is there any branch bigger and richer than the others? What makes it so?
• Is there any branch that is dying? What is this branch missing?
• How are the leaves? How should they be instead?
• What fruits do you want? Are they already growing? If not, what's missing? What needs to be different?

There is an amazing amount of explorations you can do just looking at your roots and your branches!

In order to fix the learning, ask the client to draw herself as a tree!

Though this is a tool regularly used in systemic coaching in Germany, I curiously could not find any reference in English: if you have any you're welcome to post it here. For German speakers, here's a description of the method.

Evolving Identities

In the previous post I was mentioning that a company culture is anyway emergent and what emerges cannot really be predicted, but can be influenced in many different ways.

Here's one way to do that, which I found very useful when working with agile teams.

A big part of the agility is based on values and principles, be it the XP ones or the Agile Manifesto ones, or the lean ones. But how are values and principles playing together? How do they exactly help us?

Values, principles and beliefs are actually interworking together to define the identities of individuals, teams and organisations. As a change agent in an organisation, one of my objectives is to support a common identity in the teams (even better in the whole company) as this will create alignment, agreement and, in the end, teamwork.

So here are the driving questions your team should answer in this type of work:

1. What are the values and principles you want to promote in your team? There are a lot to choose from in all the agile practices!
2. What are the values and principles that give you most of the value in improving the team?
3. How do you set up a feedback mechanism to enable your self-organising teams to improve themselves based on those values? Hint: solution focused scales and retrospectives!
4. How do you set up a feedback mechanism to enable your self-organising teams to reflect on what values and principles they need to work next? Hint: retrospectives again!
5. What are the values that are instead damaging the team and should be dampened?

By raising awareness on values and principles, we are effectively stimulating an evolution of the emergent identity in a direction that will eventually support an effective agile implementation.

P.S. Be aware values work is not for the faint-hearted and it's not easy: consider that conflicts can be re-conducted to a values disagreement!