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.

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 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.

Over the last few weeks we have been looking at the various organisational alignment patterns - top down, bottom up, etc. In each of those, the way to move forward once you have hit the limits of that particular pattern was always to extend alignment vertically and horizontally to other parts of the organisation. I made mention of a wondrous state that could be achieved where the whole organisation shares the same goals and is working together towards a common goal. Welcome to the Fully Aligned pattern.

This is the end goal for any enterprise agile adoption. This is the pattern that will really let you grow agile within the organisation and firmly embed it into the culture. This isn't just a desirable end state though. In my experience this is a necessary end state if agile is to thrive and become part of the organisational culture. Without full alignment, agile tends to wither away to a sort of agile-ish (or fragile) set of practices that are followed without really understanding why and more importantly without really delivering real business benefit. If agile is to deliver real benefits at the enterprise level, you need to achieve alignment.

Last time we looked at one horizontal alignment direction - IT lead; today we'll look at the other - Business lead. This is much less common than IT lead. Agile has its origins in software development and the IT side of an organisation is usually much more aware of agile and agility as a concept than the business side so it is natural that the drive for agile would come from there. Business lead does happen though. The problem is that when it's business driving agility, it's either because the business is really advanced and is actively seeking out ways to transform itself (great but not likely) or they have issues with their IT department and have heard of this thing called Agile which apparently makes IT departments deliver stuff.

Yes, if the push is from business, it's usually because there are delivery issues and someone in business has seen agile and sees it as a way to make the IT guys deliver faster, or better, or cheaper, or some combination of all three. Even when business is asking for agile, it is still (most of the time) seen very much as an IT thing. The brief is usually "go make our IT teams agile". Of course the IT teams just love business folks telling them how to write software don't they? If your business is in the "really advanced and looking for ways to transform itself" category then it's likely your IT department is as well and your life just got a whole lot easier. But that's a different pattern.

So far we have looked at the vertical component of organisational alignment - which level of the business is pushing for change. Today we will look at the other dimension. Most businesses are split vertically into different layers of management and also horizontally into different operational units. Every enterprise does this a bit differently but in most of them the main split is usually between "business" and "IT".

Business groups connect directly with customers and come up with new products and features. IT groups tend to sit in the background and do... geek stuff. Now, those who have been doing agile for a while will know that one of the things agile does is to break down this artificial split and align IT teams directly with the business. For an organisation right at the start of its agile journey though, you are more likely to see this structure than not. When planning the transformation, one of the keys is finding where

We have been looking at organisational alignment patterns over the last few posts. We have covered the two common ones - bottom up and top down. Today I'll look at a far less common one - Middle Out. As the name implies, this pattern occurs when change is being pushed by the middle of the organisation - middle management.

Actually uncommon is an understatement, middle out is so rare that I have never seen it in the wild. It's still worth looking at though, as winning over middle management is key to the success of the top down and bottom up patterns we looked at previously. By looking at why middle out is so uncommon, it can help us to understand what prevents change from occurring at this level in large organisations, and to see what we can do to change that. What we are talking about here is the phenomenon of the frozen middle.

Last time we looked at the bottom up pattern. Today we'll look at its inverse - the top down pattern. In this case, the top levels of the organisation want agile but the levels below them are resisting (again, if they aren't... great, but that's a different pattern). This can be a tricky pattern as senior execs may want agile but often don't know much about what it is and what it means for their organisation. With most agile adoptions, you need to spend a lot of time educating your detractors, with this pattern you may need to spend as much time educating your supporters as well.

They probably see agile as a delivery methodology and expect it to be implemented that way. They don't see it as a major cultural change at all levels (including theirs). Tread carefully. Don't lose them. It's very easy to go in too hard, making it seem like too big a change too quickly. Senior managers got where they are by successfully managing risk. They tend to be quite risk averse. They will want to see a strategy that manages organisational risk during the transition.

Today I'll start looking at organisational alignment patterns. The first thing I should do is explain what the heck I mean by that. In this context, organisational alignment is which parts of the organisation are supporting an agile adoption. This is a really key thing to know because where the support for agile is coming from will seriously affect how agile can be introduced, how far it can go before it meets resistance, the type of resistance it can meet and so on. Having worked as a coach in a number of companies, I have found that organisations tend to align around agile in a number of fairly standard ways. I call these standard ways alignment patterns. There are two dimensions to an alignment pattern - vertical (which layers of the business are aligned) and horizontal (which parts of the business are aligned).

If you can pick which alignment pattern you are dealing with, that gives you some insight into the sorts of issues you will experience when managing an agile transition. Knowing your alignment pattern lets you pick the right adoption pattern to get the best success. Essentially, different alignment patterns work well with certain adoption patterns while blocking others. Pick the adoption pattern that matches your alignment pattern and things will go smoother than picking one that is incompatible. Or if you want to use a particular adoption pattern but it's incompatible with the current alignment pattern, then you may need to change the organisational alignment before proceeding. Anyway. I'll talk more about this mixing of patterns later. First I'll start by describing the basic alignment patterns, starting with the most common - the bottom up pattern.

Last post I briefly mentioned a patterns based approach to agile adoption within enterprises. I should probably spend a little time explaining what I mean by that. The first question, of course, is what do I mean by a pattern?

Back a few years, when things were still made by hand, a craftsman who wanted to make a set of things that were the same each time would make one reference piece, measured and constructed very accurately, and use it to create more pieces that looked the same. That reference piece would be carefully labelled with instructions on which way to align wood grains (or whatever was appropriate) and which techniques to use to construct it. This reference piece was called a pattern. There was even a specialised skill within workshops called patternmaker, with its own set of specialised (and very accurate) tools. So a pattern is a template or a guide to doing something. It's a way to reliably and consistently make copies of something.