Attending to Teams is Important

August 23, 2013 — Posted by Al Shalloway

One of the most powerful tools for improving software development is to create more effective teams. Every method and every framework – Agile, Scrum, XP, waterfall, the various flavors of Kanban[1] – depend on it. This short series of blog posts address the importance of effective teams for fully functioning lean software development. The series looks at:

This article is the third in the series and is a splitting up of an earlier blog Creating Teams in Scrum and Kanban to make the concepts more accessible.

Introduction

The use of cross-functional teams is a powerful approach for eliminating waste in software development. Often, it is not practical or feasible to use them, especially at scale. Classic Scrum, Kanban, and other Agile methods do not provide specific guidance in what to do in this case. Net Objectives has found that the creative use of “pods”[2] and “hubs”,[3] guided by Lean principles, helps organizations realize much of the benefit of cross-functional teams.

Classic Scrum. Classic Scrum requires cross-functional teams. This, unfortunately, is not always feasible due to a shortage of SMEs, architects, knowledge of legacy code, highly specialized skills, etc.  This is why alternative methods than pure cross-functional teams needs to be known – and which I discussed in the earlier blog -  Creating Teams When It Does Not Seem Possible.   Not having true teams is the most common cause of Scrum-but in our experience.  Although many people transition from Scrum to Kanban it is still important to remember the value of teams.

Kanban. Kanban is a powerful approach. People who are new to Kanban, and especially those following the Kanban Method (the Kanban approach espoused by the Lean Kanban University company), tend to over-focus on managing queues with WIP limits (see Framework Tunnel Vision).  This often results in missing easily achievable team/workflow related improvements. This is a recurring problem. Focusing on any one thing always means missing something else that might be very important (see Selective Attention, an interesting video that is only a few minutes long and definitely worthwhile if you do what they say).

Consider this example. I was talking to a team lead about a challenge his teams had with Kanban. They had a front-end team and a back-end team. They were using Kanban and measuring cycle-time for the two teams. He said that most of their stories were under statistical control but there were some outliers. Now, Lean says not to worry about outliers if they are due to a one-off event, which is what he was speculating was the case I asked him if it was possible that the outliers were not really outliers but rather infrequent occurrences of a common theme. Upon reflection, he realized that he had three workflows: front-end only, back-end only, and front-end and back-end. Rather than focusing on managing queue size, it would be much more effective to implement a team structural solution: creating pods with core and extended team members (that is, have a back-end team person be available to the front-end team when a story came through that required both).

Software development methods are very helpful. They give us lessons and guidance about what to look at. But to the extent that they have a bias or an over-focus, to that extent they can blind us to other helpful solutions for improvement. We like Agile, XP, Scrum, flavors of Kanban. But we let Lean principles guide us so we can take from each what is helpful and adapt to the specific context that is before us.

The brain is an amazing tool, but we have to remember that it filters out most of the information we receive. Over-focusing on one thing means we often miss other things that would help advance our methods and understanding.

Al Shalloway
CEO, Net Objectives

Net Objectives trains and consults in Lean-Agile, Scrum, Kanban for software engineering, and team technical practices. Let us know if we can help.

A note about Kanban and the Kanban Method

The original Kanban is Kanban for Software Engineering. This is still what most people mean when they say Kanban. It was created by David Anderson, Jim Benson, Corey Ladas, Darren Davis, and others. The Kanban Method is an approach to transitioning organizations to more effective methods and uses a pull system implemented with kanban (pull). The similarity of the names continues to cause much confusion. In the same way Scrum proponents a few years ago used Scrum and Agile interchangeably, we see this being done by the main proponents of the Kanban Method (in this case, Lean Kanban University, a wholly owned subsidiary of David Anderson and Associates). There is nothing wrong with this, I just think it important to keep a management process separate from a transition method. Kanban and the Kanban Method are not the same.

I am a great proponent of Kanban but have become disillusioned with the Kanban Method. My biggest concern is about how the Kanban Method somewhat ignores the importance of teams (not to mention other things – see Extending the Kanban Method). Software development is not orthogonal to team structure. Kanban makes no claim about this. The Kanban Method does currently hold them to be orthogonal and this is delaying insights for many using the Kanban Method. If you are interested in more on this, read Why We Need a New Meaning/Name for Kanban.




[1] Kanban is a widely used method for process management, software development, and transition management. The “Kanban Method” is one flavor of Kanban that is promoted by the Lean Kanban University company.

[2] A “pod” is a group of people who are working together to build a particular vertical slice of functionality. The pod must contain the capability to analyze, design, code and test what is being built.

[3] A “hub” is a collection of pods that is focused on delivering business value. Hubs are typically organized around an application or service.

 

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