Submitted by MichaelJames on May 10, 2008 - 10:45pm.
I had the privilege of working with Jim Schiel this week at a CSM class in Manhattan. I'm blessed to be on a team with the likes of Kane Mar, Dan Rawsthorne, and now Jim Schiel.
Some class participants were eager to discuss an interesting situation at their organization. We found ourselves in the position of trying to second guess thirdhand stories about past decisions made by a Scrum coach and an onsite uber ScrumMaster.
That night it occurred to me our role as Scrum trainers is to impart fundamental principals and past experience so that people can make their own judgements about particular circumstances they know much more about than we do.
The very few "rules" of Scrum are there to exploit basic laws of nature. Stephen Covey might call them "lighthouse principles" -- you don't break them, you only break yourself against them.
If you extend a Sprint past the original commitment, the Scrum Police aren't going to arrest you, but you'll probably miss an opportunity to learn something that would make you a better performing team in the future.
If you stuff a team with more people that can easily keep track of each other (about seven), self organization will probably suffer.
If you fail to ratchet up your definition of "done", you'll either slip your release date until you do, or ship a shoddy product.
You already knew this, but your friendly neighborhood Scrum rules are there to counteract your natural tendency toward self deception. When breaking a Scrum rule, I suggest asking yourself whether you're doing this to mask an organizational impediment.
Recommendations on the other hand, are more situational -- sometimes wrong for a given circumstance. Should the taskboard be updated during the Daily Scrum, or beforehand? Should technical debt be exposed on the Product Backlog? Can we have a team of ten if they have really good teamwork skills? Is adding a new person to a team more harmful than taking someone away? Ask ten Agile experts and get eleven different answers. We've all discovered different tools to get on the same pathway.
I had the privilege of working with Jim Schiel this week at a CSM class in Manhattan. I'm blessed to be on a team with the likes of Kane Mar, Dan Rawsthorne, and now Jim Schiel.
Some class participants were eager to discuss an interesting situation at their organization. We found ourselves in the position of trying to second guess thirdhand stories about past decisions made by a Scrum coach and an onsite uber ScrumMaster.
That night it occurred to me our role as Scrum trainers is to impart fundamental principals and past experience so that people can make their own judgements about particular circumstances they know much more about than we do.
The very few "rules" of Scrum are there to exploit basic laws of nature. Stephen Covey might call them "lighthouse principles" -- you don't break them, you only break yourself against them.
You already knew this, but your friendly neighborhood Scrum rules are there to counteract your natural tendency toward self deception. When breaking a Scrum rule, I suggest asking yourself whether you're doing this to mask an organizational impediment.
Recommendations on the other hand, are more situational -- sometimes wrong for a given circumstance. Should the taskboard be updated during the Daily Scrum, or beforehand? Should technical debt be exposed on the Product Backlog? Can we have a team of ten if they have really good teamwork skills? Is adding a new person to a team more harmful than taking someone away? Ask ten Agile experts and get eleven different answers. We've all discovered different tools to get on the same pathway.
--mj