The Scrum Framework

The Scrum framework is defined in The Scrum Guide and was introduced as a better way of team collaboration for solving complex problems. The Scrum framework is fairly simple being made up of a Scrum Team consisting of a Product Owner, a Scrum Master, and Developers, each of which has specific accountabilities. 

The Scrum Team takes part in five events and produces three artifacts. The Scrum Guide contains the definition of Scrum,  describing the Scrum accountabilities, events, artifacts, and the guidance that binds them together.

Scrum Accountabilities 

  • Scrum Master: The person on the Scrum Team who uses their knowledge of Scrum to help the team and organization to be as effective as they can be; they do so by taking approaches like coaching, teaching, facilitating, and mentoring
  • Product Owner: The person on the Scrum Team who makes sure that the team is creating the most valuable product they can create.
  • Developers - the people on the Scrum Team who work together to create the product.

Scrum Events

  • Sprint: Short cycles of one month or less, during which the work is done; the Sprint contains all of the other Scrum events; a new Sprint starts immediately after the conclusion of the previous Sprint
  • Sprint Planning: The event is dedicated to planning out the work that will take place during the Sprint
  • Daily Scrum: The event is held every day where the Developers inspect the progress toward the Sprint Goal, uncover anything that may be getting in their way and adapt accordingly
  • Sprint Review: The event is held at the end of the Sprint where the Scrum Team and key stakeholders review what was accomplished in the Sprint and what has changed in their environment; next, attendees collaborate on what to do next
  • Sprint Retrospective: The Scrum Team gets together during this event to talk about how the last Sprint went and identify the most helpful changes to improve their effectiveness

Scrum Artifacts

  • Product Backlog - an evolving, ordered list of what is needed to improve the product; it is the single source of work undertaken by the Scrum Team
    • Commitment: Product Goal -  the target the team plans against 
  • Sprint Backlog - a highly visible list of work that is the Developer’s plan for Sprint, which may evolve as they learn
    • Commitment: Sprint Goal - the single objective of the Sprint
  • Increments - small pieces of work that serve as concrete stepping stones toward the Product Goal. You can deliver as often as needed during the Sprint and are not limited to only one release per Sprint.
    • Commitment: Definition of Done -  the description of what it takes for an Increment to be considered complete

References

Share:

The Kanban Method

With Kanban, you can manage work. It is a method to manage all types of professional services, also referred to as knowledge work.

Using the Kanban method means applying a holistic way of thinking about your services with a focus on improving them from your customers' perspective.

Kanban is not a methodology nor a process framework. Rather, it is a management method or approach that should be applied to an existing process or way of working.

STATIK

The STATIK approach should be applied to each service. It will result in a full Kanban system design. Throughout the process, systems thinking should be applied. The (future) system is always considered as a whole, with the goal of improving the flow of value to customers.

Kanban Boards

Kanban boards are the most common means of visualizing a Kanban system. 
  • Common to all boards is pulling work from left to right through the board: on the left, new work items enter the board. When they exit on the right, value is delivered to customers.
  • There is at least one clear commitment and delivery point and a representation of the permitted amount of work (Work in progress, WIP).
  • Work Items can be of different types and sizes, from tasks to requirements, types of artifacts, (groups of) product features and topics to projects or product packages on higher-level boards.
  • Work items are typically displayed on individual (paper) notes, which are usually called cards or tickets.
  • The series of activities these work items go through is referred to as Workflow. Kanban is based on the "Start where you are now" approach, so, the actual workflow (not a wishful future image) is being modeled on the Kanban board.
  • The individual steps in the workflow and buffers are shown in columns.
  • Lanes are often used for different work types, projects, etc. to distribute capacity.
  • The workflow is modeled on the board. Different colored notes can be used, for example, to represent different types of work items.
  • The flow of work and its risks should be realistically shown in their true current state rather than a wishful image of the future at all times.

WIP Limits and Pull

The so-called WIP limit, i.e., the maximum number of work items allowed at a time, can be defined per work state(s), per person, per lane, per type of work, for a whole Kanban system, etc. WIP limits are typically represented by a number in a circle, above the respective columns.
  • Limiting the work that is allowed to enter the system is an important key to reducing delay and context switching which may result in poor timeliness, quality, and potential waste.
  • The aim is to create a balance between demand and capability over time.
  • Limiting the work that is allowed to enter the system also creates a continuous flow of work in which drawing or "pulling" work only happens if there is capacity. 
  • A virtual pull signal is generated when the WIP limit is not fully utilized. While work on the board moves to the right, pull signals move to the left, further upstream.

Core Kanbas Metrics

  • Lead time is the time it takes for a single work item to pass through the system from the start (commitment point) to completion.
  • Delivery rate is the number of completed work items per unit of time, such as features per week, training classes per month, or new hires per month.
  • WIP (work in progress) is the number of work items in the system (or a defined part of it) at a certain point in time.
  • Cumulative flow diagram (CFD). It is useful information regarding the flow of work across multiple activities. The colored areas in the diagram represent the number of work items within a particular activity in the workflow and how these work items move across all activities, from top to bottom, over time until done.

Kanban Cadences

Please note that like all elements of a Kanban implementation, the cadences can and should be set up to it within the given organizational context. In practical terms, this means:

  • Identify existing meetings and reviews that already serve a similar purpose and continually evolve them.
  • Keep the existing names or use the standard cadence naming or come up with something else. It is the purpose that matters.
  • Pick the frequency and duration based on your context. In many cases, having more frequent but shorter meetings over time increases agility.

References

Share: