Applying Scrumban within a scaled agile framework like SAFe

As any new manager, immediately after arriving at my new company, I did a careful assessment of the landscape, attempting to derive the strengths and challenges facing the organization. As expected those challenges quickly became opportunities where I felt a clear and unified Agile process was needed. As I’d seen in so many “Agile” shops, there's never a shortage of smart and resilient people in the equation. But the processes in place needed some careful adjustments to render them truly adaptive and responsive to the wide range of customer demands the organization had.

The first step to improvement, whether mental, moral, or religious, is to know ourselves - our weakness, errors, deficiencies, and sins, that, by divine grace, we may overcome and turn from them all. -- Tyron Edwards, American theologian, best known for compiling A Dictionary of Thoughts, 1842

My initial goals attempted to achieve three fundamentals that all teams could benefit from when attempting projects, regardless of size or complexity of effort:

• Become Feature-based – the real currency of customers is not stories or points – it’s functionality and features.
• Employ Normalized-pointing techniques – relative sizing is wonderful. But somehow connecting story points to velocity (capacity) is even better.
• Visualize work through achievable release plans and roadmaps – help our customers (and teams) understand the effort entailed and the impacts for releasing deliverables over agreed-upon and realistic timelines.

In most cases these three traits were missing but necessary if teams were to seriously attempt complex and large-scale (enterprise-level) projects. For whereas Scrum works terrifically for small to medium sized teams, for enterprise sized projects having a cavalcade of convoluted integration points and dependencies, requires a scaled-up level of planning. Whether it’s through SAFe, or any other scaled agile technique, a unified approach across all teams is a value-add with abundant benefits.

Techniques such as Scrum, XP, and others – yes, even Waterfall – are considered “prescriptive” project management methodologies. That is, they take a piece of work and place boundaries around it in Scope, Time and Budget. This provides teams the parameters they require to scope the work, apply estimates and make commitments to their customers for delivery.

Sometimes though, the nature of the work or the sketchiness of the customer's (or stakeholder's) requirements render the best of plans for scope, time and commitments, secondary, or even obsolete, minutes after the sprint has begun. This does not diminish the value of Agile but it does force us to carefully look at potential modifications that still enable team coordination and mobilization around a goal, while allowing for ongoing nimbleness.

There are a number of techniques out there in the Agile world that promise just that. One of which is called Scrumban.

This technique is a calculated marriage of the Lean-process Kanban with Scrum. This marriage enables teams to still make commitments (soft) while remaining adaptive to the dynamics of the customer, where a commitment one day becomes less important the next due to a business or market variant. The mechanics of this, although mildly prescriptive, enables a team to throttle work between what is needed to deliver for a planned Feature or Milestone, with any new “just in” requirement being pushed on the team by the business. Of course this requires smart, creative and empowered people!

“Empowerment isn’t about letting people do whatever they want, or assuming they’ll somehow self-organize to produce the right outcome. Empowerment is about defining boundaries...clear boundaries, and then letting them use their initiatives inside the boundaries.” -- David J Anderson, Pioneer of the Kanban Method

There are numerous books on the market about Scrumban. My favorite is Ajay Reddy’s “The Scrumban [R]Evolution”. Books and theories like this, when read in the light of the culture and nature of the work being addressed, can be a marvelous additive to the Scrum journey. In fact Ajay Reddy sees Scrumban in just that light – as an additive and enabler for Scrum maturity.

If you think of the Agile spectrum running from complete team autonomy (Kanban) to a more prescriptive method as Scrum, you can see that Scrumban attempts to achieve the best of both worlds. Scrumban (somewhere in the middle) allows us to release plan and make soft commitments towards our Features while still maintaining a significant level of team-empowerment for throttling work needed to be done based on often-changing business drivers. This is where creative - and diligent product management becomes a critical factor.

One team of mine has been using Scrumban to help manage the requirement changes that occur during their sprints. These occur because, although the product owner and business sponsors do their best to plan out their 8-12 week PIs (Program Increments), they recognize that business dynamics will inevitably cause them to have to place certain stories on-hold (Strategic Technical Debt) so the team can respond quickly to much more time-critical requests. To enable this, the team (with the Product Owner) only loads about 20%-25% of stories against their velocity (capacity) per sprint, leaving a contingency buffer for in-flight story ingestion. That 25% consists of the necessary stories to meet their sprint, milestone or feature commitments. This then allows the team to pull from the product backlog the prioritized stories that are next in queue to meet commitments or new work that has become Must-Do in the sprint. Additionally, it allows the team to better manage their capabilities across the different team members who may have specialized skills.

We are experimenting with other teams and with variations of Scrumban and will shortly have significant metrics to assess how successful this process is doing – not to mention where we may need to tune it.  Remember it’s all Agile! I’ll be sharing those metrics with you all when they’re in.

If you wish to delve into this topic further don’t hesitate to reach out to me.

And remember: "Nothing is static. Even the Mona Lisa is falling apart."

John