Last time we started to look at safety and what that could mean for your organisation. We looked at some historic disasters (and there are many more than those BTW, I wasn't short of examples) and how a lack of safety played into those. We also started to look at what we could learn from those disasters about the sorts of safety issues that could be lurking in your organisation. Today we'll continue looking at safety and how we can start to build a culture based on respect and trust. Before I do though, I should show you just how prevalent safety problems are in the workplace, because you may well be thinking "that can't be my organisation". Guess what, it probably is.

In 2018, The Australian Workplace Psychological Safety Survey canvassed 1,176 Australian employees and found that: 

Only 23 per cent of lower income-earning frontline employees felt their workplace was “psychologically safe” to take a risk, compared to 45 per cent of workers on significantly higher incomes.
A “psychologically safe” workplace is characterised by a climate of interpersonal trust and mutual respect in which people feel comfortable being themselves to make mistakes or take risks in their work.

So far we have looked at four of the five aspects of agile culture:

• Supportive leadership

• Striving for quality

• Becoming a Learning Organisation

• Enabling people

If an organisation can embrace those four they will truly be an agile organisation. So if all they need are those four, why is there a fifth? The fifth aspect, Enhancing Safety, is in the list because without it none of the others can happen. Without a sense of safety, you won't get supportive leadership, you won't get a focus on quality, you won't get learning and you certainly won't get enabled people. What you will get is what you probably have now - people doing exactly what they are told, not asking questions, not challenging, not pushing boundaries, not setting challenging goals and escalating all decisions upwards. You will get an organisation that is risk averse (that's not a good thing BTW... a lot of organisations brag about being risk averse, what they really mean is that they manage risk carefully; being risk averse means being afraid to take any risks at all, like new products, innovation of any kind, process improvements...), ossified and incapable of change.

Last time we looked at what it means to be a learning organisation. There are obvious benefits to having a learning organisation - better decisions, better products, better processes, better, well, just about everything. There are also some non-obvious benefits that are, in some ways, even more powerful than the obvious stuff - it turns out that learning is extremely motivating for people. Learning organisations tend to have very highly motivated, switched on, dedicated people in them and that gives them a huge advantage. It's not just that these organisations attract those sort of people, but the really amazing thing is that the people already in the organisation become more motivated when the organisation embraces learning.

It turns out that learning - getting better at something - is one of the key things that motivate us. When we talk about motivators in a work context we tend not to think about things like learning. We tend to think more about things like pay and bonuses. Psychologists who work in this field divide up motivators into two types - extrinsic (meaning coming from outside) and intrinsic (coming from inside). Things like pay, bonuses, company cars and the like are extrinsic motivators. Things like learning are intrinsic motivators. Guess which turns out to be more powerful? Yep. Intrinsic motivators win. Extrinsic motivators tend to work in reverse - the lack of pay is a de-motivator, but once you are paid fairly, more pay does not equal more motivation. So, what are intrinsic motivators and how do they work?

Last time, we looked at Striving for Quality and how that means not just ensuring that what you produce isn't simply defect free, but also the right thing, and produced in the right way. To do that, an organisation needs to be able to learn. This is a problem for many organisations. In many organisations, learning is not only not encouraged but is often unofficially discouraged, or worse, it's officially and actively discouraged. I don't mean training budgets getting reduced here. Learning new skills is an important part of organisational learning and people should be given the opportunity to do so, but I'm talking about something different. I'm talking about an organisation learning whether what they are building is the right thing or not. And whether the way they are building it is the right way to build it Or whether the organisational structure they have is the right structure. What I'm really talking about is organisations learning how to become better at everything they do. 

Most organisations are afraid of learning. Why? It seems like such an obvious question - is what we are building, what people want? Organisations will say they are interested. They will quote sales figures and user numbers and so on, but dig a little deeper and they shy away. Did that particular feature meet its goals? Don't want to know. Did that project succeed in the market? Don't want to know. Why? Because if it isn't performing, someone in the organisation was wrong. And they might be important. So it's best not to find out. I have asked about whether a particular feature that a team worked on was meeting its user uptake goals and been told "We don't measure that because that way no-one gets fired for telling the product director that they picked the wrong thing to build". Organisations are afraid of learning because they are afraid of failure.

Hi Folks. Back after the new year (and a major unplanned upgrade to the blog that knocked me off air for a few months…so much for keeping up to date with maintenance) I’ll be kicking off with something I talked about at the end of last year - an in-depth look at my views on what an agile culture looks like. If you can cast your minds all the way back to 2018, I posted an overview of 5 things that I feel are the foundations of a good agile culture. To refresh everyone's memories (including mine) after the holiday season, here they are again -

• Supportive leadership

• Strive for quality

• Learning organisation

• Enable people 

• Enhance safety

Today I'll be looking at the first one - supportive leadership. Agile folks talk about this all the time by different names. Servant leadership, supportive leadership, people-focused leadership, and a host of others. We all mean the same thing. The trouble is, when we are asked "well, what exactly does that mean, we generally aren't very good at defining it, and are even worse at giving leaders real, practical guidance on what to do to become a supportive/servant/people focused leader. So here is my attempt.

Over the last few posts we have looked at the four key things that organisations need to do in order to become agile - Distributed Decision Making, Execution Efficiency, Measure what Matters, Inspect and Adapt. In each of those I make brief mention of an "agile culture" that enables them. It's now time to take a deeper look at that agile culture and see what it is.

What is an agile culture? To me the culture is a set of organisational behaviours that enable agility to flourish. If you think about two garden beds - one has poor soil, little sun and get no attention. The other has good soil, plenty of water and lots of sun. If you plant identical plants into each bed, which one will do better (and it's probably best not to ask my wife about flannel flowers at this point - a lovely Australian native plant that flourishes on neglect in rocks by the side of the road but curls up its toes and dies when lovingly tended in our garden)? Agile culture is the well tended garden bed that lets agility thrive. All too often we see agility struggling - thin and weedy, straggly yellow leaves. That's because the culture wasn't there to support it.

Over the last few posts we have been looking at the key changes I feel are necessary for an organisation to be agile, rather than just do agile. We have looked at distributed decision making, execution efficiency and measuring what matters. It's time now to cover the fourth key change - inspect and adapt.

This is probably the hardest of all the four changes for an organisation to adopt in anything but the most superficial of ways. By adopting inspect and adapt, they are not just adopting the need to continuously improve. They are also adopting a view of the world that is fundamentally non-deterministic. Where uncertainty is not just normal, but accepted and even embraced. Where long term plans give way to rapid experimentation. This may be a step too far for many organisations.

So far we have looked at two of the four key elements for real business agility - distributed decision making and execution efficiency. It's time now to look at the third element - measuring what matters. Organisations tend to collect a lot of data They measure a lot of stuff. The problem with many of those measurements is that they are often data that is easy to collect rather than data that is important. 

What's the problem with that? Data is data. If it's easy to measure, why not measure it? Having more data has to be better than less. Not necessarily. There is something important about making a measurement that makes it vitally important to measure the right things, rather than just measuring stuff just because you can. The important thing about making a measurement is that measuring drives behaviour. As soon as you measure something, people will naturally try to optimise that measurement and if you're measuring the wrong things, that can drive some very bad behaviour.

It's time to continue our look at the 4 key changes needed to become a truly agile organisation. This time we will look at the second key change - execution efficiency. Now most organisations will claim to be efficient already. They make very efficient use of their resources - everything is scheduled to achieve 100% resource loading at all times and costs are kept to a minimum. Things are produced with the minimum number of people and at the minimum cost. What could be more efficient that that?

From a pure, cost efficient sense, they are right, so I'm going to carefully define what I mean by efficiency here. It's not cost efficiency. What I'm talking about is how efficiently the organisation can turn ideas into value. How long does it take, and how much does it cost to take an idea and turn it into a real product or service that generates business value? Isn't that the same as resource efficiency? No, it isn't.

Imagine you are in a car travelling down the motorway. You are trying to keep to the speed limit (110km/h here in Australia). How good are you at doing that? Do you, like me (and most of the population) just follow the car in front with an occasional glance at the speedometer? A few hasty speed corrections when that occasional glance tells you that the car in front was doing 130 not 100? Now imagine that there is a police car right behind you. Does your strategy change? Mine certainly does. Your eyes barely leave the speedometer. You maintain absolute, tight control over the car's speed.

There are downsides to this approach though. While your eyes are firmly fixed on the speedo (that's Australian for speedometer BTW) they aren't firmly fixed on the road. While you are deeply focused on the operational details of driving the car (controlling its speed) you have lost sight of something very important - the road ahead. You may be sitting right on the speed limit but you have just driven past your exit. Or worse, you may have missed a sign telling you that the speed limit had changed and now the flashing lights are in your rear view mirror and you are being pulled over for speeding. Precisely the thing you were trying to avoid.

Let me get this out of the way first - Agile is not the point. I see a lot of organisations wanting to "do agile". My question is always "Why?" Why do they want to do agile? Often I find that there is no why. They want to do agile because doing agile is what you do these days, or doing agile is what our competitors do. Doing agile is seen as some sort of magic formula for success. Do these things and good things will happen. No one is quite sure what good things they will be, people talk vaguely about efficiency and faster/better/cheaper. But that doesn't really matter, whatever happens, it will be good.

All these efforts will fail. The organisation will end up doing a bunch of agile things - standups, boards, retros and so on, but the end result will be - nothing. No change in any real measures of organisational success. No improvements in ROI, no improvements in time to market. Nothing. Why? Because doing agile is not the point. Agility is a way to deliver business outcomes. Business outcomes are the point. Not doing agile. The outcome organisations are really looking for is to become agile. Becoming agile means they can respond quickly to changing markets, deliver what their customers need before their competitors do and so on. Becoming agile as an organisation is not the same as doing agile practices. Yes, the practices are important but they aren't the full picture. If all you do are the practices, you will never become agile. As a mathematician would say, they are a necessary condition but not a sufficient condition.

We have all heard about organisations that have successfully made the transition to an agile way of working. Some of us may even know someone who knows someone who says they worked at one once. But much like sightings of the Loch Ness Monster, Bigfoot or the Tasmanian Tiger, most of these claims evaporate under even basic scrutiny. Now, I know there are agile organisations out there. Organisations that have been born in the agile age and have been built from the ground up with agile principles in mind. I'm not talking about those organisations.

I'm talking about the old, legacy organisations. The ones with decades of process and culture to remake. The ones we are always being told (mostly in press releases or flashy conference presentations) are transforming themselves into new, agile organisations. Shedding the baggage of the past and embracing the bright, agile future. But scratch the surface and how many have actually managed to transform themselves? "But transformation is hard", I hear you say. "It takes time and many organisations just haven't had time to complete the job. What you ask isn't fair". And indeed, transformation is hard so let's relax the criteria a bit - how many organisations have actually managed to establish even the start of a real agile culture?

We have all heard the story of the hyperproductive team. That beautiful creation that is 400% more effective that regular teams. The team that never stops getting better. But how many of us have actually seen such a thing in the flesh? I have been lucky enough to see one or two but most teams never reach those lofty heights. Why? Is it because we have the wrong people? Not smart enough? Not talented enough? Not committed enough? I don't think so. I have seen very talented teams struggle while teams that had much less raw talent went on to do great things. Although talent helps, there is no guarantee that a talented team will become hyperproductive and a less talented team will not.

Is it the methodology they use? Is scrum the recipe for hyperproductive teams? Is it Kanban? Crystal? SAFe? Less? Again, none of these things seem to matter. I have seen teams struggle and succeed with all methodologies. So what is it then that allows some teams to become hyperproductive? In my experience, there is one thing that allowed my hyperproductive teams to become hyperproductive - they are parts of hyperproductive organisations. The hyperproductive team is a myth.

I have a confession to make. I'm a bit of a physics nerd. Actually that's not true. I'm a huge physics nerd. I'm not a trained physicist, I'm an engineer by training (which is pretty close...BTW that loud noise you just heard was a bunch of physicists' heads exploding at the thought of being compared to an engineer) but I have always loved physics. All that sets the stage for my next sentence - I was reading an article the other day on ideal gases (as you do) and suddenly thought that gases make a great metaphor for our teams. Stick with me on this...

An ideal gas is a construct physicists use to better understand the behaviour of real gases. Real gases are messy and awkward and do some strange things (like heat up when you compress them) which make studying them difficult. An ideal gas is a conceptual model of a gas that you can use to infer the behaviour of a real gas. In an ideal gas, you assume that the particles that make up the gas are free to move without impediments and when they interact, they do so in a perfectly elastic collision - both particles rebound and go about their business with no loss of energy. The speed of the particles is related entirely to the temperature of the gas. The hotter the gas the faster they move. This also makes an ideal gas a model of an ideal team.

"Come and have a look at my team" says my new stakeholder. "We have been doing agile for a few years now and while we started well, I think we have slipped back to old habits". How often have you heard this when starting a new engagement? Quite often? What do you see when you take a look? It's usually lack of planning, absence of meaningful retrospectives, ineffective standups, lax WIP limits, poor metrics, mini waterfalls. Yep. They have slipped all right.

When you ask the team why they think they have slipped, you will usually get answers like "we scaled up and things went wrong" or "the rest of the organisation is pulling us back" or "some key people left" or something like that. In my experience these are never the real reason. They may have contributed, but the underlying problem is something else entirely. That underlying problem is almost always the same - they never had the basics right in the first place.

Last time we looked at the trend towards massive scale in the agile community and some of the problems scale leads to. We looked at an alternative approach. A scaled down approach -

"Imagine, instead of a huge program, we have small groups of teams, say 2-5 teams in a group. Each group manages its own stakeholders, environments, dependencies and the like. Each group is directly aligned to a set of business stakeholders with a common set of outcomes, is funded through an investment pool aligned to business outcomes, not specific project deliverables, and delivers value end to end for the stakeholder group."

This approach would allow the organisation to deliver value efficiently without the need for massive scaled structures and the complexity and inefficiencies that go along with them. The only problem of course is that such a structure is impossible in most organisations because they are built around large programs and large platforms and simply don't have the ability, architecture or processes to handle a scaled down operation.

There has been a trend recently within the agile community to embrace massive scale. Not just a few teams working together but really large groups. Every day we see examples of bigger programs, larger release trains, all successfully being managed through agile techniques. Just recently, a colleague ran a PI planning event for close to 1000 people spread across three countries. I have seen other organisations proudly boasting that they have "the largest release train in the southern hemisphere", with some figures on the incredible budgets that the train is managing. The SAFe framework now has 4 levels rather than 3 to enable it to manage bigger and bigger structures. Less has Less-huge to do the same.

While I celebrate the achievements of the coaches successfully helping organisations achieve this, and the incredible feat of facilitation that a 1000 person, 3 country PI event must be, I can't help worrying that this drive towards massive scale is not altogether a good thing. Large companies want scale because that's the way they are used to working. They are used to thinking in terms of large programs of work involving hundreds of people. In order to help them, we have developed techniques that allow us to handle this sort of scale. But just because we can do something, it does not automatically follow that we should do something. There are significant downsides to scale.

We were having a discussion about coaching teams at work a few weeks ago, in particular how deeply embedded a coach should be, so I naturally got to thinking about teaching kids to ride bikes. I know that sounds like a stretch but stick with me. Back quite a few years ago when I was teaching my kids how to ride, I did a lot of observing of other parents and, being a geek, did a bunch of reading online about how to go about it. There are generally two accepted ways to teach kid to ride and the difference is on how long to leave the training wheels on.

Method one leaves the training wheels on for a long time - until the child is "fully confident" and the second leaves the training wheels on for the shortest possible time (there is a third radical method that rejects the training wheel altogether but we shall leave such heresy out of this discussion for now). I was, for the record, a method two parent but I observed a lot of parents using both methods. Method one is the intuitive one - leave the training wheels on until the kids knows how to ride then take them off and away they go. Easy. Trouble is, it quite often doesn't work out that way because training wheels have some significant disadvantages.