“Logic is the beginning of wisdom, not the end.” Mr. Spock, Star Trek VI: The Undiscovered Country
We love Agile at Waracle. We use Scrum in our deliveries and evangelise it to our clients. However, not all programmes are a fit for Scrum, and clients may mistake that as a failing. So what other methods might a pressured team use to reap the benefits of Agile?
Scrum sits in an array of Agile methods, and for an overworked project with unclear requirements, Kanban can be a compelling alternative. First used in a Japanese motor factory in an effort to tame chaotic workloads, Kanban gave birth to the familiar tickets-on-a-board look for To-Do, In-Progress and Done. An effective visual representation of the work at hand was achieved.
Managing the workload this way ensured the team only took on what it could manage, bringing the workstream under control and ensuring faster delivery. By focusing on the immediate, however, the concept of sprints and measures of velocity are sacrificed. Naturally, this presents its own set of challenges if used in a programme setting.
Planning / Implementing Kanban
“If I show up at your door, chances are you did something to bring me there.” – John Cusack, Grosse, Point Blank, 1996
Kanban would typically be embraced in situations where it’s impossible to plan, potentially in projects with unstable workflow, opaque requirements or when engaged in discovery and investigation. In a programme setting, a core strength of a good Scrum is an inherent weakness in Kanban; spotting a delay before it happens and pivoting.
Your programme manager might be pleased you’ve adopted a method that supports the team but won’t be as understanding if you can’t forward-plan, or if you amass a backlog too big to deliver on time. So how to forward-plan in a method that wasn’t designed for it?
Quick wins can be found by scavenging and recycling parts of Scrum. Maintaining ceremonies like stand-ups, reviews and retrospectives, not only ensure the team’s delivery is in good health but maintain the working method the Product Owner and stakeholders will be accustomed to.
Planning and progress reporting offers a challenge, however, through lack of story points which can be abandoned for day’s effort. Consider a ‘cookie-cutter’ approach to estimates and refine over time, perhaps using a range of days for estimation.
Simple Fibonacci multipliers for complexity can also be applied to estimates after some basic sizing, e.g. ‘easy’ work is multiplied by 1, work of medium difficulty by 3, etc. These multipliers and sizings must be reviewed and refined over time by the team as a whole – similar to the concept of velocity in sprints. This can be a chance to innovate planning and empower your squad – remember that responding to change is a big part of the Agile manifesto.
Reporting
“Our need will be the real creator”, Plato, 428-347 BC
Progress reporting presents a similar challenge. Programme managers want the same reporting and planning provided by other Scrum teams rather than make allowances for a team running Kanban. The Scrum Master must avoid a loss of confidence in the team’s ability to deliver, and hence must make up ‘the gap’. Methods include extending the techniques above into progress reporting to forward-plan and cross-fit into Sprints.
A more aggressive cadence can provide an opportunity to course-correct if confidence becomes low in estimates. Moving from a fortnightly measure to weekly could achieve this, in effect providing a compressed form of Scrum. A more frequent checkpoint also provides the opportunity to protect the team, to effect retrospectives and more quickly identify and eliminate waste. More frequent deliveries will build confidence, but the aggressive schedule will mean more meetings for developers when they should be coding.
The rest is down to the Scrum Master’s ability to foster, facilitate and support an effective team. In a real sense Kanban places a greater burden on the Scrum Master; should they contour an alternative to velocity, or hold developer’s feet to the flames without feeling like they’re being held to Waterfall dates? Can you glean learnings and apply them without the benefit of sprints, or when there’s been little supporting structure to avoid blockages and delays?
It pays to remember that agile is built around people over process, software over documentation, and frank, honest communication. Be honest about the challenges faced and in particular why Kanban is being used, you may find the team appreciates the decision and supports it.
–
Waracle are experts in agile development, we lend our knowledge and experience to help teams achieve their goals. If your organisation could benefit from an agile environment, get in touch with our team, and learn how Agile Coaching can help.
Related insights
