User>Driven

I mentioned recently that we are exploring Agile development techniques at ATG. As we work through how to adapt these techniques to our organization and project realities, I thought it would be useful to jot down our experiences, issues and solutions, both so readers increase their understanding of what issues may come up with Agile, and also to solicit advice and ideas.

In this post, I thought I'd outline our current understanding of Scrum. Briefly, Scrum is an Agile software development methodology designed to produce higher-quality output that is more responsive to market needs. it is focused on constantly delivering value rather than on meeting a specific date with a pre-determined set of features. It is characterised by:

• Work periods called "sprints," usually of 2-4 weeks, wherein the team attempts to complete some segment of work such as a short list of product features.
• An agreed-upon definition of completeness for the work, such as that it is functional, tested, documented and otherwise "done" enough that it could be shipped to the customer as is if required. Usually this requires a demo of the work at a meeting called the "sprint review" at the end of the sprint.
  
• A list of features and other work to be done called the "product backlog," maintained and prioritized by the "product owner" (the representative of the customer, usually a product manager) and updatable between sprints.
• "Just in time requirements" that are specific and detailed for what is being worked on in the current sprint but less well-defined for work that is further down the road.
• An agreement among the team members on what features will be attempted for a given sprint, and joint responsibility for delivery of that fixed list of features.
  
• Daily quick meetings run by the "scrum master" to review what's been done in the last 24 hours and what each team member intends to do in the next (called "stand-up meetings" because they are supposed to be held standing up to motivate people to finish quickly), designed to uncover issues that need immediate resolution among team members.

The team is independent during a sprint, dividing up and and completing work as they see fit, but they must demonstrate the results of their work to the product owner at the end of every sprint. Despite the autonomy of the sprint, this increases transparency and accountability. Flexibility is also enhanced by allowing the product owner to continuously adjust the priorities of the features on the backlog for the following and later sprints in response to changing market conditions and knowledge.

There is a lot more to it, but I suggest people view Ken Schwaber's video or read some of the other great material available on the web about Scrum rather than me summarizing it all here. In my next post, I will try to summarize some of the early concerns and issues raised by folks at ATG as we talk through piloting Scrum on a project or two.