One of the key benefits that David Anderson, the renowned Kanban thought-leader and father of the Kanban Method for software development highlights about Kanban is that it is evolutionary and not revolutionary. That is to say, it does not introduce a humongous new set of processes in an organization and cause massive disruption like traditional methods have tended to do.
There is no question that Kanban does not introduce a “big bang” new set of processes and rigor in an organization, with a whole new set of procedures to be learnt, guidelines to be followed, new documents/ deliverables to be created to show compliance.
In fact, Kanban needs an existing process or methodology so that Kanban can be applied to improve that process! In itself, Kanban is not a software development or project management methodology, as David clearly points out.
However, going by our own experience as well as that of many of our customers Kanban does introduce several small changes that can be considered revolutionary! These changes – while not difficult to understand – might be considered extremely challenging – downright revolutionary! – to get used to and implement in a way that truly brings out the essence of Kanban and enable teams and organizations to reap the real benefits of Kanban.
Can you Pull?
While it is easy for everyone to understand the concept of Pull, I suspect it may not be understood just how hard it may be to implement and practice. Most organizations are used to a somewhat hierarchical/ directive approach to deciding who works on what in any given situation. Be it software project tasks or normal business function activities, managers are all too used to ‘telling’ their subordinates what to do – and for their part, employees are far too used to be ‘assigned’ work. We live in a classic Push world. In a significant – majority? – fraction of workplaces, employees bemoan the manner in which they are assigned work (after all why is Dilbert so popular?!), yet, left on their own, employees will look to managers to help them decide what work they should do next. In a ‘good workplace environment’, managers will regularly sit down with subordinates to understand what work they can be given or can take on, before assigning work. This probably comes closest to being Pull.
Kanban turns the whole thing on its head – and asks people to “Pull” work – assign it to themselves – ONLY when they have bandwidth to work, actively discouraging multitasking. I can just see middle- and senior-management gasp in horror at the implications of this. Not only can they not “TELL” their subordinates on what to work on next, they can’t even tell them to do 3 things at the same time! Subordinates, on the other hand, must face their own demons. “How do I decide what to do? I am paid to work that I am told to! Someone better tell me quick!” Even in knowledge industries, especially in top-down, hierarchy-conscious societies or where a lot of young (immature) people are part of the workforce, team members may be reluctant to exercise sufficient independence and free thought in order to grasp the new power they have in their hands with “Pull”.
Having come to and settled in the US from a not-so-long-ago-socialist India, I believe this may not be as much of a problem for Western/ American managers/ employees, who have long been used to having plenty of choice in almost every aspect of life – and being able to ‘pull’ from a set of choices, as it would be people in developing/ socialist countries long used to government/ public sector driven choices – be it for automobiles (Ambassador or Fiat?) or toothpaste (Colgate or Binaca?) or jobs (Doctor or Engineer?). However, that is perhaps a topic for another blog post!
Pull, if not revolutionary, is definitely a huge mind-set change – and needs all the support it can get from the management and the teams to make it work. Management must encourage teams to take the necessary decisions to pull work. Team members must step up the challenges and the responsibility of standing by their Pull decisions. This, I suspect, takes some getting used to – and for Pull to start working in the Kanban sense of the word.
Thinking out of the (Time) Box
Everyone loves goals, objectives, deliverables and deadlines. “Tell me what I need to do and by when, and then watch me do it!” Financial Years and Quarter, Project milestones, Phase-Gates, Releases, Iterations, Sprints – time-boxes all. Then along comes Kanban and says one word – “Cadence”! Can you imagine the frenzy this must create in the minds of people trying to grasp this simple, yet elegant, concept?
Some of the common concerns I have heard –
“How can I understand what my team is doing, if they don’t tell me what they will deliver by when?!” Managers’ own ability to drive their teams without the 2 crucial crutches – scope and time-box – is severely impacted. Managers must go through a tremendous reorientation to understand that even though the planning mechanism that a release or sprint or a project deadline provided, through the use of cadence and other mechanisms, they can still plan for significant events in their business, yet relieve pressure from teams and actually get them to perform better!
“Unless my current iteration is complete, I do not want my team to look at work in the next iteration!” The need to control what the team members are doing to the extent of not letting them get an early start on the next set of work may be rare, but it is there!
“As a product company, how can I show my customers my product and release roadmap, if we don’t have defined iterations and releases?”
The mindset change required to get past this type of thinking requires enlightening everyone up and down the chain, including customers! But the benefits are there for all to see. At Digité, we have been able to do it for ourselves as well as for our customers – and in the process winning high praise for our responsiveness and speed of doing great product features.
How can I let go of my capability to W(H)IP?
We have all thrived on the ability to multi-task. We have all touted the ability to do so. We have exhorted our colleagues, especially our subordinates, to “just handle” stuff thrown their way. And at great cost – in terms of quality of work, time taken to complete it and in sheer dollar cost. And yet a vast majority of teams and managers continue to practice it. Kanban changes all that. It brings into sharp focus why multi-tasking is not good for the individual or the team and that limiting the amount of work being done at a time actually improves throughput and quality.
In many organizations, it just kills managers to get used to actually limiting the amount of work their subordinates will do at a time – and to prioritize the work for them so they can do so effectively! It actually forces the managers to face the reality that their teams cannot handle all the work dumped on them, and it can be a shocking experience to learn that by limiting WIP, their teams may actually produce more, better! But to get to that stage requires them to believe, to take the plunge and over a period of 3-6 months actually get to observe that. It is not easy because it is so – revolutionary!
I hate to say this – but I am stuck!
A picture is worth a thousand words – we have all known that. A chart or a report communicates the status of a project better than a detailed text report – we get that too. But Kanban make our work visual in a very different way. It not only helps you communicate how work is to be done, where it is at any point in time, where are the bottlenecks – and finally what (and who) might be stuck or blocked!
As technical people, we thrive on complexity and challenge. We love to solve problems – without asking for help. We hate to give bad news to our team members, our bosses, our customers! Kanban says – ditch that – and tell EVERYONE as soon as possible that you are stuck – and your work is blocked! In the most visual way! Not only that, by doing so – you are also doing the unthinkable – you are asking the entire team to swarm and help you get unstuck!
Yet suddenly, Kanban is helping us communicate to business stakeholders or customers that there are problems. But work is progressing. And is getting delivered. In line with the priority that they set!
So, yes, Kanban is evolutionary. It does not bring about disruptive process changes that many processes and frameworks have done in the past. Yet, with due apologies to and full credit to David, it is revolutionary as it strikes at fundamental management and organizational principles, turns things upside down – and makes for a more transparent, more open, more able to experiment type of an organization that is far more prepared to succeed in today’s business environment.
I believe Kanban is evolutionary in the right places and revolutionary in the right places!
Mahesh Singh
Co-founder
Digite, Inc.
