< Using the Intake Process to Educate Leadership ToC The assessment timeline for a development group of less than 125 people >

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.