The 2009 Software Test and Performance Conference

Last week I gave a class on SCM for Agile Teams at the 2009 Software Test and Performance Conference in Cambridge, MA. The conference had a focus on Agile software development. Good SCM is essential to agile (and any) software development, though it's an oft ignored topic, so I applaud the organizers for considering the topic worth a session. And I thank them for inviting me to give the class.

At the risk of making sweeping generalizations, I like testers, and I tend to find that the way good testers think is very well aligned with the way that I think. Maybe this is part of the reason that I enjoy agile software development so much: testing and automation are very closely tied to the development process. One of the messages in my talk on SCM for Agile Teams is that testing is an essential part of the configuration management process. If you have good automated testing, you have to worry less about branching for isolation, and you save the overhead that (unnecessary) branching adds to your process.

If you have testing established as part of everyone's (including the developers) job, the tester's job becomes far more interesting. Rather than executing scripts and reporting "simple" bugs, a tester can explore the product and find interesting edge cases, driving software quality and starting conversations about what functionality the product needs. And testers and developers can collaborate on automation.

My class was during the last session of the last day, and I was happy to have the small number of people in attendance who were there. I hope that they learned something useful, and I hope that I addressed the concerns of the testers and test managers at the session. I know that I learned a lot from sessions that I went to lead by Michael Bolton and Scott Barber, among others.

If you're interested in more about the kinds of topics that were covered at the conference, look at the STP Collaborative. (And if you want to know more about SCM for Agile Teams than is covered in the talk, you can always read my book: Software Configuration Management Patterns: Effective Teamwork, Practical Integration
:) )

Information, Interaction, and Scrum

A Scrum team that has dependencies on another group often struggles with how to integrate the other group's deliverables into their sprints. Since the other group hasn't signed up for the sprint commitment, and also has commitments to other teams, the Scrum team has the problem of how to commit to a delivery when they depend on someone outside of the team.

One way to manage dependencies is to list them as roadblocks. However, while that's a good start, it's not the whole answer. A few years ago I was working in the IT department of a large (not-a-software) company. My team was building a tool to archive a class of instant messages. We used Scrum, and consistently followed "the three questions" : what I did yesterday, what I plan to do today, roadblocks. A couple of items relating to the operations group were on the roadblock board for quite a while. While we had a designated contact in that group, he had many other commitments, and our requirements kept getting bumped.

After a while I asked the project manager if we could have our operations contact come to our daily Scrum. We promised that it would only be 15 minutes, and that this would be the only time that we asked him about the issues. After attending Scrum reluctantly for a few days, our ops contact started to be more enthusiastic, and our dependencies got done quickly, and the project moved smoothly from then on.

While I don't really know what our operations contact was thinking, it seemed to me that his presence in the Scrum helped him to understand how important his contribution to the project was. We were people he was working for, not just another issue in his work queue. Perhaps being in the Scrum helped him see himself as part of the team; people can commit to a team more readily than to a random issue.

Sometimes people suggest that, in the interest of efficiency, the best way to interact with external organizations is to generate a list of detailed requirements. The challenge with this approach is that by delivering a list of things you need rather than having a conversation of problems that you want to solve, you many end up with the wrong answer. This, combined with the teamwork aspects of having someone in the Scrum, lead me to believe that having someone join the Scrum as soon as roadblock items pile up is something to try sooner than later.

Agile works well because it focuses on individuals and interactions as a path to finding the information you need. While you need to be mindful of having too many people in every Scrum, if you find yourself wanting to pass a spec around rather than inviting someone you need to a Scrum, remember that sometimes interaction is more valuable than information.

Continuous Integration as Metaphor for Agile Methods

Build and SCM practices are essential for agile teams to deliver working software on a periodic basis. Continuous integration is an essential practice for agile teams, as described in the XP book: Extreme Programming Explained: Embrace Change, and Paul Duvall's excellent book: Continuous Integration: Improving Software Quality and Reducing Risk.

For those not familiar with the continuous integration (CI), it's a practice where a team has an automated build that monitors the source code repository for changes and builds and tests the software periodically. CI allows the team to monitor the state of the project and detect mistakes and integration errors quickly, minimizing the risk of someone on the team being stuck because they checked out broken code, and thus enabling the team to deliver quickly.

Continuous integration is also a good metaphor for agile software development not just because it's about providing feedback and enabling change, but because of the way that CI tools work.

While the concept is called "continuous" integration, most, if not all, CI tools work in "sprints." CI tools can be configured to check the repository using two parameters:

• A polling interval: How often to check the repository
• A quiet period: How much time should elapse between changes before a build starts.

There are a couple of reasons for not building after every commit. The first is that people can sometimes be undisciplined about committing change sets. You may forget a file and check it in minutes later. In this case the quiet period saves you from failed builds that are "false negatives."

The other reason for the quiet period is that, even if all the developers were perfectly disciplined about committing atomic change sets, the build system might not be able to keep up with the work of the team if it built after every change. Building after a couple of closely related changes gives you the information you need to keep the codeline healthy. Building more frequently could put you at risk of getting more feedback in a less timely manner.

While the "keeping up with the developers" problem can be fixed with technology, the idea of working efficiently by not building more often than necessary also describes how agile teams work. Teams periodically check to see what work there is, and once requirements are "stable enough" they plan and execute. This approach is valuable because chaotic change can lead to churn and reduced productivity. For example, a Sprint starts with a fixed backlog that the team plans and quickly executes. If the requirements change too much during the Sprint, the Sprint is supposed to be terminated and re-planned. In practice many teams allow for some changes to requirements, changing direction too often can waste energy.

Agile is about embracing change, but being agile is not the same as being chaotic. We configure our tools to work effectively to give the feedback we need; we can do the same with our teams.

Enabling Change

I'm starting to gather my thoughts for the October issues of CM Crossroads which has a theme of "Overcoming Resistance to Change." Some of my favorite books on the topic of enabling change are:

• Fearless Change: Patterns for Introducing New Ideas
  by Linda Rising and Mary Lynn Manns
• Becoming a Technical Leader: An Organic Problem-Solving Approach by Jerry Weinberg
  
• Quality Software Management: Anticipating Change (and other books in the QSM Series) b Jerry Weinberg
  

While I can't possibly cover all of the ground that these books do, I can share some observations I've made while trying to help teams to do things differently, such as adopting Scrum or developing a more agile release management approach.

A common reason people resist change is because they follow "rules" that they don't understand no longer apply. When these "rules" are embedded in the culture of an organization the challend to change is greater, since its often more pardonable to fail when you've followed the established practices, than failing when trying something new. This is a big challenge to overcome, and there is no easy answer to addressing this challenge, other than to be aware that this behavior may be happening. But there are a couple of things that help make enable change:

• Leading by example. Often others just don't understand that other ways are possible.
• Gather (visible) data. Often others ignore uncomfortable facts.

As an example of the first point, I've been on teams where unit testing was dismissed as simply too hard to do, or a waste of time. By a small group adopting the practice in small cases (and refactoring the more difficult code to enable unit testing), they can demonstrate how the presence of the tests helps improve quality and speed of delivery. In this way a small group of enthusiasts can lead the way for the more timid. (Really Dumb Tests discusses a similar point.)

In other cases, the team isn't aware of a problem. A colleague of mine recently said "you can't change what you can't measure," and gathering data is essential to making a team aware of a need to change. Once you have the data, you then have the ability to make decisions, and then measure whether those decisions have the desired effect.

To make this concrete, imagine a team that is estimating tasks based on a 7 hour ideal day (and an 88hour work day). At the end of each 2 week sprint the team either isn't meeting its goals or is feeling overworked, yet none of the tasks seemed more complicated than expected. One possibly is that that the teams days aren't really 7-hours. To measure this you could keep a chart on the wall, measuring team and organization meetings, adding marks to a bar chart after each activity that seems unrelated to coding. If at the end of a two week sprint this number is much higher than 10 hours (10 days*(8hours@work-7hours-coding)), then you have some options to consider:

• Run meetings more effectively
• Decide if all of the meetings add value
• Decide to estimate based on a shorter ideal day
• Decide that the work day needs to be longer than 8 hours.
• (etc)

It's important that:

• The data collection be lightweight and that everyone understand that the data need not be entirely scientific to be useful. Too much effort to gather data can derail a change effort because of perceived cost.
• The data be visible and incremental. A hand drawn chart on a wall can be more effective than spreadsheet data that lives on someone's laptop. (But electronic data can also be made visible in the right context)
  
• The team evaluates the data with a goal of improving, not blaming. Maybe the extra time was spent in meetings was well-intentioned, or even necessary.
  
• The team consider a number of options to change the situation. (See Finding and Evaluating Options for more on evaluating options.)
  

What's useful about data is that it avoids arguments about who has the most accurate memory. Collecting data may not solve the problem; the data may leave you with more questions than answers, but without data you'll have no good way to decide what to try changing, and if the change had the desired effect.

Change is hard often because people often don't understand the need for change, or the possible changes. By demonstrating the alternatives and their value, and by gathering data to evaluate current practices, you can start the process.