[ Agile Manifesto — Principle 3 ]
Adhering to the third principle of the Agile Manifesto, “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale,” ensures continuous value creation. By delivering working software frequently, teams gather feedback, adapt to changes, and confirm that the product meets the evolving needs of the stakeholders.
In the context of Scrum, this principle is closely tied to the concept of time-boxed iterations known as Sprints. Sprints typically last one month or less, during which the Scrum team aims to deliver a working product increment. This iterative approach allows for regular inspection and adaptation, enabling the team to respond to feedback and make necessary adjustments throughout the development process.
"The ability to deliver working software frequently is a key measure of agility and responsiveness.” — Martin Fowler
Strategies for adhering to the 3rd Principle
To adhere to this principle effectively, Scrum and any agile team can employ several strategies:
(1) Embrace incremental development: Instead of aiming for a single, large release at the end of a lengthy development cycle, focus on delivering incremental value in each iteration. By breaking down the product into smaller, manageable features, the team can deliver working software at the end of every Sprint/iteration, providing stakeholders with tangible results and opportunities for feedback.
“Frequent releases help you build a solid relationship with your customers because they see the results of your work more often.” — Henrik Kniberg
(2) Implement continuous integration and delivery: Implementing robust continuous integration and delivery practices enables teams to automate the build, test, and deployment processes, facilitating the frequent delivery of working software. By streamlining these processes, teams can reduce the time and effort required to release new features, thereby accelerating the feedback loop and enhancing the overall product quality.
“Deliver a small batch of working software often, with each release providing business value and an opportunity for feedback.” — Mike Cohn
3) Foster collaborative planning and prioritization: Engaging stakeholders and prioritizing the Product Backlog based on value and feasibility can help ensure that the most valuable features are delivered early and frequently. This approach allows the team to focus on delivering high-impact functionality within shorter timescales, aligning with the preference for shorter feedback loops.
“Frequent software delivery fosters trust and collaboration between development teams and stakeholders.” — Ron Jeffries
(4) Encourage empowerment and accountability: Encouraging a culture of empowerment and accountability within the team fosters a sense of ownership and commitment to delivering working software frequently. When team members are empowered to make decisions and take ownership of their work, they are more likely to proactively drive the delivery process and uphold the principle of frequent software delivery.
Common Challenges
It may sound promising and straightforward in theory, doesn’t it? However, in reality, teams often encounter obstacles that prevent them from fully embracing the third principle.
- Teams may feel pressure to deliver quickly and this sometimes compromises quality in their quest.
- Some team members may resist adopting new practices, hindering progress towards frequent software delivery.
- Delivering complex features within shorter timescales can pose a significant challenge.
- Rushing to deliver software may lead to the accumulation of technical debt, complicating future maintenance.
- External dependencies may introduce delays, affecting delivery timelines.
- Ensuring software quality within shorter timescales can be challenging.
- Responding to change while minimizing disruptions can be challenging.
- Continuous integration remains a significant challenge for many teams due to the considerable investment required to set up and maintain infrastructure and tooling.
Negative impacts of NOT following this principle and strategies to overcome them
Too many times though, teams do not follow this principle and this is what happens:
Reduced visibility and feedback
Long development cycles without frequent software delivery can limit stakeholder visibility into the product’s progress and functionality. This lack of visibility may result in misaligned expectations and missed opportunities for valuable feedback, leading to potential rework and delays.
What you can do:
Emphasize transparent communication: Establishing open and transparent communication channels with stakeholders can mitigate the impact of reduced visibility. Regularly sharing progress updates, conducting demos (i.e Sprint Reviews), and seeking feedback can help align expectations and ensure that stakeholders remain engaged throughout the development process.
Foster adaptive planning: Embracing adaptive planning practices allows the team to respond to changes effectively, even in the absence of frequent software delivery. By maintaining a flexible mindset and adapting plans based on evolving requirements, the team can mitigate the risk of change management challenges associated with delayed delivery (see my blog article about principle 2 Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.).
“Delivering working software frequently allows teams to maintain momentum and respond quickly to changing market conditions.” — Alistair Cockburn
Increased Risk of Change Management
Delayed software delivery increases the risk of accommodating changes late in the development cycle, potentially disrupting the project timeline and introducing uncertainties. Without regular feedback and adaptation, the team may struggle to address evolving requirements effectively.
What you can do:
Leverage prototyping and mockups: In situations where frequent software delivery is challenging, leveraging prototyping and mockups can provide stakeholders with early visualizations of the product’s direction. While not a substitute for working software, these artifacts can facilitate early feedback and validation, reducing the impact of delayed delivery on stakeholder engagement.
Avoid scope creep and keep it simple (see my blog article about principle 10 Simplicity — the art of maximizing the amount of work not done — is essential. ).
Diminished Product Quality
Lengthy development cycles may result in a lack of early validation and testing, leading to the accumulation of defects and technical debt. Without the opportunity to validate the software incrementally, the overall product quality may suffer, impacting user satisfaction and market competitiveness.
What you can do:
Prioritize continuous improvement: Encouraging a culture of continuous improvement within the team fosters a proactive approach to addressing quality issues and technical debt. By prioritizing regular retrospectives and actioning improvement initiatives, the team can mitigate the impact of diminished product quality resulting from delayed software delivery (see my blog article about principle 8 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly ).
“Frequent delivery is crucial; it’s how we learn, adapt, and respond to change.” — Mary Poppendieck
Invest in test automation and test infrastructure to ensure comprehensive test coverage and timely feedback on code quality.
By recognizing these challenges and implementing appropriate strategies and countermeasures, teams can effectively adhere to the Agile Manifesto’s third principle and deliver working software frequently.
Reflection in other agile methods or frameworks
Other agile methods, such as XP, Kanban, Lean Software Development, and DevOps, support the frequent delivery of working software through various practices and principles:
Extreme Programming (XP)
Extreme Programming (XP) is an Agile software development methodology emphasizing continuous feedback, rapid iterations, and customer involvement. Its practices, including Test-Driven Development (TDD), Continuous Integration (CI), and Pair Programming, ensure frequent delivery of working software by testing, integrating, and deploying code regularly. XP iterations mirror those in Scrum with a fixed length determined by the team. Releases should occur at least quarterly, and new software integration into production should be daily, fulfilling prerequisites for achieving these goals.
Kanban
Kanban is a visual management tool that helps teams visualize their work and workflow, enabling them to prioritize tasks, identify bottlenecks, and deliver work incrementally. By limiting work in progress (WIP) and optimizing flow, Kanban encourages the frequent delivery of value to customers. This approach allows teams to focus on completing and delivering small, valuable increments of work, leading to more frequent software releases and customer feedback.
Lean Software Development
Lean Software Development is rooted in principles derived from Lean manufacturing, emphasizing the delivery of value to customers quickly and efficiently. Lean practices, such as eliminating waste, empowering teams, and optimizing the flow of work, support the frequent delivery of working software by streamlining processes, reducing lead times, and increasing productivity. By identifying and eliminating non-value-adding activities, Lean Software Development enables teams to deliver software in smaller, more frequent increments, aligning with the agile principle of delivering working software frequently.
DevOps
DevOps is a cultural and technical movement that aims to bridge the gap between software development and IT operations, enabling organizations to deliver high-quality software rapidly and reliably. DevOps practices, including Continuous Integration (CI) and Continuous Deployment (CD), support the frequent delivery of working software by automating build, test, and deployment processes. This automation reduces cycle times and increases release cadence, allowing teams to deliver software updates and new features more frequently while maintaining high quality and reliability.
In summary, XP, Kanban, Lean Software Development, and DevOps all contribute to the frequent delivery of working software by promoting incremental delivery, optimizing workflow, and automating processes to reduce cycle times and increase release frequency.
The impact of Scaling Frameworks
Sounds all fair enough. Most of us work in an environment where more than one team contributes to a product. Your organization may therefore have decided to introduce a scaling framework in order to coordinate multiple teams effectively.
While some scaling frameworks may contradict agile values and principles here and there, it’s worth examining their impact on adhering to the principle of frequent software delivery. Scaling frameworks like Nexus, LeSS (Large-Scale Scrum), SAFe (Scaled Agile Framework), and Scrum of Scrums can significantly affect a Scrum team’s ability to achieve this principle.
The challenges with using Scaling Frameworks
- Increased Coordination: Scaling frameworks like SAFe (Scaled Agile Framework) and LeSS (Large-Scale Scrum) introduce additional layers of coordination and planning to manage larger teams and projects. While these frameworks aim to improve alignment and collaboration, the overhead associated with extensive planning ceremonies can hinder teams’ ability to deliver working software frequently. Example: In a large organization implementing SAFe, teams engage in Program Increment (PI) Planning every quarter. During PI Planning, teams spend several days aligning their work for the upcoming increment, creating detailed plans, and identifying dependencies. However, the extensive planning process consumes a significant amount of time and resources, detracting from actual software development efforts. This results in a delay in delivering working software as teams are preoccupied with planning activities rather than executing on delivering value.
- Balancing flexibility and structure: Scaling frameworks provide a structured approach to agile development, offering guidelines and best practices for managing complex projects. However, rigid adherence to these frameworks can limit teams’ flexibility and autonomy, making it challenging to adapt to changing requirements and deliver software on shorter timescales.
- Addressing dependencies: Large-scale projects often involve multiple teams working on interdependent features or components. Scaling frameworks introduce mechanisms for managing dependencies, such as Scrum of Scrums and cross-team collaboration events. While these practices help address coordination challenges, they can also introduce delays and overhead, impacting the frequency of software delivery.
- Scaling agile practices: Agile practices such as Test-Driven Development (TDD), Continuous Integration (CI), and automated testing are essential for enabling frequent software delivery. Scaling frameworks must support the adoption and scaling of these practices across large teams and projects to ensure the continuous delivery of high-quality software.
- Risk of Waterfall-Like Behaviors: For example, in an organization transitioning to SAFe from a traditional waterfall development approach, teams struggle to adapt to the new framework. Despite SAFe’s agile principles, teams continue to work in silos, with little collaboration between development, testing, and operations. The emphasis on large-scale planning and coordination perpetuates a waterfall-like mindset, where work is handed off sequentially between teams and phases. As a result, the organization experiences delays in delivering working software, undermining the rapid feedback loops essential for agile development.
Navigating these challenges
- Tailoring frameworks to fit: Organizations should customize scaling frameworks to fit their specific context and needs. This may involve adapting ceremonies/events, roles, and processes to strike the right balance between structure and flexibility while prioritizing frequent software delivery.
- Emphasizing incremental progress: Instead of focusing solely on long-term planning and milestone-based delivery, teams should prioritize incremental progress and iterative delivery. Breaking down large initiatives into smaller, manageable chunks allows teams to deliver value more frequently and respond to feedback effectively. Especially when introducing SAFe, your teams may spend considerable time and effort on planning, detracting from their ability to focus on delivering working software frequently. This emphasis on planning can result in rigid, plan-driven development approaches that hinder agility and responsiveness to change.
- Cultivating a culture of continuous improvement: Scaling agile practices requires a culture of continuous improvement and learning. Teams should regularly reflect on their processes, identify areas for improvement, and experiment with new practices to enhance their ability to deliver working software frequently.
Scaling frameworks play a crucial role in enabling organizations to scale agile practices and manage large-scale projects effectively. However, they also introduce challenges that can impact teams’ ability to adhere to the Agile Manifesto’s third principle of frequent software delivery. By carefully navigating these challenges and prioritizing flexibility, collaboration, and continuous improvement, organizations can overcome the constraints of scaling frameworks and maintain their commitment to delivering working software frequently.
“The faster we can deliver valuable software to users, the sooner we get feedback to make adjustments.” — Ken Schwaber
Key Takeaways
- Adherence to Agile Principle: Delivering working software frequently, within shorter timescales, is crucial for ensuring continuous value creation and meeting stakeholder needs in agile development.
- Strategies for Adherence: Embrace incremental development, implement continuous integration, foster collaborative planning, and encourage empowerment and accountability to effectively adhere to the principle.
- Common Challenges: Teams may face challenges such as time pressure, resistance to change, technical complexities, and external dependencies, hindering their ability to deliver software frequently.
- Negative Impacts of Non-Adherence: Failure to follow this principle can result in reduced visibility and feedback, increased risk of change management issues, and diminished product quality.
- Strategies to Overcome Challenges: Emphasize transparent communication, adaptive planning, and continuous improvement to mitigate the negative impacts of non-adherence.
- Support from Agile Methods and Frameworks: Various agile methods and frameworks, including Extreme Programming, Kanban, Lean Software Development, and DevOps, support the frequent delivery of working software through their respective practices and principles.
- Challenges with Scaling Frameworks: While scaling frameworks like SAFe and LeSS introduce coordination challenges and risk of waterfall-like behaviors, organizations can navigate these challenges by tailoring frameworks, emphasizing incremental progress, and cultivating a culture of continuous improvement.
- Commitment to Agile Principles: Despite the constraints of scaling frameworks, organizations can maintain their commitment to delivering working software frequently by prioritizing flexibility, collaboration, and continuous improvement.
We are here to coach you and your team. We’ve got a range of awesome trainings for you to pick from.
THE poster to always have the Agile Manifesto right in front of you. Or simply, to visually enhance a dull workplace.
