Scrum

Basic Guiding Principles

Reed House systems uses an adapted form of the Scrum process, with some Crystal Clear and other agile methodologies included. Here is an initial shot at describing the way we do things:

1. Teamwork and trust as a basis for going forward
2. Work organisation in agile cycles..
3. Joint statement of tasks at the beginning of a cycle
4. Close cooperation on decisions about which tasks and when by team members
5. Use of a pinboard tool to track tasks (photo)
6. Daily meetings, even if a team member is missing
7. Demonstration of running, checked in code at the end of the cycle
8. All checked in code is accompanied by an up-to-date Maven file
9. Cycle.length = 1209600000 (milliseconds)

Everyone Must Get Involved

Additionally, we like the following by Martin Fowler:

Here's a common misconception about agile methods. It centers on the way user stories are created and flow through the development activity. The misconception is that the product owner (or business analysts) creates user stories and then put them in front of developers to implement. The notion is that this is a flow from product owner to development, with the product owner responsible for determining what needs to be done and the developers how to do it.

A justification for this approach is that this separates the responsibilities along the lines of competence. The product owner knows the business, what the software is for, and thus what needs to be done. The developers know technology and know how to do things, so they can figure out how to realize the demands of the product owner.

This notion of product owners coming up with DecreedStories is a profound misunderstanding of the way agile development should work. When we were brainstorming names at Snowbird, I remember Kent suggesting "conversational". This emphasized the fact that the heart of our thinking was of an on-going conversation between customers and developers about how a development project should proceed.

In terms of coming up with stories, what this means is that they are always something to be refined through conversation - and that developers should play an active role in helping that definition.

• spotting inconsistencies and gaps between the stories
• using technical knowledge to come up with new stories that seem to fit the product owner's vision
• seeing alternative stories that would be cheaper to build given the technological landscape
• split stories to make them easier to plan or implement

This is the Negotiable principle in Bill Wake's INVEST test for stories. Any member of an agile team can create stories and suggest modifications. It may be that just a few members of a team gravitate to writing most of the stories. That's up to the team's self-organization as to how they want that to happen. But everyone should be engaged in coming up and refining stories. (This involvement is in addition to the develpers' responsibility to estimate stories.)

The product owner does have a special responsibility. In the end the product owner is the final decider on stories, particularly their prioritization. This reflects the fact that the product owner should be the best person to judge that slippery attribute of business value. But having a final decision maker should never stop others from participating, and should not lead people astray into a decreed model of stories.

Original can be found here