By now, most people involved in the world of systems architecture, software development, business development, and modernization are familiar with Agile. The term originated as a system of programming techniques, but is now widely regarded as a representation of an entire philosophy for encouraging simplicity and efficiency in business settings.
However, Agile is neither a collection of techniques nor a philosophy.
Agile is a discipline: it involves a series of events or practices that follow a consistent pattern and are set within a clear, repeatable structure. These events are designed to streamline progress, help to quickly identify issues and resolutions, minimize confusion, and allow for frequent communication; all resulting in maximized efficiency for an organization.
These results may sound too good to be true, but all that is necessary to achieve them is recognizing Agile as a disciple and carefully following its set sequence of developmental steps. These steps center around the Sprint Method, in which small teams collaborate over a period of about five to ten days to answer business questions through design, prototyping, and testing ideas with customers.
This process might sound complicated, but it can actually be broken down simply into the following five steps.
Step one: Sprint Planning
Duration: 2-4 Hours
The objective of the sprint planning phase is to ensure that everyone in the team has a communal understanding of the work to be completed in the current sprint.
Sprint planning begins with the Scrum Master, or project manager, laying out the context information and goal of the current sprint to all team members.
Next, team members will work together to review the backlog, taking care to include any work left over from the previous sprint, and assign members to work tasks. Team members may either volunteer for tasks or be assigned to them by their team leaders.
Before planning begins, all team members must agree over what estimates or criteria will qualify their sprint as “complete.” After this, teams are free to breakout and begin planning in groups for the sprint.
To reiterate, the simplified suggested meeting agenda for sprint planning is as follows:
- Review the sprint’s context, establish a goal statement for the current sprint, and discuss what was and was not completed in the previous sprint, priorities of the current sprint, and the next sprint’s goal.
- Review each item in the backlog thoroughly, eliciting questions and clarification from the team, and assign members to complete each task. Teams breakout to begin planning while the project manager performs check-ins, concluding with a review of progress and a collective confirmation of the sprint’s goals and priorities.
Best practices for the sprint planning step include teams working at the same time on their respective plans instead of waiting for each team to go one by one. This is important for preventing excuses for individuals to sit around while others are working.
Another key best practice for sprint planning is having the project manager or team lead perform frequent checks with teams to ensure that they aren’t getting stuck at any point while planning. These checks are also a good opportunity for teams to ask questions if needed.
Step two: Daily Cadence
The objective of the daily cadence phase is to establish a consistent structure that can inspire productivity for the developers and allow their progress to remain visible.
The daily cadence, comprised of morning and afternoon standups, provides an opportunity for team leaders to check on progress and ensure none of the teams are stuck.
In this step, it is important for developers to maintain their daily progress on a Kanban board and online in Confluence/Jira, so that the Scrum Master can see progress both on the physical board and online.
Best practices for daily cadences include ensuring that developers are updating their team boards and online software. Online tools are the recommended system of record, as developers can use this platform to update their tasks and progress several times per day.
Make sure to give special recognition to teams completing work ahead of schedule.
Step three: Daily Standups (am/pm)
Duration: 15 Minutes
The objective of daily standups is to establish the current status and progress of all activities, identify any problem areas that halt progress, and then assign workers to assist in problem solving wherever needed.
Best Practices for daily standups include promoting honesty and raising issues early. Any risk that may prevent the developers from achieving their sprint goal should be brought up immediately, so as to address problems before they can get worse.
Another key practice is avoiding problem solving during meetings, as this is not the point of standups and will take up too much time. Instead, use the meeting to simply identify the problems and assign who will work through them after the meeting.
Daily startups should never exceed fifteen minutes. If any further discussions are needed that exceed the allotted time, schedule a follow up meeting so that anyone who is not involved in the discussion may resume working.
Step four: Sprint Demonstration:
The objective of the sprint demonstration, or sprint demo, is to demonstrate all work completed during the spring to Product Owners and Stakeholders.
In a sprint demo, each team provides an overview of the features implemented during the sprint. This should include:
- An overview of the purpose and use of each feature, as well as its context and importance to the rest of the system.
- A demonstration of the sprint’s deliverables, walking through instructions for how a user could activate each feature.
- Identification of any issues encountered in your sprint and what actions were performed to mitigate these issues.
The best practices for sprint demos start with all team members being involved in the presentation. Next, rather than launching straight into the features of the project, it’s important to provide the context of each feature for your audience; the Project Owner and Stakeholders. This will help to avoid confusion as well as demonstrate that the developers thoroughly understand their projects.
Finally, remember to demonstrate the system from the perspective of the user, not from the perspective of the developer.
Step five: Sprint Retrospection
Duration: 1- 1.5 hours
The objective of the sprint retrospection, or sprint retro, is to review the current sprint by identifying process, approach, or solution improvements that can be learned from and later applied in following sprints.
The Scrum Master begins the sprint retro with an outline of both the progress so far as well as the specific issues that were raised during the sprint.
Next, the Scrum Master facilitates discussion of these issues, taking care to ask for suggestions, and concludes by reviewing what was discussed and documenting the conclusions.
The best practices for sprint retros involve all team members coming prepared to share their honest thoughts and suggestions. The Scrum Master should be honest, but not critical, and focus on identifying solutions. The most successful retros include input from every member of the team.
Breaking up your personnel into Agile Pods and following the Agile Development Process can provide many benefits to almost any organization.
Having smaller teams allow individuals to have more opportunities to speak up, innovate, and get recognized for their progress. Having team leaders minimizes distance between management and developers and creates a more relaxed, collaborative environment.
Sprints provide the structure that small groups need to plan ahead while giving them the freedom to experiment and make mistakes.
Thanks to the five steps of the Agile Development Process, organizations all around the world can easily liberate themselves from traditional, rigid management structures and operations in favor of flexibility, scalability, and process simplicity.
If you have any questions about agile software development- reach out. We’d be happy to chat.
For additional resources, check out RG’s resources page.