![]() |
This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group. |
How your people are organized and allocated to teams, trains, programs or whatever you call your groups of people, is one of the six most important aspects of your eco-system. The factors for effective value streams are shown in Figure 1.

The key to an effective value stream is:
- work on small items of work that can be quickly completed and delivered.
- have your people organized and allocated to limit handoffs, handbacks and delays in the workflow
- have all work and workflow be visible
- have the level of work be below capacity
- use test-first methods to ensure good communication
- have few interruptions in the value stream
- have quick feedback in the value stream
There are several ways to organize people. Here are a few of the most common:
- Cross-functional teams: Improving communication between people who work together
- Feature teams are cross-functional teams that can build and deliver features, but not cross-functional enough to create MBIs.
- Component teams are teams that can create, modify, maintain components that are used by other teams to create and deliver releases.
- Core teams are collections of people that can mostly build a feature or MBI but sometimes require others to help them. This need may be satisfied with a combination of the “borrow member” or “clean up with Kanban” pattern.
- Borrow member is when one team lends a member of their team to another. This is often useful when on team makes enough requests to another team where it warrants the team fulfilling the requests lends a team member to the requesting team. When this happens this person remains on their original team but works with the requesting team while they are useful. They must attend required meeting from both teams (e.g., daily standups).
- Clean up with Kanban is when one or more individuals are required for more than one team. In this case their workload should be managed with each having their own kanban board.
- Focused Solution Teams are a group a team-of-teams consisting of feature teams, core teams and a limited number of individuals that have to work across the core teams. They are able to build and deliver either MVPs or MBIs.They are focused on the MVPs and MBIs they have in their backlog but can be available on a limited basis to other teams. They are the key to achieving Agile budgeting by having FSTs aligned with the initiatives of the stakeholders. While reasonably stable, they will adjust according to need.
- Dynamic Feature Teams: Handling the big rocks. Dynamic feature teams are useful when several small teams exist that are mostly independent from each other but every now and then have to collaborate with each other.
Team organization can also be affected by how product backlogs are managed:
- A case study where merely doing Scrum well and using MBIs was not enough
- Coordinating teams with backlog management
- Aligning multiple teams with Lean-Agile thinking (covers above with more background information)
- Product Manager and Product Owner: Linking stakeholders with teams
How to decide which practice to use?
Agile is very much about self-organization. But many in the Agile community haven’t recognized that there is a science underneath Agile. This includes theories of Flow, Lean, Theory of Constraints, organizational development and more. Self-organization needs to take place in a manner that is consistent with these theories. Of course, it’s not always cut and dried. Human factors and how well individuals get along with others must be considered. That being said, however, the first factors to look at are what cuts delays out of the workflow and reduces miscommunications. If rearranging where people work makes sense from this perspective it’s probably the right thing to do, even, if the individuals involved don’t like it. In these cases it’s worth asking why. If it’s people don’t get along then reconsideration is probably justified. But very often it’s simply a preference for the individual and not considering the big picture.
Here’s an example. Years ago, after a client of ours was trained in basic Lean flow we came back a couple of weeks later to get an update. The director in charge of the Lean-Agile adoption talked about how they had a development team that needed about 25% of the capacity of a component team. Instead of just having them load up 25% of their backlog they decided to assign 2 of the 8 people on the team to the requesting team. These two people still belonged to their original team, but were now working side by side with their new team. I was pleased, this was a great way to improve communications and avoid handoffs. They had basically implemented the (at the time not yet defined) “borrow member” pattern. However, the director said that these two people complained about going to 2 daily standups a day (one for the old team to keep their work consistent with it and one for their new team). It’s true this was costing them a little time but the extra 15 minutes a day they were spending more than made up for the gains in the bigger picture.
I remember making a comment “I don’t like putting gas in my car either, but it’s something I have to do.” Agile is not about being able to do what you want to do. It’s about what works. Not everyone wants to do the right thing. When you look at theories of Flow, Lean and Theory of Constraints, however, you can make more objective judgements. If there is disagreement, you can run experiments and see which person was correct.
If you think your team is up to making solid decisions based on what works and not just what they like, it’s worth checking out Fast-Agile. This is a method wherein an entire group as a whole decides how to work together. This is not a recommendation of this method or organization, but it is worth checking out.
Summary of Different Types of Value Create Structures
References
See this page for books on value creation structures.
This chapter was an excerpt from FLEX for the Disciplined Agilist: FLow for Enterprise Transformation (online book). It has been edited to fit into the Disciplined Agile Value Stream Consultant workshop. The Table of Contents for the book is here.