We recorded the Webinar discussing the amazing results that BMC and Follet had achieved using Agile methods.  There were over 60 participants and enough questions to last several hours, even though we had to cut it off at one hour.

Click here to view the recording.

I'll be doing a Webinar on Agile (Feb 14, 2008) with Michael Mah (Cutter & QSM) and Kim Wheeler (Follet).  We will be discussing what things have gone well with our Agile implementations, and we will be available to take questions from those attending the Webinar. 

Here's the link to register (for free).

I am asked this question at least once a week, and I’ve heard all kinds of arguments and disbeliefs in the theory of making every iteration “releasable”.  As one of the fundamental tenants of a good Agile practice and the antithesis of most Waterfall projects, the ability to keep the software in a customer-shippable format is a key measure into how “agile” a team really is.  It seems odd to me that it’s almost been a year since my last blog entry on this, and it’s still a nagging issue which we still struggle with from time to time.

So, what are the acceptance criteria for staying releasable?  Here’s a recent definition we have starting using on a daily and/or iteration basis:

• The software builds and can be installed in its current state.  (a daily requirement)
• No severity 1 or 2 defects exist.  If regression defects are found, they must be prioritized over new user stories in iteration planning.  (an iteration requirement)
• Shipping to a customer is 1 (2 max) hardening iterations away.  (an iteration requirement)

As mentioned previously, there are a variety of ways to address “the big feature at the core of code base”.  Beyond trying to break the feature down as much as possible, some methods include hiding the new functionality and using configuration to enable/disable the new functionality.  A more extreme way to solve this problem is to create a branch of the software that can be tested in some form or fashion.  This part of the software would be merged back into the main development path once it has proven its merit.  (While possible, this last approach is the least desired, due to the integration risk introduced later than normal.) 

Regardless, the actual implementation is often less important than the discussions related to mitigating the risk associated with destabilizing the existing functionality.  Having the releasability criteria often triggers conversations within the Agile teams on how to address trouble areas instead of dumping weeks of code into the product hoping for a miracle in the end.

I recently recorded a podcast on Agile at BMC and made some predictions on where Agile is headed.

Here's the link: Mike's Agile Podcast.

As many of us have discovered, coordinating three or more Agile teams is a lot of work, especially when the teams are scattered around the globe.  I “borrowed” the title of this post from Cohn’s book ' Agile Estimating and Planning', where he mentions the pains of coordinating large projects and suggests some ideas on how to deal with this situation.  For the Performance Manager group, a key item is our intense system of communication that never sleeps (literally, in some cases). 

Two of our most popular methods of communication are well known in the Scrum community, even though they serve additional purposes with our multi-cross-continent-time-zone setup.  First and foremost, daily Scrum of Scum (SOS) meetings occur with leads/leaders from every team, and these meetings occur early in morning (US time), so they are friendly for participants in India, Israel, etc.  During these meetings, all of the teams get a chance to hear what’s going on across the teams and determine whether roadblocks exist within another team that may cause a problem for other teams.  An important aspect to keeping these meetings short and productive is focusing on what’s being done or on blocking items affecting other teams.

A second important method of communication is our iteration demos, which occur every two weeks during non-hardening iterations.  Again, these are done at globally friendly times, and all of the teams get to see what the others have done.  This provides a sanity check for consistency and allows each team to accept critiques on the work from the past two weeks.  Since these meetings are recorded (via Live Meeting), the support teams and others can always use these meetings as on-going training for the new release well in advance of it being made available to customers. 

In all cases, the communication methods are setup to create total transparency and prevent passive-aggressive behaviors.  As transparency increases, the teams become more comfortable with being open and potentially “exposed”.  The main goal is to make small course corrections instead of having big rework items, but the process never gets put on cruise control because the fleet can quickly run aground.

From my experiences, backlogs are important to the Agile process for a variety of reasons, but the most important purpose is to provide a common medium for what the team should be focused on and in what order.  A backlog should reflect customer value, since the backlog has been derived from the customer (in theory).  Often, side projects and corporate initiatives skirt the backlog, creating contradictions in focus.  In Agile Estimating and Planning, Cohn describes several problems that occur when focus is compromised.  First, when team members are forced into a multitasking situation, productivity falls as switching amongst tasks becomes a burden.  In addition, the ability to prioritize is quickly lost when initiatives run parallel to the backlog.

One solution we often debate is to push these parallel objectives into the backlog and prioritize them with everything else.  The difficult thing about doing this is rationalizing the customer value in these side projects; however, the exercise alone will be well worth the effort.  The team may determine to that the side projects do not result in something real to the customer and/or increased revenue, and they may ultimately lower the priority.  In other cases, the benefits of implementing an initiative may be realized by discussing the customer impact and subsequently estimating the cost.  In either case, when these items are listed as “overhead” and left out of the backlog, there is a greater chance the team’s productivity will be lower in both real and perceived terms.  The hit to real productivity occurs due to a lack of focus; however, the perceived productivity will be lower because the list of items accomplished will be much shorter since the overhead items were never listed in the first place.

Many software companies talk about underpinning layers of software that allow various products to be built with the idea that interoperability and integration will just happen. These layers of software are called "infrastructure" in many environments. Without software infrastructures, many products are often forced to recreate the same functionality over and over, such as logging in to a system. Unfortunately, there are often many "infrastructures" which hurts the original intention of creating the base layer in the first place.

To minimize this, companies must first consider another layer, and this could be characterized as the cultural infrastructure. The cultural infrastructure is similar to getting everyone to do the wave at a baseball game. Each person can be individually shown how to standup, throw two arms in the air, and sit down; however, if the group as a whole isn't in sync, there is no wave. Setting the cultural infrastructure is often difficult because employees in a company are rarely sitting shoulder to shoulder within site distance of each other.

Setting the cultural infrastructure can be remedied (no pun intended) by first aligning goals and second, coordinating expectations. One way to do this with an Agile method is to use matching iterations and release cadences. With this model, people are thinking about the releases and planning at the same time. Adjustments needed by one team are domino-ed into the iterations of another team, and most importantly, the goal is the same for everyone at the same time.

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.