“So much of what we call management consists in making it difficult for people to work.” — Peter Drucker
“As a job seeker, remember this: You only lack experience if they want it done the same old way.” — Robert Brault
“Deciding what not to do is as important as deciding what to do.” — Steve Jobs
“Out of clutter, find simplicity.” — Albert Einstein
KLRUS14 – Monterey
In January leading practitioners and coaches of the Kanban Method gathered at the Kanban Leadership Retreat. While preparing our “just-in-time” agenda at the start, a topic suggested for discussion was a variation on a question we had all heard often, “How does ‘kanban’ impact my role: as a Project Manager, or as a Business Analyst, or as Product Manager, or as a Program Manager?” It was definitely interesting to hear responses from others to this question, and for me it was one of the more useful sessions.
First Things First
Since the Kanban Method is not a specific workflow methodology or process, and therefore is not something that replaces your current workflow process, but rather a tool that can be used to improve any workflow process, it doesn’t prescribe specific roles. It isn’t that kind of tool.
It’s also helpful to consider that improving your current workflow, even in significant ways, won’t necessarily require creating and defining “new roles and practices.” Still, it is important to recognize using it as a tool to improve your current workflow process should clearly result in some noteworthy changes. Right?
A good place to start is to understand upfront that a core component of the “Kanban Method” is using a kanban system, or even more fundamentally using a “pull based system”, to help address obstacles to creating and maintaining a predictable workflow and improving performance over time. That is, if you’re not familiar with “pull systems”, I’d suggest to anyone using the Kanban Method to first focus on understanding the fundamental changes to pull thinking. Allow this new thinking in turn to influence the ideas and experiments (changes) that emerge for improving the design and operations of your workflow process.1 Then, if necessary and only as needed, consider any benefits that might exist from adding (or removing) roles and associated practices.
Some Role-based Guidance Examples
Below are a few examples for three common roles found in organizations today that were derived from the role-based guidance session I participated in while at KLRUS, and from a similar session I facilitated at the February Agile Denver Kanban SIG (special interest group) meeting.
Business Analyst:
Analyze demand and be a “voice of the system” as you help shape the demand entering the workflow. For example, help others understand how work item types and sizes impact the workflow performance (quality, throughput, lead times, etc.). In contrast and in addition to being a voice for the customer’s demands (requests).
Communicate and ensure the understanding of target dates accompanied by meaningful probabilities of occurrence for states of undesirable outcomes (risk). In contrast to communicating only personal or team commitments without any accompanying meaningful probability measures of risk.
Project Manager:
Guide and influence the parts of the workflow design responsible for developing and making explicit the policies that govern scheduling and predictable delivery and quality of services and products, in particular policies related to establishing a pull system and pull scheduling. For example, policies associated to limiting work-in-progress, handling expedite requests, or the occurrence and frequency of activities and events needed to replenish the workflow’s “Ready” queue.
Develop probabilistic expectations and forecasts for delivery, and establish target dates accompanied by meaningful probabilities of occurrence for states of undesirable outcomes (risk). In contrast to only developing an estimate given as a single date or level of effort (LOE) (single point estimate) or a date range or LOE range without any accompanying meaningful measures of risk.
Product Manager:
Actively contribute and participate in the workflow design and in its improvement over time, in particular related to the upstream facing process interfaces, and in the management and allocation of capacity for work items identified upfront as high risk, and for “normal” work items that become “at risk” as events unfold. In contrast to being simply a “passive user or customer” of the downstream workflow processes.
Manage releases at a sustainable and necessary pace with a balance that optimizes the development, delivery, and quality of the workflow products and services with the needs of the business and customers. In particular in the context of a pull system be aware of the benefits and effects of classes of services options and cost of delay considerations as needed.
An Invitation To Contribute
I’ll be attending the LKNA 2014 conference coming up in early May and facilitating another Role-based Guidance session there as one the Interactive Workshops. I look forward to gathering even more insights from the experiences of other practitioners, coaches, and trainers on how we might answer this common question “How does ‘kanban’ impact my role?” for the roles listed above and other common roles found in organizations today.
If you’re reading this post and make it to San Francisco, I invite you to attend this session and contribute. There are a lot of great sessions to choose from, so I can understand if you decide to attend another. In that case, I still hope you’ll make it a point to look for me at the “Ask a KCP” sessions that will occur on Tuesday and Wednesday afternoons and introduce yourself and share with me some of your answers and insights.
Take care,
Frank
References:
1 For more information on the “Theory-to-Performance Model” see Sense and Respond: The Journey to Customer Purpose by Susan Barlow, Stephen Parry, and Mike Faulkner (2005.