Deitte.com

Scrum is a development process most recognizable by its 30 day sprints. Brightcove uses Scrum for all of its development. I recently went to a course from Ken Schwaber for the exalted title of Certified Scrum Master (which comes with its own secret handshake). From my notes on this course, I've written some thoughts on Scrum, which are below.

The notes below aren't meant to encompass all aspects of Scrum. For a better overview, read the Scrum wiki page, get Agile Project Management with Scrum, or take one of Ken's courses (which I highly recommend if you can get your company to send you).

1. ScrumMaster is a silly name on purpose to make sure it's not a Grand Title. ScrumMasters are there to try to help the team become self-managing.
2. Scrum should be results orientated, not effort driven.
3. If at all possible, start with the "right" way to Scrum and then customize later. Usually the changes that are requested show a problem within the organization.
4. Team self-organizes as needed. Some teams won't need their own ScrumMaster in time and will only need the ScrumMaster to remove impediments.
5. A common bad and wrong assumption is that by telling people how to do things, they'll work better.
6. Don't make Scrum an iterative death march.
7. Backlog shows the remaining time. Don't confuse this with time worked, which is simply not a part of Scrum.
8. There needs to be one product owner, who can report to other product owners and listen to the team. One product owner leads to a single decision point.
9. The team owns all aspects of development. It's not features owned by engineering, testing owned by QA, etc. There's not the normal functional groups as there is for waterfall but rather a shared "done".
10. It's important to keep Scrum teams together, as they are much more effective in time. Also, after a few sprints, teams are better at determining their velocity.
11. If a team is dependent on people external from the team, then it can't reliably commit to tasks.
12. Scrum doesn't make a lot of sense for R&D or other open-ended experiments. This isn't to mean its not for prototypes but rather that its not really suited for basic research.
13. Development often shows too much unneeded coding details to the business side without giving enough visibility into progress. It's the worst of both worlds.
14. Development should give the risk to the product owner and not try to take on risk that isn't rightfully theirs.
15. If we celebrate the amount that gets done, then the more done isn't done and future sprints slow down.
16. There's no such thing as a failure of a sprint. There can be a failure of a product but not a failure of a sprint. What gets done has gotten done and the product owner will make choices based on the new reality.
17. Expand on "done" so that tasks don't have later ramifications. Make sure everyone knows what "done" is.