1.2.1 Agile Software Development Approaches Flashcards
What are the common practices across most Agile organizations?
There are a number of Agile approaches in use by organizations.
Common practices across most Agile organizations include:
- collaborative user story creation,
- retrospectives
- continuous integration, and planning for each iteration as well as for overall release.
This subsection describes some of the Agile approaches.
What are the Agile Software Development Approaches?
- Extreme Programming
- Scrum
- Kanban
What is Extreme Programming?
- Extreme Programming (XP), originally introduced by Kent Beck [Beck04], is an Agile approach to software development described by certain values, principles, and development practices.
- XP embraces five values to guide development: communication, simplicity, feedback, courage, and respect.
- XP describes a set of principles as additional guidelines: humanity, economics, mutual benefit, self- similarity, improvement, diversity, reflection, flow, opportunity, redundancy, failure, quality, baby steps, and accepted responsibility.
- XP describes thirteen primary practices: sit together, whole team, informative workspace, energized work, pair programming, stories, weekly cycle, quarterly cycle, slack, ten-minute build, continuous integration, test first programming, and incremental design.
- Many of the Agile software development approaches in use today are influenced by XP and its values and principles. For example, Agile teams following Scrum often incorporate XP practices.
What is Scrum?
Scrum is an Agile management framework which contains the following constituent instruments and practices [Schwaber01]:
Sprint: Scrum divides a project into iterations (called sprints) of fixed length (usually two to four weeks).
Product Increment: Each sprint results in a potentially releasable/shippable product (called an increment).
Product Backlog: The product owner manages a prioritized list of planned product items (called the product backlog). The product backlog evolves from sprint to sprint (called backlog refinement).
Sprint Backlog: At the start of each sprint, the Scrum team selects a set of highest priority items (called the sprint backlog) from the product backlog. Since the Scrum team, not the product owner, selects the items to be realized within the sprint, the selection is referred to as being on the pull principle rather than the push principle.
Definition of Done: To make sure that there is a potentially releasable product at each sprint’s end, the Scrum team discusses and defines appropriate criteria for sprint completion. The discussion deepens the team’s understanding of the backlog items and the product requirements.
Timeboxing: Only those tasks, requirements, or features that the team expects to finish within the sprint are part of the sprint backlog. If the development team cannot finish a task within a sprint, the associated product features are removed from the sprint and the task is moved back into the product backlog. Timeboxing applies not only to tasks, but in other situations (e.g., enforcing meeting start and end times).
Transparency: The development team reports and updates sprint status on a daily basis at a meeting called the daily scrum. This makes the content and progress of the current sprint, including test results, visible to the team, management, and all interested parties. For example, the development team can show sprint status on a whiteboard.
What does Scrum define as the three roles:
Scrum Master: ensures that Scrum practices and rules are implemented and followed, and
resolves any violations, resource issues, or other impediments that could prevent the team
from following the practices and rules. This person is not the team lead, but a coach.
Product Owner: represents the customer, and generates, maintains, and prioritizes the
product backlog. This person is not the team lead.
Development Team: develop and test the product. The team is self-organized: There is no
team lead, so the team makes the decisions. The team is also cross-functional (see Section 2.3.2 and Section 3.1.4).
Scrum (as opposed to XP) does not dictate specific software development techniques (e.g., test first programming). In addition, Scrum does not provide guidance on how testing has to be done in a Scrum project.
What is Kanban?
Kanban [Anderson13] is a management approach that is sometimes used in Agile projects. The general objective is to visualize and optimize the flow of work within a value-added chain. Kanban utilizes three instruments [Linz14]:
Kanban Board: The value chain to be managed is visualized by a Kanban board. Each column shows a station, which is a set of related activities, e.g., development or testing. The items to be produced or tasks to be processed are symbolized by tickets moving from left to right across the board through the stations.
Work-in-Progress Limit: The amount of parallel active tasks is strictly limited. This is controlled by the maximum number of tickets allowed for a station and/or globally for the board. Whenever a station has free capacity, the worker pulls a ticket from the predecessor station.
Lead Time: Kanban is used to optimize the continuous flow of tasks by minimizing the (average) lead time for the complete value stream.
What Kanban features share similarities with Scrum?
- Kanban features some similarities to Scrum. In both frameworks, visualizing the active tasks (e.g., on a public whiteboard) provides transparency of content and progress of tasks.
- Tasks not yet scheduled are waiting in a backlog and moved onto the Kanban board as soon as there is new space (production capacity) available.
- Iterations or sprints are optional in Kanban. The Kanban process allows releasing its deliverables item by item, rather than as part of a release.
- Timeboxing as a synchronizing mechanism, therefore, is optional, unlike in Scrum, which synchronizes all tasks within a sprint.
