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.
A Brief History of Agile
Software development began with the traditional Waterfall approach, but now we commonly see, hear, or think of the more iterative approach known as Agile. The creation of the Agile approach didn’t occur because Waterfall was a ‘bad’ way of managing software development. In actual fact, when Waterfall first came out, there were many benefits to using this approach in software development. However, some negative side effects occurred through using Waterfall and the method didn’t fully resolve all the challenges developers faced with the changing customer needs of the software industry.
Thus, along came Agile and the Agile Manifesto. In the Agile approach, developers consider the more iterative and responsive methods as opposed to the more structured or infrastructure-heavy methods that Waterfall supports. In most cases, Agile was a step forward for software development, but there were still some negative side effects and issues that Agile didn’t fully resolve.
But Agile Wasn’t the Complete Answer…
When we compare Agile and Waterfall, we find that by taking a completely Agile approach, we lose some of the beneficial principles or parts of Waterfall. The Agile Manifesto states that, while we value the Waterfall approach and principles, we place even greater value on the Agile approach and principles. However, in most cases today, software teams attempt to use one approach or the other, thereby losing some benefits by completely prioritising or switching to a single approach.
Often, when teams are using the Agile Software Development Methodology, developers can get ‘lost down a rabbit hole.’ Developers become too focused on the next feature, then the next feature, or on customers’ ‘nice-to-have’ requests, rather than the end product. It’s easy to lose sight of the bigger picture when there isn’t a structured direction or a robust plan to follow.
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.
The original idea behind sprints was working to create a point of value that could be integrated into the product at the end of a sprint. That is, we focus on that one point of value and we sprint on it. The issue with managing it like that is the assumption that all features, or all points of value, are going to take the same amount of time for a team to develop. That’s unlikely to be true, so it doesn’t make sense to treat it that way. We also run into problems when we fail to consider the fact that different members of a team have different levels of output and different interactions required for a feature or piece of code require interactions and dependencies between those resources. Some resources are always required and, thus, become overloaded and slow down the flow of work.
A New Approach
Wouldn’t it be great if we could somehow pull the best parts from both approaches so as to have this meeting in the middle? We would be receiving the benefits of Agile without the negative side effects of going fully Agile.
This is where Pace comes in. Pace, as an approach to software development, looks at how a team manages the individual resources and interactions required during the software development process. A backlog of work is planned, rather than only planning the work for each sprint, so the direction is set with thought to the effects required for the bigger picture.
This backlog of work is chunked into smaller pieces and released onto a visual work board, a Kanban, or a dashboard. The visual board enables developers to see what they need to focus on and work on, so that they are working on the right thing, at the right time. The work is only released onto the board to be started when all the resources required to complete it have the capacity to do so. If a team has a series of processes, and some of those can move faster than others, then the team can only move as fast as the slowest process in the chain.
Pace identifies the most heavily-loaded resource(s) and then releases work based on that resource’s output. As a result, the resource does not become overloaded and slow down the flow of work or completions through the system.