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.