Quantcast
Channel: The Blogging Terrier | Den bloggande terriern
Viewing all articles
Browse latest Browse all 24

Thinking and Doing Together

$
0
0

For effective organizational change, consider working with both the mindset (the thinking) and the behaviour (the doing). Let people try new ways of working through mindful practice, but also let it be informed by theory. Learn by doing, but also invite people to consider other beliefs of what good looks like. What we do and how we think and feel are deeply connected.

Thinking & Doing

Thinking First, or Doing First?

It is logical to think that we will start behaving differently as soon as we start thinking differently. This seems right because we (falsely) believe that our decisions are rational and our conscience is in control of our bodies1. In practice, however, this approach leads to problems. It is just very hard to make people change their way of thinking without them actually doing something. How many times have you changed your mind just by being told how to think?

I hear and I forget. I see and I remember. I do and I understand. – Attributed to Confucius

We now understand that the way we behave can have a strong effect on how we think and feel. Research shows that we feel better just by physically raising the corners of the mouth by putting a pencil between our teeth2. This is also how Toyota approaches change. Not through pencils but their outlook on change. They teach people a new behaviour. Based on the results and reflection through active coaching, the mindset follows. People behave themselves into a new kind of thinking.

Good think. Now go do something! (photo by Juan Rumimpunu on Unsplash)

There is a lot of wisdom in learning by doing, but it does not explain why so many Agile adoptions are full of meaningless rituals and fake agility. Should not teaching teams how to follow the Scrum meeting practices change the way they think about their work and their collaboration? In my experience, this is not the case. I have seen many mechanical process implementations with little understanding of the purpose behind the mechanics and the negative effects are considerable. Is learning by doing really enough?

A Tale of Two Teams

Let’s visit two imaginary teams at work.

Team 1: Imagine a scene at the office. It’s time for the Daily Scrum for the development team. Slowly, they saunter into the meeting room and take their seats around the big table. The manager opens her laptop and starts the meeting. From the Jira board we can see the team has a lot on their plate. There are lots of what they call “tickets” on the board and many have been worked on for weeks. Everyone on the team is responsible for their own tickets. The meeting proceeds with the manager asking each one what they’ve done since yesterday morning. Everyone answers with the number of their Jira ticket, for example IH-5316, and that it proceeds according to plan. Manager asks what they will be doing today. Answer: Keep going on their tickets. Finally, the manager asks for impediments. The team sees no obstacles. The meeting ends in under 10 minutes. Everybody leaves the room quickly, happy that it’s over. One of the developers turns and whisper to a colleague: “Agile sucks”.

Team 2: Imagine a scene at another office. The team gathers quickly for their Daily Kickstart. This week, the DevOps engineer Louise will be facilitating the team meetings. Some current stakeholders join and gather up close to listen. The team reviews their team whiteboard, containing a lot of information. We see a few product changes and one improvement, all formulated as experiments, in progress. Louise starts by asking everyone for energy level today, as a number 1-5. One of the team members volunteer a low number due to a stressful morning and gets support from people standing next to him. Louise lets people talk but is sure to maintain the flow of the meeting. Divergent threads are asked to pause until after the meeting. They start talking about an experiment they released last week. It doesn’t really generate the outcomes they’d hoped for and needs a tweak. They talk about several other experiments with a focus on flow and obstacles to it. Everyone gets to talk and everyone is heard. At the end of the meeting, today’s priorities are clear to everyone. Martin, one of the frontend specialists makes a pun that makes most team members cringe but also smile. The meeting is over in 10 minutes.

These examples may be a bit exaggerated but only slightly. I have certainly seen all of these behaviours in different contexts.

It seems obvious to me that the second situation is preferable. The second team shows much more joy and engagement. I strongly believe that this team will also create better outcomes and more value for the customers. But both teams followed the Scrum recommendations. In fact the first team followed standard Scrum very well. Yet, the experience, and probably the results, of the first team was much worse. What is causing this difference?

I believe these differences can be traced back to the knowledge of the team members, their attitude to their work, and the team working climate they have created. The second team understood the purpose of the Daily Scrum practice and could harness its power and related practices wisely. They had assumed ownership of their ways of working and shaped them in a way that suited them. They also nurtured their relationships and created a safe and joyful working climate. An agile mindset combined with extensive feeling of ownership.

When Doing Doesn’t Influence Thinking

My point here is that the first team will not turn into the second team by simply continuing with the Daily Standup. Instead, what you are likely to get is just more resentment. In this case, thinking does not seem to follow behaviour. Some time ago, the team started a new practice but it has not turned the team members into agile thinkers – or even just a collaborating team. Why is that?

There could be several reasons for this. For example, it could be because the results are not impressive enough to lead people to consider changing their way of thinking or that the practices in themselves are not strong enough to influence their thinking. But I think the main reason is this: The way the team approaches the new practice is misguided, not based on Lean and Agile principles. They will never find it valuable and enjoyable the way they perform it so why should they consider it to be a good thing to frequently come together and coordinate the work together?

Many agile practices are social practices, which are sensitive to both individual and group mindset. The practice of a Daily Standup can only be valuable if it is informed by theory and an agile mindset. You need a bit of agile understanding to perform the practice in a productive and valuable manner. And in complex domains, practices need to emerge. Finding good ways of working requires endless experimentation and tweaking. You need to modify it to suit your context, which requires safety and a feeling of ownership.

In these situations, we need an upgraded approach. I believe we need to do both. By all means, practice new behaviours. Do it in a safe space with lots of feedback from peers and coaches. But also teach and invite people to consider new ways of thinking. Let that theory inform and guide the practical exercises. In complex domains, learning and doing are two sides of the same coin.


1This is only half true. Many, if not most, bodily functions are done subconsciously or only inform the conscious mind after the fact.
2See Try Some Smile Therapy, Psychology Today


Earlier posts in the series on principles for organisational development:

  1. Nothing Ever Lasts but Change
  2. Include the People Involved
  3. Start by Changing Change
  4. Think Big, Start Small
  5. Pulled Change: Sustainable Change That Spreads Organically

Viewing all articles
Browse latest Browse all 24

Latest Images

Trending Articles





Latest Images