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 James Grenning

Today, we feature exclusive conversation with one of the original signatories of Agile Manifesto and XP Pioneer – James Grenning. It was our pleasure to converse with him. We learned more about his thoughts on Agile, Birth of Planning Poker, Agile implementation in non-IT environments, and his memories with Mike Beedle.

Let’s read;

Q1. It is said that you were Agile before it was Agile. Please elaborate a little for our readers.

James: I started learning and practicing Extreme Programming late in 1999. The Agile Manifesto was created in 2001.  Simply, XP proceeded the writing of the Agile Manifesto. My opinion is that there would not have been a manifesto, if there was no XP.  The provocative name got people looking at it, mocking it a bit. Though, they took notice and many discovered how it provided a way of working that solved many of the problems individuals, companies and our industry had. With 20 year experience prior to seeing XP, I got the problems and the solutions seemed logical.  

Q2. How was Planning Poker born? How did it transform ‘Estimation’ in past few years?

James: There is a paper on my website describing planning poker. You can get the complete story here

Basically, at an early XP planning meeting, our client’s two senior architects would debate for an hour how to implement something and finally write down an estimate. Often the same estimate they mentioned in the first minutes. We had a lot of stories to estimate; all the talking got in the way.  Most the other people around the table were not engaged.

We took a break and when we got back together, I asked participants to take a note card and write their estimate on the card, then simultaneously reveal their estimates.  (Deciding then showing helped to avoid bias of verbal estimates. a.k.a. telegraphing) After a little while people were holding what looked like a poker hand. Planning poker was born.  I wrote about it and posted it on Object Mentor’s website. Mike Cohn read my paper and asked if he could put it in his book and started giving away decks of planning poker cards at conferences.

In retrospect, planning poker was a pragmatic solution to a problem in a planning meeting.  We studied and practiced structured problem solving as part of Total Quality Management (TQM) at Teradyne in the 1980s. We learned various communication and problem solving techniques.  One was brainstorming, but not out loud. Given a question or a problem, everyone would write their ideas for solutions or causes on post it notes or note cards. The we would group common solutions and discuss the possibilities and merits of each proposal.

In verbal brainstorming, often ideas immediately get shot down.  This tends to make people not express their ideas. It also biases the participants when the loudest or senior person dominates.  The day of the first planning poker game, the two ‘experts’ dominated and no one else had a voice.

In a nutshell, planning poker was initially solving the problem of people in agreement talking too much and dominating the effort.

Q3. Which one thing, you think today’s Agile Practitioner’s are missing while implementation? Please share one of your experiences addressing such issue.

James: Most Agile adoptions I see first adopt management and planning practices.  Developers struggle because they lack knowledge and skill incremental engineering.  This is a a formula for pain and unhappiness.

Q4. If you have to introduce application of TDD to embedded C to a novice, what benefits would you like to highlight?

James: The initial problem being solved by TDD is that programmer make mistakes, many per hour.  TDD helps detect many mistakes immediately thus preventing code and product defects. The opposite of TDD is Debug Later Programming.  In DLP, programmers write code and debug it later. How long does it take to find the cause of a bug? It’s big unanswerable question. The TDD cycle is very predictable. You can read a comparison TDD vs DLP here:

TDD also produces a regression test suite virtually for free.  Another driver for TDD is the need to automate tests. You can read why Manual Test is Unsustainable here:

These are only the started benefits.  In the hands of a knowledgable and skilled software engineer, TDD has many more benefits.  The experienced practitioners tell me TDD’s test let you change your mind about design and safely refactor for you needs software’s changing needs.

Q5. When developing the Agile Manifesto, have you ever thought that it would be implemented beyond the IT Industry? How do you feel when you see Agile being implemented in HR, Marketing and other non-IT practices?

James: For starters, we never thought anyone would notice or care about the Agile Manifesto.  As far as applying the principles in other areas, I think it is pretty natural. People work incrementally. Some say it cannot work for embedded software.  I don’t share that opinion. It works for embedded software, it can work other places. You’ve heard of the wiki-speed car? A group of people are building a car using Scrum techniques.

Be it hardware, software, or mechanical, something is being invented. Incremental learning and building is part of the process.  

Q6. Agile Transformations has been an emerging trend in past few years in various domains. What it would be after Agile? Do you feel  the need of any changes in Manifesto with time?

James: The Agile Manifesto is a historic document.  As far as I know, none of the authors are interested in changing it.  That’s not to say that Agile should not change and evolve. It should. Don’t worry about the Manifesto.  It’s fine. How people adopt Agile needs to evolve. I’d like to see a big emphasis in the industry to embracing high-quality incrementation engineering approaches, those embodied in XP are a great start.

Q7. What are your plans for 2019? What should we expect coming from Wingman Software?

James: I’m cutting back my travel a bit being more selective, working with clients that really want to improve how they collaborate and engineer their products.

I’ve been doing an Industrial Internet of Things (IIoT) prototype with my brother’s company.  I think there are some important concepts in how to approach the problem and how to keep code independent of the ecosystem I’m using. That will be a topic.

I’ve had some wonderful family things that have gotten in the way of writing.  I’ve got ideas I’d like to share. Hopefully I’ll get back to writing.

Q8. Mike Beedle’s sudden demise has been a shock for Agile Community. Please share your fond memories with him while developing Agile Manifesto.

James: It is sad and tragic that Mike was taken so senselessly.  

Mike and I skied together one of the afternoons at the meeting that created to the Agile Manifesto. We skied some very tough tree runs in that famous Utah knee-deep powder.  It is a fond memory.

Mike and I did not cross paths a lot professionally.  Though he was a respected man in Agile and Chicago, the city that is my home.


James W. Grenning is one of the original signatories of Agile Manifesto. He trains, coaches and consults worldwide.  He started developing software in last 70s after avoiding computers from high school to early college years. He had worked in both technical and management practices to development teams.

He had authored much read book ‘Test-Driven Development for Embedded C’. James is one of the few experts in applying TDD to embedded C. With his 1.5 decades of training,coaching, and practicing TDD in C, C++, Java, and C# he will lead you from being a novice in TDD to using the techniques that few have mastered. Any C or C++ programmer can use this book to learn the whys and hows of TDD.