Scrum Introduction at RailsCamp

I did end up giving a talk at RailsCamp on Scrum. I'd had a few conversations about client management the previous day so I pitched it at a reasonably introductory level. The audience that showed up was probably about half familiar with scrum and half not. I think we got through a pretty good overview of the Scrum process and the experienced folks caused a lot of really interesting discussion.

Scrum

View more presentations from breccan.

During the talk estimating/sprint size and client trust became a significant part of the discussion. A number of people had issues with picking an amount of work and suggesting that that amount of work should be concrete for the sprint. I mentioned a few ways of minimising or accepting this and there are probably many other methods:

• Set stretch targets at sprint planning by putting some targets in the sprint at the bottom of the sprint backlog. This way there's something to do if you run out, they should only be done if you really finish the other tasks and there's no penalty for not reaching them.
• Regardless of having slightly less work, there's almost always something else for developers to be doing. From refactoring time to working on side projects there's never likely to be a shortage of work.
• Clients are going to be happy with consistent work and meeting the goals they've started with. If velocity needs to change that should be worked out before the sprint.
• Developers are most likely going to be happier if rules agreed on at the beginning of the process are kept throughout, changing things at odd times is likely to have odd flow on effects.
• Any change to these rules can be easily addressed according to team desires during the retrospectives and planning for the next sprint.
  

My general belief is that by maintaining consistency in process and methods, clients and teams will have a more comfortable feel for what's happening in the project. All parties are likely to trust each other more. Parties that trust each other(where the trust is justified) are more productive than groups that are trying work everything through an adversarial state of requirements and contract negotiation. Scrum occupies a similar position in development to manners in general society by allowing people to have a set of behaviours that allow for smooth communication without intimate knowledge of each other.

The talk also spawned a talk on Kanban a project management system with some interesting properties that I might blog about sometime(it also has inbuilt support in cucumber).