Ken Schwaber on Google Tech Talk

Here is an excellent video where Ken Schwaber (co-creator of Scrum) explains what Scrum is and where it came from. He also explains how everyone can create their own design dead software and how to avoid it.

I have summarized and paraphrased some of the key points.

Scrum is not a methodology - you are on your own

Scrum isn't a methodology and as such does not have answers on how to do things. It frees us from the belief that someone else can tell us what to do in every circumstance and that it'll work. Scrum's assumption is that you are intelligent and that you will use that intelligence and your experience to come up with the best solution for whatever circumstance you are in right then.

Most Scrum implementations fail because of denial

Scrum gets all of the news visible, whether it's good or bad. It assumes that intelligent people will want the news so they can do what is best for the entire organization. Because of this only about 30-35% of organizations manage to implement Scrum successfully. Most organizations don't want to be faced with something they don't want to see.

The Core problem

Very common problem in all organizations is Core or infrastructure software that all the company's software depends on. Usually such software is fragile, does not have a test harness and there are only few developers in the company who know it and are willing to work on it. The Core software then effectively constrains all development in the company. If you don't have enough money to rebuild your Core and competition is breathing down your neck, you should shift into another market or sell your company.

You don't have to buy your Core, you can make your own. Squeezing a bit more "must have" features into your releases works in short term, but leads into cutting quality. Soon your team's capability to deliver starts dropping because they are working on a worse codebase. That leads into more squeezing, and after five years you have your own design dead product that will kill your business.

There are two main problems here. First, when developers are told to do more they cut quality without telling a soul. Second, product management beliefs in magic that to do more all they have to do is tell developers.

The solution is incremental and iterative development, and managing releases by scope rather than by time. In Scrum also every team has a Scrum Master (the prick), whose job is to make sure the team does not cut quality.