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".
- 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
- 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.
- 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.
- What did we do?
- 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