Monday 22 September 2014

Scrum, the most popular agile method

Over the last few years, there has been a paradigm shift on how organizations manage projects. The global market faces increased pressures due to a demand for faster product development from customers, frequent changes in product requirements, and an expectation for development teams to be highly flexible and have cross-functional knowledge. Increased competition, rapid changes in the technological landscape and continued turbulence in business and economic fronts pushed the organizations to look beyond the traditional project management.

Many organizations found their answer in adaptive project management methods. Adaptive management is an iterative decision making process especially useful in rapidly changing and uncertain conditions. Adaptive project management uses a feedback process to reduce uncertainty in the future thereby embracing risk and uncertainty as tools to further understand the environment.

Agile is a group of product and service development techniques using an iterative and incremental approach in which solutions are delivered in stages. Agile promotes adaptive planning to develop a product in iterations, thereby, lending a greater flexibility to change during the development process while also reducing the extent of long-term planning. This minimizes the risk involved with changes in the long-term vision of a project. There are several Agile methods/frameworks developed over time such as Crystal, Scrum, Dynamic System Development Method, Extreme Programming, Kanban, Lean Product Development etc. Among the various frameworks, Scrum is the most matured and widely used framework across industries. About half of all Agile projects use Scrum.

Scrum is easy to implement yet a very effective and powerful framework; a lot because of its philosophies, which are based on the following five governing principles:

1. Empirical process control: There are two ways to control any process—defined process control and empirical process control. Empirical process control is based on transparency, inspection, and adaptation. Scrum uses empirical process control to inspect and adapt, because this approach is more apt for processes that generate unrepeatable and unpredictable outputs.
2. Self-organization: As opposed to the traditional command-and-control style of management, Scrum believes that today’s workers have much more to offer than just their technical expertise and deliver greater value when self-organized. Scrum teams are cross-functional to ensure greater interaction.
3. Collaboration: Scrum believes that product development is a shared value creation process that needs all stakeholders working and interacting together to deliver the greatest value.
4. Prioritization: Delivering the greatest value in the shortest amount of time requires prioritization and dividing what will be done from what needs to be done.
5. Time-boxing: Time is treated as a limiting constraint, and time-boxing is used for all work
To know more about Scrum and how to deliver projects using Scrum, ‘Scrum Body Of Knowledge (SBOKTM Guide)’ is a recommended reading.

Tuesday 9 September 2014

Scrum Components: Sprint Planning Meeting

Sprint Planning Meeting
The Sprint Planning Meeting is the discussion held by a Scrum team with the goal of agreeing which task will be executed during a set sprint period. In preparing for the Sprint Planning Meeting the SCRUM Master needs to surround the team with the following artifacts and discussion elements:
1. Product Backlog
2. Sprint Backlog
3. Burn-down Chart
The Sprint Planning Meeting is attended by the Product Owner (voice of the customer), Scrum Master and the Development Team. This team discussion is convened to discuss/plan the execution of user stories over the current Sprint and is held in co-located facilities.
In this meeting, the product owner will be prepared to discuss or present enough product backlog items to fit known team’s sprint velocity and is concerned in communicating the sprint goal that will result in a shippable product.
The meeting is devoted to defining the sprint goal which together with the object definition – a Q & A period where the PO details his priorities, the team decomposes user stories from the Product Backlog and devotes time to estimation –where tasks are defined according to time/risk/complexity. Upon agreement a number of these are moved onto the current Sprint Backlog that the team will volunteer to work on and revisit during the sprint.
The Product Backlog
In the example above we have taken a snapshot of a Product backlog and its initial stages of decomposition. Please note that some of the entries were introduced not by the PO but by members of the development team as items found during grooming.
The Sprint Backlog
An output of the Sprint Review Meeting, the Sprint Backlog is shown above. There can be many varieties of what is listed but for the most part it identifies the User Story from where the task originated the description of the task, the status and the estimate value. The estimate is the measure of the task relative to the velocity and the team accomplishment value.
The Burn-down Chart
One of the best sprint status reporting artifacts, the Burn-down Chart is used to assess the success of the sprint remaining days relative to the target velocity. The chart is updated towards the end of the sprint day by the team deducting the amount of completed work from the sprint backlog. Unfinished tasks are moved back to the product backlog and may be prioritized on the next sprint iteration.