One of the biggest changes the Coronavirus has made to the way we interact is that we are now interacting with each other not in the office, but in each other's homes. Their living rooms, kitchens, verandahs and home offices. The thing that strikes me about this is how personal those spaces are compared to our offices, and how comfortable people appear in their own spaces. Seeing this really brings home how much physical space matters in our work lives, and how much the design of our offices really lets us down.

Offices these days pretty much come in two flavours - the sterile cubicle farm and the modern funky. Your cube farm is the classic office layout, all beige or pastel panelling. An off white plywood desk in a tiny individual cubicle or (horror of horrors) a communal "pod". The modern funky office on the other hand is all bright colours, faux industrial chic furniture, exposed plywood, lots of communal spaces and plenty of green. This sort of office space is designed to scream out "Look at us…look how modern and funky we are!" Both of these office layouts are bad and, despite their very different appearances, for essentially the same reason.

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.

Last time we looked at refactoring. How real refactoring isn't re-writing big chunks of legacy code, it's cleaning as you go. Making sure the code you write now is clean. But what do you do about those big lumps of legacy? They weren't written with "clean" in mind, they were written with "hack it together to meet the date" in mind instead. It's messy and it's slowing you down. What do we do about it?

Well, we need to refactor it. But how, if we can't spend the whole sprint rewriting a big chunk of it? We need to stop thinking big - think small instead. Use the Boy Scout Principle - leave the camp ground cleaner than when you found it. When scouts leave a camp ground, they spend a few minutes cleaning up. Not just their rubbish but anything else they can find left by previous campers. And crucially, they don't try to clean up the whole forest, or even the whole camp-site - that would take weeks - they just clean up the area they were using.

Whenever I mention refactoring in an organisation, I usually get the same response - "Yes, we know it's important, but we don't have time. We need to move fast. We can't afford to go back and keep tweaking things, we have to keep moving forwards". On the surface that's a reasonable sounding argument. It doesn't matter whether your organisation is big or small, established or startup, the imperative is to move fast. Get things done. Those customers won't wait, you either give them what they want now or someone else will. In an environment like that, who has time for refactoring?

I'd like to challenge that thinking. Not the bit about having to move fast, that's a given these days. No, the bit I want to challenge is the bit about refactoring being incompatible with being fast. To me, refactoring is not an impediment to being fast, it's an enabler. I think the view that refactoring slows you down stems from a serious misinterpretation of what refactoring is.

I have had quite a few comments over the years that I have been running this blog along the lines of - "OMG! Wall of text" or "What's the takeout here?" or "Why don't you make this an easy to read list? " or "Can you summarise into a few bullet points? " or just the basic "TL:DR". This worries me a bit. Not just because people aren't reading my stuff, but because I think this points to a much deeper problem. I think this points to the reason people and organisations find it so hard to change.

My posts are always between 800 and 1200 words. That's not exactly a wall of text. If you print it out, it's about a page and a half. The reading time is about 5-10 minutes. Maybe 15 if I really make you think. That's not a large amount of time. But yet many of us feel unable to invest that amount of time to read something. If it's hard to find time to read a short blog post, what about longer format work? An essay? A book? 200 pages? 50,000 words? I know a lot of people who tell me that they barely have time to read tweets these days. What does this say about our capacity to absorb and process new information?

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.