What Team-Level Approaches Should Include

November 29, 2014 — Posted by Al Shalloway

Scrum, Kanban and the Kanban Method (henceforth called LKU Kanban*) have had great success with many organizations.  But there are also many patterns of challenge in all of these methods. I outlined some of these in my blog Framework Tunnel Vision. I believe the way around these dysfunctional patterns is to step back and reflect on what a team-level approach should consider. This blog lays out the issues that must be considered to avoid the challenges inherent in an incomplete approach.  A complete approach does not imply a heavy approach.  It means to consider the forces that, if you ignore them, may adversely affect your work.  You can attend to these issues to the degree optimal for success.

I’ll start by listing out those issues that must be considered, and then go through each one in more detail.  The core list:

  • Must be business driven
  • Must include core practices that all teams should be doing
  • Provides a consistent approach across the enterprise
  • Enable tailoring itself to each team’s situation
  • Provides a way to abandon adopted practices when betters ones are available
  • Must be based on principles
  • Attends to the culture of the organization

Must be business driven

Agility is about the delivery of business value, incrementally – not about team iterations.  The focus on the team must shift to a focus on the delivery of business value.  Using minimum business increments (MBIs - often called MVPs).  By using MBIs to drive the elucidation of features and stories, the focus can shift from what a team does to how the teams building the required MBI must work together.  Without this focus, teams will devolve into local optimization.

Must include core practices that all teams should be doing

It is fairly well established that a set of practices should be followed by virtually all teams doing software development.  While there are a few exceptions, there are not as many as one might suppose.  These practices include:

  • Work in small batches
  • Self-organize
  • Do daily standups
  • Focus on finishing
  • Make everything visible
  • Have an explicit workflow
  • Manage work in process (WIP)
  • Use estimation & velocity
  • Implement ATDD at least minimally
  • As soon as possible add continuous integration and automated testing

Providing these practices also has the following advantages:

  • It enables individuals to move around more easily
  • It facilitates cross-team learning
  • It facilitates management understanding

Enable tailoring to each team’s situation

Although there are core practices that every team should do, we must allow for variations between teams.  These variations mostly relate to whether we have cross-functional teams, whether we need iterations and the level of a team’s discipline.  Iterations are very important for many teams new to Agile as they provide a reality check every two weeks and help facilitate a focus on finishing.

Provide a consistent approach across the enterprise

Perhaps surprisingly, if you add these practices to Scrum teams and those doing Kanban/LKU Kanban, the practices of these teams will not be that different.  Some teams will have iterations (sprints) and some will not be true teams.  But they will all work in somewhat similar methods, tailored for their own situation.

Provide a way to abandon practices when better ones are available

One shortcoming of Scrum and LKU Kanban is that neither one tells you where to apply it and where to try something else.  Ironic since we all know that one size does not fit all.  But if you believe that, that means you should know when not to “the one size” of Scrum and LKU Kanban.  But the implication also is that there is no guidance for when to abandon the practices they espouse.   We have a dilemma – each approach provides us with prescribed practices, but neither suggests when we should abandon them or how.  

Scrum-but had gotten fairly ubiquitous until people just started saying they do Kanban.  Many Scrum teams abandon iterations without adopting the core Kanban practices of explicit workflow, creating full visibility and managing WIP and claim what they are doing is Kanban.  It isn’t, but it does sound better.  But does abandoning iterations necessarily mean adopting Kanban?  Not necessarily. 

One should consider the purpose of the iterations in the first place. I would suggest iterations provide more than cadence.  They also provide discipline, enforce using small batches, provide for a planning method and increase focus on the next two week’s worth of work.  It is fine to not have iterations, but one should then make sure they have other means for achieving these objectives (which, btw, Kanban’s practice do).

Must be based on principles

Admittedly, when Agile first came out, many of knew it worked, but didn’t always know why.  Many of the rationales provided were often little more than cargo cult.  However, we now know considerably more than 15-20 years ago when Agile first came on the scene. We should base our approach on principles to avoid dogma and religious conversations about what to do.  We should take a more scientific approach and use an experimentation model to investigate whether proposed changes are as beneficial as we had hoped.

Attends to the culture of the organization

Culture clearly plays a significant role in any transition to better methods.  However, what is culture and how can we change it?  This excerpt from David Mann’s Creating a Lean Culture provides some great insights.

Should a company target its culture in its efforts to transform its
production process and all the positions - high and low - associated
with it? It is tempting to answer: Yes! But, that would be a mistake.

Culture is no more likely a target than the air we breathe. It is
not something to target for change. Culture is an idea arising from
experience. That is, our idea of culture of a place or organization
is a result of what we experience there. In this way, a company's
culture is a result of its management system. The premise of this
book is that culture is critical, and to change it, you have to
change your management system.

So, focus on your management system, on targets you can see, such as
leader's behavior, specific expectations, tools, and routine
practices. Lean production systems make this easier, because they
emphasize explicitly defined processes and use visual controls.

Ignoring culture essentially means that we are ignoring our management practices and this can be fraught with danger. Attending to change too much or too little can doom any initiative to failure.  While it is likely better to risk changing too little than changing too much, it is important to recognize that approaches that avoid structural changes (e.g., team formations) will result in failure in many situations.

In conclusion

While I think it is clear that all methods should include the aforementioned concepts, it is also clear that no current, popular framework/method does.  Not to worry, however.  Net Objectives will be announcing such a method in January.  I’ve already been writing some blogs about this approach (see A New Agile Team Approach Emerges).

Al Shalloway
CEO, Net Objectives

* I refer to the Kanban Method as LKU Kanban since it is Lean Kanban University’s flavor of Kanban and not what virtually every non-LKU affiliated Kanban thought leader would consider Kanban to be.

 

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 over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

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