An in-house practice session for Agile Training was conducted by Write Concept on Saturday, 5th June, 2010.
The workshop aimed at giving us an overview of Agile methodology so that by the end of the session all of us have a basic understanding of the same. The day-long session was highly interactive and focused on the popular Agile methodology – Scrum. The instructor (Vasanth) used slides, videos, exercises, and handouts to provide us with a working knowledge of Scrum.

Scrum was a totally new concept for all of us. We learned about the benefits of Scrum over the traditional waterfall model. Scrum is more beneficial as it is more realistic and emphasizes on building working software that people can get their hands on quickly, versus spending a lot of time writing specifications up front. This is because Agile development focuses on cross-functional teams empowered to make decisions and rapid iteration, with continuous customer input along the way.

Product or application development in Scrum structures development in cycles of work called Sprints (2-4 weeks). These are time-bound and are never extended. At the beginning of each Sprint, items are selected from a prioritized list called Product Backlog. The team commits to complete the items by the end of the Sprint. Every day the progress is reviewed and at the end of the Sprint, a working product that is integrated, fully tested and potentially shippable is available.

In Scrum there are 3 roles – the Product Owner, Team and the ScrumMaster. The Product Owner is responsible for maximizing return on investment by identifying product features, translating these into a prioritized list, and continually re-prioritizing and refining the list. The Team builds the product that the Product Owner indicates and is a team of seven plus or minus two people. For a software product, the Team might include people with skills in analysis, development, testing, interface design, database design, architecture, documentation and so on. Scrum Teams work best if all members are 100% dedicated to the work for one product during the Sprint and avoid multitasking across multiple products or projects. The ScrumMaster helps the product group learn and apply Scrum. He or she serves the Team, protects them from external problems, and educates the Team in the skillful use of Scrum. A ScrumMaster is a dedicated member of the team and can come from any background or discipline. The ScrumMaster and the Product Owner cannot be the same individual.

The first step in Scrum is for the Product Owner to articulate the product vision and make a list of features called the Product Backlog. At the beginning of each Sprint, the Sprint Planning Meeting takes place. It is divided into two distinct parts. In Part One, the Product Owner and Team review the high-priority items in the Product Backlog that the Product Owner wants to implement in the Sprint. In the second part, the Team focuses on detailed task planning for how to implement the items that the Team decides to take on. This meeting will often last a number of hours, but no more than 8 hours. Each member decides how much time can be spent on Sprint-related work and how many Product Backlog items they can complete in that time. The Product Backlog items are broken into individual tasks and recorded in a document called the Sprint Backlog. Scrum encourages multi-skilled workers who have the capability of doing many tasks and can help out whenever possible. Teams use a visual task-tracking tool to check the progress of ‘Not Yet Started’, ‘In Progress’ and ‘Completed’ tasks.

Once the Sprint has started, the Team has a Daily Scrum meeting that happens every workday at an appointed time. Only three things are reported in this meeting by each member to the other Team members:
1) What they were able to get done since the last meeting.
2) What they are planning to finish by the next meeting.
3) Any blocks or impediments in their way.

If there are any blocks, the ScrumMaster helps the Team members resolve them.
Every day, the Team members update their estimate of the amount of time remaining to complete their current task in the Sprint Backlog. Following this, someone adds up the hours remaining for the Team as a whole, and plots it on the Sprint Burndown Chart. The Product Backlog may also require refining–done by scheduling a focused workshop near the end of the Sprint, so that the Team and Product Owner can do this work without interruption.
The duration of the Sprint is never extended–it ends on the assigned date regardless of whether the Team has completed the work it committed to or not. After the Sprint ends, there is a Sprint Review, where the Team and the Product Owner review the Sprint. The Sprint Review involves “inspect and adapt” of the product. The Sprint Retrospective, which follows the Sprint Review, involves “inspect and adapt” of the process.
At this point, some items have been finished, some added, and some dropped. The Product Owner has to ensure that these changes are reflected in the Release Backlog. In addition, Scrum includes a Release Burndown chart that shows progress towards the release date.
Following the Sprint Review, the Team is now ready to start another Sprint cycle. Scrum is therefore a set of practices and also a framework that provides transparency and a mechanism that allows for change through inspect and adapt. Implementing Scrum is not easy but the benefits are visible and worth the effort.

Some links to better understand Scrum are given : Click here
www.justwriteclick.com
‘Succeeding with Agile’ by Mike Cohn is a useful reference book for those interested in knowing more about Agile.
At the end of the workshop, we definitely had a lot of questions, but also knew quite a bit about Agile and Scrum!