Why You Need a Hybrid System

June 27, 2013 — Posted by Al Shalloway

People seem to pick between Scrum & Kanban instead of looking to see what they need to do. We should not start with a solution. We should start with understanding our problem. Scrum and Kanban both provide insights into challenges we may have and how to solve them.  We should also look to other methods to provide us insights.

What Needs To Be Done

Net Objectives has worked with hundreds of teams, ranging from 6 to 6000, IT to product company and using a variety of methods from Scrum to Kanban to eXtreme Programming to Lean.  We have found that virtually all of these companies should try to use the following practices:

  • Minimum Business Increments
  • Visibility
  • Explicit policies
  • ATDD
  • Manage Flow by managing:
    • the workload hitting the team
    • WIP
    • the workflow
    • the team structure of the folks doing the work
  • Have teams as much as is possible
  • Smaller pieces internally – feedback
  • Retrospectives
  • Time-boxing (not necessarily a la Sprint)

Minimum Business Increments. This has become almost universal now albeit it goes by many other names: Minimum Marketable Feature (MMF), Minimum Viable Product (MVP), Minimum Viable Feature (MVF), amongst others.  It is essentially the smallest functionality that can be delivered that is worth the development, deployment and consumption cost.

Visibility. The work and how it is being accomplished must be visible.  Scrum and Kanban boards can provide this.  We must see the work that is taking place so that we can manage it.

Explicit Policies.  A deceptively simple, yet powerful method, that provides much of the power of Kanban (both process and method). Explicit policies vastly accelerate team learning and lay the foundation for incremental improvement by creating an across the board understanding of the best way to currently do something.

ATDD. Acceptance Test-Driven Development can be performed to several different degrees.  At a minimum, it is about doing analysis by having product owners, developers and testers discuss what needs to happen. Acceptance Test-Driven Development means to define scenarios to test for as well as the results for these tests.  The conversations needed to happen to achieve these tests must occur before coding begins.  This can vastly reduce the number of communication errors and bad assumptions, greatly increasing code quality.

Manage Flow with WIP limits, workflow adjustments and improved team structure. Managing flow is critical.  There are several ways to do it:

  • Manage the workload hitting the team. This can be accomplished by teams pulling work at a pace they can manage.  It is facilitated by using MBIs as well so to enable the most value being delivered by the teams.
  • Manage with Work In Process limits.  Lean is about doing work “just in time.”  Too much WIP means the work prior to the overloaded steps is being done too soon before it should be.
  • Manage with better workflow. Very often delays occur because of improper workflow.  A common example is testing lagging coding.  ATDD improves workflow by aligning developers and testers.  Doing this removes delay between coding and testing.
  • Manage with team structure.  While fully cross-functional teams are hard to achieve across the board, we should strive for achieving them as much as possible.  Cross-functional teams improve flow dramatically because they can remove delays almost completely if they have the right mix of skills.  Even when permanent cross-functional teams cannot be formed, other forms of teams often can be which work just about as well. Core teams representing 50-80% of the cross-functionality needed can often be joined by folks with the remaining specialized skills needed.  This semi-permanent cross-functional team can function as well as a permanent one.

Break work down into one to three day chunks. Although the size of the MBIs coming in cannot be controlled, once they have been started being worked on, there is nothing to prevent the team from breaking them down into small chunks.  This practice tends to lower variability of work going through the value stream, but more importantly, it provide feedback and discipline to the workflow.

Do retrospectives. Good systems provide feedback on an ongoing basis. Corrections, adjustments and learning can be done daily or faster.  However, taking time to do retrospections is quite valuable. Click here to see Net Objectives' After Action Review template (registration required).

Time-boxing.  Iterations are the most common time-boxing.  But even in a Kanban system, one should time box the work.  In other words, a chunk of work that needs to be done should have an estimated length of time for it.  This does not need to be precise, nor even public outside the team.  Experienced developers typically make a mental note how long something is going to take.  Once that amount of time has come and gone and the work is not done, they know it is a good practice to re-think their approach.  This is a time-boxing by work chunk.  If this is not done, one can find that people are working on the right number of things but these things are taking much longer than they should.

One Other Big Difference

Scrum and Kanban have different transition methods.  Scrum is about revolutionary change.  It often requires teams to be formed, new roles to be adopted and new methods of working.  This can be great if you can do it and if your teams want to.  The Kanban Method is about evolutionary change.  That is, start where you are and make small adjustments to your methods.  Each of these is right in different circumstances based on culture, current team structure, ability for organizations to change, attitude of the team amongst other issues.  How you should transition to new methods will depend upon how these factors show up in your organization.

Need for a Hybrid Method

Each of these practices is a core practice of Scrum, Kanban, XP or Lean as shown below:

  • Minimum Business Increments - Lean
  • Visibility – Lean and Kanban
  • Explicit policies – Lean and Kanban
  • ATDD – Extreme Programming
  • Manage Flow by managing:
    • the workload hitting the team – Lean and Kanban
    • WIP - Kanban
    • the workflow - Lean
    • the team structure of the folks doing the work - Scrum
  • Have teams as much as is possible - Scrum
  • Smaller pieces internally – feedback - Lean
  • Retrospectives – Lean and Scrum
  • Time-boxing (not necessarily a la Sprint) – Scrum and quality coding practices

As you’ll notice, no one method covers all of these.

The Dangers of Scrum Alone or Kanban Alone

Scrum alone tends to miss the importance of managing WIP and explicit policies.  Some Scrum thought leaders have actually spoken against these practices, although we have seen their value.  Kanban alone tends to miss the importance of teams.  Just because you can use the Kanban Method to not have teams doesn’t mean you shouldn’t create them when possible.

What Is Needed

The key is starting with the proper mindset:

  • Do systems thinking
  • Attend to time (do just in time)
  • Manage with pull
  • Attend to quality

How to achieve value delivery without delay can be achieved by selecting the right practices from Lean-based methods that fit your situation.  Unfortunately, at present, both Scrum and Kanban tend to provide only some of the needed practices.  It is up to you to pull what is needed from Scrum and Kanban and other sources as needed.

Getting Help

If this blog makes sense to you and you are looking consulting or training help, I strongly suggest going to a firm that has expertise in Scrum, Kanban and Lean (Net Objectives does, of course).  Firms that offer only one of these typically tend to dismiss the needs to services they don't provide.

Al Shalloway

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Comments

I like that you include ATDD but good design skills like those found in XP are an important part of the hybrid system.

I would take timeboxing one step further in a Kanban. I would specify a "max cycle time" or similar that forces work to be decomposed into smaller chunks if the estimated time will take too long. I know there are weaknesses with this approach, but it is another good forcing function to keep items reasonably small.

Wes and John:

I agree with both of your comments. We made a "Roadmap to Lean-Agile Programming Competencies" years ago to discuss practices all developers needed. http://www.netobjectives.com/competencies/lean-agile-programming

probably should promote this more.

Also, our Essential Skills for the Agile Developer discusses easy to learn skills that can make a huge difference in your code quality.

 

Thanks Al. Nice balanced blog.

It reminded me of a couple of articles I read in the past, somehow complementary and supporting to what you mention here... touching on various aspects of the idea that "a balanced selection of approach and practices (tools)" to address a situation are just good sense applied ; instead of being dogmatic about a particular tool or approach ... Focusing on the WHY (principles) and continuous assessment and improvement (PDCA) would normally lead to a sustainable long-term solution to obtain desired results (set goals and objectives) ...

Blog by Henrik Kniberg'- The Thinking Tool Called Agile: http://blog.crisp.se/2010/09/08/henrikkniberg/1283938020000
and,
This article by Uncle Bob: The Land That Scrum Forgot: http://www.scrumalliance.org/community/articles/2010/december/the-land-t...

Keep up the good work!! :-)

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban