From Agile to Systems Thinking: Lessons on Company Culture

One day in 2010, I realised I was fed up with Agile. I was at the US Agile Conference and for the nth time I listened to people argue over whether everyone should use story points for estimation or not. I’d had enough of these silly repeated debates. It all felt insignificant. I decided it was time to switch my focus elsewhere.

But before we dive into that, I’ll have to give you some background. Bear with me. It’ll be worth it.

I started my career as a developer. When Agile came along, in my case in 2005, I began by studying the technical implications, such as collective code ownership, continuous integration, and automated testing. In a couple of years, I was consulting all around the world, teaching companies about these new technical practices.

When I saw developers at companies failing to write decent code, I felt I was doing the right thing in helping them. If a software company has developers who can’t write good code, it doesn’t matter what methods or processes they use. Bad code would, at least eventually, lead to bad business. I believed that to make a company Agile developers were the key point of leverage.

For a few years, I was the lead on a software team. One day the manager introduced a newly transferred guy who would join my team. When I familiarized him with the project and saw him write some code, I immediately went back to the manager and told him that this was never going to work out. He was having problems with the basic syntax of the programming language we used. The manager said there was nothing she could do about it. And I told her it would take years for this guy to be productive.

After accepting, however begrudgingly, that the new guy was staying, we started investing time and effort into teaching and coaching him. He was smart and funny. He’d spent the last few years as an architect and had lost touch with hands-on programming. We started pair programming frequently, reviewed all commits, held technical brown bag sessions and debated the essence of good code together.

After six months I had to admit to the manager that I’d been wrong. The new guy was now one of the most productive developers on the project. Our team had been a great environment for him to catch up on his technical skills and he worked hard to improve.

After that experience, I realised that some teams can turn crappy developers into good ones, and possibly turn good developers into great ones. It’s not all about the members of the team, it’s also about the surrounding environment.

This shift in thinking was huge for me. I noticed that when I left work, I was no longer thinking about coding. I started spending more and more time pondering questions unrelated to coding, which until recently was completely unheard of for me. Not just personal questions, either. Big questions such as: “How do you create an environment in which people thrive?”

I dipped my toes into systems thinking and immediately realised there was no turning back. It became all-consuming. Once I began seeing systems, I couldn’t unsee them. Everything was, and still is, a system.

I started noticing the impact system conditions have everywhere I looked. Prisons are an excellent example. In solitary confinement, people begin to lose their minds without anyone directly harming them. It’s the system conditions that make isolation unbearable.

A simple example of a system condition is lighting. Turning off the lights has severe effects in virtually any human system, be it a prison or an office. Many system conditions are hard to see because we’re so used to their presence. System conditions consist of our policies, processes, and structures. We are constantly within their influence, and we need to take a step back to be able to break the spell and see them.

I also soon realised that fuming about systems was, for most people, slightly overwhelming. So instead, I started talking about culture. Culture is an all-encompassing word. Most people agree that culture is important and has an enormous impact on performance.

Culture is more familiar than systems, but it’s still abstract. If you want to change culture, how do you even start? What do you grasp?

A helpful way to look at culture is to see it as a result. It’s like cake. The cake is the result of a recipe. To improve all cake everywhere, we don’t try to change a finished cake; we adjust the recipe instead. Similarly, there’s a recipe for company culture that needs some changes.

Through my years in studying organisations in a multitude of roles I’ve come to the conclusion that the ingredients of company culture are:

* System conditions

* Behavior of key people

* History of the organisation

System conditions have an enormous impact on the team. For example, trying to create a collaborative culture in an organisation that has a bonus system that rewards individual performance is a waste of time. System conditions will overrule any soft talk on the value of collaboration.

The behavior of key people defines patterns. If a person with a long history of merits fears mistakes, others in the company will adopt a similar stance, for good or for worse.

The history of the organisation is the only ingredient we can’t change. However, there are many ways to interpret it. We often learn history by hearing and telling stories. So we can alter the impact of a company’s history by changing the stories we tell and the lessons we take from them.

The recipe is our ability to understand the ingredients and put them together in the right order and amount. And that is, of course, context-specific.

In 2017, with 12 years of Agile behind me, I see Agile as a means to an end. I no longer consider Agile a value in itself. I don’t even care about the distinction between doing Agile and being Agile. When working with organisations, I’m interested in clarifying why we’re doing what we’re doing and adapting the organisation to fit that purpose.

This post originally appeared in edition #14 of AgileTODAY. For more information and to subscribe, visit the website.

Sami Honkonen will be at Agile Australia 2017 from 22-23 June to present insights on company culture. He is also running a workshop in both Sydney (21 June) and Melbourne (26 June) on Creating a Boss Level Company Culture. 

For more information please visit the website: www.agileaustralia.com.au/2017.