… said Agitar CEO Jerry Rudisin from SD Times.

“The practice works, but it hasn’t taken off as a mainstream practice.”

In 2008, I find this quote surprising and saddening that we still do not have software developers recognizing the need for automated unit testing. Sure, a lot of people now talk a good game about unit testing (how can they not since it is talked about so much), but they don’t really buy it. I see it with the teams I work with today and teams I worked with in the past. When I was interviewing at SAIC, I specifically asked the team if they did unit testing (it was my minimal qualification for the job) and I got nods from everyone at the table. Little did I know that we were talking about completely different things: I was talking about Michael Feathers’s definition of unit testing and they were talking about a more classic definition of unit testing. It was an immediate mismatch of expectations and goes back to an earlier post on being precise in language.

So how do we bridge the gap and help people understand the value of automated unit testing? I think the first step is to help people understand that testing is really a design activity. Writing automated unit tests is defining your API so that it may be consumed by its very first client, the test harness. I have always believed (and found through practice), that if your application is hard to test, the design is likely overly complex. Tests that are hard to set-up, or exercise, normally mean the classes are too tightly coupled. Or put another way, the classes know too much about the internal workings of other classes and your design concepts are not properly encapsulated, i.e. you have leaky abstractions.

I understand it is hard to change the way we code, especially if we have habits that have helped us be successful for many years. However, what really has helped me crystallize the importance of writing automated unit tests and practicing TDD is a quote I heard from Alan Shalloway, and I am paraphrasing here:

“I am putting the bugs into the system. There are no people, or gremlins, coming in at night sprinkling bugs while I am gone. It is me, so I need to do practices that stop me from putting more bugs into the system and TDD is what works for me.” [emphasis added]

So, I guess the first thing that needs to happen is not learning testing is a design activity, but accepting responsibility we are responsible for the low quality and wanting to make things better. Without that, unit testing will never take off.

There was some really interesting art on the site of the this year’s Code Camp.  I snapped a few pictures and forgot to upload them.  I like public art since it can be very stimulating to the mind and when you are not expecting it, quite a surprise to encounter.

Lost the art during the blog move – 01/31/2009 CEN

On the Scrum mailing list, Alan Shalloway came up with a great list for questions you need to answer before starting your Scrum teams. In his experience, this checklist becomes very useful after the organization reaches 75 people.

• How do I know I’m done planning?
• What documents do I have?
• What do I know?
• How do I know I’m ready for my first Sprint?

These are the business and architectural requirements for starting the first Sprint.

• Project/Product Vision Statement, OBT (Why are we here?)
• Release plan set
• Product backlog established and visible
• Initial Estimate w/Top-Line (story points) established and visible
• Sprint length set
• Prioritized and estimated Feature list
• Architectural goals/approach identified and visible
• Dependencies & Risks Identified and made visible
• Conceptual design completed

The Team and their Environment also needs to be prepared before embarking on Scrum.

• Team established with roles set
• Trained in Lean-Agile Software development (process and technical practices)
• Definition of “Done” established and documented (unit, functional, acceptance)
• Testing approach committed to (Unit, Functional, Acceptance) and visible
• Information radiator established and visible
• Tools for testing, coding, integrating, building selected and installed

Last weekend I went to the Churchill Cup in Chicago, IL. It was a very fun rugby tournament and I had a great time. I never went to Chicago before, so it was great fun to visit a new city.  Chicago has great architecture and very good restaurants.

The winners at the tournament were England, Ireland and Canada. I had hoped the Argentina team would do better, but they wilted in the second half to Ireland. The England\Scotland match was very close up until the end and was some excellent “footie”. Unfortunately, the US Rugby Team lost and sadly have a long way to go to be competitive in international rugby.

I have provided some pictures from the England\Scotland match.

Kent Beck, the father of XP, made some Wordles on What is XP and the XP Corollary Practices. They are very neat visualizations on the process.

Just wanted to post a “head’s up” that I will be speaking at the San Diego Code Camp at UCSD Extension. This will be my third year at Code Camp (started at the first one in Fullerton in 2005) and I will have three presentations this year.

1. ScrumMaster Tools for Change - I will show three tools I use frequently when implementing change on a team.
2. What I Learned About Scrum By Doing It - highlight what I think are the key parts of Scrum that you must use & apply if you are to call it Scrum
3. Top Ten Refactorings - my classic presentation on the ten refactoring every programmer should know by now.

I very much like the Code Camp concept since it is people in the local community talking about things they are passionate about.  As we often do, the members of XPSD will be presenting many sessions on Agile software development practices and techniques.  If you plan on attending Code Camp, then stop by and say “Hi”.

One of the things I strive for in my work is to make sure that when people are doing Scrum, they are really doing it. My reasoning is that if you are going to go through all the effort and extra burden of Scrum, you might as well do it right and then decide if it is worth it. Unfortunately, in the course of my time helping teams implement Scrum I have seen a lot of what I would call “bad Scrum” and teams jettison the process without really doing (most of) it. Here are the common anti-patterns I have come across in the last year.

“We are doing Scrum, but …”

1. “… we don’t have a Product Backlog.”
2. “… the Product Owner does not prioritize our work.”
3. “… our manager tells me what to do.”
4. “… our ScrumMaster tells me what to do.”
5. “… the only thing we do is fill out the Excel spreadsheet .”
6. “… we don’t meet everyday ’cause we all work right next to each other.”
7. “… we don’t do Retrospectives.”
8. “… I just email my status to the ScrumMaster.”
9. “… there are too many meetings. Can we cut some of the meetings?”
10. “… it does not improve the quality of our product.”
11. “… it still feels like business as usual.”
12. “… no one removes obstacles.”