Most development teams today say they follow Agile, but the actual practice varies widely. Agile is not a single methodology. It is a set of principles described in the Agile Manifesto, which values individuals over processes, working software over documentation, customer collaboration over contract negotiation, and responding to change over following a plan. How teams implement these values is where the differences emerge.
\nScrum is the most common Agile framework. It divides work into fixed-length iterations called sprints, usually two weeks. At the start of each sprint, the team selects items from the backlog to work on. At the end, the team demonstrates what was completed and reflects on how the sprint went in a retrospective.
\nKey roles in Scrum include the product owner, who prioritises the backlog, the scrum master, who facilitates the process and removes blockers, and the development team, who does the actual work. Daily standups keep everyone aligned by briefly sharing what was done, what is planned, and what is blocking progress.
\nKanban takes a different approach. Instead of fixed sprints, work flows continuously through stages like To Do, In Progress, and Done. The focus is on limiting work in progress (WIP). By setting a maximum number of items that can be in any stage at a time, the team avoids overloading themselves and can focus on finishing tasks before starting new ones.
\nKanban works well for teams that handle a mix of planned work and unplanned requests, like support teams or operations teams. There is no sprint planning or fixed cadence. Items are pulled into the workflow as capacity becomes available.
\nIn practice, many teams adopt a hybrid approach, taking elements from Scrum and Kanban that work for their context. The framework matters less than the habits.
\nRegular retrospectives are arguably the most valuable Agile practice. Without reflecting on what went well and what did not, the team cannot improve. It does not matter whether they happen every two weeks or monthly, as long as they happen and lead to actionable changes.
\nBreaking work into small pieces makes progress visible and reduces risk. A task that takes a week to complete and is only checked at the end is riskier than five tasks that each take a day, because problems surface earlier.
\nCollaboration over handoffs keeps work moving. When developers, designers, and product people talk regularly instead of passing documents back and forth, misunderstandings are caught sooner.
\nAgile goes wrong when teams follow the ceremonies without understanding the purpose. Having a daily standup where people read their ticket statuses adds little value. Estimating story points with false precision wastes time. Treating the sprint as a deadline that must be met at all costs leads to cutting corners.
\nThe goal is to deliver working software incrementally, gather feedback, and adapt. If the process is not helping with that, it is worth questioning whether the process needs to change.
"}},"pageContext":{"slug":"/2024-07-14-agile-in-practice/"}},"staticQueryHashes":[]}