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!!)
- 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.
- It provided clear visibility of the problem to act as the catalyst for wider organisational discussions to begin.
- 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.