| Plan Do Check Act |
Overview
In software development terms; products are built iteratively using Scrum, wherein each Sprint creates
an increment of the product, starting with the most valuable and riskiest. More and more Sprints create additional increments of the product. Each increment is a potentially shippable slice of the entire product. When enough increments have been created for the Product to be of value, the product is released.
Scrum theory states that Scrum is:
- a framework for optomising your own process
- grounded in process control theory
- iterative and incremental approach
- optomisation of predictability
- control of risks
Transparency - visible to those managing the outcomes - complete work matches definition of done
Inspection - frequently enough to detect unacceptable variances (Note: Shrodingers cat)
Adaptation - correct process issues quickly
-- Daily scrum meeting - sprint goal adaptation - optomise for next working day
-- Sprint review (showcase) and Sprint planning - release goal adaptation - optomise the next sprint
-- Sprint Retrospective - review the past sprint - adapt for next sprint
Scrum team characteristics
Self organising
Cross functional
Iterative working
Time boxed activities
Scrum roles
Scrum Master ensures that the scrum process (values, practices & rules) are understood and followed by the team. Encouraging self-organisation and removing impediments for the team. The scrum master advises the team on how the scrum framework can be utilized most effectively.
Product Owner is focused on maximising value that the team delivers - manages priorities and solely responsible for the product backlog priorities.
Team is the collection of people who have all the necessary skills to get the work each sprint and are preferably cross functional (everyone does everything). Typical team size is 5-9 people, not counting product owner & scrum master
Sprint Activities
The following activities in Scrum are time-boxed in help keep focus and remain effective.
Release planning meeting is to establish an overall plan and set of goals for the project that the organisation can understand as see value in. Establishes the overall features (MMF's) and major risks of the project, indicating probable release date and costs. The release plan is reviewed (and modified if necessary) on a per sprint basis.
Sprint planning meeting is a just in time planning session for each sprint. Typically 2 hours per week of the sprint duration (2 week sprint = ~4 hours sprint planning). The meeting is split into two parts: define the goal of the sprint (the "what"); create the sprint backlog (the "how").
Sprint review is held at the end of each sprint (2 week sprint = ~2 hours sprint review). Scrum team discusses with stakeholders the work done in the sprint and what work could be done next. The product owner will give an update on the status of the project (product backlog, velocity, release date). It is important to show the working software (i.e. a showcase) to get valuable feedback. The sprint review provides valuable input into the next sprint planning meeting.
Sprint retrospective occurs after the sprint review and before the next planning meeting (2 week sprint = ~1.5 hours). The scrum master guides the team to improve the process for the next sprint, reviewing how the last sprint went (people, relationships, process and tools) and what actionable improvements could be made.
Daily scrum occurs daily at the same time (~15 minutes) to inspect the progress towards the scrum goal and improve the teams' chance of meeting that goal. Each team member states: what they accomplished; what they are working on next; what obstacles are in there way. The scrum aims to improve communication by reducing other meetings, identifying impediments, promote quick decision making (without limiting options) and improve product knowledge.
Sprint Artifacts
Product backlog is a dynamic list of requirements (user stories) that could be done in for the project, managed and prioritised by the product owner to deliver the most value. In larger projects, functionality is often grouped into feature sets. The product backlog lasts for the useful life of the product and dynamically changes according to business or commercial needs.
Release burn-down records the remaining estimated effort of the product backlog across the timeline of the release plan, usually using a sprint length as the measure of time. Initial estimates created from the release planning meeting give a high level view of the work, so you can project the work remaining based on the teams capacity for doing the work (velocity). Note: Burn-up charts have benefits when the feature set of a project continually grows.
Sprint backlog is the set of tasks to be worked on for a particular sprint, identified by the team mainly during the sprint planning meeting, but also during the sprint. Only the team can change the sprint backlog during the sprint, but should do so only with respect to the sprint goal.
Sprint burn-down records the remaining sprint backlog across the sprint by summing the backlog estimates every day of the sprint.
The meaning of Done
Scrum requires that a team build an increment of product functionality during each sprint that is potentially shippable. Therefore the increment should be a slice through the product (from user interface to back end services). Each increment should be additive to all prior increments and throughly tested, ensuring that all increments work together.
Everyone involved must have a shared understanding of what done means, therefore the term done must be defined by all involved.
Scrum rules
- Only the team can talk during a daily scrum
- The purpose of each sprint is to deliver increments of potentially shippable functionality that adheres to a working definition of "done".
Tips
Scrum master works with customers and management to establish a product owner - SM teaches PO the role - PO manages team to optomise value
The scrum master can be any member of the team - product owner though would have conflict of interest, so avoid
The scrum master is a role and should be shared between the team where possible to help maintain team cohesiveness and maintain a balanced approach.
Acceptance tests are often used as another product backlog item attribute. Often supplanting more detailed text descriptions of what done is.
Undone work is often accumulated in a product backlog item called undone work or implementation work. As this work accumulates, the product backlog burndown remains more accurate than if it weren't accumulated.
Not part of Scrum
The following aspects of managing a project are not explicitly covered in the scrum framework, although there are lots of complementary techniques that a team can use whist striving to become agile
- Estimation techniques
- Prioritisation techniques
- Visualisation of work activites (eg. Kanban)
- Managing work in progress
- Continual Improvement - Kaizen
Summary
My own view is that scrum is a great way to start making your organisation a little more agile, especially if your organisation is well ordered and used to a structured process. It is a very light process framework that can be effectively used to build the core of your own agile process. In essence it is an example of a plan,do,check,act cycle to help manage change, adding specific activities, rules and roles to give a base structure for an agile way of working.
It is important to get a solid grasp of what you are trying to achieve with scrum (manage change effectively) and understand the reasons behind the rules, roles and activities in scrum. The specific practices are flexible enough to adapt to the circumstances of each organisation without loosing the values and overall goals of scrum.
Approaches such as Behaviour Driven Development, Kanban and XP are also effective at managing change, having subtle differences in focus and defining variations and additions to the practices of scrum whilst sharing (in some cases extending) the agile principles that underpin scrum.
If any change is difficult to introduce when trying to improve a teams effectiveness, then I recommend using Kanban to visualise the current practices / process so that when discussions take place about change the facts about the current situation are inescapable.
Posts
