Fail, To Succeed

I was listening to a commentary on NPR about a pre-school graduation which mentioned a comment from an education expert Leon Botstein that "we should be rewarding: Curiosity. Creativity. Taking risks. Taking the subjects that you're afraid you might fail. Working hard in those subjects, even if you do fail. We should reward children when they show joy in learning."

This led me to thinking about a reason that some teams struggle with being agile. Agile teams are good at making corrections based on feedback. For this to work you need to be willing to honestly evaluate your progress against a plan, and be willing to revise the plan (and how you work) based on this feedback. This is a hard thing to do if you're used to the idea that any feedback other than "you're doing OK" is bad. (I have more to say about this in a contribution to the 97 Things Every Programmer Should Know project.)

Agile methods help you create an environment where it's safer to try things by providing for feedback at such an interval that things can't go that wrong. By making small steps and evaluating the results, you can take small risks that you believe will be for the better. And if it didn't work out, you haven't lost that much.

This process is visible at all scales in an agile project.

Sprint Reviews give the team a chance to evaluate features every sprint. It happens that, based on review feedback that features are removed as well as added or enhanced. And that's fine because the team only spent a week or two. In other environments such decisions might not be made til it was far too late to change course and either implement something new or avoid embarrassment.

Integration builds give the team rapid feedback when a code change causes an integration problem (even when the developer thought that it was adequately tested).

Unit Tests give you a chance to understand the impact of a refactor before you commit a change. You can see a problem before anyone else is affected. And you can decide to abort a change with unintended consequences.

Frequent commits to a a version management system allow you to recover from changes that become more involved than you thought.

Being willing to fail allows you to improve as long as the failures are small and easily identified. Being agile means being willing to take small risks.

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.