Posts tagged patterns
Agile Culture Part 2 - Strive For Quality

Last time we looked at supportive leadership and how that can really let people in an organisation become empowered.That feeling of empowerment will vanish pretty quickly if they feel that they just aren't achieving good results. Nothing is more demotivating than feeling that you have worked all day and achieved nothing, or made things worse. This is where quality comes in. People need to feel that they are doing a quality job to be really happy. Pride in your work is one of the biggest motivating factors out there. Quality is also great for an organisation. After all, if it's not producing quality, how likely is it to stay in business long term?

Now, when I mentioned quality, I'm betting a bunch of you immediately thought about things like defects, and testing, That's what most people associate with quality - building the thing right. But that's not all there is to quality. By itself, building the thing right only ensures that what you build is defect free. Is it the right thing? Building the right thing is an even more important aspect of quality. And what about the way we build it? Is it quality if our processes are bad so that what we build is late to market or too expensive? An organisation needs to consider all 3 aspects of quality before they can really say that they are producing a quality product. 

Read More
Agile Culture Part 1 - Supportive Leadership

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.

Read More
Inspect And Adapt

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.

Read More
Measure What Matters

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.

Read More
Execution Efficiency

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.

Read More
Distributed Decision Making

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.

Read More
Doing vs Being

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.

Read More
Pirate Teams

A few months ago I saw a meme floating around contrasting a good agile team with a group of cowboy coders. Their chosen metaphor was a nautical one. The good agile team was the navy (age of sail style) - disciplined, focused, effective, working together for a common purpose. The bad team was, of course, pirates - rough, undisciplined, attacking stuff at random, scary but ultimately ineffective.

I looked at that, and knowing a little something about pirates (real ones, not the Long John Silver/Jack Sparrow/Captain Hook type Hollywood ones) it didn't quite ring true. In fact, if you look a little deeper, the age of sail navy is actually quite a good metaphor for traditional organisations and pirates actually make a great agile team. Since this is International Talk Like A Pirate Day, heave to for a moment ye scurvy dogs and let me explain.

Read More
Inspect And Block, Or Consult And Enable?

Often in large organisations we have to deal with groups with names like "legal" or "compliance" or to use an example from my days in the healthcare software industry "patient safety". To a project manager, the function of these groups seems to be to throw up obstacles and prevent getting things done. These groups tend to appear out of the woodwork near the end of a project, inspect everything that has been produced, identify a bunch of problems and then block release until they are all fixed. The problem of course is that at the end of a project, everything has already been built so changing things is hard and expensive. There is also a very good chance that the money is starting to run out so these changes would push the project well over budget. Throw in a rapidly approaching release date and a team already stressed with defects and last minute changes, and it's no wonder project managers view these groups with dread.

Of course, these teams are not just a bureaucratic hurdle to be jumped. They do an important job. The organisation could be in serious trouble if they release anything that is illegal or is not in line with whatever regulations they are under. Groups like legal and compliance have the skills and knowledge to make sure that doesn't happen. In the healthcare company I worked for, patient safety was responsible for exactly that - the safety of the patients whose treatment was administered through the software we wrote. They were trained medical professionals, with years of hospital experience, who assessed what we produced and made sure that in the stressful, overworked environment of a typical hospital, that the software could be used without the risk of accidentally administering the wrong drug or the wrong dose or operating on the wrong leg (or even wrong patient) or anything like that. That's a pretty important thing to do. We knew how valuable it was. We still hated dealing with them though. Product managers would jump through hoops to get their product classified "non-therapeutic" so they could avoid a safety review. The downside of course is that there was no safety review. If only there was a way that we could get the value that these groups provide without all the downsides.

Read More