From the beginning of this blog (and more recently on my internal company blog), I've spent more time writing down thoughts on more advanced Agile topics such as what to do once a team is semi-successful with an Agile process. However, over the past couple of months, I've encountered a growing number of questions about how to get started with Agile, both from within the company and from outside. This surprised me in some ways because I've been thinking there are fewer books written about advanced, large Agile projects, but converting over to this new process for software development is still a challenge for many. What appears to be missing is the incentive for those to make the change, so here a few ideas to use as ammunition in convincing those in your group to seriously consider the change to an Agile-based process.

As your eyes roll back and forth in sync with the swinging pocket watch just a few feet in front of your face, the therapist asks you to picture a tranquil place where harmony and a feeling of security fill your thoughts.  She proposes that you imagine a mythical place where all the product teams in a large products company march to the beat of two week iterations.  Your stress levels immediately start to decrease as the amount of cross-project communication is increased by the coordination of planning sessions, and your fears of matching schedules remind you of the punch cards you once heard about in a book (textbook, not comic book).

The shiny watch is now a blur swiping out two week splotches across your poster-sized yearly planner.  At the end of each iteration, all of the teams show their progress and catch up on any integration issues that may have risen between various products.  You envision the smiles of customers and product managers being entertained as quippy engineers show off their latest achievements.  Schedules and interop risks are minimized as the maximum time between interface revelations changes from months into days.  The unknown has now become the known, and transparency rules the day, regardless of how hard it is to see.

The watch and the therapist are distanced from your mind as reports of massive product launches pop up in the news.  You begin to visualize motivated engineers running (but not quite skipping) through the halls, excited about expanding functionality by simply bonding with other existing products.  Suddenly, these are not pieces that can survive on their own; they are the internal organs of a living creature set on a healthy survival, possibly a unicorn.  The daily builds and concurrent testing prove the heartbeat is as strong as ever.

As the words of a countdown reenter your consciousness, you realize the watch is no longer swinging back and forth.  You leave the therapist’s office heading toward your own office with one objective in mind: discovering the corporate cadence.  You know it’s not a legend and can be obtained, one team at a time or all at once.  The only question left to answer is whether the marching will occur on the uphill or downhill side of the chasm.

As I mentioned in a previous post, one of the productivity killers on any team is a dependent event that slows the entire process.  The common and somewhat inverted way to look at this situation in the software world is to claim a bottleneck exists.  I use inverted because a bottleneck is often interpreted to mean that a fixed throughput exists, while a dependent event doesn’t attempt to imply any sort of throughput.  A dependent event is just some action that must occur before another.  How a dependent event is interpreted and handled is left wide open as a problem for the team to solve.

So, enough of the theory junk, a real world example will help.  Let’s consider a large software engineering team composed of many smaller Agile teams.  When one Agile team (Team A) is bogged down with a part of the software that other teams require, the other Agile teams end up waiting.  Is Team A considered a bottleneck?  The answer depends on the flexibility of the organization.  If Team A is only allowed to work on a certain part of the functionality, a bottleneck exists, but if there are no restrictions on teams relative to any specific functionality, a dependent event exists where the other teams are able to come to the rescue.  While it may sound obvious, this setup requires teams that have the capability to work on all parts of the functionality, which may necessitate significant organizational and cross-training changes.

A second example is the case where apparent resource constraints within a team force delays within the team itself.  Let’s take an example where the designated technical writer for a team unable to keep up with documenting the new functionality because of other commitments.  A bottleneck exists if the team continues to create new product without the writer or just stops and waits for the writer.  On the other hand, a dependent event problem exists if the team considers that getting the documentation ready is the real requirement and does not get bogged down with the thought that there is only one resource-constrained writer.  In this case, the team may designate others to help create or research content, or the team may choose a different method for documentation such that everyone can participate.

In both cases, claiming a bottleneck exists is just one interpretation of the problem.  Just thinking bottlenecks exist should be a mental trigger to reconsider looking at any apparent resource constraint.  Creating teams where bottlenecks can be turned into dependent event problems can require major shifts in process, and it may take time to build a cross-functional team, so starting yesterday is the key.

The Goal made me realize some striking similarities between the software development process and regular manufacturing processes in other industries. As some of the readers of this post might quickly recognize and argue to the death, software development isn’t the same thing as tooling a factory to make the same part over and over, even though the bean counters of the world probably wish otherwise. However, there are some undeniable parallels between the software process and a typical manufacturing process.

For instance, those familiar with the waterfall process immediately notice the serialized process represented by the step downs from one discipline to the next, which is very similar to an assembly line building cars. Granted, in the software world, the car would be completely re-engineered each time with a special mosaic painted on the hood, resembling a van with a lift kit; however, the general process for building new software is similar each time. Even when using an Agile process (i.e. not waterfall), there are certain steps that are required before other actions can take place, but with Agile, the length between concept and completion is decreased by iterating through the ideas one at a time.

In many cases, dependent events are created because various individuals on a team are specialized in doing certain kinds of tasks such as documenting, coding, testing, etc. If any one of these functional areas gets too far ahead, a bottleneck is created in one of the other areas; however, this notion of a dependent event is often ignored in the software world until it’s too late to adjust the schedule. The advantage of an Agile process over a more traditional approach is that the planning is limited to a shorter period of time, which prevents one functional area from getting too far out of sync before continuing, but even within an iteration, resources can get out of sync without strong discipline.

Is there a solution or something to be learned from this knowledge of dependent events? Sure, an Agile process is great and wonderful, but it also points to a couple areas of improvement in removing bottlenecks, even within an existing Agile team. First, recognize that dependent events will occur on a team and plan for them. Coding like crazy while the testing lags is like using a Ferrari (or a van as the case may be) to drive around on a mud track. The wheels may be spinning, but the overalla progress isn’t any faster. Second, be creative and think outside of traditional software norms for solutions. In other words, specialization may need to take a backseat to help the bottlenecked areas. As opposed to most planning sessions, focus should first be on the bottlenecks rather than where the resources are abundant. Look for follow-up posts to elaborate on this in more detail.