Crossing the chasm between traditional and agile planning

6 differences between agile and traditional planning

Traditional and agile planning differ in significant ways. Before you make the leap to agile, make sure you understand how it's distinct from what you're used to.

arrows pointing different directions
Image by : 

Pixabay. Modified by Opensource.com. CC-BY-SA 4.0.

Get the newsletter

Join the 85,000 open source advocates who receive our giveaway alerts and article roundups.

Traditional and agile planning methods both focus on developing strategies to lead teams to succeed in today's competitive landscape; however, their approaches are quite distinct. If you're transitioning from traditional to agile planning, it's important to understand their substantially different mindsets and leadership styles.

Before we examine some of their key differences, it's important to understand why it's worth the effort to change. For many project managers, the basic tenets of agile are at odds with traditional management or leadership strengths. Unless there is a very strong imperative to change, our human nature will resist and fight it.

The primary reason to move to agile planning is the reality is that we can't plan our way around a world where there is constant disruption, and any effort to lock in specific execution steps will have gaps and flaws. This is driving companies to adopt a culture of open innovation and a new style of leadership to facilitate it.

Traditional top-down management is being replaced with a collaborative leadership style that empowers teams to plan and make decisions. It also leverages collective knowledge and experience, essentially doing crowdsourcing within the organization.

Six differences between traditional and agile planning

1. Directing vs. Allowing the team to find its own way

In traditional leadership, it's considered a great strength to direct a team to achieve a specific outcome. It is analogous to a shepherd herding his sheep through a treacherous terrain to a safe haven. The basic assumption is that that the leader (e.g., the project manager) knows the best way to allocate resources, manage risks, and even react to inevitable change. The team is expected to follow the plan that was set in motion, and any change or deviation must be routed back to the leader, who makes the necessary corrections after consulting with other stakeholders.

The agile approach allows the team to find their own way towards achieving specific goals. Senior management must invest more time and energy upfront to help the team understand the big picture and the organizational strategy. From there on, leadership trusts the team to make adjustments and tradeoffs to turn the vision into a reality. All impediments or changes in direction are openly and directly discussed with the stakeholders, and the plan dynamically changes to accommodate new learnings.

2. Expecting to never fail vs. Expecting to fail fast and fail forward

In traditional project planning, risk management carries enormous weight, and the leader continuously assesses the risks involved. The project manager works diligently to overcome or mitigate risks and ensure the team achieves objectives at predetermined deadlines. Failing is not seen as an option, hence there is no easy way to deal with it when it occurs. A lot of energy goes into determining why the failure occurred and who was responsible. Typically, the whole team—including the project manager—is blamed and everyone ends up dejected with decreased team morale.

In contrast, an agile mindset understands failing sometimes is natural, and early failure is in our best interest because it teaches us what does and doesn't work as soon as possible. It also recognizes there is no clear path to innovation and execution, and the team has to find its way through constant experimentation and subsequent learning. The default way is to try new things, even if the risk of failing is high in the initial stages. The collaborative leadership style encourages the team to fail fast and fail forward to learn and lay out a dynamic path to reach its key objectives and goals.

3. Limiting scope changes vs. Having a flexible scope

Change is often seen as a negative force in traditional planning because it disrupts the team from its original path, which had been laid out in exhaustive planning sessions spanning several months. Change request boards, which weigh the proposed change against the original scope rather than trying to understand why the change was requested, are set up to limit scope changes. If it's determined a change will extend deadlines or cause rework, it's usually rejected outright or pushed to the next phase of the project.

Agile thinking acknowledges that change is a constant force, and the best way to handle it is to remain flexible. This approach recognizes that it's better to deliver a project based on the most current information rather than sticking with old intel that may no longer be accurate. Even if it means scrapping or refactoring months of work, change will be entertained, be it a major course correction or a completely new goal post, if new information or feedback indicates it will produce a better result.

4. Investing in specific outcomes vs. Investing in the team's overall wellbeing and growth

The focus of traditional project planning is to deliver a project based on scope, quality, and schedule. That is a specific, narrow, and likely achievable outcome, and yet the project may be a failure if it doesn't account for other outcomes, such as products or skill sets that are no longer relevant in the market. Individual team members' growth and wellbeing is not directly relevant to traditional project managers; this responsibility is traditionally allocated to others in the organization.

In agile planning, the team's wellbeing and growth are considered an integral part of project delivery. At frequent intervals, team members are urged to reflect on how the team is feeling, their overall morale, and their ability to deliver projects. If team morale is low, the reasons are investigated and addressed by the team or management. A happy team is also an energetic and enthusiastic one that can deliver more than just a set of expectations and can lead a culture of innovation.

5. Coordinating individual and team efforts vs. Encouraging self-organization and collaboration

In the traditional model, the project manager is responsible for coordinating individual and team efforts by setting up checkpoints and meetings with other internal or external teams. It is tedious and laborious to work with all the teams involved, analyzing their dependencies and untangling them to lay out a clear and crisp plan to move work forward. The team is content to escalate its needs and wait for a response or instructions. The team doesn't proactively engage, self-organize, or collaborate inside or outside the team to address its issues.

The agile way encourages the team to self-organize and collaborate internally or with external parties (even those outside the organization). This is especially true in an open source project, where teams collaborate with multiple contributors and organizations as needed and without being prompted to do so. The expectation is that the team understands what needs to be done and it is trusted to do the work as the members see fit. They're empowered to work through the dependencies through a constant stream of communication with all the contributors of the project.

6. Finding solutions vs. Engaging the team to solve issues and challenges

Most projects run into impediments and challenges of many shapes and forms. In the traditional model, the project manager is responsible for finding solutions. There is a clear escalation procedure that bubbles issues to the top, then the team waits for a solution to be presented to them. Sometimes the team is blocked for a few weeks or even months waiting for someone to present a path forward.

In contrast, when the team is tasked with solving their own issues, something extraordinary happens: They typically rise to the challenge and find innovative solutions to dig their way out of the trenches. Agile planning puts many minds to work, instead of just one, to solve issues and resolve blockers. Crowdsourcing and collective thinking overcome challenges in unique and extraordinary ways.

The emerging new norm

Traditional leadership and planning served corporate culture well during the Industrial Revolution, where the focus was special-purpose machinery, factories, and mass production. A few executives who understood the market made decisions based on information that wasn't necessarily important to lower-level employees with very specific and specialized functions.

Today we live in an interconnected world where organizations deal with a challenging economic climate and international competition. As companies are seeking new paths to growth, new forms of leadership are emerging and taking hold. Workers are seeking more autonomy and engagement in their daily work. It is in the best interest of every organization to create a collaborative environment to foster a culture of creativity and innovation led by an agile approach to planning.

This article is based on a talk (Crossing the chasm between Traditional & Agile Planning) the author will be giving at Red Hat Summit 2018, which will be held May 8-10 in San Francisco.

Register by May 7 to save US$ 500 off of registration. Use discount code OPEN18 on the payment page to apply the discount.

About the author

Ranjith Varakantam
Ranjith Varakantam - I am part of the amazing Red Hat Developers Program and lead the Agile Transformation as the Principal Agile Coach. Our goal is to provide tools that make it easier for developers to succeed in their everyday endeavours, right from planning to production. Be sure to checkout our latest project OpenShift.io that allows all developers to plan, develop, test, build and deploy to production just from the web browser.