Sara Avdagić

How Adaptable Should Agile Be? When I first came across Agile software development, one particular phrase stuck with me - “Agile until it hurts.” After working for almost two years in an Agile environment, I started thinking that Agile somehow started causing not only pain but bleeding several times. The methodology that teaches us to adapt somehow needs adaptation. I will share why adaptation is necessary and how to achieve it, drawing on insights from my experiences. 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.   (more…)

1. Puzzles called Products In the realm of software development, the initial path forward is usually clear, with a well-defined goal of creating a high-quality product through incremental task deliveries. However, amidst this journey, it's not uncommon for the team members to have varying interpretations of what constitutes a task being truly "Done." My team encountered a similar challenge, and in this article, I will share how we successfully overcame this obstacle. 2. Done - so simple yet so abstract The concept of "Done" may appear deceptively simple, but it proves to be rather abstract and intricate in practice. Achieving completion requires a shared understanding among the Scrum Team members to ensure transparency throughout the software development process. This shared understanding is encapsulated in the Definition of "Done" (DoD) for Scrum, representing the agreed-upon conditions that must hold true to consider a backlog item truly completed. While certain DoD may suffice for a period, they often need adjustments as the team and product evolve.  Here are some examples of real-life situations where you realize that your team urgently needs to have a clear DoD:  A team member completed work on functionality as defined in the user story, but the following scenario occurred: The unit tests were skipped depending on who was working on the code Some of the functionalities in the system got broken The UI review for the particular feature never happened Some of the small parts that weren’t done fully per design got noticed after the feature was ready to be released The purpose of the definition of done is not to complicate matters or impose rigid rules that stress the team. Rather, it serves as a transparent and well-known guide, catering to the unique work cycle and needs of each team. It should be customized to fit the needs of the team and follow their unique work cycle.  Since Scrum promotes work transparency, executing the proper definition of done goes hand in hand with it. The whole team is well aware of the expected amount of development, testing, documentation, and deployments involved with a backlog item. 3. Real-life challenges  There were several situations where our team recognized the need to upgrade their DoD and evolve the procedures. In a timeframe of one year, we faced several changes in the team:  Significant team expansion with  some members joining the team at the same time Members switching to other teams reducing shared tribal knowledge Shorter release cycle due to the product needs All of these circumstances brought us to the point where we needed to consider evolving our DoD in order to return balance and understanding of the standards we as a team want to preserve and improve: Our initial DoD was nowhere documented - it was a rather verbally agreed set of steps that need to be followed to achieve Done. Back in the days when team was smaller and the product wasn’t mature as now, it was fine to have it that way Ambiguous ownership - in one point it became very unclear who owns the certain part of DoD at each phase since sometimes there could be few people responsible at the same time Current work procedures didn’t fit the product’s needs any longer  - most of our work procedures were defined in a way that assumed well-defined, finite tasks that were present at the very beginning of the project. As the product evolved, most of our new requirements implied investigation, bug fixes, refactoring, prototyping, and so on We understood that documenting DoD is the first step to evolving it and adjusting to our new needs.  To overcome this situation, we have created the following action plan: Meetings with representatives from each sub-team - Each sub-team (UI/UX design, Software Development, QA testing, and DevOps) had its own daily challenges. We tried to extract each sub-teams' biggest issues:  for the UI/UX team, those were mostly regarding the urge to have a unique place to perform UI reviews the Software Development team was facing large PRs and complex code to analyze the QA testing team had several challenges regarding documenting and automating tests DevOps team was having issues with frequent releases Analyzing work procedures and adjusting them to the current team’s needs Collecting each sub-teams needs and combining them into set work procedures This brought us to a newly created DoD that fits our needs. 4. Good practices adopted Reflecting on the implementation of our customized Definition of Done (DoD), several key aspects stand out. Each DoD Step has its Owner - Perhaps the most crucial aspect for our expanding Scrum team is the assignment of ownership to each step within the DoD. It's not just one person handling all tasks; instead, as a ticket progresses through various phases, from design to deployment, clear responsibilities are designated to specific individuals. These designated owners are accountable for executing, monitoring, and transitioning the task to its subsequent phase. As soon as a task is added to the Sprint backlog, the owners for each phase are promptly defined. They are also responsible for gathering and analyzing all necessary information from the rest of the team to ensure smooth progress Integrating Work with our Tools - Emphasizing the integration of our work tools is another beneficial practice we diligently nurture. Our toolkit includes Figma, JIRA, and GitHub, and we make the most of their integration options to facilitate seamless tracking of each task's lifecycle. Leveraging the extensive configurability and automation modules of JIRA, we have constructed a custom-made set of rules, adding various phases, fields, and workflows tailored to our specific needs. This integration not only streamlines our processes but also enhances collaboration and visibility across the team 5. Conclusion Over time, our team has wholeheartedly embraced and adapted to our new Definition of Done. It almost feels like tasks are effortlessly flowing through a well-oiled conveyor belt. With every team member keenly aware of their responsibilities, there are no bottlenecks or standstills in any phase of our work. This approach has proved instrumental in consistently delivering high-quality increments and, ultimately, a top-notch product. Beyond the tangible benefits of a high-quality product, providing a clear set of steps that emphasize quality and efficiency elevates the work atmosphere to a new level. By establishing well-defined procedures, ensuring thoroughness, and maintaining consistency, we invest not only in the product's future but also in the team's well-being. The synergy between a satisfied team and the creation of high-quality products is undeniable. As we continue to refine and optimize our processes, we find that our journey doesn't just lead us to a successful product but fosters a culture of growth, collaboration, and pride in our work. A well-crafted Definition of Done is more than just a checklist; it becomes the cornerstone of our achievements, pushing us toward excellence in every aspect of our software development endeavors. And the work is not done there yet. We will continue to evolve, as our team and product grow, change and mature. 6. References https://www.scrum.org/resources/blog/dod-evocycle-simple-technique-effectively-manage-your-definition-done https://www.productboard.com/glossary/agile-definition-of-done/#:~:text=What%20is%20the%20definition%20of%20done%20in%20agile%3F,perform%20for%20every%20backlog%20item https://www.scrum.org/resources/what-scrum-module https://www.atlantbh.com/design-review-in-product-development-2/ "Definition of Done Evolution" Tech Bite was brought to you by Sara Avdagić, Junior Product Owner at Atlantbh. (more…)