Interview with Andy Carmichael

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.


Interview with Jeff Lopez-Stuit

We conversed with Jeff Lopez-Stuit recently on challenges for Agile Coach. Jeff is a Scrum Alliance Certified Enterprise Coach and helps organisations and individuals to improve their ability to improve.

This discussion has brought up interesting information on why organisations need Agility, how to make everyone in organisation accept, respect and understand Agile, how to be customer ready, and common mistakes made in Agile assessment.

Q1. Why organizations need Agility?

Jeff: Learning to practice Agility well can give any organization the ability to continuously create and improve focus, delivery, and operations in such a way that it can be an unstoppable force for the good of its customers, employees and the world. Agility is a powerful shift in the way humans can make and use things.  We’re entering a time when even some of the most ordinary objects can have some kind of intelligence and communication built into them.  Learning to focus on the most valuable way to utilize these new powers is why learning and practicing agility are essential.

Q2. What are the challenges to find managers with leadership qualities, business acumen, and customer management skills?

Jeff: Last year, I coached at a medical technology company in the United States that had been founded by a man who was brilliant at identifying great leaders and managers. So brilliant, that it seemed like he could look at people standing on the street and see leadership potential in them. He used that gift to build his company from nothing to over $4.5 billion US over the course of his lifetime.  When he saw leadership and management potential, he wasn’t looking for a list of business skills:  he could see who they were going to be as managers and leaders, if they could quickly adapt themselves to changing conditions, and if they wouldn’t let impediments get in their way.  His approach to business was to inspect and adapt, and he looked for people who could practice that and grow with him.

For current leaders and managers, the challenge is to not drag your past along with you and try to map what’s being asked of you now to how things worked in the past.  Being uncomfortable with new and unknown situations, allowing people to work in teams and create their solutions, and facilitating communication instead of controlling it, are all fundamental skills that agile leaders have to learn.  But before that, cultivating the ability to leave the past in the past is the most important skill to practice.

Q3. How to have everyone in organization accept, respect and understand Agile and its practices?

Jeff: The best way to inspire an organization to start practicing agile is to have a powerful vision and mission for a business future that includes agility, invite people to join in that journey, give them the space and support they need to learn and practice, and then believe and expect that they can be accountable for owning the delivery of the mission.
The most important element for a leader is a powerful conversation about the future that they can influence and coach an organization to own for itself.  Too many companies try to adopt agility by inflicting a framework on people in hopes that they will all “become more agile”. Any attempt to improve performance has to have a context for why it’s happening, and an invitation to join.

I need to point out that this is the great contribution that Daniel Mezick has made through Open Space Agility.  It’s a very powerful approach to allowing an organization to own its own future through practicing agile.

Q4. Share your views on 3 major challenges for new age coaches. How to overcome these challenges?

Jeff: The biggest challenge is to keep focus on doing good agile and helping others do it.   Lack of experience and rigor in agility is the biggest threat to the agile coaching profession.
Unfortunately, there’s been way too much emphasis in agile coaching education on things like team and organizational dynamics, cultural transformation, and mindset, and not enough emphasis on agility itself.   There are fundamental skills needed to practice and lead agile teams and organizations, and those skills must be mastered before attempting to coach a team. Most people learn these skills when working as a Scrum Master or Product Owner.  Alas many people move on to try to become agile coaches before they master the fundamentals. Practice, practice, practice the fundamentals every day, in both your personal life and your team. That will lay the foundation for being a great agile coach.

Choosing your path and focusing your personal growth and development efforts to it is a major challenge now, and unfortunately, the agile community isn’t helping aspiring agile coaches do this.  Every week there are new certifications and training programs that compete for your focus and money.  (Disclaimer: I am a certified trainer in the Scrum @ Scale framework). An aspiring coach needs to be very careful to choose only those programs that will help them become a better practitioner.  I can’t tell you how many aspiring Scrum Masters I’ve met that have a huge list of certifications printed behind their name but can’t facilitate a sprint planning meeting if their life depended on it.  Believe it or not, attending a local meetup group to share experiences and practices can be a much more powerful way to learn than by attending a big-budget certification program.

The last of the three challenges is to stay open to iterating yourself.  In fact, learn how to iterate yourself faster than the tools, technology and processes that are being thrown at you every day.  You can’t help an organization with transformation unless you personally have mastered the ability to transform.

Q5. How can an organization become customer ready to receive changes quickly?

Jeff: The best way to learn to serve customers with agility is to invite those customers on the journey with you.  Involve all your customers to create the product backlog with you and invite them to all sprint reviews to get direct feedback from them.  As the agile manifesto implies, work with them every day.

In the best agile organization I’ve worked with, we invited the customer into a few hours of training to introduce them to the foundations of agile practices at the start of the program.  We showed them from the first contact the value they would get from participating directly and daily in the development process and from providing iterative feedback on real working stuff.  We gave them space to ask all the questions they could come up with. Then, that very afternoon, we invited them into the first user story workshop. The customer was overjoyed, because for the first time, they had an opportunity to work directly with the team and get honest visibility into the work that was going on.  Partnership, transparency, and frequent feedback caused them to pivot their entire strategy from what they thought they would be doing into something that was immediately valuable.

Another example is a client that required all of their teams to have real paying customer present at every sprint review.  Teams at that company often had multiple customers present – even when those customers were competitors! The customers knew that they sprint review was their best opportunity to get their feedback build into the product, so they were willing to sit side-by-side with competitors and have conversations with the team.

Q6. Briefly share some common mistakes made in Agile assessment.

Jeff: The most common mistake these days is to rely too much on metrics and dashboards to guide your actions before a team or organization knows how to practice agile well.  To paraphrase something we teach at Scrum @ Scale courses:  if you can’t prioritize, cool dashboards will only make you look beautiful as you fail.  If you can’t deliver, fascinating metrics will only keep you busy calculating numbers while you fail.

During assessment, agile coaches often forget the very thing from the Agile Manifesto that we teach people:  the most effective means of communication is a face-to-face conversation.  You need to learn how to walk around an organization, observe what’s going on, and have conversations with people about what their work and lives are like.   Swim in the waters of the people that you’re seeking to help. Orient yourself to what’s going on with people inside their own space before trying to assess them. Only then can you establish a good foundation upon which to assess which path to follow with your client.

All of the work an organization takes on to learn agility happens inside a context:  the team, the organization, and the civilization people live in. Assessments often ignore this.  This is why I never use an off-the-shelf assessment tool. Assessment tools often constrain a coach’s ability to help your client observe and orient themselves to where they are, and where they can go.

Q7. What is your advice to new generation of Agile Coaches?

Jeff: First, stand for something larger than yourself:  something larger than you can comprehend achieving at your current state of coaching experience and practice.  Take up that thing and make that thing your life.  Don’t settle for being an agile coach alone: stand for something extraordinary in the world and let what you’re standing for flow through everything you’re coaching.

Second, master your agile coaching craft through practice.  Whether it’s Scrum, Kanban, or any other framework, the core practices of what you’re coaching need to be modeled in your own behavior.  For instance, if you don’t have a personal backlog for your own development that anyone can see, you’re going to have a hard time influencing teams and customers to adopt that same behavior.  Do agile well in everything you do and hold the space that you’re coaching clients do the same.

Finally, don’t settle for whatever constraints or impediments that will inevitably appear in your way.  Be completely unreasonable in what you’re standing for on behalf of your clients as you’re coaching.  The practice you’ve done becoming a great agilest will support you in this.  Be ready to break through the boundaries of what your prior conception of being an agile coach is.  Even be ready to break through the boundaries of what the agile community or what some certification body tells you being an agile coach is.  There is a strong tendency in professional education to commodify and standardize agility, so it can be packaged and sold. Don’t buy in to that.  Learn from it what helps you, and then navigate your own path.

This is still a very young profession, and it’s quickly becoming a very global profession.  The world needs you to contribute all your creativity and commitment to improving the practice of agile coaching.  Agile itself is a means to do this. Stand for something great, practice delivering it iteratively, and share it widely and often to the whole world.  Repeat that early and often. Through iterating and improving your agile coaching practice, you’ll improve yourself, your clients, and the world.


Jeff Lopez-Stuit is a Certified Enterprise Coach who has trained and coached individuals and organizations all over the world to improve their ability to improve. He guides organizations to exploit the fundamentals of Agile to leave behind the inadequate structures of the past and establish an environment that enables continuous delivery of the highest value for all.

Jeff has been invited to present at global agile events throughout North America, Asia, and Europe, as well as speaking frequently at regional Agile conferences wherever he is working.