Kanban and Scrum ask different things of management; what do they explicitly say about management’s involvement and how might that influence adoption? Just as Paul did in his second post on becoming a catalyst, we will use the following principle from the Agile Manifesto as a vehicle for our investigation:
Build projects around motivated individuals.
Give them the environment and support their need,
and trust them to get the job done.
Kanban: Start With Where You Are
Kanban emphasizes starting where you are… so it seems a good place to begin. Kanban welcomes established management roles and seeks to improve their effectiveness. It emphasizes visualizing work to improve situational awareness and introducing work-in-progress limits to smooth the flow of that work. Specific metrics, such as lead time and throughput, help improve flow and make it more predictable. Visualization highlights bottlenecks and system constraints. Are more engineers needed? Will automation of some tasks be worthwhile? Kanban provides more information to answer these kinds of questions and creates an environment in which managers get specific information that helps them support their staff.
Kanban also allows managers to “walk the gemba”— to go to the place of work and see how it is being performed. They, and others, are encouraged to make acts of leadership. Most often this is triggered by the visualization, but effective metrics also play a role. With a clear sense of how the process is performing, managers and team members can propose experiments framed with clear hypotheses. Since Kanban builds on the concepts of Lean, an effective way to do this is to use Lean tools. Managers can introduce the A3 Problem-Solving Approach as a way to encourage deliberate experimentation. The A3 approach positions the manager as a coach who fosters continual improvement, not the source of all the good ideas. This will increase trust and motivation, leading to a more effective environment.
Scrum: Management Support For Change…
The Scrum Guide explains that Scrum is a framework founded on empirical process control; it relies on Transparency, Inspection, and Adaptation. It is also largely silent on management’s role. The lack of specific guidance, combined with an entirely new framework can trigger some unfortunate dysfunctions.
Because earlier versions of the Scrum Guide treated those outside the team as separate and distinct, it is not uncommon for Scrum practitioners to hold management at a distance. Where the current draft of the Scrum Guide does mention management, it positions the Scrum Master as the primary interface: “The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t.” This places great reliance on the Scrum Master and the relationship she has developed with management. We have seen some Scrum Masters who keep managers at a distance and others who foster effective collaboration.
The Scrum Guide also obliquely mentions management in reference to the Product Owner: “For the Product Owner to succeed, the entire organization must respect his or her decisions.” Some have interpreted this to mean that once the Product Owner has been appointed, so long as management stands behind her decisions, nothing else is required. Far more collaboration is necessary to ensure an effective team.
We recommend being explicit about management’s involvement with the team and the nature of expected interactions between and among management, the Scrum Master, the Product Owner, and even team members during team chartering. This will help explore expectations, draw out potential differences of opinion, and foster mutual understanding. Scrum can be used to create an effective environment of trust and support, but expectations must be clearly set in order for that to happen. Once they are transparent, the organization has a good basis for inspection and adaptation.
Common to Both
It may seem that we have placed Kanban in a much more positive light; while there is more explicit guidance that can help management foster a supportive environment in Kanban, that does not mean it is inherently more effective. Both approaches require coaching, guidance, and regular reflection to adapt to specific organizational contexts.
In both Scrum and Kanban, managers at all levels are responsible for three things:
- Provide direction, with a clear vision and well-defined goals. Explain where the organization is going.
- Tell the story of transition, explain the motivation for the change, and describe what everyone is expected to learn along the way.
- Assume responsibility for the organizational climate and work to ensure individuals are empowered. Both approaches rely on the people doing the work to improve the process; they must be capable of acting on their own initiative toward that end.
We hope this post helps give insight into how management interactions may change or improve with either approach. But don’t think it is one or the other; as Trent has previously explained, the debate between Kanban and Scrum is often a false binary choice.
Read More
This blog post is part of our “Scrum vs. Kanban” series, triggered by a working session at one of Excella’s Agile Coaching Circle’s offsite meetings. We explored our experiences with and thoughts about the Scrum Framework and Kanban Method, identifying a series of themes that would enhance the knowledge and understanding of our colleagues. We are pleased to share those lessons with you.
- Scrum vs. Kanban vs. Scrumban – Jaap Dekkinga
- Scrum vs. Kanban: Impact to WIP – Nicole Spence-Goon
- How Do Technical Practices Fit In Kanban – Paul Boos
- Scrum vs. Kanban: “Renting vs. Owning” the Process – Trent Hone
- My Experience with Kanban Outside IT – Mark Grove
- Reflecting on Agile Principles – Jaap Dekkinga
- How do Scrum & Kanban create Psychological Safety? – Nicole Spence-Goon
- Scrum vs. Kanban: Management’s Explicit Invite – Paul Boos & Trent Hone