Why Scrum

November 3, 2011

Why Scrum?
Scrum doesnt rely on a complex set of controls (the more complex, the less likely rules and constraints will work). Instead it relies on the judgement of empowered experts which is a classic way of handling complexity. These experts can make collective and informed judgements to keep the project on track. As such, the team are effectively managing their own delivery. It strips away convoluted communication mechanisms and enables the developers to crack on on the customers behalf. This is not as risky as you may think for development cycles are short and are therefore far more capable of handling change. There is no better way of learning than through short cycles of discovery. Ken Schwaber refers to this as Fact-based decision making which is more effective than Front-end loaded predictive approaches. (Schwaber, 2004) Each iteration delivers attempts to deliver actual business value there are no partially implemented incomplete features. As such we are left in no doubt as to whether a particular feature really works. There is a focus on delivering the highest priority first (according to the customer also called the Product Owner). There is a test early and often ethos to ensure the value vision is in line with expectations.

A few things to consider

Scrum is beautifully simplistic but dont let that fool you into a false sense of confidence. Although Scrum excels in its approach to delivering complex changing projects, its lack of controls rely on empowered experts to ensure success. The team must be educated, intelligent and apply common sense for Scrum to be effective! Keep in mind that many of use, especially Project Managers (like me) have been taught, and become used to, various classic project controls such as project plans depicting Gantt charts with milestones and critical paths, resource plans, work schedules, issues and risk logs etc. Throwing these out of the window can feel uncomfortable and offer quite a hard sell to an organisation used to the classic way.

Why did Scrum come about?

Software creation is complex. Scrum attempts to keep the process simple. Scrum implements processes to handle this complexity and guide projects to deliver products of value. Software development is prone to change. Scrum welcomes change and implements mechanisms to handle it. In doing so it improves a teams chances of delivering a successful product.

Chris M. Currie

Why Scrum

November 3, 2011

What is Scrum?
An agile approach to delivering complex software (although it can be applied to other project types) projects. It incrementally delivers value through iterative cycles of software development. These cycles continue until the project is shutdown. Each iteration should complete deliver an increment of functionality that is potentially shippable. Software projects are typically complex so Scrum adopts an empirical process control approach An empirical process control mechanism is one that collects/manages information by observation, comparison against checkpoint s and adaption. In Scrum our checkpoints are the daily scrum, sprint planning, sprint review and sprint retrospective meetings. At these we consider visible progress against the objective and can modify our approach based on the information collected. At the heart of Scrums success sits an empowered team of experts that self-manage and ensure quality through the inspection of each others contribution. These experts evaluate the requirements, consider their skills and self-organise to take on the tasks most suitable. The team review progress and adapting their approach regularly if necessary.

Roles
There are only three roles in Scrum. Collectively they manage the delivery.

Scrum Master
The Scrum Master can be considered a, kind of, project manager. The Scrum Master is responsible for providing direction, leadership, advice, knowledge transfer, management (of the development process) and ensuring the team is free from obstacles that may inhibit successful delivery of the product.

Product Owner
The Product Owner owns the requirement. It is likely the Product Owner would have been involved in the business case and defining the original requirements. There may also be responsibility for the financials and authorisation for the project to proceed. During the project the Product Owner maintains responsibility for on-going financials and release plans. In Scrum, the requirements list is considered a product backlog. The Product Owner should organise the product backlog to ensure the highest value products are prioritised and therefore appear top of the list for early inclusion. This list is continually reprioritised with each iteration.

Team
The team deliver the project. They are held jointly responsible for the project and are empowered to structure the list of deliverables (product backlog) and ensure the higher value products are delivered first. This list is continually evaluated throughout development.

Pigs and Chickens

The terms Pigs and Chickens are used in Scrum to describe the commitment of stakeholders. They come from a joke (look it up). In short, Pigs are committed (responsible/accountable) but Chickens are not (they only have an interest). Those responsible (the Pigs) carry the authority required to make the

Chris M. Currie

Why Scrum

November 3, 2011

decisions necessary in order to ensure delivery. The chickens, on the other hand, are kept from interfering wherever possible. This is an important feature of Scrum.

The Scrum Approach

High level to begin with becoming more detailed over time.

Vision

Plan

Product Owner creates a plan and defines the 'Product backlog' - a list of functional & non-functional requirements needed to deliver the vision. Product backlog is prioritized with high value items at the top Product backlog change is expected over time.

Prioritization

Product backlog is organized into 'releases'. These will become our 'Sprints'.
Sprints

Sprint:

Re-prioritize Product Backlog

30 Day Sprint Agree Sprint backlog 24 hours

Daily Scrum

Value added New functionality Potentially shippable Sprint review

Product Increment

Team demonstrates new functionality to the Product Owner (and any other invited Stakeholders) Sprint Review Decisions as to what the Team should do next.
4 hours

ScrumMaster and Team consider progress and lessons learned Approach to development is revised within the Scrum process Sprint framework and practices to improve efficiency. Retrospective
3 hours

Chris M. Currie

Why Scrum

November 3, 2011

The Scrum process begins with a high-level vision (which may be refined over time). The vision belongs to the Product Owner who is most likely responsible for ensuring a return on investment from the project. The Product Owner will create the Product Backlog - a list of functional and non-functional requirements needed to realise the project. These products are then prioritised with the most valuable (or highest priority) listed top. It should now be possible to articulate what constitutes a release and at what point the project can be considered delivered. The Product Backlog is continually re-evaluated for each Sprint to accommodate changing requirements and/or capability to deliver against the timeline. Scrum uses Sprints to deliver incremental value over a set period of time (normally 30 consecutive calendar days). To kick-off each Sprint, the Product Owner and Team meet in a Sprint Planning Meeting. This meeting is time-boxed to 8 hours maximum and used to select products from the Product Backlog for inclusion within the following Sprint. The selection process is guided by what the Product Owner deems the highest value/priority, tempered by what the Team feel they can realistically achieve within the time, based on previous capability. The Sprint Planning meeting is conducted in two 4 hour parts: Part one: The Product Owner articulates which products have highest value/priority and responds to questions from the Team who seek to better understand the whats and the whys. The team then determine what, from the Product Backlog, can realistically be completed within the Sprint. Their commitment, to the Product Owner, is to do their best to deliver against this selection. Part two: The team plan the Sprint by creating an initial set of tasks and activities. This is the Sprint Backlog and it will be continually evaluated throughout the Sprint.

The team meet for 15 minutes at the start of each day. This is called the Daily Scrum and is used to ensure the members are working productively with no impeding issues. At this meeting three questions are asked by the ScrumMaster: 1. What have you done on this project since the last Daily Scrum meeting? 2. What do you plan on doing on this project between now and the next Daily Scrum meeting? 3. What impediments stand in the way of you meeting your commitments to this Sprint and this project? (Schwaber, 2004) When a Sprint concludes a Sprint Review meeting is held (time-boxed to 4 hours). The team present the new functionality to the Product Owner other stakeholders are permitted to attend. Collectively the team determine what they should focus on next. Following the review, there is a Sprint Retrospective meeting (time-boxed to 3 hours) with the Team. The retrospective offers an opportunity to evaluate the Teams performance within the last Sprint and consider adjustments that improve efficiency for the next Sprint. This meeting must take place before the next Sprint Planning meeting. Earlier we mentioned that Scrum adopts an empirical process control approach. This is achieved through the Sprint planning, Daily Scrum, Sprint Review and Sprint Retrospective meetings.

Chris M. Currie

Why Scrum

November 3, 2011

Bibliography
Schwaber, K. (2004). Agile Project Management With Scrum. Redmond: Microsoft.

Chris M. Currie