Click here to view the recording.

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

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.

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

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.

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.

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.

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.

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.

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.

Unit testing
JUnit - (open source)
HttpUnit – (open source)

Acceptance testing
Fit  - (freeware)
Fitnesse - (freeware)

Functional testing
WATIR - (open source)
Autoit - (freeware)
Selenium - (open source)

For the most complete list of test tools (both open source and for pay) I’ve seen compiled on the Internet, take a look at this site.  Also, Brett Pettichord, who is responsible for writing several tools himself, has an exhaustive review of many other open source tools for those that need even more information.

First, the soft skills aspect of the meeting continues to retain its value.  This is the continued bond between a group of people struggling to accomplish a similar goal.  Gathering everyone together once a day, even if via conference call, provides a continual reminder of each person’s commitment to the project.

Second (and my personal favorite), transparency is forced to the top.  Conducting these meetings daily prevents any passive-aggressive behavior from creeping back into the process.  In other words, individuals and groups can no longer sit on a problem for weeks, only to surprise the overall group at the tail end of a release, when it’s too late to make adjustments.  The opportunity to discuss issues and delays is presented every day, and the privilege to divulge blocking issues should be used to its fullest.

Third, the ability to reprioritize is one of the key strengths to a fully functioning Agile process, and having this opportunity every 24 hours is a significant benefit.  This is especially important when there are multiple Agile teams, and the team lead is gathering additional information from the other teams.

Overall, the goal for our software engineering teams (and most others) is to create “working software” faster and with more relevance to our customers; consequently, the posts on this blog will be focused with that objective in mind.  To be certain, I make no presumption that any methods or suggestions discussed here are flawless, so any and all feedback is always welcome.