Project Management

In the old world, Project Managers would give a deadline to the teams and “manage” them to deliver on or as near to on-time as possible using the he who shouts the loudest methodology. In the transitional period from the old world to the new world, Project Managers are forced to go head to head in the prioritisation stakes – instead of beating the delivery team up. Having anyone going head-to-head is a bad thing. This is a specific system problem and could only be addressed at the portfolio level. See the Portfolio Mgmt section for information on how this particular problem is addressed (yes, it was resolved!). The best outcome for the teams is the security fence Kanban provides them to focus on doing their jobs properly – and with pride.

Senior & Middle Management

In the early stages of Kanban adoption, managers regularly dominated the daily stand-ups. It took quite a bit of coaching to get them to understand the redefinition of their role as a manager. No more allocating tasks and putting pressure on individuals to deliver on time. Instead they were there to prioritise and unblock work, and let self-organisation flurish. All the blockages are highly visible for managers to see – so there’s no excuse for not assisting the teams in unblocking work. The mechanism for prioritisation is extremely visible and easy to understand, so again they’re there to help manage stakeholder expectations.


After some teams had reached a very comfortable place in using Kanban on a daily basis, they became a bit lapse around daily stand-ups, and keeping on top of metrics. To address this a number of Kanban Champions where identified and coached in coaching so they can help to keep the teams focused.

Sub-Optimising the Whole

From a Systems Thinking perspective, one particular team ran the risk of creating sub-optimisation from an end-to-end perspective. This team is the Sys Admins team.

Before Kanban, they were in high demand from the Service Lines (software development teams) as they created development environments, qa environments, and live environments. The team were small, serving many masters. The team received work via email, electronic ticketing system (Infra), and verbally via walk-ups. A common complaint was that each service line wanted a Sys Admin sat within their team so as to create a cross-functional team, and not have to put requests into a centralised team. This is a great idea from a flow perspective but it has a number of drawbacks:

  • Single point of failure if your sys admin is off sick or leaves the company taking the knowledge with them. So you would need more than 1 sys admin per service line.
  • The live infrastructure is a shared entity so having sys admins working in silo’s could create challenges around consistency of approach.
  • The reality is, there isn’t enough sys admin work in each service line to justify a full time bum on seat.
  • Sys admins don’t just service the demand of the service lines. They also do a lot of BAU type tasks that still require a centralised team to service. (again, another Systems Thinking signal!!)
The sys admins team implemented Kanban which helped them in a number of different ways:
  1. It created a safe, protective environment so that demand could be throttled back to balance against supply. In other words, shifted the problem to where it can be better dealt with.
  2. It provided clear visibility of the problem to act as the catalyst for wider organisational discussions to begin.
  3. It improved productivity and collaboration with the service lines to reduce their frustrations. Service lines fed back that they noticed a big difference between the before and after Kanban.
Optimising the sysadmins team delivered a lot of immediate benefit but I can see this benefit being a short term benefit if the demand from service lines changes. To address this the sys admins attend service line daily stand-ups ahead of their own so they get better visibility of work due to hit them (the service lines make the sys admins work visible as well). They feed this intelligence into their own priority mechanism. This is a two way street meaning the service lines also attend the sys admins team daily stand-up.
  1. Ian, great site which have me a lot of information to implement kanban in my dba team.
    We are using a simple board (backlog, ready, in progress / running, in progress / waiting, done)
    Actually we find a lot of cards in our in progress / waiting column. I think most of the cards are supposed to be marked as blocked instead of being parked in the waiting ( for external events) section. However, my team decided to create this column in order to be allowed to work on other tasks while waiting for external event. Any recommendations to deal with it? The good thing: at least we know that we have to wait a lot on external events (new hardware, approval, acceptance) until we can contiue with our work. My concern is that we would have to much work started…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: