Heh - Being late from lunch to the first part, I missed the opening, where Joseph ran a video of an unmanaged - but efficient - traffic intersection. No lights, no signs, seeming chaos - but no accidents, and continuous flow.

So on to Scrum Practices:

• Iterations of 1 to 4 weeks
• Team builds functionality that includes product backlog and meets Sprint goals
• Team self-organizes to achieve goals
• Team conforms to existing standards and conventions
• Abnormal termination of Sprint:
• Team can cancel Sprint if the goal of the Sprint is deemed to be unattainable
• Product owner can cancel based on external circumstances changing

An interesting heuristic for Sprint length: How long can management shut up and allow the team to work? Another interesting comment: "The purpose of meetings is to keep people from taking responsibility".

Product Owner:

• Takes ownership of the backlog
• Can be influenced by committees, management, customers, sales (etc)
• Responsible for ensuring that the most important business functionality is delivered first
• Ensures that one (and only one) set of requirements drives the project
• Eliminates the confusion of multiple bosses, interference, etc

Scrum Teams:

• Cross Functional
• Selects the iteration goal and specific work results
• responsible for committing to work
• Self organizing
• Authority to do whatever is required to meet goals
• Open, co-located space
• Demos work results to the Project Owner

Ideal team size: Seven +/-2. That's the largest size that can sit at a table and all engage in one conversation.

Scrum Master:

• Responsible for establishing Scrum practices and rules
• Representative to management
• Representative to team
• A coach
• Engineering and Development skills
• Agile version of IT project manager

The Lead developer really can't be in this role, due to conflict of interest issues. A Scrum Master can be defined as a "Servant Leader".

There are few roles and few practices - Scrum is low overhead. There's a Product Planning Meeting, where requirements emerge. From that, a product backlog gets put together - this consists of functional and non-functional requirements. Anyone can add to the backlog, but the Product Owner is the only one who prioritizes.

Estimates for work - like produce - have a "sell by" date, and that date is the end of a Sprint. At the end of a Sprint, the estimate will either be past (i.e., functionality delivered), or need revisiting. Joseph recommends this book: "Agile Estimation and Planning" by Mike Cohn, as a good source of information about how to do agile planning.

Scrum Planning Meetings:

• What's on the backlog
• What are the Team Capabilities (who can do this?)
• What are the Business Conditions?
• How stable is the technology? What's Changed?
• Executable Product Increment (what did we do last Sprint)

The goal is to plan the next sprint.

Daily Scrum Meeting:

• 15 minute status update - trick to get people there on-time: last in talks first
• Same place/time every day
• Meeting room
• "chicken and pigs"
• Three questions:
• What did you do yesterday
• What will you do today
• Do you have any impediments blocking your progress?
• Impediments and Decisions

Another thing here - Joseph recommends lightweight tools. Index Cards, Spreadsheets, web-based equivalents for distributed teams.

Sprint Review

• What did we do?
• Retrospective
• New priorities set
• Team devises solution to most vexing problems

Common complaints as to why "it won't work for us"

• We don't have the right people
• Requires business involvement
• Project is too big for Agile
• Project is too complex for Agile

In all these cases, there's a business problem. You know you're doing Scrum when "things come together" - you realize that you can start a project without all information, the team starts to work as a team of developers.

Technorati Tags: smalltalk