Windcuffer

I was reading the may 2009 issue of Harward Business Review and came across this very interesting interview of J. Richard Hackman a Professor of Social and Organizational Psychology. It’s called ‘Why Teams Don’t Work’. Professor Hackman has a long career studying teamwork and this interview summarizes his most important findings.

While I was reading I couldn’t help thinking that all his work is highly relevant to any software producing team and to those seeking to implement Scrum or some other agile process. One quote that immediately stands out: ‘… research consistently shows that teams underperform their great potential.’. So how do we ensure that we aren’t stuck with an underperforming team ?

Professor Hackman has five basic conditions for building effective teams. Teams must be real, they need compelling direction, enabling structures, a supportive organization and expert coaching. On some level these are the same things we are trying to achieve with Agile. Let’s review each point in detail in the context of Scrum.

Teams must be real means people need to know who is on the team and who is not. Scrum provides a really good implicit way of reinforcing the meaning of team. The Daily standup. Basically anyone who participates on a regular basis is on the team. Of course other forces in the organization can sabotage this view of the team. But then it should be the ScrumMaster’s job to raise this as an impediment.

Compelling direction comes when the team members know, and agree on, what they are supposed to do together. Here Scrum actually has several tools to provide direction. First the Product Owner is supposed to articulate an overall vision of the product. Then the PO sets a goal for each Sprint. Finally the various backlogs are guiding the team in what each release and sprint are supposed to produce.

Enabling structure are the actual tasks teams are supposed to do, the mix of members in the team and norms of conduct. Scrum says that a team has to be ‘cross functional’. That is the same as saying we need the right mix of members to produce the intended result. The design of tasks is something the team is doing itself and shouldn’t cause a problem assuming the actual product backlog items are defined in sufficient detail. Scrum itself doesn’t say much about norms, but Agile in general does have values and principles. Having a definition of ‘DONE’ and a working agreement for the team are ways of defining ‘norms of conduct’.

Supportive organization is something that Scrum or any agile process by itself can’t provide. But these things should come out as impediments very soon. Problems with reward systems, human resources systems and information systems are the things the ScrumMaster needs to solve to improve the team.

Finally the expert coaching bit is interesting. Apparently studies have shown that coaching focusing on individual performance doesn’t improve actual teamwork. Instead teams need coaching as a group in team processes. The ScrumMaster obviously provides some coaching, does this mean we should also send a team new to Scrum together to a Scrum course ? This is something I have to research more.

Professor Hackman has written a book called ‘Leading Teams’. I have to read that as soon as possible. Even this short interview reveals that the content is relevant to the everyday work of ScrumMasters and Scrum Coaches. It also tells us that we as Agilists should follow social psychology studies much more closely.

Yesterday I was at the monthly Helsinki Agile Dinner and the conversation turned to one of Marko’s latest blog posts where he expresses his conviction how unit tests sometimes aren’t needed. I actually agree with the basics of his argument. He isn’t even the only one who has talked about similar things lately. Look no further than Luke Francl at InfoQ for example.

Shortly after we talked about the blog post, we covered how to test legacy systems that have all kinds of barriers to testing. The basic thought being played with was something along the lines of ‘just use automated acceptance tests’. I interjected with ‘…except when you have a component that is easy to isolate from the system.’ At that point I was asked ‘What’s the value of your unit test?’. I couldn’t come up with a well thought out response on the spot, but here’s a second take.

The unit test itself has no value at all. It is only valuable if it actually can help me isolate problems with the system. I regard that as it’s primary function. Luke talks about the fact that 80 percent of problems are usually in 20 percent of the code. The old 80/20 rule. Fine. That’s probably as close to the truth as anything we can get without actually measuring some real projects. Now even if we had a pretty good set of acceptance tests for our application, those tests cover a lot of ground. They may show us that there is a problem with our code, but the problem could be in five different places. I know, that probably means there is something else wrong with the code, but we are talking legacy applications that have a varied history here.

If I’ve identified some moderately complex functionality in the code, and extracted it into something that I can test with a unit test then why not do it ? Since you are refactoring it will only add 15 to 35 percent to your overhead. I never write the test for something that I don’t have to change anyway. This is important if you think about the costs involved. If at a later date my acceptance tests suddenly start failing I can refer back to my unit test. Does the component still do what it’s supposed to ? And of course ‘Am I testing the right thing ?’. If the unit tests look like the component still works I can start looking elsewhere for the problem. I think the value of having at least some unit tests is just that, it will save you some time localizing the problem. I guess the question that remains is ‘Will you gain back your time investment into writing the test ?’.

Oh, one more thing. The acceptance test presumably goes through your GUI to test things. Does your GUI really control all of the inputs to your code ? I’d say probably not. Some things just are much easier to test with a unit test than setting up the acceptance test in a way that can actually cover the area. Of course we could start an argument about what is proper acceptance testing, but that’s a whole other discussion really.

Crystal Clear is a software development process suitable for small teams. The book of the same name by Alistair Cockburn is the definitive work describing this process. Essentially this is a book for teams beginning with agile development and contains a lot of practical advice on both the values and practices you should be following. Or in the Shu-Ha-Ri division of learning favoured by Alistair Cockburn this book would be a description at the Shu-level. If you happen to be just starting out Cockburn’s book is also easy to read and explains the concepts well. At just 300 pages it should be quick read. There are however a few good reasons to read this book even if you aren’t going to implement Crystal Clear.

Not uncommonly the book is divided in three parts. The first part explains what the values and practices are for this methodology. In the middle there is a part with examples of the work products from actual projects. Mostly this means a lot of pictures of walls with things on them. Finally in the end we have a few chapters dealing with common questions and mistakes and a single case-study.

So far you might ask, why should you read this book ? It’s the techniques and work product examples. Going back to Shu-Ha-Ri or follow-break-leave, this book will also come in handy at the breaking level. According to Cockburn at the breaking level you are gathering information on different techniques and learning when they apply and when they fall short. So it’s useful to have alternatives which you can compare to what you are currently doing. So far most people trying to be agile are doing Scrum or XP or both. But agile development is supposed to be about the values. And withing those values there are alternative approaches that still qualify. Learning a bit about what’s beyond the current favorite process helps see things in different light.

So what are we left with ? A description of a software development methodology that’s easy to understand for the most part. Some good suggestions for actual practices to use and even some reflection on common problems in software development. All in all an interesting read and a book that I’ve gone back to more than once when looking for ideas.

Hello, my name is Sebastian. My weblog is called Windcuffer in reference to a hawk. This site will continue a weblog I started some years ago, but never really managed to update with any regularity. Also the old system wasn’t based on a real blogging engine, but used a template system that generated some static pages.

I won’t be importing most of the old posts, since I don’t think they had that much interesting content. Maybe I’ll write updated versions of some of them in time. Anyway, my areas of interest include Agile Methodology, Ruby, Java, Architecture and various other bits like general science etc. So expect to see posts around those topics.