How Adaptable Should Agile Be?
How It All Began: Project Setup and Emerging Challenges
Our Scrum team followed Scrum practices and a 14-day sprint cycle. While things ran smoothly initially, increasing scope changes became a challenge as the product grew.
The project, an operations management app with evolving requirements from multiple stakeholder teams, faced frequent and urgent feature requests, sometimes mid-sprint. New requests that arrived at that time were the result of various in-house demands from different teams using the application. Each request was deemed important due to the equal involvement of these teams in the organization. To manage these requests, we engaged in discussions with stakeholders to prioritize them effectively, utilizing several approaches to reach an agreement. Nevertheless, there were instances when consensus could not be achieved, necessitating mid-sprint adjustments to our sprint goals. Despite planning, these requests often took precedence over current tasks. The rapid influx of new features, priority shifts, bugs, and needed improvements made managing scope changes challenging. Adhering to Scrum’s framework became difficult as we struggled to keep up with the pace of change, leading us to be “too agile” for the environment.
Starting to Tackle the Challenges
As a product owner, I took this problem seriously and analyzed possible solutions. So, my first stop in this analysis was the good old Agile Manifesto, as we were still using Scrum at the moment.
“Responding to change over following a plan.”
This principle suggests that the team should be able to respond to and welcome change (sounds like just what I needed), but Scrum’s “no change within the sprint” rule doesn’t address mid-sprint scope changes. Shortening sprints to 7 days might help manage scope, but client requests can still arise during the sprint. Adapting to change requires balancing completed work with delivery frequency. Maintaining a two-week cycle while frequently adding new features and changing plans made allocating time for critical phases like testing increasingly difficult. Consequently, sticking to the “no change” rule during sprints became unfeasible, prompting me to explore other solutions.
I left some space in upcoming sprints for new features, which worked in some cases but not others. Sometimes, the design team completed medium to large features that later lost priority, causing inefficiencies and frequent context switching. Rushing without proper planning also led to neglected performance and suboptimal iterations that didn’t integrate well into the overall product.
Unveiling New Pathways
After some time, I came across the Agile 2.0, which at the beginning seemed to me like the newest version of the iPhone – 90% the same as the one before, but this time, you have one additional camera lens. However, I read one argument on why Agile 2.0 is better that says:
“Agile does not tell you how to transition to being more Agile – it only provides a target state.”
Since I completely resonate with this, I gave it a shot. So one of the first principles of Agile 2.0 says:
“Any successful initiative requires both a vision or goal and a flexible, steerable, outcome-oriented plan.”
The difference here is that Agile 2.0 shifts from merely responding to change to actively initiating it. Why is this different? When initiating, one needs a plan and a structure. This approach emphasizes the need for planning and structure, enabling teams to prepare for and embrace changes effectively. By focusing on goals rather than just tasks—like removing obstacles and achieving alignment—Agile 2.0 combines structured planning with Agile’s adaptability, enhancing overall effectiveness.
Agile 2.0 didn’t introduce a new methodology or tool but rather facilitated implementing change. For me, it opened the door to implementing changes. While investigating Agile 2.0, I noticed it was built by customizing what didn’t work in an Agile. This also sends us the message that even the best methodologies need adaptation at one point. Our goal should be that we are always prepared for needed change and have a plan even for plan changing.
At the Heart of the Solution
Next, we combined these new principles with the old-schooled Scrum we were previously implementing, left the strict frames of Scrum that were not serving us any longer, and still kept the good stuff. These are some of the key points:
- Encouraged clients to consider their most important long-term needs for the product
Inspiring clients to think about their most important goals for the upcoming period brings a lot of value – to their business, to the product we are building, and most importantly for all of us to be on the same page regarding the priorities for the near future.
- Introduced incremental planning with a time frame tailored to the team’s specific needs
We started having more frequent planning meetings where we would discuss some of the newest requests and how to incorporate them into the upcoming work. In addition, we introduced a concept of quarterly planning to our clients to set clear goals for the upcoming quarter since the quarterly approach worked well with our client tempo. We ensured the incremental plan reduced scope changes for the team and provided clients with clear expectations for product expansions.
- Allowed flexibility for high-priority features while keeping a predefined general path for the upcoming months
This gave us a clear view of planned features and expansions. We always left some space for thehigh-priority features to squeeze into particular months, but the general path for the next few months was preset. Still, we kept our sprint plannings, where we would add some smaller new features, bugs, and improvements to the sprint. But the “highest” goal was always known in advance.
- Adjust plans according to the preset goals: add new items if needed, decide if something must be removed, and establish priorities for removal
When adopting plan adjustments, base them on the preset goals. If new items or features need to be included, evaluate whether existing elements should be removed to maintain balance. Prioritize which elements to remove by assessing their importance relative to the new additions and overall goals. This approach ensures that changes align with strategic objectives and resource constraints.
This method balanced structured long-term goals with the ability to address immediate needs, ensuring that both the team and the clients were aligned on priorities. As a result, it significantly reduced the frequency of scope changes and improved overall project stability, making our planning process more strategic and efficient.
Final Thoughts: No One-Size-Fits-All – Crafting Custom Solutions
Agile and Agile 2 focus on flexibility, collaboration, and customer satisfaction. Agile 2 enhances Agile by streamlining processes and addressing its limitations, making it better for larger teams needing structured flexibility. But overall, my experience has taught me that no methodology in the world will fit each team’s and each product’s needs. Organizing work in a way that we are always ready for change but in a way where we planned it in advance by leaving space for urgent requests without disrupting the initial plan that much, was really a winner for my team. Product owners and service leads must adapt methodologies to fit their team’s needs for success. The challenge lies in finding the right balance between frequent adjustments and maintaining a structured approach. It’s essential to select the appropriate cadence that aligns with your team’s dynamics and project requirements. I found success by blending principles from Agile, Agile 2, and even waterfall into a custom solution tailored to my team. Crafting a solution and adapting it in every moment where you notice it doesn’t serve you any longer, using all kinds of sources and methodologies, certainly will give results if done properly – just give it a shot.
