Not all development groups are organized in the same fashion
There are several patterns of flow through development groups. The factors that affect this are when:
- the number of applications that interact with each other
- the number of different development platforms (e.g., IOS, Android)
- have vertical applications riding on top of horizontal applications (e.g., MSCIT)
- the number of support groups for the applications
- the amount of dependency on shared services (e.g., Business Intelligence, documentation)
Not attending to these organizational issues can make it difficult to achieve flow through the teams. An easy solution is to do a planning event that identifies dependencies 2 to 3 months out, such as SAFe does. While this will help, it creates challenges on its own:
- interruptions that occur will push stories out, resulting both in breaking the plan for managing dependencies and having the analysis work done on those pushed stories to be redone
- requirements will be stale towards the end of the program increment
- makes any pivoting more expensive
- removes focus because people are now thinking in terms of the program increment
- long range planning without the use of MBIs often spreads out the time that releasable items are built
- Parkinson’s law (work will fill the available time) comes into play
To better understand the problem of the needs of these organizations, let’s look at a few of the most common.
Mostly independent teams
The first case to look at is when there are several development groups that are mostly independent. This is shown in the following figure.
Figure 1: Independent development groups
This structure is relatively easy to manage. This is a common structure for development organizations for less than 75 people. After that almost all organizations require some support group as shown in Figure 2. Independent development groups are easy to manage and can be planned on a per sprint basis. Big room planning is not needed, but often good for its social aspects. Also, because of the size of the organization it is often affordable.
Simplest case typically found for development groups greater than 50 people
Figure 2: More common organization structure
For most organizations over 50 or so people in the development group, figure 2 is more common. This requires a bit more planning or the use of Kanban. Kanban at the application support to products can usually manage how to handle dependencies. But in order for this to work, MBIs must be used to sequence the work being requested so that the support teams know which are the most important to get done. Another practice to improve flow is to temporarily assign people from the application support teams to the teams that need them.
Application and Platform Products
As the cloud becomes more popular we’re seeing more and more often that applications share a common platform which may be a product in and of itself.
Figure 3: Applications with platform support
Manufacturing Supply Chain IT
Many companies have the challenge of multiple horizontal platforms that are products in their own right supporting multiple vertical applications that require them. A common example is Manufacturing Supply Chain IT.
Figure 4: Applications with multiple platforms (MSCIT)
What’s Required to Solve these Differences
There are two essential concepts required to solve these challenges:
- the use of MBIs so that cost of delay can be computed on releasable items
- use of organization wide OKRs so that MBIs can be sequenced based on consistent business value – allowing low level decisions to be tied back to high level business value
- an understanding of Flow so that teams can be organized to reduce hand offs, interruptions and delays in general
Seeing how to manage flow can be accomplished through the A Simple Guide to See if a Change Will Be an Improvement later in this book.