Cross-Functional Teams Eliminate Waste and Manifest Lean

Error message

Strict warning: Declaration of role_expire_handler_field_rid::pre_render() should be compatible with views_handler_field::pre_render(&$values) in require_once() (line 83 of /home2/netobje2/public_html/sites/all/modules/role_expire-7.x-1.0-beta2/role_expire/role_expire.views.inc).
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 first in the series and is a splitting up of an earlier blog Creating Teams in Scrum and Kanban to make the concepts more accessible.

Cross-Functional Teams and Waste

Software development is not done in isolation. It is best done in teams, by groups of people organized together to achieve a common objective. And the best sort of team, according to Lean-Agile, is the “cross-functional” team, a team that includes the different functional expertise and domain knowledge required to define, develop, and deploy software product. Perhaps nothing provides more benefit than this.

In their seminal work, Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck identified seven kinds of waste in software development: Partially done work, paperwork, hand-offs, extra features, task switching, delays and defects. The use of cross-functional teams significantly reduces each of these wastes.

  • Partially done work. Inventory is work product that has not yet been delivered to customers. It represents potential value not yet realized. From the customer’s perspective, this partially-done, not yet completed work is waste. Lean calls this “Work-in-Progress” (WIP). While there will always be some WIP, Lean-Agile focuses on minimizing WIP.  A major cause of WIP in software development is the lag time between development and testing; product cannot / should not be released until it is tested. Cross-functional teams include people who can test that the code works and domain experts that can test that the code does what it is supposed to do. Being on the same team means testing can be done continually, minimizing the amount of code waiting to be released.
  • Paperwork. Communication with someone who is not on the team runs the risk of mistakes and misunderstandings. Mitigating this requires careful thought, discussion, documentation, and effort. Effort that would not have to be invested if the person were part of the cross-functional team, part of the discussions of the team. It goes beyond communicating about requirements. Cross-functional teams also develop how they will work together. They do not have to spend time documenting workflows and coordinating with other departments (although Lean-Agile recommends having explicit policies that allow the team to experiment and improve).
  • Hand-offs. The problem of hand-offs is similar to the waste of paperwork. Whenever a work item must be handed-off to someone not on the team, there is an inevitable degradation in knowledge about the work. The recipient will not fully understand what has been done before. It injects delay into the workflow. Keeping work – and knowledge – within the cross-functional team reduces the cause of this waste.
  • Extra features. One great source of waste in software development is building more features than are needed. To cut down on this, Agile methods recommend building software in stages. Work on finishing small slices of functionality in order to get feedback before going on to new features. Cross-functional teams help in at least two ways. Since the team includes business domain experts, they can give feedback quickly, even continually, which cuts down on cycle-time. The domain experts can also guide the team in when to stop working on a feature – when enough has been done to realize value – and to turn attention to some other feature. The cross-functional team has the skills required to make timely decisions about features.
  • Task switching. Task switching always lowers productivity. Every time there is a switch, the person must spend some amount of time letting go of the previous task and figuring out what needs to be done on the new task. The time spent spinning up on the new task is waste. Some amount of task switching is inevitable. But some task switching is caused by having to wait on someone or having someone interrupt you (which we call a “shoulder tap”). Cross-functional teams minimize these latter causes because the team can more easily coordinate their work: the people you need to work with are part of your team.
  • Delays. Delay causes waste. Delay causes additional work. Delay inhibits the flow of value to the customer. Lean-Agile, Agile methods, and Kanban all focus on eliminating delays in the workflow and managing WIP one way or another. Cross-functional teams minimize delays due to waiting, to communication, to differing priorities, to wasted work. Here is a valuable webinar that explores this issue: How Delays Cause Waste on our Lightning Webinars page.
  • Defects. Defects include both building the right thing incorrectly and building the wrong thing as a result of a misunderstanding or incomplete knowledge. A short cycle time from start of a story until its completion is the best way to stay on track. Methods such as Acceptance Test-Driven Development encourage different roles to work together. Cross-functional teams include all of the knowledge and skills required to do this.

Every approach to software development benefits from using cross-functional teams: Lean, Lean-Agile, Agile, Scrum, Kanban (in its many flavors), XP. One of our clients was committed to waterfall. They found that when they put people on cross-functional teams, they were three times more productive than similarly skilled people working on similar projects in the same company who were in working in traditional departments. Just by using cross-functional teams. Part of the success of Scrum is its insistence on cross-functional teams. In our experience, Kanban enjoys the most success when it is deployed in existing teams.

Of course, it is not always possible to use cross-functional teams. It is naive to insist on it. That is when it is helpful to fall back on Lean principles to guide what to do to get some of the benefits.  How to do this is discussed in the next blog in this series – Creating Teams When it Does Not Seem Possible.

Al Shalloway
CEO, Net Objectives Inc.

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


[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 Lean Kanban University, a wholly  owned subsidiary of David Anderson and Associates.

 

Author: 

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, Scrum and agile design.


Comments

Great blog, Al

Coming from and working with the biz and ops side of the cross-func organization I frequently see the lean-agile wall . Often the business and operations groups get sandwiched between agile SW development and lean manufacturing. This wall is made up of language barriers, differing process paths, push vs pull forces to name a few.

I've been successful in knocking down these wall by following the social patterns in the company. For example, folks from collaborating groups went for their morning and afternoon beverage breaks at about the same time and at the same beverage stations; and at companies with cafeterias, folks would be chatting in the lines. I took these naturally occurring events and made them into standup meetings.

Another successful team building approach I've used is reminding collaborating groups about their role in the product lifecycle (conception through discontinuation) and how continuous, synchronous communication yields the highest ROI.

Now I'm going to read your "Creating Teams When it Does Not Seem Possible" blog and I won't be surprised to find everything I've said here in there.

Share This Blog

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean-Agile, Kanban, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
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, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Scrum
Scott Bain
Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile