The Power of Integration

I was fortunate enough to attend TechEd Europe this summer and attend (instead of presenting) a session on MSF presented by Rafal Lukawiecki. Rafal described the changes that we have made between the old (3.0) and new versions of this framework for building processes. His session was very entertaining and won ”Best in Show”.

One of his many interesting assertions was, “Integration is a marketing term for ‘we ain’t gonna ship on time.’” It’s always interesting to hear a European use colloquial American English as part of their presentation. He was, of course, referring to the waterfall approach where components are created in isolation and brought together to create the contorted (improperly integrated), old dog. This is, as Rafal asserted, an unnatural act, as nature grows the dog from a baby puppy instead. The logical conclusion is that iterative development is the more natural way to build software.

There are many analogies that follow from this idea. However, I felt that it was time to turn this blog from overview topics like competition and project size to more detailed topics in MSF for Agile Software Development. Since integration is the topic of the day, I thought that this would be a great place to start.

Integration is not often discussed in most software development processes. This is a shame since the amount of effort involved can be trivial on many projects, and enormous on others. Some factors that increase the cost of integration include project size (large projects are costlier), embedded systems where the hardware is changing out from under them, and systems created by multiple teams or parties. But even if integration is easy on your project, it should not be taken lightly.

Here’s a question for the testers in the audience. How many times have you received what is supposed to be working functionality only to find that it doesn’t work at all? Hopefully, this is a rare occurrence but even if the answer is once, it is one too many times. I certainly don’t doubt the best intensions of the developers that gave you the system, but it may not have been anyone’s job to test that the integration produced the behavior of the scenario from end to end.

To ensure that this does not happen, we assign the scenario work item to a developer when it is scheduled for the current iteration in the iteration plan (known as the sprint backlog in Scrum). This developer is probably one of the developers with development tasks that need to be completed to implement the scenario. As soon as they can see the entire scenario working in an accepted build, they may now reassign the scenario to a tester. If an automated test case can be created to test the scenario, the automated test case is attached to the scenario. In this way, there is no confusion about whether the pieces of the scenario have been completely integrated.

Assignment to test is also a sign that the scenario (or quality of service requirement) is integrated and ready to be tested. The tester assigned the scenario lets the other testers who have test tasks for that scenario know that the new build is ready to be tested. Once all of the tests have run unblocked (and bugs created if necessary), the scenario can be closed.

One of the things that the Remaining Work report shows is whether this process is running smoothly. A widening gap in the Remaining Work report for scenarios indicates that either test is being overrun by new functionality or that too many tests are blocked. This should be an indication to the project manager that a bug allotment iteration may be needed.

Another area that the cost of integration influences is the length of the iterations. While two week iterations may be fine for small teams with minor integration costs, longer iterations may be needed for teams that incur higher integration costs. Six to eight week iterations are the norm for larger projects that may utilize teams of teams, or have larger scenarios.

All of this shows a philosophy that we have espoused all along. Understanding the dynamics of your project, including details such as integration, will help you become more efficient in building software. But these details are useless without a context-based, or configurable, software development process. MSF for Agile Software Development is such a process.

Comments

• Anonymous
  July 10, 2005
  Visual Studio Team System
  
  According to my sources, the Team System VPC that was distributed to TechEd...
• Anonymous
  July 10, 2005
  Visual Studio Team System
  
  According to my sources, the Team System VPC that was distributed to TechEd...
• Anonymous
  July 11, 2005
  Visual Studio Team System
  
  According to my sources, the Team System VPC that was distributed to TechEd...