Skip to main content


Showing posts from October, 2009

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 ad…

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 gett…

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 t…

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 MannsBecoming 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 f…