Q&A on the Scrumban [R]Evolution

In the book The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban Ajay Reddy describes what Scrumban is, explores the principles and theories on which it is based, and shows how Scrumban can be deployed in organizations.

You can download a Sample of the Scrumban [R]evolution to get an impression of the book. These pages are excerpted from the new book, 'The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban' by Ajay Reddy, published by Pearson/Addison-Wesley Professional, July 2015, ISBN 978-0-13-408621-7. For more info, please visit the publisher site.

InfoQ interviewed Reddy about the origins of Scrumban, how Scrumban can boost the capabilities of Scrum and how Scrumban support agile adoption, how daily stand-ups in Scrumban tend to differ from those in Scrum, time boxing and continuous flow, how work can be planned and tracked with Scrumban, measuring quality, and Scrumban's view on management and leadership.

InfoQ: What made you decide to write this book?

Reddy: Enterprises initiate Agile transformation efforts to address a variety of needs -- to more quickly respond to a changing marketplace, to gain greater predictability around development efforts, and so forth. They typically engage consultants who, in turn, attempt to guide them down a radical, big change path. They start with a couple of 'Agile Pilots’ that demonstrate some initial results, but broader success past those pilots is generally elusive.

I see a contradiction in concepts with the way this story has typically played out. One of the major objectives of a successful Agile transformation is to create a culture focused on delivering value in small batches. Yet the companies seeking these outcomes attack the transformation effort, itself, as a large batch undertaking. They set themselves up for failure, and then continually fight the resulting distrust that creates substantial resistance to needed change. All these organizations end up realizing are short lived ‘successes’ and cargo cult implementations heavy on Agile jargon. This, in turn, has catalyzed the rise of tribes and cults in the Lean, Agile and Kanban communities.

The sustainable successes I've seen have occurred in organizations where sound values, sound principles, systems thinking, entrepreneurial thinking, and empiricism have been emphasized to drive a series of parallel evolutionary changes driven by a common alignment of thinking and action. Scrumban is a framework that helps teams and organizations to focus on these success criteria, but few people recognize the framework for what it really is. In fact, I'd say it's more misunderstood than understood. I wrote this book to help reverse this state of affairs.

InfoQ: For whom is this book intended, and what can they expect to learn from reading it?

Reddy: This book was written for a variety of audiences. Lean-Agile consultants and coaches will find the content informative across a variety of issues, from understanding the foundational science and principles upon which Scrumban is based to expanding their knowledge on how to help teams and organizations acquire and apply metrics to make better informed decisions around their work and continuous improvement efforts.

Similarly, IT workers, managers and executive leaders will learn why it takes more than simply learning and adopting specific practices to achieve real results and real agility in the marketplace.  Throughout the book I’ve identified specific areas where effective management and leadership is critical to supporting high performance and improved outcomes. More importantly, I’ve tried to provide pragmatic guidance on how to develop and nurture effective management / leadership skills at all levels.

At the end of the day, however, one of the fundamental purposes behind this book is to provide a comprehensive and holistic understanding of context -- understanding the “why” and increasing awareness of options so all can appreciate that simply putting certain practices into place does not necessarily lead to better performance.

InfoQ: Can you define Scrumban and elaborate where it originates from?

Reddy: Scrumban is both a mindset and a management framework.

Though a great deal of Scrumban originates from Scrum and the Kanban Method, it’s not a blending of these two frameworks (for a little more insight into this statement, check out Agile, Scrum and Kanban 101).  

It’s Scrum roots inform us on how to structure self-organizing teams, expose organizational dysfunctions, and manage complex undertakings.  It’s Kanban roots enable us to acquire and synthesize information that allow for substantially better informed decisions about both the products and services we produce as well as the process we use to produce them.  Additional principles stem from understandings rooted in other management sciences.

Since the term was first coined, Scrumban has evolved to a point where it manifests itself in 3 fundamental ways:

1. As a framework for introducing Scrum to a team or organization;
2. As a framework for scaling Scrum across an enterprise; and
3. As a framework for adapting Scrum to better identify, understand and overcome organizational “dysfunctions” that can’t be quickly or easily changed.

InfoQ: Can you give some examples that show how Scrumban can boost the capabilities of Scrum?

Reddy: As an Agile framework, Scrum is designed to help teams make and reliably meet commitments with confidence. Mechanics such as the time-boxed sprint and techniques such as team estimation support these outcomes, but tend not to scale well in enterprise environments (where interdependencies cannot be quickly eliminated and subjective estimation techniques are difficult to synthesize in meaningful ways).

The flow systems we create within a Scrumban framework support the same outcomes, but do so in a way that provide uniform measurements across multiple teams with the added benefit of better understanding the scope of inherent variability within the work undertaken.  

By way of example, consider a scenario where multiple Scrum teams are contributing to the development effort of a major undertaking. No matter how capable a team becomes in its estimation process, it remains a subjective, forward-looking approach that is relevant and meaningful to only that team.  It would not be surprising to have five Scrum teams using the same estimation technique assign five different estimates to the same user story.  Though each estimate could be exactly on target for each team, it would not be apparent to anybody on the outside that these separate estimates would actually end up encompassing the same degree of time and effort.

In Scrumban, teams can still employ the same estimation techniques, but they can enhance their understanding of the work in the context of their historical performance.  Delivery time -- the amount of time it takes for work to be completed once it has begun -- can be graphically plotted to reflect the team’s distribution pattern.  These kinds of additional views into the team’s work provides many advantages.  

From a team standpoint, they begin to better understand the degree of variability in their historical deliveries. They can explore whether or not some of that variability can be correlated to other factors (type of work, risk attributes associated with that work, etc), and manage their estimation and Sprint planning process from a position of superior understanding of their historical performance.

From an organizational standpoint by using units of time you now have performance metrics that are uniform across teams.  These metrics can be easily  understood by both Agile practitioners and non-technical personnel.  More reliable, probabilistic forecasting and planning techniques can be employed to support more meaningful conversations with customers and stakeholders around setting expectations or making informed decisions on trade-offs (In fact, the forecasting and planning techniques can become quite sophisticated - see for example #noestimates Project Planning Using Monte Carlo Simulation)

InfoQ: Different approaches exist that organizations can use to adopt Agile. How does Scrumban support Agile adoption?

Reddy: As I noted above, one of Scrumban’s distinct manifestations lies in helping teams and organizations adopt Scrum. This capability extends to adopting Lean and Agile thinking, in general.

The act of exploring and adopting new ways of working is usually an overwhelming experience.  There’s a lot of new information to master, new approaches often require overcoming years of institutional momentum in terms of both how things are done and how people think about how things should be done.  And let’s not dismiss the emotional and psychological impact of change. For all these reasons, finding the right quantity of information and practices to introduce, as well as the right pace at which to introduce them, is often critical to overall success.

As a framework, Scrumban eases the challenge of forming new habits and ways of thinking. Rather than immediately introducing new roles, events and practices, we focus on identifying and articulating sources of organizational and team dissatisfactions.  We introduce a very limited number of new practices (like visualizing work and creating stable flow systems), reinforcing that we’re doing this to help the team gain a better understanding of how they currently work.  From these understandings, the team can be presented with Scrum principles and practices as options for addressing specific challenges they collectively wish to address.  Adopting Scrum in this fashion provides a greater sense of ownership over the process than being trained on a methodology and being told to adopt it.   

InfoQ: Can you elaborate how daily stand-ups in Scrumban tend to differ from those in Scrum?

Reddy: Traditional Scrum stand-ups tend to be focused on status.  Each team member speaks to what they’ve last worked on, what they intend to work on, and identifying any known impediments to getting that work done.

In Scrumban, the status of work should be clearly radiated by the visual Scrumban board, so there’s no need for team members to recite their efforts.  Team members can still hold themselves accountable for getting work done, but this accountability is enforced by engaging in a collective focus on the flow of work.  The conversations become centered on how do we finish delivery of this item that’s almost complete, or what’s blocking or impeding progress on this item that hasn’t shown any movement.  Another way of describing the difference is to say the focus is on the flow of work, and not on the individual workers or what they’re doing.

InfoQ: Scrum proposes to do fixed time sprints, where Kanban focuses on continuous flow. How are time boxing and delivery flow treated in Scrumban?

Reddy: First, let me emphasize that though continuous flow has become a common outcome or practice among teams employing Kanban and flow systems to manage their work, the framework itself does not prescribe continuous flow as an outcome or practice.  It does emphasize promoting and managing the smooth flow of work, and that kind of an outcome can be achieved within the context of a mechanic like a Sprint time-box.

That said, there are often distinct challenges with the time-boxed approach that must be addressed in many contexts.  Sometimes the nature of the work undertaken by a team simply can’t be sliced to fit within a given time-box.  This is when you’ll see teams artificially slicing work into inappropriate chunks simply for the purpose of fitting the work into the methodology rather than delivering the value needed by the business.  Sometimes it doesn’t make sense to tightly couple the acceptance of work with the delivery of work in a synchronous cadence. For example, if you’re operating in a rapidly changing marketplace, even a two-week delivery and feedback cadence can be too long to be truly Agile.

Scrumban supports both time-boxes and continuous flow.  More importantly, it forces the team to make decisions about which approach is best based on data-driven insights over following a prescriptive approach.

Examples of Evolutions:

(Click on the image to enlarge it)

(Click on the image to enlarge it)

(Click on the image to enlarge it)

InfoQ: Can you give some examples how work can be planned and tracked with Scrumban?

Reddy: I alluded to some of them when I answered your question on how Scrumban can boost Scrum’s capabilities.  Among my favorite are the probabilistic forecasting techniques made possible by the use of flow systems.

A related capability I’ve recently worked on lies in using a technique called Randomized Branch Sampling (see Probabilistic Project Sizing Using Randomized Branch Sampling (RBS) and Improving Sizing).  In a nutshell, this approach employs a technique that has its “roots” in horticulture (pun intended). It’s a way of more reliably predicting the scope of a large project without having to devote a significant amount of time and effort analyzing all the projected work. A shout out to my team at www.CodeGenesys.com and www.ScrumDo.com for participating in this research of RBS.

InfoQ: In your opinion does it matter to measure quality? Can you elaborate how it can be done?

Reddy: Quality defined is whether a product or service is fit for purpose from a customer standpoint.

What we often see is fancy dashboards that track esoteric metrics that only peripherally measure fitness from a customer standpoint.

As a framework, Scrumban emphasizes the scientific method and making data-driven decisions, it doesn’t dictate what to measure.  Every decision the team makes -- what work it chooses to visualize, how it chooses to visualize it, what metrics it chooses to capture -- should be driven by the team’s need to address a source of stakeholder or team dissatisfaction.

So, if quality is an issue for the stakeholder (or even for the team), then it would certainly make sense to capture and assess quality measures.

Some of the ways this can be done would be to separately identify, visualize and measure all rework undertaken by the team.  What’s the percentage of rework as compared to all other work passing through the system?  Another measure might be to identify the cause of defects or rework and look for trends across these causes. The categories of measurement are many, and the team may isolate on different ones at different times in the course of honing in on resolving the dissatisfactions that are the focus of their improvement efforts.

So, it matters to measure quality only if what and when we measure, is against a reference that the customer defines or expects. 

InfoQ: Can you briefly describe Scrumban's view on management and leadership?

Reddy: If I had to boil it down to one sentence, it would be that effective leadership and management involves providing the people in your organization with a clear idea of where the organization wants to be in the future (an articulated vision), and then a setting of clear boundaries within which they are freed to exercise their collective initiative.  

To this end, effective leadership is all about ensuring the right things are done -- whether it’s the right work or the values that foster the kind of alignment needed for consistent decision-making.  Effective management is about reinforcing these things through the nurturing and development of effective practices. 

About the Book Author

Ajay Reddy has spent more than a decade helping teams and organizations improve how they work. His engagements emphasize a hands-on approach, collaborative experimentation, verified business outcomes, and improved team satisfaction. After discovering Agile approaches as a software engineer, he transitioned to coaching organizations. Reddy founded CodeGenesys, the Lean-Agile consulting boutique in 2009. In 2010, he co-founded ScrumDo.com, which provides cloud-based project management tools to facilitate better Scrum and Kanban implementations. As its managing partner and product owner he helps teams in 145 countries realize Scrumban’s benefits. He co-created the GetScrumban.com game to help people discover Scrumban’s capabilities. He teaches Scrumban across the United States, India, and Europe and is a regular speaker at Scrum and Kanban meetups events. Ajay Reddy is married and has four children. Twitter: @ajrdy