Welcome back to our Getting Started with Agile series, where we’re diving deep into the values that underlie today’s most popular agile methodologies.
In the last installment in this series, we discussed the value of treating your customers as collaborators, as well as how you can encourage them to become more involved in your product development process—and therefore, more vested in its ultimate outcome. In this installment, we’ll discuss how you can learn from your product development process so your team can benefit from that learning along the way.
A trait that’s common to most agile methodologies is favoring adaptive planning throughout the project over big up-front planning at the project’s outset. In fact, this trait is so valued by agile methodologies that the fourth value of the Agile Manifesto is Responding to change over following a plan. But to best understand why adaptive planning is so favored, let’s take a moment to contrast both approaches.
A team following a big up-front planning approach would take the time to plan its entire project, often in excruciating detail, at the project’s outset. After planning, the team would then focus on managing to the plan, or trying to keep project execution in alignment with the original plan that was defined months, or even years, prior.
While creating a very detailed plan at a project’s outset can provide stakeholders with a sense of security, this approach usually runs into one significant problem. As project execution unfolds, the team learns more about what needs that resulting product will fill as well as how that product can best be built. As this new reality emerges, the team struggles to keep their project aligned to the original plan, which likely no longer reflects the team’s new reality.
And therein lies the problem: as hard as the team might try to hold fast to their original plan and fight this new reality…reality always wins.
Agile methods, on the other hand, favor an adaptive planning approach. In this approach, planning is an ongoing activity throughout the execution of the entire project, occurring in small increments as the reality of project execution unfolds. The team then works to maintain alignment to a plan that continuously evolves to match the reality of both the end product and the team’s capabilities to deliver that product.
However, an adaptive planning approach doesn’t mean that there isn’t any planning at the outset, only that such planning is lightweight and occurs at a high level. This initial planning should be detailed enough to give the team a general direction and objective, but not detailed enough to dictate every move the team must make throughout the project. Instead, the team will discover the best moves for itself as the project unfolds.
But even aside from the challenge of managing to a plan that was created with complete naivety about how the project will actually unfold, there’s a more nefarious problem with big up-front planning.
The focus on managing to the plan that’s encouraged by proponents of big up-front planning rewards delivering what was originally defined at the project’s outset, within time and budget. This elevation of adherence to the project plan above the value that the product actually creates incentivizes the team to shortchange other aspects of its project (such as quality, sustainable team health, or customer value) in an attempt to meet the plan.
This is in contrast to an adaptive planning approach that encourages us to dig deeper into our project along the way to better understand the problem our customer is facing and how our end product can best solve it. In this scenario, the ultimate measure of success is not how closely the team was able to adhere to a 12-month-old plan that no longer reflects the customer’s actual needs, but rather how delighted the customer was when that product was delivered. Time and budget are still important in this scenario, but when viewed in this way, they simply become enablers of our product’s success, not the measure of it.
We’ve stressed the importance of adaptively refining our plan during project execution, but how do we do so? We do so through a combination of iterative and incremental development that’s so often encouraged by today’s agile methodologies.
Incremental development is the process of breaking a project into small chunks that can each be delivered separately. This approach can take many forms, depending on the specific agile methodology that your team may be following. For example, if your team is following an iteration-based methodology such as Scrum, then these iterations naturally lend themselves to incremental development. On the other hand, if your team is following a flow-based approach such as Kanban, then you can think of each work item or card as an increment that can be delivered independently of the rest.
Most agile teams intuitively understand the concept of incremental development, since it maps so closely to how they’re already working. But the concept of iterative development isn’t always so clear.
Iterative development builds on the concept of incremental development by asking teams to use each increment as a learning opportunity and then folding that learning into future increments. This learning may take the form of building a clearer understanding of who the customer for their product is, better defining what that customer’s needs are, or even simply improving how the team works together during execution. In any case, this constant iteration of the team’s product and process should ensure that each increment is better than the last.
But what’s behind this idea of adaptive planning?
Many agile methodologies are built on a branch of management theory known as empirical process control. Empirical process control is the idea that the most effective way to guide a process to success is to observe that process then act accordingly. Hence, empirical process control drives the idea of a team breaking a project into small increments and then adapting future increments based on what’as been learned from previous increments.
The theory of empirical process control is based on three tenets: inspection, adaptation, and transparency.
Inspection states that a team should closely inspect the outcome of each iteration to understand not only what that iteration produced but also what occurred during that iteration.
Adaptation states that a team should alter its behavior based on the results of inspecting the previous iteration. This adaptation may take the form of revising goals and objectives or even altering how the team works together to achieve those objectives.
Transparency tells us that the information the team uses to inspect its recent outcomes and adapt accordingly must be accurate and presented without bias. If a team is not fully transparent and forthcoming with the information it’s inspecting, such as withholding quality issues or failing to surface concerns that may be festering, then the team will not be equipped with the information necessary to adapt its way to success.
Few would doubt that agile teams tend to be more successful than teams following a traditional process, but the reasons for that success are often misunderstood.
From an outsider’s perspective, high-performing agile teams seem to know all of the answers at the outset. But those who have spent any significant amount of time inside of an agile team know that the truth is rarely so simple.
When a project begins, agile teams face as many questions as a traditional team. But how agile teams view those questions is what differentiates them from their traditional counterparts. Rather than believing that all questions must be answered at the outset, agile teams build learning and growing into their process to uncover the answers along the way and adapt their way of working accordingly.
It’s not that agile teams know all of the answers…it’s that agile teams are willing to ask the questions and adapt to what they learn along the way.
Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at www.jeremyjarrell.com, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.
Category: Productivity
