Introduction to the Agile development framework

Introduction The Agile development framework is based on the Scrum model [1] driven by the values shared by all members of the DevOps Team and those surrounding the team:

  • Commitment to achieve the goals of the DevOpsTeam.
  • Courage to do the right things and work on tough problems.
  • Focus from everyone on the work of the Sprint and the goals of the DevOps Team.
  • Openness about all the work and the challenges with performing the work.
  • Respect for each other to be capable, independent and competent people.
Agile rely on three strict process controls, which makes it feasible for use in a regulated industry:
  • Transparency – observers share a common understanding of what is being seen.
  • Inspection – diligently performed by skilled inspectors at the point of work.
  • Adaptation – unacceptable deviations in process or solution is corrected right away.
Agile is an iterative development model starting with a list of requirements, expressed as either an “User Story” or an “Epic“. These are gathered in a Release Backlog and sorted based on business priority. This Backlog is not fixed from the start, but can be changed during the work on the release as required by e.g. new business need, changes in the market, or changes in regulatory requirements, etc.
The Backlog is implemented in a number of iterations, Sprints. Each iteration implement a subset of the requirements from the Release Backlog.
The iterations stops when there is either no more “User Stories” in the Release backlog, or the project runs out of time or of money. Each iteration ends with a potentially releasable solution.
What does a Scrum project look like? The figure below illustrates one iteration in the Scrum framework. Scrum apply controls of the Sprint using the following events:

  • Sprint Planning,
  • Daily Scrum,
  • Sprint Review and
  • Sprint Retrospective.
“Click” on the various elements in the picture to get an explanation of the key concepts in the Agile Framework.

Scrum Illustrated

Get a brief explanation of the Release Backlog Get a brief explanation of the Sprint Backlog Get a brief explanation of the Sprint Planning Get a brief explanation of the Sprint Review Get a brief explanation of the Retrospective Get a brief explanation of the Sprint Get a brief explanation of the Sprint Get a brief explanation of the Daily Scrum Get a brief explanation about the Steeing Committee Get a brief explanation about the Scrum Team
What is the Backlogs? The are three Backlog in the Scrum Framework – list of requirements. Common for all three are that a requirement is expressed as either an “User Story” or an “Epic“.

  • The Business Backlog – this is a list of all “User Stories” or “Epics” related to the business and the topic can be about e.g.market researh, vendor selection, products or systems. They are sorted by priority for the Business. The list is dynamic, “User Stories” or “Epics” can be added or delete from the list, changed or given another priority.
  • The Release Backlog – this is a subset of the “User Stories” or “Epics” selected fromthe Business Backlog for being solved in a Release. They are sorted by priority for the Business and can bechanged during the release, as long as they are NOT selected for a Sprint yet.
  • The Sprint Backlog – this is a subset of the “User Stories” or “Epics” selected from the Release Backlog for solving in the next upcoming Sprint. The list is fixed and cannot be changed.

What is a Scrum Team?

 The Scrum Team is the group of people who perform the development in a Sprint. The team is made up of these members:

  • The Product Owner – is the person who represent customers/business interests. The Product Owner can answer questions regarding the interpretation of the “User Stories” (or find someone who can) and is the one who can decide to accept or reject a deliverable.
  • The Development Team – is an interdisciplinary self organising group, who have all the skills needed to manage, develop, verify and validate a solution to the “User Stories” or “Epics” selected for the Sprint. The Scrum Team set the scope and define activities in the Sprint during the Sprint Planning together with the Product Owner.
  • The Scrum Master – is the organisation’s Scrum ambassador and facilitator/couch for the Scrum Team, helping them to keep focused on the process, support them to resolve internal and external problems and collaborate with everyone who interact with the Scrum Team to maximize the value they create for the Team.
What is a Sprint? The Sprint is the “manufacturing” part of the Scrum Framework. A Sprint is an iteration, typically from 1-4 weeks in which a set of “User Stories” or “Epics” from the Sprint Backlog are transformed into a solution for business. The Sprint has two activities and four mandatory events:

  • Sprint Planning – this event takes place at the very beginning of the sprint (½-1 day). During the Sprint Planning the Development Team set the scope for the sprint (establish the Sprint Backlog), defines together with key stakeholders the definition of “Done” and establish a plan for what to do (all the tasks) in order to finish within time, scope and budget. The plan schedule is detailed for the first couple of days and then developed consecutively in the Daily Scrum to maintain a couple of days forecast.
  • Daily Scrum – this event takes place every day (usually at the start of the day in a 15-20 minutes stand-up meeting). The progress is inspected toward the Sprint Goal and any impediment that prevents the Development Team from meeting the Sprint Goal is identified.The Sprint Plan is updated with the next 24 – 48 hours.
  • Solution – this activity takes places outside the events and is where the User Stories are turned into solutions with the perceived value for the user and the organisation. The solution can be e.g. a market research based on User Stories about the market, a proof of concept for an Epic related to a product concept og some code to implement User Stories related to a IT System.
  • Sprint Review – this event takes place at the end of the Sprint (3-4 hours). During the Sprint Review the stakeholders and the Scum Team Inspect each deliverable using the definition of “Done” to provide Transparency to the acceptance of the deliverable. The Product Owner has the final saying in approving/rejecting the deliverable.
  • Sprint Retrospective – this event takes place at the end of the Sprint (3-4 hours). During the Sprint Retrospective the Scrum Team Inspect how the Sprint went with regards to people, relationships, process, and tools. The Scrum Team identify and order the major items that went well and potential improvements. These are used to create a plan for implementing improvements to the way the Scrum Team does its work.
  • Release – if it decided to release the increment, this activity can either be done by the Development Team, the DevOps tema, or another organisational unit responsible for releases in general.
What does ‘Done’ mean? The term ‘Done‘ is used to describe the criteria for accepting the solution to a User Story. These criteria can include test to be passed, regulated documentation to be provided, etc. “Done” can be pre-defined in e.g. the Quality Management System or defined in the Sprint Planning for selected “User Stories” or “Epics“.
What is an User Story? The “User Story” is a description of the requirement in the form:

“As a <persona>, I can <what?> so that <why?>”.
Example:
As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved.
What is an Epic? The “Epic” can be considered a large or broad “User Story”, which is too big to be implemented in one Sprint, and therefore need to be broken down into smaller, more specific, “User Stories” – the divide an conquer principle.

Example:
As a user, I can manage my backup, to safe guard my data,save time and disc space
This Epic could include the User Story from above plus some other more specific user stories about e.g. creating backups, restore backups, etc.
Who is the Steering Committee? The Steering Committee is not considered a part of the scrum framework, but none less the Scrum Team do exist in vacuum, but are establish by some kind steering committee.
The Steering Committee is usually formed by members from high level management, who represent business interests and have authority to fund the team, set high level goals for the team, and empower the Product Owner to take decisions on behalf of the business.
Who is the Stakeholders? These groups are not considered part of the Scrum Framework, but is all the people outside the Scrum Team, who in some way interact with the team, are influenced by the work the team do or in some or another way have a stake in what the team do. Stakeholders typically includes:
Hints and references:
[1] The 2020 Scrum GuideTM; https://www.scrumguides.org/scrum-guide.html
Essential Scrum; A Practical Guide to the Most Popular Agile Process; Kenneth S. Rubin; Addison-Wesley; ISBN-13: 978-0-13-704329-3; ISBN-10: 0-13-704329-3.