0

Posted on : 04-11-2011 | By : Chris | In : Coding, Methodologies, Project Management, Scrum

I love Scrum. For me it just ‘feels’ right and as I’ve never had the luxury of large teams, large budgets and an entourage of experts it is a perfect ‘fit’ to the way I work.

That said, empowered small teams of technical experts with the authority to make decisions is new territory for many organisations and for older, dare I say ‘crusty’ organisations with embedded laboursome processes this is a massive leap of faith!

I find that I often have to justify the merits of Scrum so I thought I’d produce a little blog post that I can refer to – based on the points raised in Ken Schwaber’s excellent book ‘Agile Project Management With Scrum’. Here it is below.

Why Scrum?

  • Scrum doesn’t 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 customer’s 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 don’t 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 team’s chances of delivering a successful product.

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 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 Scrum’s success sits an empowered team of experts that self-manage and ensure quality through the inspection of each other’s 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 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

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 Process

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 Team’s 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.

Bibliography

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

http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/digg_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/reddit_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/dzone_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/stumbleupon_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/delicious_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/blinklist_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/blogmarks_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/furl_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/newsvine_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/technorati_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/magnolia_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/google_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/myspace_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/facebook_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/yahoobuzz_48.png http://chriscurrie.co.uk/blog/wp-content/plugins/sociofluid/images/twitter_48.png