https://engineering-leadership-preview.hinshelwood.com/tags/increment/ Recent content in Increment on Engineering Leadership in AI & Software Hugo en Tue, 16 Jun 2026 17:40:35 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/the-definition-of-done-is-a-commitment-to-quality/ Mon, 28 Jul 2025 09:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/the-definition-of-done-is-a-commitment-to-quality/ A clear, shared Definition of Done is essential for delivering quality, releasable software in Scrum and aligns teams on what “complete” means. It ensures transparency, predictability, and accountability, protects your product’s reputation, and must be created, automated, and regularly improved by all teams working on a product. Development managers should prioritise running DoD workshops, making standards visible, automating checks, and reviewing the DoD every sprint to maintain quality and reduce risk. https://engineering-leadership-preview.hinshelwood.com/videos/why-done-only-counts-when-it-s-live-moving-beyond-fake-finishes-to-real-value-in-software-delivery/ Wed, 07 May 2025 11:46:58 +0000 https://engineering-leadership-preview.hinshelwood.com/videos/why-done-only-counts-when-it-s-live-moving-beyond-fake-finishes-to-real-value-in-software-delivery/ Work is only truly done when it is live in production and delivering value to users, not just when code is written, tested, or demoed. Teams often mistake internal milestones for real progress, which delays learning and frustrates stakeholders; real feedback and value come only from live usage and telemetry. Development managers should redefine “done” as live in production, invest in automation to shorten release cycles, and focus on measuring and celebrating actual user impact. https://engineering-leadership-preview.hinshelwood.com/articles/release-planning-and-predictable-delivery/ Tue, 24 Nov 2020 13:00:01 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/release-planning-and-predictable-delivery/ Predictable delivery and agile release planning are not incompatible, but achieving them requires a shift in mindset, a focus on continuous quality, and embracing transparency. Key actions include making quality non-negotiable, refining backlog items to be small and clear, ensuring teams own the full delivery process, and minimizing dependencies. Development managers should prioritize building working software in regular increments, stop accumulating technical debt, and foster a culture of continuous improvement to improve delivery predictability. https://engineering-leadership-preview.hinshelwood.com/videos/stop-paying-the-hidden-costs-of-weak-delivery-why-a-strong-definition-of-done-transforms-your-team-s-results/ Wed, 21 May 2025 06:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/videos/stop-paying-the-hidden-costs-of-weak-delivery-why-a-strong-definition-of-done-transforms-your-team-s-results/ Cutting corners on quality and having a weak definition of done leads to hidden costs like rework, production risks, and lost trust. A clear, shared, and enforceable definition of done ensures every increment is truly usable, reliable, and aligned with business goals. Make your definition of done visible, evidence-based, and strictly enforced to improve delivery outcomes and build stakeholder confidence. https://engineering-leadership-preview.hinshelwood.com/videos/why-your-definition-of-done-is-holding-back-quality-agility-and-trust-and-how-to-raise-the-bar/ Wed, 09 Jul 2025 06:45:00 +0000 https://engineering-leadership-preview.hinshelwood.com/videos/why-your-definition-of-done-is-holding-back-quality-agility-and-trust-and-how-to-raise-the-bar/ Treating “done” as a vague checklist limits quality, agility, and stakeholder trust; instead, teams should define “done” as delivering thoroughly tested, production-ready, and valuable increments that work in the real world. Clear, objective standards for “done” reduce defects, speed up learning, and build confidence with stakeholders. Development managers should work with their teams to set and uphold a robust definition of “done” to drive better outcomes and long-term success. https://engineering-leadership-preview.hinshelwood.com/articles/a-better-way-than-staggered-iterations-for-delivery/ Thu, 10 Dec 2020 09:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/a-better-way-than-staggered-iterations-for-delivery/ Staggered iterations slow feedback, increase technical debt, and reduce software quality, making delivery less agile and more expensive. Instead, form cross-functional teams that deliver working software every iteration, integrate all required work including testing into each sprint, and automate as much as possible. Shift away from staged handoffs to continuous, team-owned delivery to improve value and quality. https://engineering-leadership-preview.hinshelwood.com/articles/without-delivery-there-is-no-value/ Mon, 10 Feb 2025 09:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/without-delivery-there-is-no-value/ Value in software is only realised when products are delivered to users, so frequent releases are essential to validate assumptions, gather feedback, and adapt quickly. Delaying delivery increases costs, risks, and missed opportunities, while research shows that teams releasing often are more successful and resilient. Development managers should prioritise short feedback loops and empower teams to release working software regularly to maximise value and minimise waste. https://engineering-leadership-preview.hinshelwood.com/articles/professional-scrum-teams-build-software-that-works/ Thu, 03 Dec 2020 00:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/professional-scrum-teams-build-software-that-works/ Professional Scrum teams must deliver high-quality, working software every sprint, prioritizing quality over speed or feature quantity to build trust and protect the organization’s reputation. Developers are accountable for quality and should use automation, DevOps practices, and continuous improvement to avoid technical debt and defects. Managers should empower teams to focus on quality, address technical debt in retrospectives, and consider upskilling developers through professional training. https://engineering-leadership-preview.hinshelwood.com/articles/the-scrum-master-is-accountable-for-delivery/ Thu, 30 Jan 2025 00:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/the-scrum-master-is-accountable-for-delivery/ The Scrum Master is ultimately accountable for ensuring the Scrum Team delivers a usable product increment every sprint, as delivery is the minimum requirement for team effectiveness. While delivery is a shared team responsibility, the Scrum Master must create the right environment, remove impediments, and enable continuous improvement so delivery becomes inevitable. Development managers should hold Scrum Masters accountable for delivery outcomes and empower them with the authority and resources needed to support team success. https://engineering-leadership-preview.hinshelwood.com/articles/i-do-continuous-deliver-why-should-i-sprint/ Mon, 13 Jul 2020 18:42:03 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/i-do-continuous-deliver-why-should-i-sprint/ Sprints are not about limiting release frequency but about providing a regular cadence for planning, communication, and predictability, even if you use continuous delivery. Scrum requires a working increment at least every 30 days, but you can release more often; Sprints help structure feedback loops and align teams and stakeholders. To stay competitive and responsive, use Sprints as a planning container while delivering to production as frequently as possible. https://engineering-leadership-preview.hinshelwood.com/signals/executives-want-predictability/ Mon, 31 Mar 2025 15:30:08 +0100 https://engineering-leadership-preview.hinshelwood.com/signals/executives-want-predictability/ If your teams do not have a clear, enforced Definition of Done, you are creating hidden risks and unreliable forecasts, which leads to missed deadlines and frustrated customers. Treating “Done” as negotiable means you are not delivering real value or predictability. Make sure your teams only mark work as done when it meets objective, enforceable standards to ensure true progress and trustworthy commitments. https://engineering-leadership-preview.hinshelwood.com/signals/if-every-release-feels-high-risk-you-lack-a-true-definition-of-done/ Sat, 05 Apr 2025 15:30:00 +0100 https://engineering-leadership-preview.hinshelwood.com/signals/if-every-release-feels-high-risk-you-lack-a-true-definition-of-done/ If every release feels risky and stressful, your team likely lacks a clear Definition of Done that ensures software is truly ready for production. A strong Definition of Done means releases are routine, with quality, security, and compliance built in, so there are no last-minute scrambles. Review your team’s process to make releases predictable and low-stress. https://engineering-leadership-preview.hinshelwood.com/videos/special-sprints-agile-banditry-or-risk-management/ Thu, 04 Jan 2024 11:09:15 +0000 https://engineering-leadership-preview.hinshelwood.com/videos/special-sprints-agile-banditry-or-risk-management/ Special sprints like bug-fix or hardening sprints undermine Agile by encouraging teams to defer work and accumulate risk, rather than delivering usable products every sprint. The Azure DevOps team found that relying on a safety net led to overwhelming undone work, but shifting to shipping every sprint improved quality and reduced technical debt. Development managers should eliminate special sprints, ensure each sprint delivers a shippable product, and address issues as they arise to maintain true agility and reduce risk. https://engineering-leadership-preview.hinshelwood.com/videos/ditching-the-myth-of-special-sprints-embrace-true-agile-practices-for-usable-products/ Thu, 04 Jan 2024 12:14:45 +0000 https://engineering-leadership-preview.hinshelwood.com/videos/ditching-the-myth-of-special-sprints-embrace-true-agile-practices-for-usable-products/ Relying on special Sprints like Sprint Zero or bug fix Sprints undermines true Agile practices by encouraging risky behavior, diluting focus, and creating a false sense of security. Teams should instead prioritize delivering a usable product at the end of every Sprint, foster accountability, and integrate quality assurance into regular work. Development managers should avoid safety nets and focus on continuous improvement and value delivery each Sprint. https://engineering-leadership-preview.hinshelwood.com/articles/getting-started-with-a-definition-of-done-dod/ Mon, 14 Dec 2020 13:03:00 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/getting-started-with-a-definition-of-done-dod/ A clear Definition of Done (DoD) is essential for ensuring software quality and predictable delivery, as it sets shared criteria for what “done” means for every increment. Involve the whole Scrum Team and relevant experts to create a short, measurable checklist that covers code quality, testing, security, and usability, and review it regularly to keep raising the quality bar. Before starting sprints, make sure your current increment meets the DoD, and continuously improve both your software and your DoD to maintain a working, shippable product. https://engineering-leadership-preview.hinshelwood.com/articles/storms-of-neglect-the-perils-of-not-delivering-usable-products-in-agile-iterations/ Thu, 27 Jul 2023 09:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/storms-of-neglect-the-perils-of-not-delivering-usable-products-in-agile-iterations/ If teams do not deliver a usable product at the end of each iteration, trust with stakeholders erodes, technical debt grows, adaptability slows, and expectations become misaligned. This also leads to lower team morale and a lack of feedback, making it hard to improve or stay on track. To avoid these issues, ensure every iteration results in a usable product so you maintain trust, alignment, and the ability to adapt quickly. https://engineering-leadership-preview.hinshelwood.com/articles/professional-scrum-developer-net-training-in-london/ Fri, 18 Jun 2010 15:53:27 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/professional-scrum-developer-net-training-in-london/ Intensive five-day course for software developers covering Scrum, Visual Studio 2010, .NET, and Agile practices through hands-on team sprints and real-world case studies. https://engineering-leadership-preview.hinshelwood.com/articles/how-usable-working-products-are-your-ultimate-weapon-against-risks/ Thu, 20 Jul 2023 09:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/how-usable-working-products-are-your-ultimate-weapon-against-risks/ Continuously delivering a usable working product is the most effective way to reduce risk in Agile development. Focus on releasing functional increments, fixing bugs quickly, automating tests, and keeping documentation lean to stay responsive to market needs. Prioritise regular feedback from users and stakeholders to ensure you are building what truly adds value. https://engineering-leadership-preview.hinshelwood.com/articles/the-fallacy-of-the-rejected-backlog-item/ Mon, 13 Jul 2020 08:55:00 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/the-fallacy-of-the-rejected-backlog-item/ Rejecting individual backlog items at the Sprint Review is a misunderstanding, since the increment is delivered as a whole and removing a single item is complex and risky. The Sprint Review is for feedback and learning, not for accepting or rejecting specific items, and any gaps should inform future backlog updates. Development managers should focus on clear communication, well-structured backlog items, and using feature flags to provide flexibility and faster feedback. https://engineering-leadership-preview.hinshelwood.com/guides/scrum-guide/ Mon, 01 Feb 2010 00:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/guides/scrum-guide/ A clear summary of Scrum’s framework, roles, events, artefacts, and values, explaining how teams use Scrum to deliver value and adapt to complex problems. https://engineering-leadership-preview.hinshelwood.com/videos/the-importance-of-delivering-working-software-every-iteration/ Wed, 26 Jun 2024 06:45:00 +0000 https://engineering-leadership-preview.hinshelwood.com/videos/the-importance-of-delivering-working-software-every-iteration/ Delivering working software to real users every iteration is essential for true agility because it enables rapid feedback, validates assumptions early, and maximizes value for stakeholders. Key practices include starting with a minimal viable product, prioritizing user stories for value, involving stakeholders regularly, automating testing and deployment, and fostering continuous improvement. To ensure your team is truly Agile, focus on releasing usable software each iteration and use real user feedback to guide development and avoid wasted effort. https://engineering-leadership-preview.hinshelwood.com/signals/let-us-be-blunt-if-a-scrum-team-isn-t-delivering-is-it-effective/ Fri, 07 Mar 2025 16:30:00 +0000 https://engineering-leadership-preview.hinshelwood.com/signals/let-us-be-blunt-if-a-scrum-team-isn-t-delivering-is-it-effective/ A Scrum Team is only effective if it consistently delivers usable product increments; without delivery, Scrum practices are just empty rituals. The Scrum Master is accountable for enabling the team to deliver by fixing any issues that block progress. If your team is not delivering, focus on identifying and removing obstacles to restore effectiveness. https://engineering-leadership-preview.hinshelwood.com/workshops/sprint-review-1/ Tue, 17 Sep 2024 00:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/workshops/sprint-review-1/ Guides a 160-minute Sprint Review workshop using Liberating Structures to inspect product progress, gather feedback, and plan next steps for Scrum teams and stakeholders. https://engineering-leadership-preview.hinshelwood.com/signals/agile-without-a-usable-working-product-is-just-expensive-theatre/ Sun, 20 Apr 2025 15:30:27 +0100 https://engineering-leadership-preview.hinshelwood.com/signals/agile-without-a-usable-working-product-is-just-expensive-theatre/ Agile only delivers value if each sprint results in a usable working product; focusing on rituals, documentation, or velocity without real output wastes time and resources. The key measure of success is having something shippable at the end of every sprint, which enables feedback and reduces risk. Development managers should ensure their teams are consistently delivering usable products rather than just going through the motions. https://engineering-leadership-preview.hinshelwood.com/signals/scrum-myth-debunked-unfinished-work-is-allowed-in-scrum/ Sat, 24 May 2025 15:30:17 +0100 https://engineering-leadership-preview.hinshelwood.com/signals/scrum-myth-debunked-unfinished-work-is-allowed-in-scrum/ Scrum does not require all work to be finished by the end of a Sprint, only that the Increment is Done and meets the Definition of Done. Unfinished items can carry over as long as the Sprint Goal and Increment are not compromised. Managers should focus on delivering value and avoid forcing work to fit arbitrary Sprint boundaries. https://engineering-leadership-preview.hinshelwood.com/guides/nexus-guide/ Tue, 17 Sep 2024 00:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/guides/nexus-guide/ Explains the Nexus framework for scaling Scrum with multiple teams, detailing roles, events, and artefacts to coordinate product delivery and manage cross-team dependencies. https://engineering-leadership-preview.hinshelwood.com/videos/navigating-complexity-why-agile-practices-are-essential-for-modern-product-development/ Fri, 07 Oct 2022 10:41:41 +0000 https://engineering-leadership-preview.hinshelwood.com/videos/navigating-complexity-why-agile-practices-are-essential-for-modern-product-development/ Agile practices are essential for modern product development because they help teams deliver value faster and adapt to constant change, unlike traditional methods that struggle with today’s complexity. Key insights include the unpredictability of requirements, technology, and people, and the importance of delivering working products regularly to reduce risk and waste. Development managers should focus on adopting agile approaches to improve responsiveness and ensure products better meet customer needs. https://engineering-leadership-preview.hinshelwood.com/articles/update-to-the-scrum-guide-on-the-25th-anniversary-of-the-scrum-framework/ Wed, 18 Nov 2020 16:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/articles/update-to-the-scrum-guide-on-the-25th-anniversary-of-the-scrum-framework/ The 2020 update to the Scrum Guide simplifies language and reduces prescriptive rules, emphasizing that Scrum Teams are self-managing and collectively accountable for delivering value each Sprint. Key changes include clear commitments for Product Goal, Sprint Goal, and Definition of Done, as well as a focus on cross-functional teams and improved Sprint Planning. Development managers should review the new guide to align their teams with these streamlined practices. https://engineering-leadership-preview.hinshelwood.com/signals/scrum-is-built-on-empiricism-transparency-inspection-and-adaptation/ Mon, 24 Feb 2025 16:30:29 +0000 https://engineering-leadership-preview.hinshelwood.com/signals/scrum-is-built-on-empiricism-transparency-inspection-and-adaptation/ Scrum relies on delivering a usable product increment every sprint, and if this does not happen, the team is not truly practicing Scrum. The Scrum Master is accountable for ensuring an environment where delivery is consistent and inevitable, with no excuses for missed increments. Development managers should ensure their Scrum Masters take ownership of delivery and address any barriers to producing usable increments each sprint. https://engineering-leadership-preview.hinshelwood.com/tags/increment/ Mon, 05 May 2025 10:17:24 +0000 https://engineering-leadership-preview.hinshelwood.com/tags/increment/ Increment refers to the tangible, usable output produced at the end of each iteration, particularly within frameworks like Scrum and Agile. It encapsulates the totality of completed work during a Sprint, ensuring that the product remains potentially shippable and consistently adds measurable value. As a core artifact in Scrum, the Increment embodies the principle of delivering working software incrementally, which facilitates timely feedback, iterative improvements, and mitigates the risks associated with large-scale releases. Its significance lies in the transparency it provides, allowing teams and stakeholders to assess progress clearly, thereby fostering collaboration and alignment. In Agile environments, the Increment serves as a foundation for adaptation, enabling teams to refine their strategies based on feedback and respond effectively to evolving requirements. By prioritising the delivery of increments, organisations can enhance workflows, promote continuous improvement, and ensure that products develop in alignment with customer needs. This focus on delivering working software helps minimise technical debt and prevents over-engineering, aligning development efforts more closely with business objectives. Ultimately, the Increment delivers the concrete, inspectable output that informs decision-making and enhances collaboration, making it a vital component of Agile and Scrum practices. https://engineering-leadership-preview.hinshelwood.com/tags/definition-of-done/ Mon, 05 May 2025 09:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/tags/definition-of-done/ The Definition of Done (DoD) is a critical framework that establishes a shared understanding of what constitutes a completed and releasable product increment within agile and DevOps environments. Originating from the need for clarity in product development, the DoD serves as an organisational standard that all teams must adhere to, ensuring that every increment meets minimum quality criteria before it can be considered complete. This framework is vital for fostering transparency and consistency across teams, enabling empirical decision-making based on real-world feedback. By defining specific criteria, such as deployment in production, telemetry collection, and validation of initial hypotheses, the DoD helps mitigate risks associated with incomplete or subpar work, thereby reducing technical debt and enhancing the overall quality of deliverables. Furthermore, it facilitates faster feedback loops and iterative learning, allowing teams to adapt their processes based on actual performance data. The DoD not only clarifies expectations for stakeholders but also protects the integrity of the product, ensuring that increments are valuable, verifiable, and ready for real-world use. In essence, the Definition of Done is foundational to maintaining high standards in product development, promoting alignment among teams, and ultimately driving successful outcomes in organisational design and delivery. https://engineering-leadership-preview.hinshelwood.com/tags/working-software/ Tue, 11 Feb 2025 10:17:24 +0000 https://engineering-leadership-preview.hinshelwood.com/tags/working-software/ Working Software is a fundamental artifact in Agile, Scrum, and Lean frameworks, serving as the tangible output of a team’s efforts throughout the development process. It emerges from iterative development cycles and acts as a demonstration of progress and value delivery. In Scrum, working software is the primary success metric for each Sprint, encapsulated in the Increment artifact, which is subject to inspection and adaptation based on stakeholder feedback. The Definition of Done ensures that the software meets established quality criteria, making it valuable and ready for release. The importance of working software lies in its ability to provide a concrete measure of progress, aligning teams and stakeholders around completed work and remaining tasks. It transcends mere code, representing deliverables that address real-world needs and customer expectations, thereby maintaining a focus on value delivery. In agile methodologies, the emphasis on working software fosters continuous feedback and improvement, enabling teams to release increments iteratively and adapt to evolving requirements. This focus enhances collaboration, increases transparency, and drives ongoing improvement within organisations. Ultimately, working software is not solely about technical execution; it is about consistently delivering value, responding to customer needs, and ensuring long-term sustainability, thereby contributing to customer satisfaction, innovation, and overall business success. https://engineering-leadership-preview.hinshelwood.com/tags/product-developer/ Mon, 20 Jan 2025 10:00:00 +0000 https://engineering-leadership-preview.hinshelwood.com/tags/product-developer/ Product Developer is a role and an accountability within Scrum and product development frameworks. All Product Developers together should possess all the skills needed to create Increments, with their combined skill set often referred to as cross-functional. Product Developers may be human or automated, committed to creating, researching, inspecting, and adapting any aspect of a releasable Increment each Sprint. Their primary focus is on the current Sprint, with some capacity invested in future-looking refinement and examining result feedback. Product Developers adhere to the Definition of Output Done and strive for net improvement, achieving the best results when they focus solely on one Product. They should adopt appropriate behaviors including collaborator, creator, and champion of technical quality, discovery, delivery, and value validation. Product Developers are collectively accountable for creating an emergent plan in the Sprint Backlog, instilling quality, creating usable Increments, learning through data, adapting their plan toward the Sprint Goal, holding each other accountable as professionals, and driving net improvement.