The term agile was coined in 2001 when seventeen independent-minded software practitioners got together to exchange ideas on better ways to build software and came up with the Manifesto for Agile Software Development. In the last decade, agile development has dominated how software teams work. It is an iterative approach to software development that is guided by short feedback cycles and continuous improvement.

Agile development teams work in short time-boxed periods called iterations. By breaking a big project up into many smaller iterations, they can move quickly and efficiently through a project while delivering continuous, incremental value to customers. Within each iteration, there are regular “rituals” the teams participate in. These rituals facilitate team collaboration and act as a guideline for agile development.

The five most common rituals are planning, daily stand-up, backlog refinement, review, and retrospective. There are more, but these are the important ones to know about if you want to get started as an agile organization.

Agile Development Rituals

Let’s take a more detailed look at the rituals associated with agile development: what they look like, how long they take, and what their goals are.

Planning

At the start of each iteration, an agile development team does a planning session. The goal of this session is to agree on and scope the upcoming work for the iteration. The planning session brings alignment to the team on what work will be delivered by the end of the iteration.

During the planning session, the team takes work from the product backlog, which contains a list of tasks for the team to complete. Examples of existing work on the product backlog could be new features, updates to existing features, or bugs that need to be fixed. The product owner is responsible for maintaining the product backlog and keeping it prioritized.

Planning sessions should take about one hour per week of iteration.

Attendees: Development team, product owner, and a scrum master if you are using the Scrum methodology.

Daily Stand-up

The daily stand-up is a short check-in to allow the development team to share the context of where things are and bring up any blockers anyone is facing.

Teams mostly use a format in which the following questions are addressed: What was completed since the last stand-up? What is planned for completion before the next stand-up? What blockers exist? Keeping the discussions constrained to these three topics helps the stand-up happen quickly. If anything comes up that requires a bigger discussion it can be scheduled for later after the stand-up.

A daily stand-up should take no longer than fifteen minutes, making it a great way to check in with everyone at the start of the day.

Attendees: The development team is required. Optionally, the product owner, and a scrum master if you are using the Scrum methodology.

Backlog Refinement

In the backlog refinement session, the team, led by the product owner, reviews the current backlog to ensure it contains relevant items that are prioritized.The aim of the backlog refinement session is to ensure the product backlog contains enough items that are ready for delivery in upcoming iterations.

Backlog refinement sessions can either be scheduled as needed, depending on the state of the product backlog,or you can have a regular slot in your calendar for the session. Your team can decide what works best for them.

Backlog refinement sessions should take about an hour, but it is mostly driven by how much time you need to get the product backlog ready for future iterations.

Attendees: Development team, product owner, and a scrum master if you are using the Scrum methodology.

Review

The review session is where the team shares the work completed in each iteration. The team should show a working software demo that reflects how the software will work for real users.

In the review session, the team should only show completed work that meets the team’s agreed definition of done. The review session is also used for collecting feedback on the product to allow the team to improve the product in future iterations.

Review sessions should take about an hour for every week iteration of work.

Attendees: Development team, product owner, and scrum master. Customers and other external stakeholders can optionally attend.

Retrospective

In the retrospective session, the team looks back at the most recently completed iteration and identifies areas of improvement in their ways of working.

A general format for retrospective sessions is to ask: What went well in the last iteration? What didn’t go well in the last iteration? Then come up with some action items for improvement in future iterations. The action items are important as retrospectives are only valuable if the team follows up on their discussions from the sessions.

The retrospective session should be an open and safe space for the team, everyone should be encouraged to speak and share their thoughts on how the team is performing.

Your Retrospective should take one hour for every two weeks of work.

Attendees: Development team, scrum master, and optionally the product owner.

Glossary of Terms

While you now know all of the basic rituals of agile, you may be confused about some of the terms or phrases that were used. Here is a glossary of commonly used agile terms:

Iteration: A timebox during which development takes place. The duration may vary, but most teams run iterations that are between 1 and 4 weeks long.

Product increment: A software product increment is what gets produced at the end of a development period or timebox.

Planning: Planning is a session that kicks off the iteration. The purpose of planning is to define what can be delivered in the iteration and how that work will be achieved.

Daily Stand-up: The daily stand-up is a short check-in to allow the development team to share the context of where things are and bring up any blockers anyone is facing.

Backlog Refinement: Backlog refinement is when the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.

Review: The purpose of the review is for the team to show the customers and stakeholders the work they have accomplished over the iteration and compare it to the commitment given at the beginning of the iteration.

Retrospective: A retrospective is a meeting that is held at the end of an iteration. During the retrospective, the team reflects on what happened in the iteration and identifies actions for improvement going forward.

Scrum: Scrum is an agile methodology that describes a set of meetings, tools, and roles that work in concert to help teams structure and manage their work.

Product Backlog: A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes, or other activities that a team may deliver to achieve a specific outcome. The product backlog is the single authoritative source for things that a team works on.

Product Owner: The product owner is accountable for maximizing the value of the product resulting from the work of the agile team. They are responsible for defining the items on the product backlog and prioritizing them.

Scrum Master: This is a role within teams using the scrum framework. The scrum master is responsible for ensuring a true scrum process over the course of a project. They hold together the scrum framework, facilitating the process for the organization, product owner, and scrum team.

Definition of done: The definition of done is an agreed-upon list of the activities necessary to get a product increment to a done state by the end of an iteration.

Flavors of Agile

Agile is a philosophy of software development. Under this philosophy, there are different methodologies of applying agile such as Scrum, extreme programming, and kanban. There are others, but those three are the most popular.

Each of these more particular methodologies has its own ideas, communities, and leaders. Below is a brief overview of each methodology, and the similarities and differences with the other approaches.

Scrum

Scrum is an agile methodology that describes a set of meetings, tools, and roles that work in concert to help teams structure and manage their work. It focuses on the management aspects of software development. Development work is divided into iterations called ‘sprints’. Scrum applies closer monitoring to each sprint using daily scrum meetings. At the end of each sprint, the team does a sprint review and a sprint retrospective. Scrum does not push engineering practices as much as other agile methodologies. Teams often combine Scrum with engineering practices from extreme programming.

Extreme Programming

Extreme programming is an agile methodology that emphasizes engineering practices. The principles of agile development are combined with a set of engineering practices that teams can apply day-to-day. Extreme programming aims to produce higher quality software and higher quality of life for the development team. Some examples of extreme programming engineering practices include continuous integration, pair programming, refactoring, and automated testing including test-driven development.

Kanban

Kanban is an agile methodology that focuses on just-in-time delivery of functionality and managing the amount of work in progress. The work of all kanban teams revolves around a kanban board, a tool used to visualize work and optimize the flow of the work among the team. A basic kanban board has a three-step workflow: To Do, In Progress, and Done. However, depending on a team's size, structure, and objectives, the workflow can be mapped to meet the unique process of any particular team.

Scrum vs Extreme Programming vs Kanban

Cadence: Scrum and extreme programming have regular fixed-length iterations. Kanban has a continuous flow, no iterations.

Planning: Scrum and extreme programming have formal planning on a fixed iteration schedule. Kanban teams also plan, of course, but they are not on a fixed iteration schedule with formal planning.

Retrospectives: Scrum and extreme programming have a retrospective based on a fixed cadence. Kanban does not prescribe a retrospective, however kanban teams can benefit from occasional retrospectives, too.

Release methodology: Scrum and extreme programming at the end of each iteration. Kanban applies continuous delivery or at the team’s discretion.

Roles: Scrum has a product owner, scrum master, and development team. Extreme programming has a customer, developer, tracker, and coach. Kanban has no explicit roles, although some teams enlist the help of an agile coach.

Change philosophy: Scrum and extreme programming strive not to make changes to the work committed to during an iteration. Kanban, change to work can happen anytime.

In the real world teams often combine practices from multiple agile methodologies. Teams apply what works well for their context.

Conclusion

Agile rituals such as planning, daily stand-up, backlog refinement, review, and retrospective allow agile teams to deliver products faster and with better quality.

Agile rituals help development teams deliver work in small, but valuable, increments for the customer. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly.

How Status Hero Can Help

Status Hero can help make your team’s agile rituals effective by turning your agile-style check-ins and project management data into concise, insightful reports. It collects all of the work details so you can use stand-ups to talk about substance, and allows you to seamlessly connect remote team members, so you can work across asynchronous schedules and time zones with less confusion.

Finally, Status Hero will help your team build trust and gain transparency through understanding how everyone else is contributing to the team's goals. More trust means quicker decision-making, smoother collaboration, better estimates, and a more focused team.