FlexFlow - Flexible Thoughts for a Complex World

On refactoring and the organisation

I often get questions about how to approach refactoring at the cultural level, i.e. how to promote it in the organisation. This post is an adaptation of some advises I gave to a customer of mine…

The best way is to have refactoring done as part of the story development, so during the sprint. It's just there. It's a way to keep technical debt low and it's everybody's job to do it. There is no reason to make a big fuzz around it as each refactoring cycle lasts a few seconds to minutes.

Of course reality is different and more often than not the team does not have the care for good quality software they should have.

I would distinguish between two cases:

1. The team does not understand that the software has a lot of technical debt - and this includes also the case of not wanting to understand… :-)
   In this case some metrics may help: by measuring the complexity in the code it's possible to show how complicated the code is and how difficult to change it becomes over time. Another option is to discuss with the team very concretely what to do to speed up the development.
   It is a ScrumMaster's job to raise awareness in the team about these topics. Some strategies:
   • Work on a story trying something new to keep the technical debt low. For example have a code review with somebody, do some pair programming, use some metric tool. Here the ScrumMaster is a role model, breaking the pattern "it's easy for you to say to do that and not to do it yourself"
   • Subtly but constantly raising awareness. Promote good quality code as much as you can (but… avoid to be thrown out of the team because you're getting on their nerves! :-) )
   • Use some time during the sprint to discuss these topics. The retrospective is the natural place. Important is to have the team committing on some clear improvement goals and confront them with the goals at the end of the next sprint. No clear commitment usually means it won't be done!
   • For these strategies there might be people in the team who are more sensitive to these topics than others: get them on your side and start doing something with them
2. The team understands the issues, but is unwilling to take actions In this case the problems could lay in individual blocks or they could be systemic around the team, and it will be your job to understand them.
   Examples of individual and team issues:
   • Fear of not being able to do the job properly
   • Fear of being put under even more pressure
   • A latent conflict inside the team that prevents implementing more collaborative practices
   • Misalignment with the organisational goals
   • Generic de-motivation and de-engagement - though usually the cause for this is systemic.
     Examples of systemic issues:
     • Project pressure (it's probably problem #1)
     • Blaming organisation
     • Organisational goals not properly communicated
     • Organisation is forcing local optimisations on the team (metrics, pressure, …)
     • Non-supportive organisation (why should I do X if they don't care about it…)

Once you have diagnosed what this could be, try changing something you believe it might help and check whether the results are what you expect.If not, try with some other ones - it's anyway a complex adaptive system you're dealing with!

The important thing is… patience. Though it might seem just a matter of engineering practices, refactoring is also a very deep cultural change and as such will take a while to develop.

"Scaling" the team - part two

In the previous post I introduced you to Solution Focused scales and how they can be used in a one-to-one scenario. Now we'll extend this to a team context, but first, here are some tips… Tips on using scales A constructivistic approach is important also when using scales: whatever numbers the client chooses, it must be fine for you as coach. We are working in the client’s reality, so if you believe the client's 6 is actually a 2 do yourself and the client a favour and don't say it, both verbally and non verbally! You might - and should, actually - question the client’s assumptions to anchor what [s]he is saying to reality, ask about the feasibility of the various steps up the scale, check the ecology of what the client proposes, but avoid adding content, observations and comments on what the client says. The NLP Meta Model is your dear friend here, as well as more sophisticated rhetoric tools and your attention skills will be very much used in this part. This is actually the part of the whole solution focused approach that, IMO, requires the maximum training and experience to work effectively.

It follows from what I just wrote that scales are subjective and subject to change: the client might change his/her mind at any time and it typically happens between sessions, where the 8 of the first session becomes the 4 of the next one, because in the meantime the client has understood much better what is the goal and what [s]he could reach. And it's perfectly fine for me if that happens. I like to check what happened that made the client change his/her mind, but I'm perfectly fine with that!

With a team

Working with scales in a team is in principle the same as the one-to-one case, just asking each team member to rate a certain aspect on a scale from 1 to 10, then where they would like to be, … but with a few relevant differences:

• The ratings could vary a lot. I had situations of some team members rating a certain parameter as 3 and others as 8. This might trigger some analysis of why there is such a difference, but, in fact, this is irrelevant. Actually this is exactly the case where it is important, as a moderator, to give equal importance and value to all opinions. Sometimes a stronger moderation is required to avoid some team members to start arguing on the validity of the ratings. As a moderator, your role is to affirm and defend each rating as being a valuable opinion.
• You can still ask the same questions as in the one-to-one case, though asking about the +1 rating could require individual answers. It's still +1, just the process is done individually or in smaller groups.
• The level to reach on the scale with the problem solved can also be different among team members, and that's ok as well, it's just different opinions, all worth the same consideration.

Using scales requires some practice, especially when using them as part of a group process, but the results you could achieve are well worth the effort. Waiting for your feedback on this!

"Scaling" the team - part one

No, this post is not about increasing the size of your development team, but about how to establish some measurements in your team - typically during the retrospectives, but not only - to support continuous improvement: let's talk about Solution Focused Scales.

I already discussed this technique in my Solution Focus presentation, but listening to how people use this information, I realised I did not stress a few details that are actually quite important for a proper implementation of the technique.

We're using scales when we ask somebody - or, as it's usually the case in agile, a team - to rate a certain aspect on a scale from, typically, 1 to 10, where 1 is the worst it can be and 10 is not improvable at all. At first sight this might look similar to the Team Radar described in the book “Agile Retrospectives”, but it's actually a much more powerful instrument. Let's look at it in detail and let's start first with the single-client case, i.e. coach and client.We'll expand this to a team on the next post…

One-to-One

There are three important things to discuss when using a scale:

1. On a scale from 1 to 10, where are you now? / how do you rate [something] / …
   This question establishes the starting point for our measurement, but it's also the opportunity to value what the client has already done. No matter how rotten your company might be, still you cannot randomly pick the same number of people from the street and replace your team with them. I rephrase: no matter how bad the situation might look like, still you are doing something that will be difficult to replace. This something has to be valued to support the self-esteem of the client, but also because in what the client did there are also things that worked well and that we don't want to lose.
   The typical question that follows the rating is some variation of "what did you do to reach this value?". The reply of the client will usually stress what worked and should be considered also in the future.
2. Where should you be on the scale to have solved your problem?
   This sets a wish: we don't know whether the client will ever reach that level and whether it's realistic at all, but this answer sets the bar.
3. Scale up
   Now, iterating from the lowest rating, we ask the client how to reach one level higher on the scale. There are several options here, though the first question has the goal to move the client to the solution state: "How would you recognise that you have reached level n+1?". From this point on it's a matter of exploring the differences compared to level n: "What is different?", "How would others recognise it?", … - the whole arsenal of systemic and circular questions, as well as everything else you can think of, is available (but, the question about "why" is still one to avoid!)

And then you continue like this until the client has reached the wished level.

In the next post I will describe some more tips on using scales and how to use them with a group: stay tuned!

There is no resistance in coaching

One of the concepts I hear many colleague agile coaches talking about is the concept of "resistance" of the client. Typical sentences are "he is resisting the agile transition" or "I talked to her about X and she resisted the proposals I made". Now here's one thing that is important to consider: there is no such thing as resistance, there is just bad communication!

This is actually not just my statement, but also an axiom in neuro linguistic programming: "There are no resistant clients, only inflexible communicators". Let's see what it means…

Resistance is an abstract word. You cannot buy 1/2 kg resistance in a supermarket or any other shop (unless you consider electrical resistance, but those are not relevant, of course). Sure enough you know that, but the implications are important: resistance is linguistically called a nominalisation. We are making an [abstract] word out of a process: "resisting", verb "to resist". Like any verb, "resist" needs a subject and in this case also an object and possibly complements.

WHO resists WHOM HOW WHEN WHERE WHY...

The important parts are the subject and the object: there is no resistance unless subject and object interact in some way and the resistance happens only as reaction to some sentence/concept/behaviour/...

So resistance is the product of an interaction where, in the case of agile coaching, there is the client, but also the coach. When we say "the client resist", whereis the coach's responsibility? In other words, saying your client resists is a lazy way to give the client the sole responsibility of your failed communication!

I actually believe what I wrote in the title: there is no resistance in coaching. When the client is not listening to me it's my failure in communicating and interacting with him/her and it's my responsibility as change agent to find different ways to pass the message in a better way.

Some things to consider:

• Have you understood the client's interests, needs, values, responsibilities, …?
• How was your non-verbal communication? "Resistance" is a sign of defence, so how did you attack?
• Communication is a systemic phenomenon, so don't limit your analysis of the situation to THE communication you're having right now: you might have seeded the responses you're getting now sometimes even months before or with a different person
• Sure, you might have been misunderstood: it is still your fault and it's your job to ensure the client understands the message in the way you sent it
• Sometimes you need more time than you expect for a message to go through. I perceive in many agilists a sense of impatience when they cannot get results here and now, but human processes and changes might need a long time [and sometimes be incredibly fast for inexplicable reasons, but that's another topic…}
• Your responsibility as a change agent is to have the necessary flexibility in the way you communicate with your client and the capability of understanding the client at all the different levels they are communicating with you

Yeah, right, it's not an easy job, but if you practice you might also say "there is no resistance in coaching!"

The best way to coach a team is...

…to coach its individuals one-to-one!

Contradiction? Well, some time ago I thought so as well, but…

Over the last years I had a few clients where, because of some constraints in the setting I was working with, I needed to "speed up" with the coaching program and "deliver" a high-performance team faster than I usually did.

Learning the mechanics of scrum, kanban or whatever we agreed to implement has never been a problem: the people I worked with are usually pretty smart and can pick up the concepts quickly, but the team building process was taking longer and, well, I just did not have so much time available.

Now the typical feedback I got from the people I was working with is that I am quite fast in reaching results, but there was the need of even more speed, so I started to apply more and more one-to-one coaching techniques as they are targeting directly a change in an individual instead of "averaging" the intervention through a group process.

To my surprise the teams started to grow an effective teamwork quicker than I've seen in the past. So I tried even more with other teams… and it kept becoming faster!

So the sky is the limit? Not really: to work in a one-to-one setting it's paramount to understand very well the dynamics of the team and of the organisation. And it also means to be able to handle an emergent process that might in some cases reach explosion levels: I never had a team "exploding", i.e. developing some destructive conflicts, but I reckon I came close to this a couple of times.

Also it's very important to understand the implications of the intervention on individuals and what the systemic effect could be. This is definitely not rocket science since a team and an organisation are a complex adaptive system. I's not possible to predict most ramifications of what could happen as a consequence of a certain action, but I found out that caring for the ecology of the interventions as well as being able to establish an effective rapport with the clients makes the risks apparently quite controllable.

But… what if I get resistance? Well… in my model of the world there is no resistance - more about it in a later post - but there are definitely some individuals that are not open to this type of work. The fact is that it's actually not even that important: the team is a system, so the people there influence each other. By working with the willing individuals there is a measurable impact on the whole system. I gave an example in a previous post, in fact.

Steve de Shazer and his colleagues at the Brief Strategic Family Therapy in Milwaukee used to intervene on dysfunctional families even when the perceived "problem" in the family was not present because this person was not willing to work. Despite this they achieved significant results.

The reason why this way of working is so effective is that in a one-to-one setting there is a much bigger "arsenal" of tools that can be used, tools that enable change at a much deeper level than what is achievable in a group setting, especially when somebody in the group does not want/like/accept to work. Also the people who are available for a one-to-one coaching are the most motivated to change the situation, and this usually allows for a much "deeper" type of work anyway.

So I usually work with Scrum Masters and Product Owners, as they are the candidates to take a leadership role in the team, but sometimes also some developers realise they need external help and accept my support when I offer it.

At the organisational level I usually work with supportive managers who understand they have to change the way they work. Also in this case, the work done at that level changes their way of interacting with others of just a bit, but this bit usually generates new options and alternatives to the usual organisational communication paths.

Agile mythology?

Last November I presented at the Deutsche Scrum the first version of my new presentation "Debunking Agile Myths". The core message of the presentation was to show that many of the things we believe in the world of agile are based on… ehm… nothing, actually!

Surprised? So was I when I started checking the scientific validity of what we do. Already non-agile coaching is often a quite fragile discipline, where quite a lot of the validation of the methods is, in fact, just anecdotal. Yet apparently also in agile we are using several dubious sources and build on those, with sometimes very unfortunate results.

I leave you to the presentation for the details of some of our myths. Suffice to say I have enough material for probably five presentations of this kind and it is growing daily. The message here is: let's please scrap all those books that are usually filed in the "self help" and "management" sections of the various bookstores (and at least 60% of the ones filed under "psychology"!) and let's go and look at the actual scientific research: there will be surprises, but we'll become much more professional in what we do!

Debunking agile myths (with references) from Pierluigi Pugliese

Motivation: cause or effect?

In a conversation during the last agile coach camp Germany I was reminded of something I see often in agility: motivational interventions. Most, if not all, agile coaches use them in one form or another: a workshop moderated with a pot of energy on their side, a training where the reasons why agile is what it is are many times evangelistically explained with the goal of inspiring the participants, various games where motivation is either the goal itself or at least an important by-product.

Yet, when I make a systemic analysis of actual organisations, motivation would be more likely an effect of other aspects rather than a cause, i.e. there are many causes for motivation (or for the lack thereof, of course), but the circular causality around motivation impacts way less of these causes. In the diagram below, A, B and C influence motivation, while motivation influences only C.

Yet, many coaches do work with motivational coaching interventions and they do work... Hmmm… What's going on here?

Let's consider circularity: in a [complex] system cause and effect are blurred by what is called circularity. This means that some situation X, that seems to be an effect, is actually a cause of something that is the cause of X: a loop, usually self-reinforcing. This is why directly influencing motivation seems to work: you get to influence positively many other aspects of your team. BUT you are still not removing the other reasons for a lack of motivation. This means that, if you're lucky, the positive spiralling upwards you create injecting motivation will overcome everything else and your team will effectively work in a new way. But more often than not, as soon as you stop injecting motivation the other causes of demotivation will keep working against you.

Ever heard that, as soon as the agile coach was gone, nothing worked anymore? That's why!

On the top of that, when you are "motivating people" you are, in fact, extrinsically motivating, i.e. not exactly the motivation you want to promote in the team: try to get intrinsic motivation instead!

Other options?

• Look at the causes of demotivation and address them. As Herzberg would say, put hygiene in the workplace!
• Change the system constraints in order to favour intrinsic motivation and let the team grow
• Do a cause-effect analysis and understand how the various variables are related. Just be aware that what you found is an approximation of the real thing and that complex adaptive systems like teams are not predictable (as often a cause-effect analysis seems to suggest), so please remember to work with small probe-sense-respond safe-fail experiments

P.S. From this post on, this blog will also appear on the improuv blog page.

Change, Change, Change! - Workshop at XP Days Benelux

Here are the slides I presented today at XP Days Benelux in Mechelen together with Dirk Lässig (@djlaessig): Change, Change, Change! This time in a workshop version, where the participants learned to use these conditions to design change.

For a detailed description of what this is about, please refer to my previous post.

Change, change, change! workshop xp days 2011

View more presentations from Pierluigi Pugliese.

Innovation Needs Waste! - Workshop at XP Days Benelux 2011

Here's a new post on design thinking. As promised in my previous post, some more details on what the presentation at XP Days Germany together with Dirk Lässig (@djlaessig) was about. In fact, we just delivered the same material in the format of a workshop at XP Days Benelux, where, rather than talking too much, we let the participants experience what design thinking could be. Here are the slides presented:

Innovation needs waste - XP Days Benelux 2011

View more presentations from Pierluigi Pugliese.

While agility has improved the way a product is being developed, design thinking addresses what comes before the IT department: how do we get innovative product ideas? How do we envision products that our customers will love and that will have a margin over the competitors?

You might be tempted to answer by simply saying "brainstorming", but, in fact, design thinking is much more. Let's have a deeper look into it...

First of all, design thinking is a body of knowledge and, I would say, an attitude to developing a product. As a body of knowledge it collects ideas and methods coming from different disciplines and puts them into practice for the purpose of designing innovative products. In this sense it’s similar to the way agile puts together tools and methods used in software development in the past and makes them work synergistically to improve the way we develop software. While looking into design thinking you will definitely recognise several things you have seen in the past. It's their systematic usage in an innovation-focused environment that will bring out the full power of these methods.

Also it's an attitude. It's a way of living product creation as a continuum of ideas that flow through the development, a few of them making it to the end stage and being released, though the vast majority of them being canned along the way: a waste of ideas that is needed to develop a truly innovative product.

In order to do this, the central part of design thinking is what is called "Ideate", i.e. the generation of ideas. Traditional brainstorming will help here, though there are also other creativity techniques that might give also better results.

After having generated many ideas, the selection process starts: how do you "converge" to a few options to try out? The convergence process continues also with getting customer feedback on the first prototypes to refine the idea until it will be produced.

The major difference here is that the whole organisation is involved! In many companies I've seen, the feedback process involves only the engineering department, i.e. the concept is envisioned by somebody before it can be checked whether it’s working or not. In some cases the feedback goes back to the product visionaries, but only to be adapted and not to be radically changed.

What if the feedback cycles used in agile were also applied to product creation? What if a product idea gets re-evaluated, re-discussed and goes again through a creative process, taking into account all the feedback collected through the development and test phases it went though? Will the product be better then? Sure enough it will! Will it cost time to do so? Yes, it will cost time, and it's the price to pay to achieve a truly mind-blowing product!

Innovation needs waste!

Here's a short post just to publish the slides I presented today at XP Days Germany in Karlsruhe together with Dirk Lässig (@djlaessig): Innovation needs waste.

More on this topic in a future post...

Innovation needs waste - XP Days Germany 2011

View more presentations from Pierluigi Pugliese