Tag: Continuous Delivery

Andy Carmichael is a well-known name in the Agile and Kanban Community, and we are privileged to feature him in this edition. He never fails to amaze us with his humility, intelligence and vision.

In an interview with us, Andy shared his thoughts on questions like: “Why do organisations fail to achieve business agility?” “What’s the difference between growing capability and increasing capacity?” and most importantly, “Is change always an improvement?” He put his emphasis, not on being the right size, but on moving at the right speed, in today’s world of heightened competition and disruption.

This article is based on our conversation. Let’s read…

Q1. What are the reasons of failure to achieve Business Agility for organisations?

Andy: It’s an interesting question. There are many more reasons of failure, and many more different ways to fail, than to succeed. The first question I ask organisations though is what they want to achieve. Is business agility one of those things? Because if you are in a very stable situation and you have very stable business, agility isn’t necessarily on the priority list of what must be achieved.

On the other hand, nearly all organisations – including those in industries we consider most stable, where nothing seems to have changed in decades – face the disruption of new ways of doing business, and innovators entering into their markets. It means everybody must think about the need to change… the need to change fast. Remember: “It’s not the big fish that eat the small ones, it’s the fast that eat the slow!” If your organisation is slow, there is a good chance that your competitors or new entrants into the market will disrupt it and take market share.

So the first question is, “Is agility an aim for the organization?” If it isn’t, you won’t achieve it. If you realize that you do need to become agile, there are still many reasons why you may fail.

For example, you need to plan to become more agile (more able to respond rapidly to changing market conditions), and you need to invest in those plans. If you want to encourage innovation, you need to communicate that goal to staff and show how you will reward it. Traditional command and control approaches to managing business, and fixed long-term goals, won’t work, particularly if disruptors are already entering your market and introducing new ways of working more successfully than you are. You have to think about the way the organisation can empowers its staff, and allow them to think differently, to try new things in a safe-to-fail manner. That allows the organisation to discover different ways of working. Agility comes from the chosen strategy of an organisation, and from its leaders’ ability to communicate and encourage staff to implement that strategy.

When people say the word “Agile”, they are often only thinking about it in the context of software development. That software is important to business agility is not in question. Software has “eaten the world,” it is the driver for business transformation, it is the foundation of digital solutions. The way you create software, and the way you plan, manage and finance software development is crucial if you want to achieve business agility. However, I encourage leadership teams to consider first why they want to achieve business agility, and what it involves in terms of the changes needed in their organisation. Then they can start planning, not only how it will change software development, but also every other area of the business. Each area, just like the software teams, must invest in new ways of doing business, must try multiple things to see what works; must act before knowing if it will work, learning from failures and exploiting successes. Rather than waiting for the fully developed ideas – the big up-front plans with every component costed and all outcomes forecast, the big implementation and the big-bang delivery – smaller steps and more learning on the journey is essential.

These are strategies for moving faster than your competitors and ensuring survival in rapidly moving markets. That’s why business agility is important. It answers the existential question of how we survive in this rapidly changing world, where organisations can quickly discover they are no longer fit for the new competitive landscape.

Back to some of the reasons for failure to achieve business agility:

• Not wanting it
• Wanting, but not planning for it
• Planning, but not investing in it
• Not seeing through the changes
• Not dealing with the negative consequences of innovation in the organisation – not ensuring there is safety in both failed experiments, and successful ones that disrupt existing parts of the business.

One other thing. People think there is some magic method or strategy or formula that makes organisations agile. There are principles to learn, but there is no formula. Applying those principles in the unique context of your business, your market and your people – and helping your people to innovate – is where business agility comes from.

Q2. What is your take on developing/growing capability vs increasing capacity?

Andy: This is a subtle question, albeit an important one. We often talk in Kanban about the need for balance… particularly balancing demand against “capacity”. That’s why we use work-in-progress limits, so that we don’t take on more demand than the capacity of the system can service. But it’s not just capacity (how much we can do), it is more accurately “capability” (how much we can do of the specific types of work demanded).

We have demand for work (from customers of our service) and we have capability to provide completed work (provided it matches our skills). These are only in balance if both the amount of work, and the type of work is not beyond the “capability” of the service. If what is demanded is always the same over time, capacity may be all we worry about – we know we can do that type of work as long as we have enough resources and time. However where the type of work also changes – and in “knowledge work” it nearly always does – Kanban services need the flexibility, not just to produce enough stuff, but also to produce the right stuff for present and future demand.

In building effective Kanban services, we are interested in systems that can effectively deliver what the customers need. It’s all about the flow of work from customer need to needs met. Because the needs vary in the type of work demanded, we need to have flexible capability, as well as sufficient capacity for that demand.

So it is right to focus on capability and the development of flexible capability to meet all types of demand. I think it is also true to say that we should first pay attention to the capacity of Kanban systems. How many work items or requests for change can we service with the teams that we are have? That’s an aspect to manage, quite apart from the variability that requires different kinds of skills. It helps us to limit work in progress, by counting the number of work items we are dealing with, and limiting that to a number which is in balance with the capacity of team. This is the first step in applying the general practice in Kanban: limit work in progress.

After that, we can recognise that it’s not just how many items that can overload a system, but also the variability in the types of demand. So it’s appropriate to look at how we deploy resources to cope with this variability – not just limiting the capacity on the supply side, but building more flexibility in our Kanban services to match the variability in the type of demand. We need to ensure that we have the capability to serve what customers are asking for and will ask for. We should look for where there are gaps in skills – where we have only one person who can do a particular part of the job for example. That may well end up being the bottleneck in the process, so if we need to grow capability, we must have more flexible staff that can move to that part of the process when needed.

There’s a final important aspect I want to come back to. When we are applying Kanban in knowledge work, as opposed to applying it in a manufacturing or logistics context, we must realise that it’s in the nature of knowledge work to be variable. There are many more skills, and more variations in those skills, that are needed to fulfil the requirements than in say, traditional manufacturing. We should therefore build teams and services with flexibility and learning at their core. Growing capability is in the end much more important than merely growing capacity.

Q3. Is a change always an improvement?

Andy: No. Change is not always an improvement. Next question!

What? You want more than that? 😊

Perhaps, a bit more then! Remember, change usually breaks things. Gerry Weinberg used to tell a story to demonstrate this. He said that if you change your alarm clock, the chances are that you are going to miss an appointment next week. Simply because you have changed something. Either you don’t understand how to set the new alarm clock, or you leave a button down that should be up, or whatever. If you change something in what you always do, the chances are something will break.

We should realize that we are in the job of change management. Kanban is primarily a method about managing change. But when you change things, you break things. So be sure about what you are trying to change, and most especially why! Is there some source of dissatisfaction in the organization about how you do the work, how are you able to meet customer demands, the quality of work, or the need to learn and innovate? Is there something in current situation that requires change? You need to know that, and then work out how to change… how you overcome that problem. That’s the starting point.

Is change always an improvement? No. Change is almost always not an improvement unless you are focused on what you are trying to improve. Improving agility is different from increasing capacity. You can get more stuff done by standardising, or using a methodical approach, or mechanically following a process and getting faster at it so you produce more. But if you are seeking business agility, it’s likely you will prioritise getting different stuff done, rather than more of the old stuff. If you are going to make a change, make sure you know why you want to change, and focus on that. Look at whether the changes made are moving you towards the goal, and respond accordingly.

All this relates to the change management principles in Kanban. They explicitly say to “start with what you are doing now”. Don’t change everybody’s roles, don’t change everybody’s job titles, don’t change the processes even. Start from what you are doing and look at what are you are trying to do. Understand the gap in terms capabilities. Then we can make progress from there.

Secondly, seek agreement. Seek agreement with the people who are going to implement change at every level in the organization. You can then evolve from where you are. Evolution is not necessarily a slow process. Very often a revolutionary approach that sweeps away what’s been there for years, ends up being a longer process, just because of the disruption caused and the resistance to change that’s generated. That can be a very negative experience. Instead seek agreement together as you evolve towards your goals. Apply the principles of evolution: try multiple things to see what works and what doesn’t, and then move towards your goal with that learning.

The third of Kanban’s three change management principles is “leadership at every level.” It depends on everyone leading in their own capacity, gaining understanding of what’s needed, innovating, and also being able to recover and to use the learning when innovations don’t work. Then building that learning into to what you do next.

Start where you are, agree together to evolve towards the goals, and lead at every level. These are vital principles behind successful change.

Q4. What are the significant benefits of negative feedback loops?

Andy: Wow! Another quite technical question.

The thing about feedback loops is they can be negative or positive. That doesn’t mean good or bad. That’s about whether the loops move the system in the same direction as the feedback (positive) or in the opposite direction to the feedback (negative). So a positive feedback loop could be when I praise you for doing something, you do more of it. Then you get more praise and do even more! This is a “virtuous circle”. I get more and more of what I want, it seems. However positive feedback loops also work as “vicious circles,” if the change is in the opposite direction. I shout at you for not doing something perhaps, you get de-motivated and do even less! Positive feedback loops drive change away from the equilibrium and they are important for that, but they are also dangerous for the same reason.

Negative feedback loops help stabilise systems (they are sometimes called stabilising loops). Negative feedback is fundamental to the control (and evolution) of systems. Take your air-conditioning unit for example. The feedback loop compares the temperature in the room with the requested temperature on the thermostat. If the room is hotter, the system acts in the opposite direction to cool the room. Or if the room is colder, the system again acts in the opposite direction to heat the room. This opposing action in the negative feedback loop allows effective control, and that is the key benefit of negative feedback.

Your question though, might imply that because negative feedback loops are beneficial, that’s all we need. In fact there has to be both the kinds of feedback loops in complex systems. Without positive feedback loops, it’s hard to effect change, but without negative feedback loops it’s impossible to control change.

Let’s take the idea of putting your foot down in the car making the car go faster. There’s a positive feedback loop between the brain of chauffeur and speed of car here. When the car gets faster, the brain thinks “This is good, this is exciting – I will push this accelerator a little bit more. Oh! I am going even faster – this is good”. If there is no negative feedback, it’s fairly clear that we are going to crash! Somewhere a negative feedback loop has to kick in – fear of crashing for example – that results in the brain sending signals to reduce speed, stabilising the system.

These are the benefits of the different kinds of feedback loop: to effect change and to control the change. It’s necessary to have both kinds of loop in systems we wish to manage… Kanban systems and management systems included.

Q5. Is there a role for Kanban outside IT and Software development?

Andy: Kanban, its principles and general practices, are very much relevant outside IT. If we want to achieve the full benefits of Kanban and Agile, we should look outside the limited scope of just one department or one service. There is work flowing from customer needs to needs met continuously within organisations. The principles and practices we have talked about are certainly applicable to how that “network of services” is controlled and improved, and how work continues to flow, continues to deliver value to customers, and hopefully continuously improves.

If you just look at one part, say software development, but ignore what that’s connected to – how we sell software, how we market software, how we use software within products or services, how we connect to the physical artefacts that we deliver to customers – we fail to use the full potential of this approach.

Yes. Using the same principles throughout the knowledge work of an organization is very important. It is vital to realise all the potential benefits.

Q6. One advice for new age Agile/Kanban Practitioners?

Andy: Learn the principles. Apply them in your context. As I said before, there is no formula!

 

Andy Carmichael is a coach, consultant, and business builder who has been at the forefront of process change in software development teams for many years. He’s the principal Kanban trainer and coach for Huge.IO in the UK and Ireland, and he’s an author, speaker and blogger who’s active in getting the lessons of Lean and Agile into the wider business community. He co-authored a guide to Kanban, Essential Kanban Condensed, with David J Anderson.

He is active in the Kanban and Agile communities and is a Kanban Coaching Professional and Accredited Kanban Trainer.