Everyone’s talking about Agile. It’s the latest approach that dynamic or progressive companies are jumping on board with, even some that don’t do software development! Understanding what Agile is helps us see the intent behind the Agile methodology and the practices outlined in the Agile Manifesto. But, when someone claims to be using Agile, what are they actually doing or implementing?
So, What Does Agile in Practice Look Like?
Software development teams that are implementing Agile in practice are often using the Scrum framework and so are managing work through sprints. However, if you ask a typical business owner or manager whether their company is ‘agile,’ many of them will answer based solely on whether their development team are using sprints.
Agile and Scrum
There are many different ways that the Scrum framework can be implemented: some teams will have formal scrum masters, others will have someone in the team or a product manager taking on the role, other teams won’t have any, and the team will manage themselves.
About half these Agile teams following Scrum will be doing retrospectives and most teams have some form of daily meeting, such as a daily stand-up or daily Scrum meeting.
Customer feedback is an integral part of the Agile framework. Product owners or managers will talk to the users about the usability of the product and how it’s helping them. The user feedback helps in decisions about what features or bug fixes the development team should prioritise next.
Sprints
Planning Sprints
A sprint planning meeting is where the team gets together and plans what work is going to be done over the period of the next sprint. The purpose of the meeting is to estimate how much work can be done in the sprint, based on the team’s capacity, and then what mix of work should be done.
Most teams settle on two-week sprints, although some use longer sprints (up to four weeks) and some use shorter sprints (one week). One week is recommended. However, a lot of companies find a one-week sprint rate quite difficult to maintain, even though the shorter the sprint, the more ‘agile’ it is.
Read more on sprint length (and impact on workflow)…
Executing Sprints
Once the sprint has been planned, the work is given to the team. A number of teams use a task management system or visual board to track the work-in-progress. In some cases, it’s a manual board, and in other cases it will be digitally-based in a platform such as Jira. It’s also possible to find teams which are running sprints without any task management system in the background. They might work to an Excel list, or the team agrees on what they’re working on for the next two weeks and just get to it, leaving everyone responsible for tracking their own work.
What is Agile software development process?
Kanban-Style Boards
Scrum teams commonly use Kanban-style boards, which have three columns: ‘To-Do,’ ‘Doing,’ and ‘Done.’ There’s also a backlog component with all the work that hasn’t yet been approved to start. The ‘To-Do’ column is essentially the work that has been planned for the sprint but not started yet. The ‘Doing’ column shows what is being worked on, and when a task is finished it moves to the ‘Done’ column. The board may also have a testing column for noting what code needs to be tested before it can be declared ‘done.’ This style of task management system creates some visibility of the status of a particular piece of work, but doesn’t usually track the burn-down rate of progress against time.
Daily Stand-Ups
Once the sprint starts, the team gets to work on what has been approved to start, picking a task from the ‘To-Do’ column if the team is using a Kanban-style board. Alternatively, a team leader or manager may assign tasks to each developer. The team runs daily stand-up meetings, sometimes called the daily Scrum meeting, where people get an idea of what’s going on and what progress is being made with the sprint. This daily update on progress is particularly important for team leaders, because when they’re running a two-week sprint, they are essentially running a small project with a deadline of two weeks. At the stand-ups, they’re asking, “Are we on track to meet our targeted deadline?” That decision is often managed as a judgement call by the team leaders, although it would be better if they had the data or visibility to make that decision.
Summary
All of the above adds up to what Agile looks like in practice, in a typical small-to-medium-sized business.
- The development teams usually run sprints of two-weeks.
- Sprints are usually planned from a backlog of features and bug fixes.
- The teams execute the ‘To-Do’ list, sometimes using a form of task management.
- Most teams run daily stand-up meetings to monitor progress.
Beyond Agile
Pace: a new approach to software development
In some areas of software development projects, we need to go back to being less agile, and more rigid and robust with our planning. In other areas, though, some of the benefits of Agile aren’t agile enough; we need to push to be even more agile. For example, sprints in many cases are planned off what the team’s capacity is. A sprint aims to get x amount of work completed in a certain amount of time, i.e. 10 days’ worth of work completed by the team in 10 working days.
Pace is an approach to software development that has emerged as a solution to the negative side effects of the Agile approach. It’s not a radically, out-of-nowhere, different approach from Agile.
Rather, it’s much like the previous ‘evolutions’ of methodologies in the software engineering industry, where it seeks to address unresolved challenges.