Not where no man has gone before, but how to solve day to day problem

Problems look mighty small from 150 miles up

New Blog started on November 1th, 2014

Rethinking SCRUM

At my company we are following an agile development process we call scrum. We have started this thing on our own, read some information on the internet but realized that our SCRUM was something different than the thing Jeff Sutherland had in mind. But after all it might not be perfect SCRUM but it worked for us. Last week we now had the chance to invite a professional SCRUM trainer to review and improve our process. Here are some lessons learned from SCRUM in practice. This is not ment to be the perfect process it's agile so it's all about feedback.

A word about SCRUM

If you are not experienced with agile development or SCRUM you should read the Agile Manifesto and some good trainings book (I don't want to recommend one because I haven't read one when I was new to SCRUM). This post is about beyond the basics, its about my real live SCRUM experience.

SCRUM in practice

  • SCRUM has a daily standup meeting. If your team is unable to do so, because you have a distributed team or people working at their home office make a phone conference. It's important to do a daily scrum meeting not how.
  • Keep each sprint of equal length. Changing the sprint length will not only make the sprint result unpredictable but will also weaken the commitment of the team to the sprint goals.
  • Teams are immutable, whenever you change a team member you'll get a new team!
  • Consider using a function point cost estimate. I've heard about this method years ago but never considered using it. At our company we have a team with very different programming experience, by using function points we address the complexity of the project, not the time one of the team members expects for solving it.
  • Create an write down a definition of done. It is much better if you have a written commitment when you are ready than just a weak expection which differs form team member to team member.
  • Be honest for your estimate costs. Keep in mind a SCRUM team is responsible for everything, not just writing code. Calculate everything to get rid off your technical depts. It will be be much more expensive if you fix your problems later.
  • Protect your sprint. Do the things you've commited to, keep focused and don't change them. There is always the danger to get things almost ready but getting nothing really done, be aware of this.
  • Try get an external SCRUM master. A SCRUM master should as much outside of your team as possible, so he can moderate the SCRUM problems, without being involved in de development or the management. What external means depends on your team, he or she can be from a different team, a forein organisation or even a freelancer.


    Also Agile is a little bit outdated these days, SCRUM may be one way to go for. But be aware there is no perfect SCRUM, it's all about improvement. You must find your own way for your team.

comments powered by Disqus