The concept of timeboxing in Scrum is a critical factor for success. Without any timeboxing we quickly end up with inefficient development process, too much overhead and very low velocity. From day one it is therefore important to use the time boxing in Scrum as an effective tool to keep the teams velocity as high as possible.
The first time I learned the rules of backgammon, I was quite surprised by the simplicity of the rules. But as I read some more about backgammon I quickly came across the saying: "Backgammon: A minute to learn a life-time to master", and as I started playing more and more I came across new rules like The Crawford Rule, doubling and a lot of strategy principles! Gradually I realized that the key principles I learned about backgammon is merely a fundament, getting good requires hours and hours of training!
A couple of years later (2005), I came across Scrum for the first time and had some of the same feeling. The principles are few, are theory is very easy to understand! But as I started using scrum, first as a team member, and later as a Scrum master I discovered a never ending series of hard to handle problems and challenges. Today I see my self as an experienced Backgammon player and Scrum Master, but realize that both require both theoretical skills and years of experience!
Here I will present a couple of principles that can help you become a more valued scrum master!
Releasing new software will always involve some risk of failure whether you do it small incremental releases, or you do it in large cycles with comprehensive testing. There are however some key principles that will help you lower your risk of failure, principles which are easy enough to remember, but which we often don't follow for one reason or another......
I just came across a great summary of the daily stand-ups in scrum, written by Joakim Karlsson. I guess most Scrum teams start out with good intentions and focus in the begging, but as time goes by, we start falling into the old "around the table" reporting habit to the project manager, the Scrum master becomes more and more a project manager, and we gradually drift away from the core principles and ideas behind the daily stand-up!
Lean processes such as Scrum has no requirements regarding specific software design methodology, but on the other hand an agile software process requires an agile code base!
While struggeling on a customer project, I came across a post in Eric Lee's blog The root of all evil in Scrum
We are struggeling on a customer project to get scrum working. I joined the team a couple of months back, when they had allready been scrumming for a while, but I found a SCRUM team in a big crises. Yes they were scrumming (sort of), but as I asked them, why?
To quote Eric Lee: "If you have some kind of required process in place and you can’t succinctly explain exactly how that process enables you to deliver working software in a better, faster, and cheaper manner, then drop the process. It’s not helping."