M4N is used to develop its software in an Agile way. We develop in relatively short cycles, we create as few documentation as possible, we anticipate for change and work via personal interaction instead of via formal processes. A few months ago we decided to take this to a higher level and we “officially” embraced the Scrum method.
Now that we have finished a handful of Scrum sprints we can share our first lessons.
What we like about Scrum:
- As the timeframe is short, developers can plan their work precisely.
- The team delivers finished software that is ready to test.
- The whole company is involved. By announcing Sprints internally and making progress visible, the entire organization knows what the development team is currently working on.
- The team likes the diversity in tasks
- It is fun to work in a committed team that is self-organized.
What we learned:
- Keep the team small. Five developers (plus or minus two) is the maximum.
- Make sure the team is not exposed to external interferences.
- Don’t make the Sprint too long. Two or three weeks is best.
- Make sure the Scrumboard is always accessible by the team.
- Make the team homogeneous. Each member should be able to work on each ticket, so members don’t have to wait until someone has finished his task.
- Automated testing. The organization of the deployment process must be ready for releasing frequently. This means the organization requires a whole lot of automated testing facilities.
- It is a challenge to involve remote employees, but it is possible.
We are pretty enthusiastic about Scrum though we realize that Scrum is hard to implement seamlessly.