Agreed

Paul Parker — Wed, 14 May 2008 10:13:25 -0500

I've worked with various Scrum teams from several organizations with the intent to follow "good" Scrum practices. In each case we did things a little differently to fit the team and organization while maintaining the spirit of Scrum. I like the idea of using the physical or virtual task board during the daily Scrum to capture updates "live"; it provides the visualization of the team's progress and commitment.
pvp

I had the privilege of

MichaelJames — Sun, 11 May 2008 01:45:44 -0500

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.

--mj

Scrum Orthodoxy

jschiel — Wed, 7 May 2008 13:55:51 -0500

I've finished my first week and my first class as a Danube employee and trainer.

Danube - Scrum Orthodoxy - Comments

Agreed

I had the privilege of

Scrum Orthodoxy