Do “answers” result into sustainable change?

On a daily basis I see (and read) many posting about agility, scrum and many, many other frameworks, methods, tools and opinions about them. I will take a specific challenge that I have seen quite often in practise and next dissect it. And give you some ideas on how I supported my clients to change it. I even will share my failures on that as well, since I welcome each event as a potential learning outcome. With that I will ask you to think about your own “comparable” challenge, what you do and what you could learn from that, so that you can use that learning next time.

This second episode is basically about multiple clients where I have been engaged in some transformational work. One of the questions that pop up frequently in the discussions about agility, is the question of “they hire us to provide solutions, right?!”

And actually it does not really matter whether you are an employee or just hired. When we were 6 or 7 years old, our ground schools learnt us to provide answers and solutions. Actually I think it is great that you have a lot of experience and knowledge about answers and solutions. Nevertheless, when we enter our client’s space, we – independent of which specific agile role you have – are asked to help them in becoming better in their agile approach. And quite often we are very enthousiastic in giving them all the knowledge we have about that topic.

Let’s take a step back. When we learnt to how to “calculate” in ground school, you could compare the position of the teacher with the position that we nowadays take as agile experts. I don’t believe that the ground school asked the teacher to provide all possible mathematical skills to the children he could think of. Like “Hey everyone, I have here some information on complex numbers, quadratic equations and normalization that you may benefit from”. In this case, it is quite clear that ground school children, typically need to learn about numbers first and next start with simple things like add and distract, before moving on the multiply and divide.

The reason why schools are not simply start dropping information, is because (at least I hope so) schools have thought about the why and the what. The why of a ground school in general is to teach children e.g. basic calculation techniques that are very helpful in your daily life and as preparation for the education after ground school. And for the what, basic calculation techniques are seen as most appropriate to achieve that goal. As a result, teachers have developed techniques (how) to bring that knowledge to children, including a lot of practise by themselves.

Moving back to our agile playfield, I understand the tendency to simply drop all the knowledge you have to our clients. In my experience, sometimes it is helpful to provide your client with a “quick solution” to a specific problem. Unfortunately I have learnt as well, that this quick win is typically not sustainable or not the best possible solution. Quite often people just do what you have told them to do and since they don’t know why no internalization will happen. Or people disagree with the solution, and are going to look for ways not to do it. And with providing a solution, you will typically close the door for people to think of even “better” solutions.

Sometimes I hear people saying that we are in a professional environment and that people are expected to do whatever they have been told to do, right?! Let me give you an example, that this does not work that way with humans. So, suppose that I am your boss. And now I will ask you to grab a pen en keep it in two hands just in front of your nose. Yes, just grab that pen… I will wait a second…

Now I will leave the room. So what will happen? … Most people will simply put the pen back on the table. Do you know why they do that? I believe they do that because they don’t see the benefit of keeping the pen in front of their nose and since their boss who ordered to do so (maybe you are afraid that you will be fired because of not following the orders) just left the room, no specific reason is left to keep it there, just in front of your nose. Actually I think that if a benefit would be attached to that action, like some award, you could have convinced yourself into keeping the just new learnt behaviour.

So quick wins look nice, though are not always the best thing to do. And how do you discover what might be a better solution? Actually, that question is quite easy: thinking about why you need it and what is takes to (hopefully) a good step in that desired direction. Therefore within the agile community, we always talk about outcomes, so what we have learnt about something we did differently. In my opinion, even a step that has moved you away from your goals, is valuable, since you have not learnt that the change you made, is most probably not the right one.

Using this approach has however a drawback: it looks to be a lot slower than the approach of quickly providing answers and solutions. I actually challenge that kind of statements by stating that I preferably help in getting more sustainable and valuable answers slowly than not changing anything at all quickly.

So the learning here is that it is relevant to ask yourself (and others!) to why we need something (our goals) and what is needed to get there, just before jumping into how to get there. Many of the techniques or frameworks in our agile world can be valuable, if they are used as a way to solve the right problem.

My statement is that human beings are complex. And that systems of humans beings (like teams, departments, companies) are even more complex. So the awareness evoked from the example before takes some time to evolve. It happens a lot though that such issues arise, in which you will find out that your client, it may be the whole company, or just a bunch of teams or even a single team, is simply not ready to change.

And of course I could have done some things differently. Even if you are strong in exploring some solutions already before really adequately tackling the problem, people may focus on that one aspect only. Think about not just offering a training, or just individual coaching as in my case. Even with the right intent (it is just an offer), it may be interpreted quite differently, since expectations are not always clearly expressed.

What is your take on that?

Previous post: Agile Mastery