Agile Scrum

Agile and Scrum … Two words so simultaneously extolled and reviled in this day and age. Often (mis)used as synonyms of each other.
During the Shared Community, we got to work through workshops. Why explain something as a presenter when your audience can learn more by doing it themselves, going deeper into the meaning of Agile and Scrum and how they are linked.

AGILE
Agile are 4 values and 12 principles that can be found on the internet (Manifesto for Agile Software Development (agilemanifesto.org)), actually more of a large webpage than even a website. Yet rivers of ink have flowed over these words, friendships formed and broken over interpretations.

The 4 values are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The values on the right are important, but the values on the left are more important. So you need both to make a project or product succeed, but in the correct amount.

The 12 principles are:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The 12 principles support the 4 values and basically boil down to using your common sense.
Let competent people manage their own work, make sure IT has a lot of contact with the Business and potential users so that there is a lot of feedback on what the customer wants and the product (software, service…) that IT delivers. Deliver in small quantities so you can always make adjustments to your customer’s requirements or if the market changes.
So simple, yet many companies still struggle to implement Agile correctly.
Think of Agile as a philosophy to which you aspire, which is a guideline that helps you make a company resilient and agile in today’s market, but like any philosophy, you can’t implement it directly, you have to implement actions that support your philosophy.
These actions are represented in Agile by the Agile frameworks with the Scrum Framework responsible for 80% of all Agile achievements.
Other Agile frameworks include eXtreme programming (XP), Dynamic System Development Method (DSDM), Crystal, Feature Driven Development (FDD), Cynefin and several hundred others.

SCRUM
Scrum is the most widely used Agile framework. You can find everything about it in the Scrum Guide (Home | Scrum Guides). The current version of the Scrum Guide is 14 pages long, 12 pages if you don’t count the title page and the index page.
Scrum is a lightweight framework that helps people, teams and organisations create value through adaptive solutions to complex problems. Briefly, Scrum requires a Scrum Master to foster an environment where:

  • A Product Owner organises the work for a complex problem into a Product Backlog.
  • A Scrum Team turns a selection of this work into a valuable Increment during a Sprint.
  • A Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
  • Repeat.

The 3 accountabilities are:

  • Scrum Master: responsible for teaching Scrum to the Developers, Product Owner and Organisation.
  • Product Owner: voice of the customer, responsible for maximising the value of the product.
  • Developers: the people who are committed every Sprint to making every aspect of a usable increment.

The 5 events are:

  • Sprint: The Sprint is the container of Scrum in which all other Events take place. Sprints have a fixed length of one month or less. A new Sprint starts immediately after the previous Sprint ends.
  • Sprint Planning: Sprint Planning starts the Sprint by outlining the work to be performed for the Sprint. The resulting plan is created by the joint work of the entire Scrum Team.
  • Daily Scrum: The purpose of the Daily Scrum is to inspect progress towards the Sprint goal and adjust the Sprint Backlog as necessary. It is a 15-minute event for the Developers.
  • Sprint Review: The purpose is to inspect the outcome of the Sprint and determine future adjustments. The Scrum Team presents the results of their work to stakeholders and progress is discussed.
  • Sprint Retrospective: The aim is to devise and plan ways to increase quality and effectiveness. The Scrum Team inspects how things have gone with regard to individuals, interactions, processes and tools.

The 3 artifacts with their commitment are:

  • Product Backlog with Product Goal: The Product Backlog is a living, ordered list of what is needed to improve the product. It is the sole source of the work done by the Scrum Team.
  • Sprint Backlog with Sprint Goal: The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what) and an executable plan for delivering the Increment (how).
  • Increment with Definition of Done: An Increment is a concrete step towards the Product Goal. Each Increment is an addition to all previous Increments and thoroughly tested to ensure that all Increments work together. To create value, the Increment must be usable.

As you can see, Scrum is an incomplete framework (or capstone) that covers only the minimum regarding roles, meetings and products.
Everything else the Scrum Team, with the help of the Scrum Master, has to add themselves. This is deliberately done so that each version of a Scrum output can be perfectly adapted to the specific needs of a team.
Some additions are taken from other frameworks, such as eXtreme Programming (Test Driven Development, continuous integration/continuous deployment, test automation), Kanban (Work In Progress, Cycle Time, Work Item Age, Throughput) or from development practices (Requirement engineering, business analysis, testing, devops…).

Regardless of what you add to your Scrum interpretation, use the Agile philosophy as a guide so that your personal framework is Agile.

Written by: René G.