We are a kanban team so we are not participating in Planning...

I had the opportunity to work with a client where there were seven to eight kanban teams in the domain that I was assigned. As we approached the first #QuarterlyPlanning that I was part of with this client, I started hearing that different kanban teams would not be participating in the planning. They held the belief that there was no need for them to plan and that they would just work with the IT Manager and customers directly to account for work coming to them. This brings us to today’s piece: kanban Teams and perceptions regarding planning.

A major misconception surrounding kanban teams is that by virtue of their operating model, planning their work is not conducive to their progress and productivity and slows them down. Any organization that has any semblance of 'method to madness’ will identity that they have a process using which they identify the work, plan it and then go about executing before delivering that work. Planning is not a one time event, rather an on going set of activities which help clarify the scope of work, delivery of finished work and whether or not that work meets organizational definition of done.?

One best practice I’ve learnt and utilized with kanban teams is to identify the different types of work that is being brought to the team. There is a difference between the type of work (#source ) and how the work is being sent to the team (#funneldynamics). If a team caters to documentation bugs that means the customer is documentation and the team works on all their bugs (to keep it simple). This same team can also be working on product support requests for retirement of any document repositories as new document platforms are being integrated into the broader system. This already gave us two sources of work which can in turn identify pieces of work for those customers. This identification and subsequent management of work coming from these is where teams should actively be planning (as they actively work to deliver the goals set forth) which may include activities such as intake funnel management (especially when work is coming from different directions), definition of work, refinement of work pieces, #definitionofdone, #capacityallocation, #dependencymanagement and impact thereof on the team deliverables.

Another pushback that I’ve heard is that non development teams need kanban to keep the throughput and productivity going since most of the work (read eighty percent) includes the same steps from initiation to delivery. This means that we can’t plan because we don’t know where from and when our work comes. Does this mean that the team stops planning for the work. If the team understands where the work is coming from, it understands the intake source and what the expectations are. Still, it is prudent to keep a check on the backlog by keeping it prioritized (as a first step), keep checking the backlog items in terms of Readiness of backlog items (definition of done), and accounting for a roadmap while having those discussions using the timeline of the overall #milestones set for the team (that can be in terms of body of work completion or throughput numbers). There is still planning to be done especially when teams are part of broader program or in particular Agile Release Trains (ARTs). Let’s talk about when the work comes as this can be looked into by utilizing historical context for work funneled to the team. Conducting such analysis, #scrummaster and #productowner can have a better understanding of how much work each source is sending their way. That can help the team better plan in terms of capacity allocation which helps them with (other work such as) considering #BusinessAsUsual (BAU) work, Ad-Hoc (Fire drill) requests or any all hands of deck environment or production issues.

“We don’t have one intake funnel” is a widespread reason for not planning when it comes to kanban teams when teams share that since they don’t have a single channel for work coming to the team, they can’t plan their work with good degree of confidence. If a team does not have one identified intake process or the team is built in a way that it caters to multiple intake sources, something that the scrum master and product owner need to work together on is how to manage those intake funnels and utilize work coming to the team in terms of quantification of work. Let’s consider worse case scenario here where we can’t put our finger on which funnel consistently provides with work to the team in what ratio. What we can do in that case is focus our energies on the backlog that the team has. kanban teams can still use a backlog to #prioritize, #refine, and (wait for it) plan work to make life easy for themselves and those countless managers and directors breathing down their throats to get an update. Regular backlog refinement or even hygiene by scrum master and product owner can save a lot of pain for kanban teams leading into refinement and should be done on cadence regardless of how busy the team is. This will instill a sense of direction to the much perceived free flowing out rim stars in the agile galaxy that kanban teams are thought to be.?

Planning is just not quarterly planning or iteration planning and if your organization is focusing on these two as one time events then you need help in understanding the tactical and #strategicimpact of Planning as a Process which enables organizations small or large to understand the working coming in, define and refine the work before getting on with the execution and delivery part. Teams don’t need fancy tools to evolve into a planning unit rather all they need is the mindset to identify that planning will help them get faster in understanding the work which in turn will help with the #WIP and #throughput, which in the end will help the team become more predictable and mature. A massive byproduct of this is the behind the scenes #successionplanning impact this has on the team which now is training developers to act as product owners and scrum masters by virtue of behavior tweak resulting in strengthening the bench.

We receive, refine, estimate, execute, deliver software but one thing we so regularly forget that at the back of all that is individuals working to deliver an extraordinary customer experience. This is the mentality that helps organizations become nimble and agile to be able to compete in today’s ever changing world of value delivery.

What planning specific heartaches have you experienced when it comes to #kanban teams?

Businessmap (formerly Kanbanize) Daniel Vacanti Vinnie Gill Chartered Fellow CIPD AgileIndy Agile Solutions Pvt. Ltd. Agile Pakistan Agile Project Management