I really enjoy leading public CSM classes. The intensity and focus the participants bring is a blast of pure, cool, oxygen that invigorates me.

For example, the most recent class was very intense with the team asking me some really hard and crucial questions.  Then they dropped the bomb. “Hey Mike, you act like Scrum is a Silver Bullet.” Arghhh! I HATE THAT. I don’t know how many times people get that impression and how many times I have repeated the litany, “Scrum doesn’t solve anything it shows you what is happening in your organization”.  Well not this time. What jumped from my lips was “Scrum is Not a silver bullet, Scrum is a silver mirror!”.

The next day, one of the class members reported out that my ‘catch phrase’ had really worked.

Huh? The class was right behind me in asking for an explanation.

It seems he left the class last night and went back to work (we are such a bunch of OCD wonks) where is boss was talking about Scrum not being the Silver bullet he, the boss, had expected. Our teammate then popped the phrase “Scrum is Not a silver bullet, it is a silver mirror!”. This stopped the boss in his tracks as he realized that Scrum was just that, a high definition reflection of all the things that were actually going on. And if memory serves the attendee went on to say the conversation went from Scrum not meeting expectations to what was coming off the mirror.

The class, being a great one, started kicking this around. One of the comments emerged from someone saying “Talk to the hand” and became “talk to the silver mirror in my hand”.

Maybe a good ScrumMaster is a person who can have people talk to the mirror in their hand.

George pointed out that sometimes we have to rebuild systems. Sometimes they just aren’t that good. Sometimes the technology we are using is out-of-date and no longer supported. Sometimes we need to add functionality, and the design is just so bad that we can’t figure out how to add it.

My previous post about re-engineering did not discuss what to do in these circumstances. I would recommend the following:

1. Think really hard about it: is there a value proposition here? Or does the existing product do what we need it’s just not that great? Think about it again.
2. If you are certain that there is value then start a new project to replace the existing product.
3. This is the most important step. Forget everything about the existing product. Eliminate it from your brain.
4. Develop the new product in the Agile way. Find out what the customer wants to do and build software that enables them to do it. Do it incrementally and get as much feedback as you can.
5. Always, always challenge your assumptions. It is tempting to assume that the product has to work like the old one, or that you should do something that you wanted to do in the old one but never did. Forget it. Build what the customer needs.

It is worth repeating (again) that this is not a situation to enter lightly. You already have a product that is designed to meet this need. There is a real good chance you are throwing good money after bad. However, if you are going to do it, do it right — forget what you think you know. Start from the beginning. Learn at every turn.

Agile software development is really a product development strategy. Scrum has its origins in product development.  If you read the Agile Manifesto there are all sorts of hints that we are talking about developing software as a product that is valuable to some known customer.  That is product development.

Re-engineering is the activity of changing (hopefully to improve) the structure and design of software. It is distinct from refactoring which is a specific technique. Refactoring can be used to re-engineer, but it can also be used to incrementally improve the design as we add new capabilities. Re-engineering does not have to follow the contract of refactoring (small incremental design changes that preserve observable behavior.) In fact, re-engineering is often done to improve a system by changing its behavior, but not necessarily its user functionality.

If the last sentence in the preceding paragraph doesn’t scare you then I have not yet done the job I intend to do.

Re-engineering is not product development, because it is not primarily concerned with creating useful functionality for customers. Re-engineering can be customer driven, but it tends to be somewhat indirectly customer driven. It tends to be concerned with things that are traditionally considered architectural properties: performance, scalability, security, quality, usability, consistency, etc.  The customer might be saying, “This app does what I need, but it is too slow.” Something like that may drive us to re-engineer.

Re-engineering is highly problematic from an Agile point of view. We are not producing functionality. We are not working from user facing stories. There may be business value to what we are doing (such as improving the performance of our application) but it is not directly measurable business value in most cases.

Re-engineering is also too often driven by technical concerns within the team (or its management). We didn’t build it as well as we wish we had. We have learned new things now, and we want to incorporate them.

Learning is the key. Agile is all about learning. The feedback mechanisms in Agile processes are designed to help us learn as we go. The intent is that we will apply this learning immediately rather than waiting until some future (“post mortem”) time to re-evaluate.

For a functional Agile team these learning mechanisms exist at multiple (somewhat redundant) levels: TDD has tiny learning cycles that are as small as a few seconds to a few minutes. Each time a test passes or fails we have learned something. Continuous Integration is a learning cycle (Especially if we have an Informative Build.) When the build passes or fails we are meant to learn something. Stories, in the form of Card-Conversation-Confirmation are learning cycles. Releases, and the consequent customer feedback, are learning cycles. Each time we do these things we learn, and each time we learn we are meant to immediately attempt to improve.

Re-engineering is a poor business proposition. We are spending additional money on a product that is already functional. The return on that investment is hard to anticipate. We can tell the customers that we have improved the product in some ways that they may or may not be able to appreciate (or even notice.) Therefore, the risk is very high, and the best case outcome is the the product does a slightly better job doing what it already does.

Agile is not compatible with re-engineering. Agile is an alternative to re-engineering. Agile expects us to refactor our design and to incorporate our changing understanding (i.e. learning) as we develop our product, not after the fact.

I had a great time meeting a bunch of cool Agilists at the Agile Boston meeting on this past Wednesday night.  I had a chance to present on a topic I am particularly passionate about: Agile Metrics and Diagnostics.

The pdf of the presentation can be found here:

Uncle Bob Martin says programmer certification is bad. He supposes that if you start giving out certifications to people that someone will assume those certifications mean something. They will start hiring certified people preferentially, or stop hiring non-certified people entirely. This would be bad, because certification is almost certainly a poor measure of whether you should hire someone. Uncle Bob is right.

Ron Jeffries suggests that the Scrum Alliance ought to just drop the word certification. He asserts that sending people to classes is useful because they get exposed to ideas that they may not be adequately exposed to otherwise. However, going to a class should not be called “certification,” because it is imprecise and alienates parts of the community it means to serve. Ron is right.

Tobias Mayer has complained that the new Certified Scrum Developer course is no better than the Certified Scrum Master course since both are merely a couple days of training during which a human being can only retain so much. Tobias is wrong for a number of reasons. First of all, he’s not really in a position to judge something he’s never seen or done. He is also wrong because the CSD class has the one thing that all of the official Scrum Alliance classes have lacked to date – relevance to software development.

Attendees of a CSD class have to write software. This is supposed to have something to do with Agile, and the Manifesto says we value working software. So, maybe we should write some? Tobias is right to say that this isn’t enough, but it is the very first step in the right direction… ever.

I believe that it is absolutely valuable to attend a CSM or CSD course. The CSM course ought to be called, “Intro to Scrum: Do Not Try This At Home.” The CSD course ought to be called, “Intro to Extreme Programming: No Really, Someone Might Get Hurt.” The two of them together are barely a starting point. They are a little bit better than reading a book and trying to get someone to pay you to attempt what it says (The way many of us learned, including myself.) They still aren’t enough by themselves.

To be able to do this stuff well, I think you need at least the following things:

1. A commitment to do your very best and always strive to do a bit better each time.
2. Some experience attempting these practices in a setting where mistakes don’t matter: a user group, a class, doing katas on your own or with friends or coworkers.
3. Access to people who have gone before you so that you can listen and learn from their experiences, and a willingness to do so.
4. Plenty of time for these ideas to ferment and turn into something useful.

I posted this to the LAJUG mailing list, then later to the Extreme Programming Yahoo! group. Some folks really liked it, so I’m putting it up here for posterity.

The Java Programmer’s Rules of Design are, in order of priority:

1. Should not have any tests, because I wrote it so it works.
2. Should clearly express how clever I am.
3. Good idioms should be repeated often. Better idioms oftener.
4. Should contain as many classes and methods as I might possibly need
   at some point in the future.

(Read here if you don’t get the joke.)

P.S. If you are a Java programmer and this makes you sad just substitute your least favorite of: C#, C++, or Perl. It works for them too…

Hopefully you recognize that this is a play on the term information radiator, but let me explain how/why?

I find that when starting with a new client and discussing the idea that we are going to put all their tasks and activities on a wall for everyone to see and so that it’s easy for the team to update, there is almost always push back or at least hesitation. The concerns typically are centered around the fact that “well we already have a dashboard system we use here to track project status and Sr Management uses it”. My guess is they have never seen a good story board/task board wall.

So where does the refrigerator part come into this?

Well, recently my refrigerator went on the fritz and stopped working, but I didn’t know it. I noticed that items coming out of the fridge seemed to be less cold, but I figured it was just me. So I didn’t do anything. Many hours later, the problem seemed to be worsening. Lo and behold, we had a problem and ended up losing a bunch of food in the refrigerator.  We had it repaired and all was fine, until it broke again.  This time the “breakage” was more obvious, but only because I was standing in the adjacent room (there was an electrical popping sound and a puff of smoke that came out from under the unit).  If I hadn’t been in the next room, again I wouldn’t have known something was wrong.

In the end, my wife and I decided to buy a new refrigerator instead of repairing the original.  The unit we purchased was half the price of the original unit (which was only 7 years old) but has more features and fit our needs better.  We purchased based on price, look and features, in that order.  It has a feature that I really didn’t notice/appreciate until it was in my kitchen and plugged in.  A digital display that shows the temperature of the freezer and of the refrigerator.  That’s the information radiator.  It even has an alarm built in alert us if the temp rises too high.  I could have a manual thermometer in the fridge and in the freezer to tell me the same information, but the difference is, I have to go look for it.  I would have to open the fridge, find where the thermometer got moved to and read it, just like a traditional dashboard.

With my new information refrigerator every time I am in the kitchen I know if things are working as expected simply by looking.  No digging for thermometers (or dashboards located on the web or in some program management tool somewhere).  So now if one of my kids leaves the door open or if it breaks (it better not, it’s brand new), I have a much better chance of knowing and being able to take a corrective action.

So what makes a good information radiator?

• It’s highly visible
• You don’t have to go find it, it’s just always there waiting for someone to look at it
• It is kept up to date – it’s simple enough that the team actually uses it and updates it and it reflects what the team is working on
• It can alert a team to a situation that needs corrective action – it doesn’t tell you what to do, it just displays the facts, we have to do the rest
• It’s simple

I love the information radiator part of my new fridge so much, I’m not sure I would ever want one without it.  Just like I would never want to run a project without an information radiator.  Once you see it and experience the simple power of it, you’ll know what I mean.

If you are a virtual team you have additional complexity to deal with.  BigVisible has built a virtual task board (information radiator) that is free for anyone to use, check it out at www.seenowdo.com