Previously, this dictionary entry for Demo was a main one, and the entries for Sprint Review and Iteration Review pointed to here.
However, because of the current common use of the scrum framework and its terminology we have decided to make this entry a stub and to point to Sprint Review instead.
Referring to the development of software systems, DevOps has been broadly defined as “a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality”[1].
DevOps includes practices such as continuous integration, continuous automated testing, and automated deployment to ensure speed, quality, stability, and reliability.
DevOps is a cultural shift within many organizations. The historical separation between software development and IT operations is removed by having all participants contribute to the entire software development lifecycle. They are aligned around shared goals of fast delivery, high quality, and customer expectations.
DevOps is a portmanteau of the two words development and operations that refer to software development and IT operations.
What is DevOps?
https://devops.com/what-is-devops/
[1] DevOps: A Software Architect’s Perspective, 1st ed. by Bass, Weber, and Zhu.
A large user story that awaits decomposition into smaller stories prior to implementation. When an epic story works its way up the backlog, it is usually so decomposed. Epics are sometimes far off on the development horizon and have lower priority.
In the scrum framework stories that are sprint ready must be small enough that they can be confidently implemented within the timebox of a single sprint.
NB: One can easily be tempted to associate the term ‘epic’ with importance; in Agile, epic relates only to size.
As it relates to agile methodologies, Mike Cohn coined the term epic in his book User Stories Applied: For Agile Software Development. Chapter 2 of that book is available here as a pdf, in which there is discussion of epics.
Agile Alliance | Glossary | Epic
https://www.agilealliance.org/glossary/epic
Don’t Finish Your Epics! Deliver More Value Instead.
https://agilelearninglabs.com/2017/03/dont-finish-your-epics-deliver-more-value-instead/
User Stories Applied: For Agile Software Development
https://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685/
An Agile software development methodology that emphasizes customer involvement, transparency, testing, and frequent delivery of working software.
The Extreme Programming canon includes a Customer Bill of Rights and a Developer Bill of Rights. Its core values are communication, simplicity, feedback, courage, and respect. XP is a developer-centric methodology. Unlike scrum, it prescribes specific coding practices like pair programming in which two developers work side by side at a single machine, automated unit testing, and frequent integration. Another key practice in XP is refactoring, or the continual internally-visible improvement of design and code.
The basic advantage of XP is that the whole process is visible and accountable. The developers make concrete commitments about what they will accomplish, show concrete progress in the form of deployable software, and when a milestone is reached they will describe exactly what they did and how and why that differed from the plan. This allows business-oriented people to make their own business commitments with confidence, to take advantage of opportunities as they arise, and to eliminate dead-ends quickly and cheaply. — Kent Beck
In 1996, Chrysler’s visionary CIO, Sue Unger, gave Kent Beck free rein to form a team to tackle the Chrysler Comprehensive Compensation payroll project. During this project Beck along with Ron Jeffries, Ward Cunningham, and Martin Fowler promoted and further developed the practices of what Beck called extreme programming.
Agile Alliance | Glossary | Extreme Programming (XP)
https://www.agilealliance.org/glossary/xp
Extreme programming
https://en.wikipedia.org/wiki/Extreme_programming
Extreme Programming for Beginners made Easy – Roles & Practices
https://pm-training.net/extreme-programming-beginners/
Extreme Programming Explained: Embrace Change, 2nd edition. Kent Beck & Cynthia Andres.
https://smile.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/
In the scrum framework, any obstacle preventing a developer or team from completing work. One of the focusing questions each member of a scrum team answers during the daily stand-up meeting is: What impediments stand in your way?
Impediments may include such things as:
Scrum co-founder Ken Schwaber declared removing impediments to be “The scrum master’s top priority” in his 2002 book, Agile Software Development with Scrum.
The 2020 Scrum Guide mentions impediments in the section on Scrum Master and the section on Daily Scrum.
The Merriam-Webster Dictionary includes the following in its entry for the word impediment:
“Impediment comes from a Latin verb that meant ‘to interfere with’ or ‘to get in the way of progress’, as if by tripping up the feet of someone walking. In English, impediment still suggests an obstruction or obstacle along a path; for example, a lack of adequate roads and bridges would be called an impediment to economic development. Impediments usually get in the way of something we want. So we may speak of an impediment to communication, marriage, or progress–but something that slows the progress of aging, disease, or decay is rarely called an impediment.”
The Scrum Master as an Impediment Remover – Scrum.org – Barry Overeem
Also: Big Visible Charts
In agile software development the preferred way of displaying data visualizations is to post them on the wall in the team’s shared workspace (i.e., rather than logging them in a spreadsheet). Examples of information radiators include a burndown chart, a burnup chart, and a task board, although other types of charts are possible. These may also be referred to as Big Visible Charts.
An information radiator displays information in a place where passersby can see it. With information radiators, the passersby don’t need to ask questions; the information simply hits them as they pass.[1]
Keeping information visible at all times promotes transparency (one of the three pillars of scrum).
Alistair Cockburn coined the term “information radiator” in 2000 and introduced it in his 2001 book, Agile Software Development.
Information Radiators – Agile Alliance glossary
What makes a good information radiator – ThoughtWorks Australia, Lachlan Heasman – slide deck
Chapter 3: Communicating, Cooperating Teams – extract from Agile Software Development: The Cooperative Game (2nd Edition) by Alistair Cockburn
[1] From Agile Software Development (2nd Edition) by Alistair Cockburn, Chapter 3.
