FlexFlow - Flexible Thoughts for a Complex World

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!

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!

What is emerging today?

One thing to consider when you start your next organisational improvement campaign, be it introducing agile, improving your agile practices or, in fact, any sort of change you want: you are not in control of what happens. You never were. You never will. No matter how much the official org chart of your company claims you are in a control position, you are not.

The concept of an organisation as hierarchy as we know it is not the natural "way things are" but rather a product of our perceptions on how a company should work. It is, in fact, very much based on the newtonian-cartesian way of splitting up a big problem in small ones so they can possibly be solved easily.

In the same way a mirror broken into pieces does not reflect your image that well, also a compartimentalised organisation is probably not likely to give you the best possible setup to serve your customers. (The mirror metaphor is actually from Peter Senge's The Fifth Discipline)

In an organisation - better, in any social system - there are a lot of informal structures all co-existing and overlapping: from the network of people playing football together to the one who likes to hang out for a beer. These are, as well as the official company hierarchical lines of communication, all forces that compete asynchronously and build a company culture. Sure enough, the org chart is a very strong influencing structure, but not the only one and not necessarily the most powerful.

The end result of this interplay is, of course, very difficult to predict. Culture is always an emergent feature in a system, always evolving. What emerges, however, cannot be controlled.

The good news is you can influence it in millions of different ways. Finding out those ways is what today's leadership is about!

P.S. This post is dedicated to the memory of all the companies ruined by a non-systemic and complexity-unaware organisational development initiative.

The whys of why not why

During my presentation about Solution Focused work in Agile at XPDays Benelux I stated that asking "why" in coaching can be dangerous and should be avoided.

In a community where the Five Whys is actually one of the premier methods, I knew I was opening up for a lot of discussions. Exactly this happened and the discussions were good ones.

The purpose of this post is to add some more information on this controversial topic.

1. Agile coaching is also coaching

As I stated in a previous blog entry, agile coaching is not just coaching. It's more: an agile coach is also a trainer, a mentor, a moderator, a facilitator and whatever role is actually needed to help a company in becoming agile. In fact, an agile coach shows all his/her agility in doing this continuous role shift, making sure the customer gets the best out of the work of the coach in each situation.

As such, there are situations that are not coaching-related where the question why has a place. In coaching, however, and especially when using a solution focused approach, the question "why" need to be used carefully (see more below and here)

2. Solution Focused is an approach to coaching

Here's the real deal: what do you really want to find out when asking questions? There are several objectives in coaching (intended as the art of driving a customer through a process without providing content) and the approach used for each of those is different. For example, when trying to elicit values, the typical procedure involves exactly asking "why": "Why do you want to change the Definition of Done?" - "Because we need to improve the quality of our deliverables" (Quality in our deliverables is a value).

Solution Focused instead is about envisioning solutions instead of searching in the past, and here's where asking "why" can be dangerous: the question "why" implies a rationalisation process that invariably looks in the past. This is clearly evident in a question like "why did you do X?".

In a question like "why do you want to achieve X?" - apparently solution focused - the issue is more subtle: the answer to such a question is usually "because I want to avoid Y/improve compared to Y/...": defining the future in terms of differences from the past is a limiting view on the available options compared to first envisioning a future and then defining what's different compared to the past.

3. Blamed by whys

The question why implies also a request for justification. We ask misbehaving kids why did they do that, we ask people we love why did they do something that hurts us. No wonder the question why is loaded with an emotional intensity not present in the other types of questions.

4. One more reason why

"Why can't you just talk to your colleague?" This is a very typical question in almost all the workplaces I saw. The reasons are usually all but rational and it doesn't really matter whether they are real or not. The fact is, as soon as we are asking why we are eliciting these reasons and bringing them into consciousness: "Because last year during project X he made Y" is a typical answer. How does this answer help exactly in solving the problem? Well, it doesn't! How does this answer help in off-loading emotially the situation? It doesn't either, actually it strengthens all the bad feelings related to the situation!

5. Why do we need why

There are places for asking why: when eliciting values, as shown before, but also when searching for the deeper meaning of something that happened in the past.

Why searches in the past, and if this is what we want we could definitely use it.

In solution focused work though, it is not what we want as we focus on the future.

6. Why there is (almost) no need for it

Anyway, the question why is usually a simple and simplistic way to ask about something. In fact, apart for the usages I stated above, it can easily be replaced by other questions that give us a richness of details that why cannot, provided we use them skillfully to get the information we need.

Let's take the example above: "Why can't you just talk to your colleague?"

Alternative questions would be for example:

• "What do you gain not talking to your colleague?" - elicits the deeper win for an action
• "How exactly will not talking to your colleague help you achieve your goals" - elicits a possible strategy behind a behaviour
• "When do you expect your behaviour to change?" - assumes the situation can change and finds out what are the conditions for the change

And so on: there are several alternatives to the question why that allow a more targeted retrieval of the information we want. So how could we ask "why" in a better way? 7. Creative whys

Serge Beaumont has developed a great technique he uses when coaching Product Owners for linking user stories to business value. In this process asking "why" is in fact, the central technique. Contradicting what I wrote above? Actually not: when doing so, he is actually eliciting reasons why a story should be done at all. If, by asking why, the PO reaches one of the stated business values then great, if not, either the business values need to be extended with the newly found reason or the story should simply be ditched from the backlog.

By asking why he is effectively forcing the PO to keep the stories focused to the stated value for the product: a very creative way to force convergence to the product goals!

8. Emotionally why

As children we used to ask why when discovering what was around us and we are still doing it in this discovery process that is our life. As children we needed a simple question to help us making sense of the world, because we didn't know what to search for in the first place. As adults we have also other tools to use, so what advantages do we have in limiting ourselves to using just "why"?

Solution Focused Coaching in Agile

Last week I was at the XPDays Benelux conference where presented a session about Solution Focused work in agile.

The session was attended in the morning of the first day by about 40 people and, as there was a lot of interest around it, I re-made most of it in the evening for an additional 15 people. I was pleased to see so much interest around coaching techniques in general and how agile coaching is already something mature in Benelux.

The slides of my presentation are available on the XPDays website and also on slideshare:

Solution Focused Approach To Agile Coaching

Now some more words about Solution Focused coaching: this is actually a concept coming from psychotherapy, in particular from the work of Steve de Shazer, Insoo Kim Berg and others at the Milwaukee's Solution Focused Brief Therapy Center. During the eighties they recognised, during their daily practice, that analysing problems, i.e. the freudian approach, does not help in finding the solution of those problems. To know that the origin of a mental disorder comes form, say, a child abuse, does not give any hint on how to "fix" the problem.

De Shazer and his colleagues found afterwards a philosophical basis of what they were doing in the work of Ludwig Wittgenstein, in particular with the perfectly synthesized sentence stating that “All of the Facts belong only to the Problem, not to its Solution”.

Analysing the facts of the past can be a powerful mechanism to understand what happened, how it happened and what lead to the event. But finding a solution requires turning towards the future and being able to identify, among all possible future states, one that solves the problem, and also one that is reachable.

Some examples, related to the daily life on an agile project:

1. There is a conflict between the Product Owner and the Team. Knowing the fact, that this problem comes from a time several years ago when the PO and a team member had an interpersonal issue on another project, might help in reflecting on the past and expose the conflict, but all this facts don't help in reaching a solution. It is much better to discuss instead how the relationship between PO and Team should be in the future: what can they do to, how should they behave to create an effective co-operative environment.

2. The Team did not deliver software with the proper quality in the previous iterations. Sure, understanding the reasons why this happened might give some hints about a possible solution, but another - and in my opinion more powerful - option is to simply envision the team delivering and understanding what do they need to do differently in order to achieve the wished quality.

The keyword here is different: what do we need to do differently in order to achieve our goals? In order to find these differences between what we do and what we should do we need to envision our future state and, with that state clear in mind, work out the steps to reach it.

The central lesson of the Solution Focused work is, in fact, to take our clients out of the problem state, where they remain stuck in the petty analysis of what was, and bring them to a future state where the problem is solved and let them identify the differences in comparison to the problem state. Another added value of doing this is that thinking about "solution" we are in a very resourceful state, as the problem is not there anymore, and we are free of its emotional weight. Blame, for example, has no place in a solution state, as the problem is simply gone: think about how much easier some meetings could be without the search - implicit or explicit - for somebody to blame!

During my presentation I also introduced the participants to the concept that the question "why" - because of its implicit past-oriented connotation - should be used sparingly. This provoked some interesting questions and discussions. Unsurprisingly, actually, considering than one method used heavily by the agile community is called "5 Whys". I will address the topic in a subsequent post to give it the space it deserves.

Summarising: Solution Focused work is actually a language, a way to talk in the future rather than in the past. Is also the attitude of looking into the future in search for a solution instead of digging in the past and identify blame: a very important attitude indeed for an agile team!

Selected Bibliography:

• Steve de Shazer Keys to Solution in Brief Therapy
• Steve de Shazer Clues
• Steve de Shazer, Yvonne Dolan et al. More than Miracles
• Jeffrey Guterman Mastering the Art of Solution-Focused Counseling
• Peter de Jong, Insoo Kim Berg Interviewing for Solutions
• Insa Sparrer Einführung in Lösungsfokussierung und Systemische Strukturaufstellungen