Inductive Bias

Last week I attended a discussion meetup with Ken Schwaber in Berlin/ Kreuzberg. The event was scheduled pretty shortly - still quite a few developers and project managers from various companies in Berlin showed up.

Ken started with a brief summary of the history of Scrum: Before there was such a thing as an IT industry programming actually was a lot of fun. But somehow the creative job was turned into something people tend to suffer from pretty quickly as people tried to apply principles from manufacturing industries to software "production". Suddenly there was a distinction between testers, programmers, architects... People tried to plan ahead for months or even years noticing only very late in the process that the outcome was by no means what was needed when the product finally was ready.

In contrast to waterfall Scrum comes with very short feedback loops. It comes with developers working with very strong focus on one task at a time. Change is not hated but embraced and built into development.

Some features of Scrum that are often forgotten but never the less essential that were discussed that evening:

• Scrum is all about transparency - it's about telling your customers what is going on. It is about telling your customer honest estimations. It is about telling development to the best of your knowledge all that can makes up for a feature.
  
• Scrum is neither easy nor a solution in itself. It is simply a way of uncovering problems very quickly that are easier to hide in waterfall processes. You have one person who is an isle of knowledge in your company? At every sprint planning this problem will become obvious until you find a way to solve it.
  
• Scrum is about giving developers a box of time that is not to be interrupted. Developing software asks for a lot of concentration. Getting interrupted and resuming work on the task again is so expensive that there is close to nothing this can be justified with.
  
• A nice way of doing Scrum is to use Scrum for management and XP for development. Scrum does not provide any solutions on how to reach the goals set - it does not tell you exactly how to arrive at a stable release by the end of your sprint. It just sets the goal for you. On the other hand XP holds quite a few development best practices that can help achieve these goals.
  
• It needs time to change how customers and developers are working: Yearlong experience has trained them to think in certain ways. So at the beginning Scrum is all about teaching and training people. It takes time to learn a new way of getting things done.
  

There are ways to do fixed price contracts with Scrum. You just have a few more freedoms to offer to your customer:

• Tell your customer that your clients usually change their mind underway. Give them the freedom to change anything not yet implemented. An item can be exchanged with an item of equal cost for no increase in prize. An item can be exchanged with a cheaper item with a decrease of cost, it can be exchanged with a more expensive item for a rise in cost.
  
• Tell your customer that you already have pre-priorized items. The client is free to re-prioritize items as he wishes - as long as the item was not implemented already.
  
• Tell you customer that as you are implementing those items at first that have a high priority you may come to a point where those items not done are not important for release so he could eventually stop early and pay less.
  

In summary the evening was very interesting and insightful for me. It helps to talk about Scrum implementation problems. To learn which problems others have and how they attack these problems.