<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Working Software on Engineering Leadership in AI &amp; Software</title>
		<link>https://engineering-leadership.hinshelwood.com/tags/working-software/</link>
		<description>Recent content in Working Software on Engineering Leadership in AI &amp; Software</description>
		<generator>Hugo</generator>
		<language>en</language>
		
		
		
		
			<lastBuildDate>Tue, 16 Jun 2026 17:40:35 +0000</lastBuildDate>
		
			<atom:link href="https://engineering-leadership.hinshelwood.com/tags/working-software/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Is Agile Really Just a Mindset?</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/is-agile-really-just-a-mindset/</link>
				<pubDate>Mon, 11 Aug 2025 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/is-agile-really-just-a-mindset/</guid>
				<description>Agile is not just a mindset or set of behaviours; it is a disciplined system of work rooted in engineering excellence, technical leadership, and empirical delivery. True agility requires robust engineering practices like CI/CD, automated testing, and observability, not just ceremonies or coaching. To achieve real Agile outcomes, focus on building systems that enable frequent, reliable delivery and hold both teams and leadership accountable for technical and organisational change.</description>
			</item>
			<item>
				<title>The Definition of Done is a Commitment to Quality</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/the-definition-of-done-is-a-commitment-to-quality/</link>
				<pubDate>Mon, 28 Jul 2025 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/the-definition-of-done-is-a-commitment-to-quality/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Why “Done” Only Counts When It’s Live: Moving Beyond Fake Finishes to Real Value in Software Delivery</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/why-done-only-counts-when-it-s-live-moving-beyond-fake-finishes-to-real-value-in-software-delivery/</link>
				<pubDate>Wed, 07 May 2025 11:46:58 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/why-done-only-counts-when-it-s-live-moving-beyond-fake-finishes-to-real-value-in-software-delivery/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Release planning and predictable delivery</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/release-planning-and-predictable-delivery/</link>
				<pubDate>Tue, 24 Nov 2020 13:00:01 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/release-planning-and-predictable-delivery/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Stop Paying the Hidden Costs of Weak Delivery: Why a Strong Definition of Done Transforms Your Team’s Results</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/stop-paying-the-hidden-costs-of-weak-delivery-why-a-strong-definition-of-done-transforms-your-team-s-results/</link>
				<pubDate>Wed, 21 May 2025 06:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/stop-paying-the-hidden-costs-of-weak-delivery-why-a-strong-definition-of-done-transforms-your-team-s-results/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Definition of Done - Objective vs Subjective</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/definition-of-done-objective-vs-subjective/</link>
				<pubDate>Fri, 03 Jan 2025 00:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/definition-of-done-objective-vs-subjective/</guid>
				<description>The Definition of Done (DoD) in Scrum is an objective, measurable checklist that sets the minimum quality standard for every product increment, distinct from the more subjective Product and Sprint Goals. Teams should ensure their DoD is clear, comprehensive, regularly reviewed, and as automated as possible, avoiding subjective approval steps. Development managers should treat the DoD as a non-negotiable baseline for quality, not a ceiling, and keep it updated to reflect evolving standards and business needs.</description>
			</item>
			<item>
				<title>Delivery is the only Measure of Progress in Scrum</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/delivery-is-the-only-measure-of-progress-in-scrum/</link>
				<pubDate>Mon, 03 Feb 2025 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/delivery-is-the-only-measure-of-progress-in-scrum/</guid>
				<description>Progress in Scrum should be measured by delivering working software to real users, not just completing internal work. Teams must deliver increments to production every Sprint, gather user feedback quickly, and adapt based on that feedback. To stay competitive, make delivery the default by automating releases, breaking down silos, and ensuring value reaches users every iteration.</description>
			</item>
			<item>
				<title>The Power of Technical Excellence in Agile Development</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/the-power-of-technical-excellence-in-agile-development/</link>
				<pubDate>Thu, 27 Jun 2024 06:45:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/the-power-of-technical-excellence-in-agile-development/</guid>
				<description>Technical excellence is essential for delivering a usable, high-quality product at the end of every iteration, which reduces risk and enables faster, more valuable feature delivery. The Azure DevOps team at Microsoft dramatically increased their output by focusing on paying down technical debt and establishing a strong Definition of Done. Development managers should prioritize technical excellence, avoid sacrificing quality for speed, and ensure their teams have a clear Definition of Done to maximize value and stay competitive.</description>
			</item>
			<item>
				<title>Why Your Definition of “Done” Is Holding Back Quality, Agility, and Trust, And How to Raise the Bar</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/why-your-definition-of-done-is-holding-back-quality-agility-and-trust-and-how-to-raise-the-bar/</link>
				<pubDate>Wed, 09 Jul 2025 06:45:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/why-your-definition-of-done-is-holding-back-quality-agility-and-trust-and-how-to-raise-the-bar/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Building a culture of Quality</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/building-a-culture-of-quality/</link>
				<pubDate>Fri, 22 Nov 2024 07:00:08 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/building-a-culture-of-quality/</guid>
				<description>A culture of quality cannot be built by one person; it requires everyone in the organization to demonstrate and model technical excellence and leadership. Focusing only on revenue, as seen in Boeing&amp;rsquo;s decline, undermines quality and can lead to dangerous outcomes, while a strong culture of quality leads to better, safer products. Development managers should prioritize building and reinforcing engineering excellence and technical leadership across teams, using frameworks and tools as enablers rather than solutions.</description>
			</item>
			<item>
				<title>A better way than staggered iterations for delivery</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/a-better-way-than-staggered-iterations-for-delivery/</link>
				<pubDate>Thu, 10 Dec 2020 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/a-better-way-than-staggered-iterations-for-delivery/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Without Delivery, There Is No Value</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/without-delivery-there-is-no-value/</link>
				<pubDate>Mon, 10 Feb 2025 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/without-delivery-there-is-no-value/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Transforming Agility: How Azure DevOps Went from Two-Year Releases to 880,000 Deployments</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/transforming-agility-how-azure-devops-went-from-two-year-releases-to-880-000-deployments/</link>
				<pubDate>Thu, 06 Feb 2025 10:20:34 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/transforming-agility-how-azure-devops-went-from-two-year-releases-to-880-000-deployments/</guid>
				<description>Azure DevOps transformed from two-year release cycles to 880,000 deployments per year by adopting continuous delivery, shortening feedback loops, and using real-time data to guide decisions. This shift enabled rapid response to customer needs and market changes, helping them stay ahead of competitors. Development managers should focus on frequent, small releases and data-driven improvements to maximise value and agility.</description>
			</item>
			<item>
				<title>The Hidden Costs of Poor Quality Code, and How to Turn It Into a Superpower</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/the-hidden-costs-of-poor-quality-code-and-how-to-turn-it-into-a-superpower/</link>
				<pubDate>Tue, 19 Nov 2024 09:58:28 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/the-hidden-costs-of-poor-quality-code-and-how-to-turn-it-into-a-superpower/</guid>
				<description>Poor-quality code leads to escalating costs, lost productivity, and damage to team morale and brand reputation, while also causing missed opportunities for innovation. Simplifying branching, limiting supported versions, and investing in engineering excellence and security can dramatically boost productivity and customer satisfaction. Development managers should prioritize code quality improvements now to unlock greater efficiency and long-term organizational success.</description>
			</item>
			<item>
				<title>Professional Scrum teams build software that works</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/professional-scrum-teams-build-software-that-works/</link>
				<pubDate>Thu, 03 Dec 2020 00:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/professional-scrum-teams-build-software-that-works/</guid>
				<description>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&amp;rsquo;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.</description>
			</item>
			<item>
				<title>Can the Definition of Done change per Sprint?</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/can-the-definition-of-done-change-per-sprint/</link>
				<pubDate>Mon, 14 Oct 2019 13:55:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/can-the-definition-of-done-change-per-sprint/</guid>
				<description>The Definition of Done can be improved each Sprint to raise quality but should never be changed to lower standards or to vary by backlog item, as this undermines transparency and product value. Consistency in the Definition of Done ensures everyone understands what a usable increment means and supports reliable delivery. Development managers should encourage teams to strengthen the Definition of Done over time, aiming for a shippable product each Sprint.</description>
			</item>
			<item>
				<title>NKD Agility: Your partner in developing engineering excellence</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/nkd-agility-your-partner-in-developing-engineering-excellence/</link>
				<pubDate>Sat, 23 Nov 2024 07:00:12 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/nkd-agility-your-partner-in-developing-engineering-excellence/</guid>
				<description>NKD Agility helps organizations build engineering excellence and technical leadership by shifting key practices like testing, security, and architecture closer to development teams and actively addressing technical debt. This approach reduces the high costs of poor-quality products and supports a culture of quality and value creation. Development managers looking to improve software quality and team capability can partner with NKD Agility for modern engineering practices and support.</description>
			</item>
			<item>
				<title>Avoid the pick-n-mix branching anti-pattern</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/avoid-the-pick-n-mix-branching-anti-pattern/</link>
				<pubDate>Mon, 14 Jul 2014 15:35:35 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/avoid-the-pick-n-mix-branching-anti-pattern/</guid>
				<description>Explains the risks of the pick-n-mix branching anti-pattern in source control, its impact on code quality, and recommends feature branching and toggles for stability.</description>
			</item>
			<item>
				<title>Maximising Deployment Frequency: The Key to Faster Time to Market and Business Success</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/maximising-deployment-frequency-the-key-to-faster-time-to-market-and-business-success/</link>
				<pubDate>Wed, 22 Jan 2025 14:16:54 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/maximising-deployment-frequency-the-key-to-faster-time-to-market-and-business-success/</guid>
				<description>Increasing deployment frequency is key to reducing time to market and driving business success, but it only adds value if deployments reach production and enable fast learning from real user feedback. Focus on stable environments, end-to-end pipeline analysis, and shortening the time to learn so you can iterate quickly and align with business needs. Prioritise building trust with stakeholders, collecting actionable data, and enabling continuous delivery to respond rapidly to opportunities and deliver the right features at the right time.</description>
			</item>
			<item>
				<title>The Scrum Master is accountable for Delivery</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/the-scrum-master-is-accountable-for-delivery/</link>
				<pubDate>Thu, 30 Jan 2025 00:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/the-scrum-master-is-accountable-for-delivery/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Transform Your Scrum Team in 90 Days: Strategies for Continuous Delivery and Empowerment</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/transform-your-scrum-team-in-90-days-strategies-for-continuous-delivery-and-empowerment/</link>
				<pubDate>Tue, 27 Jun 2023 07:00:06 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/transform-your-scrum-team-in-90-days-strategies-for-continuous-delivery-and-empowerment/</guid>
				<description>In the first 90 days, a Scrum team can move from limited delivery to continuous delivery by focusing on frequent releases, clarifying business value, integrating user feedback, and empowering team members to take ownership. Success depends on organisational support and team readiness. Managers should prioritise building a delivery culture and enabling the team to sustain progress independently.</description>
			</item>
			<item>
				<title>I do continuous deliver, why should I Sprint?</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/i-do-continuous-deliver-why-should-i-sprint/</link>
				<pubDate>Mon, 13 Jul 2020 18:42:03 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/i-do-continuous-deliver-why-should-i-sprint/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>The Sprint is a container for Planning and not necessarily for Delivery</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/the-sprint-is-a-container-for-planning-and-not-necessarily-for-delivery/</link>
				<pubDate>Tue, 29 Nov 2011 04:36:22 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/the-sprint-is-a-container-for-planning-and-not-necessarily-for-delivery/</guid>
				<description>Explains how Scrum Sprints are primarily for planning, not fixed delivery, and discusses aligning delivery schedules, continuous deployment, and improving software quality.</description>
			</item>
			<item>
				<title>Shifting Left. Quality from the Start</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/shifting-left-quality-from-the-start/</link>
				<pubDate>Wed, 20 Nov 2024 07:00:26 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/shifting-left-quality-from-the-start/</guid>
				<description>Automating code reviews and quality checks as early as possible in the development process reduces defects and speeds up delivery by minimizing manual bottlenecks. Manual code reviews should be a safety net, not the primary method for ensuring quality, and no code should reach the main branch without passing automated checks. Development managers should invest in robust automation for code validation to improve quality and accelerate value delivery.</description>
			</item>
			<item>
				<title>Technical Debt Management for Long-Term Quality</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/technical-debt-management-for-long-term-quality/</link>
				<pubDate>Thu, 21 Nov 2024 07:00:11 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/technical-debt-management-for-long-term-quality/</guid>
				<description>Technical debt results from choosing quick fixes over long-term solutions and can be both intentional and unintentional, eventually limiting your team&amp;rsquo;s ability to deliver value. The Azure DevOps team dramatically increased their feature delivery by prioritizing and paying down technical debt, showing that addressing it leads to faster delivery and higher product quality. Development managers should actively identify and pay back technical debt to maximize long-term productivity and value.</description>
			</item>
			<item>
				<title>Bridging the Gap: Understanding the True Meaning of &#34;Done&#34; in Agile Teams</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/bridging-the-gap-understanding-the-true-meaning-of-done-in-agile-teams/</link>
				<pubDate>Thu, 07 Dec 2023 11:00:05 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/bridging-the-gap-understanding-the-true-meaning-of-done-in-agile-teams/</guid>
				<description>Many Agile teams misunderstand what &amp;ldquo;done&amp;rdquo; really means, leading to gaps in quality and unmet expectations. Clearly defining &amp;ldquo;done&amp;rdquo; with input from both leadership and the team ensures consistent quality, reduces rework, and builds trust with stakeholders. Development managers should regularly review and refine their team&amp;rsquo;s definition of done to align with evolving business needs and maintain high standards.</description>
			</item>
			<item>
				<title>I’ll never understand teams that manage bugs instead of fixing them</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/i-ll-never-understand-teams-that-manage-bugs-instead-of-fixing-them/</link>
				<pubDate>Thu, 01 May 2025 15:30:38 +0100</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/i-ll-never-understand-teams-that-manage-bugs-instead-of-fixing-them/</guid>
				<description>Teams should focus on fixing bugs as soon as they are found instead of managing or prioritising them in backlogs or meetings. Delaying bug fixes leads to bigger problems and undermines the goal of delivering working software. Development managers should ensure their teams address defects promptly rather than letting them accumulate.</description>
			</item>
			<item>
				<title>Rethinking Continuous Delivery: Why Best Practices Don&#39;t Exist in Complex Environments</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/rethinking-continuous-delivery-why-best-practices-don&#39;t-exist-in-complex-environments/</link>
				<pubDate>Thu, 23 Jan 2025 06:30:03 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/rethinking-continuous-delivery-why-best-practices-don&#39;t-exist-in-complex-environments/</guid>
				<description>There are no universal best practices for continuous delivery in complex environments; instead, teams should adopt flexible, situation-specific approaches. Key strategies include audience-based delivery for rapid feedback, testing in production to validate real-world performance, and a commitment to quickly finding and fixing issues. Development managers should focus on continuous improvement and adaptability rather than rigid processes.</description>
			</item>
			<item>
				<title>Special Sprints: Agile Banditry or Risk Management?</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/special-sprints-agile-banditry-or-risk-management/</link>
				<pubDate>Thu, 04 Jan 2024 11:09:15 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/special-sprints-agile-banditry-or-risk-management/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Ditching the Myth of Special Sprints: Embrace True Agile Practices for Usable Products</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/ditching-the-myth-of-special-sprints-embrace-true-agile-practices-for-usable-products/</link>
				<pubDate>Thu, 04 Jan 2024 12:14:45 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/ditching-the-myth-of-special-sprints-embrace-true-agile-practices-for-usable-products/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Is Your Project Ecosystem Truly Agile?</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/is-your-project-ecosystem-truly-agile/</link>
				<pubDate>Wed, 31 Jul 2024 06:45:01 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/is-your-project-ecosystem-truly-agile/</guid>
				<description>Having Agile development teams is not enough if your deployment processes remain slow and bureaucratic, as this creates delays, reduces value, and frustrates teams. Automating deployment and testing, implementing CI/CD pipelines, and shortening feedback loops are essential to achieving true end-to-end agility and maximizing stakeholder value. Review your current processes for bottlenecks, start automating where possible, and involve stakeholders early and often to ensure your entire project ecosystem is genuinely Agile.</description>
			</item>
			<item>
				<title>Unlocking Code Quality: The Transformative Power of Frequent Deployments</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/unlocking-code-quality-the-transformative-power-of-frequent-deployments/</link>
				<pubDate>Mon, 13 Jan 2025 06:45:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/unlocking-code-quality-the-transformative-power-of-frequent-deployments/</guid>
				<description>Frequent deployments lead to higher code quality, faster feedback, and better alignment with user needs, while infrequent deployments cause larger, riskier changes and more technical debt. Breaking work into smaller pieces and deploying regularly encourages maintainable code and enables quick pivots based on real user data. Development managers should focus on reducing batch sizes, increasing deployment frequency, and investing in observability to improve both product quality and team performance.</description>
			</item>
			<item>
				<title>Getting started with a Definition of Done (DoD)</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/getting-started-with-a-definition-of-done-dod/</link>
				<pubDate>Mon, 14 Dec 2020 13:03:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/getting-started-with-a-definition-of-done-dod/</guid>
				<description>A clear Definition of Done (DoD) is essential for ensuring software quality and predictable delivery, as it sets shared criteria for what &amp;ldquo;done&amp;rdquo; 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.</description>
			</item>
			<item>
				<title>Metrics that matter with evidence-based management</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/metrics-that-matter-with-evidence-based-management/</link>
				<pubDate>Tue, 25 Feb 2014 13:29:14 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/metrics-that-matter-with-evidence-based-management/</guid>
				<description>Explains how evidence-based management uses reliable metrics and KPIs at team and organisational levels to drive better decisions, value delivery, and process improvement.</description>
			</item>
			<item>
				<title>Building a release pipeline with Release Management with Visual Studio 2013</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/building-a-release-pipeline-with-release-management-with-visual-studio-2013/</link>
				<pubDate>Tue, 18 Feb 2014 16:30:59 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/building-a-release-pipeline-with-release-management-with-visual-studio-2013/</guid>
				<description>Explains how to set up a scalable release pipeline using Release Management in Visual Studio 2013, covering continuous release, feedback environments, and DevOps practices.</description>
			</item>
			<item>
				<title>Quality enablement to achieve predictable delivery</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/quality-enablement-to-achieve-predictable-delivery/</link>
				<pubDate>Wed, 24 Jul 2013 09:46:22 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/quality-enablement-to-achieve-predictable-delivery/</guid>
				<description>Explains how defining quality standards, acceptance criteria, and automation in software delivery leads to predictable outcomes, fewer bugs, and improved team performance.</description>
			</item>
			<item>
				<title>Storms of Neglect The Perils of Not Delivering Usable Products in Agile Iterations</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/storms-of-neglect-the-perils-of-not-delivering-usable-products-in-agile-iterations/</link>
				<pubDate>Thu, 27 Jul 2023 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/storms-of-neglect-the-perils-of-not-delivering-usable-products-in-agile-iterations/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Unlocking Success: How Small Experiments Transformed Feature Delivery from 25 to 150 in Software Development</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/unlocking-success-how-small-experiments-transformed-feature-delivery-from-25-to-150-in-software-development/</link>
				<pubDate>Wed, 20 Nov 2024 08:02:36 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/unlocking-success-how-small-experiments-transformed-feature-delivery-from-25-to-150-in-software-development/</guid>
				<description>A team increased their annual feature delivery from 25 to 150 by breaking down work into smaller experiments, enabling faster feedback, reduced risk, and continuous learning without increasing headcount. This approach allowed them to quickly identify and focus on features that mattered most to customers, leading to better products. Development managers should consider adopting small, frequent experiments to drive both speed and quality in feature delivery.</description>
			</item>
			<item>
				<title>Release Management with Team Foundation Server 2012</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/release-management-with-team-foundation-server-2012/</link>
				<pubDate>Wed, 24 Apr 2013 17:38:24 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/release-management-with-team-foundation-server-2012/</guid>
				<description>Explains how to automate and streamline software release management using Team Foundation Server 2012, Lab Management, and Octopus, focusing on build, deployment, and quality.</description>
			</item>
			<item>
				<title>Professional Scrum Developer (.NET) Training in London</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/professional-scrum-developer-net-training-in-london/</link>
				<pubDate>Fri, 18 Jun 2010 15:53:27 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/professional-scrum-developer-net-training-in-london/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Unlocking Agile Success: How Empirical Models Transform Project Outcomes</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/unlocking-agile-success-how-empirical-models-transform-project-outcomes/</link>
				<pubDate>Wed, 12 Oct 2022 17:08:59 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/unlocking-agile-success-how-empirical-models-transform-project-outcomes/</guid>
				<description>Agile methods significantly increase project success rates, especially for larger teams, by maintaining ongoing visibility, enabling flexibility, reducing operational risk, and delivering value incrementally. Unlike traditional models, Agile allows for regular feedback and adaptation, which keeps projects aligned with customer needs and reduces wasted effort. Development managers should consider adopting empirical Agile practices to improve outcomes and stakeholder satisfaction.</description>
			</item>
			<item>
				<title>Unlocking the True Power of Continuous Delivery: How Automation Transforms Software Development</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/unlocking-the-true-power-of-continuous-delivery-how-automation-transforms-software-development/</link>
				<pubDate>Fri, 06 Dec 2024 06:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/unlocking-the-true-power-of-continuous-delivery-how-automation-transforms-software-development/</guid>
				<description>The main benefit of continuous delivery is the automation it brings, which increases consistency, reliability, and risk mitigation in software deployments. Real-world examples like Azure DevOps and Windows teams show that automation shortens feedback loops, reduces errors, and enables faster, higher-quality releases without increasing team size. Development managers should focus on embedding automation throughout their delivery process to protect the business and empower teams to deliver better software more efficiently.</description>
			</item>
			<item>
				<title>Detecting Agile BS: Lessons from the US Department of Defense</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/detecting-agile-bs-lessons-from-the-us-department-of-defense/</link>
				<pubDate>Fri, 28 Jun 2024 06:45:01 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/detecting-agile-bs-lessons-from-the-us-department-of-defense/</guid>
				<description>Many organizations claim to be Agile but often fall short of true Agile practices, as highlighted by the US Department of Defense&amp;rsquo;s &amp;ldquo;Detecting Agile BS&amp;rdquo; guide. The guide recommends six key questions to assess real Agile maturity, focusing on frequent delivery to users, regular production releases, adapting to feedback, clear product vision, team empowerment, and a culture of continuous improvement. Development managers should honestly assess their teams against these criteria, start small with improvements, and foster a culture of feedback and learning to achieve genuine Agile transformation.</description>
			</item>
			<item>
				<title>How Usable Working Products Are Your Ultimate Weapon Against Risks</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/how-usable-working-products-are-your-ultimate-weapon-against-risks/</link>
				<pubDate>Thu, 20 Jul 2023 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/how-usable-working-products-are-your-ultimate-weapon-against-risks/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>The fallacy of the rejected backlog item</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/the-fallacy-of-the-rejected-backlog-item/</link>
				<pubDate>Mon, 13 Jul 2020 08:55:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/the-fallacy-of-the-rejected-backlog-item/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Continuous value delivery with modern business applications</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/continuous-value-delivery-with-modern-business-applications/</link>
				<pubDate>Tue, 27 Nov 2012 23:00:35 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/continuous-value-delivery-with-modern-business-applications/</guid>
				<description>Explains how modern business applications use continuous delivery to release new features frequently, reduce risk, and improve customer satisfaction through rapid updates.</description>
			</item>
			<item>
				<title>The Importance of Delivering Working Software Every Iteration</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/the-importance-of-delivering-working-software-every-iteration/</link>
				<pubDate>Wed, 26 Jun 2024 06:45:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/the-importance-of-delivering-working-software-every-iteration/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>You are doing it wrong if you are not using test first</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/you-are-doing-it-wrong-if-you-are-not-using-test-first/</link>
				<pubDate>Mon, 07 Dec 2020 12:00:58 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/you-are-doing-it-wrong-if-you-are-not-using-test-first/</guid>
				<description>Using test-first approaches like Test Driven Development helps teams deliver software that meets customer needs, reduces maintenance costs, and prevents bugs from reaching production. Writing tests before coding ensures validation at every step, shortens feedback loops, and makes it easier and cheaper to fix issues early. To improve quality and enable confident continuous delivery, development managers should encourage their teams to adopt test-first practices.</description>
			</item>
			<item>
				<title>Agile without a usable working product is just expensive theatre</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/agile-without-a-usable-working-product-is-just-expensive-theatre/</link>
				<pubDate>Sun, 20 Apr 2025 15:30:27 +0100</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/agile-without-a-usable-working-product-is-just-expensive-theatre/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Testing in the modern application lifecycle</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/testing-in-the-modern-application-lifecycle/</link>
				<pubDate>Tue, 25 Sep 2012 02:00:46 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/testing-in-the-modern-application-lifecycle/</guid>
				<description>Explores challenges and solutions for manual testing in agile software development, focusing on tracking, automation, actionable bugs, and integrated test management tools.</description>
			</item>
			<item>
				<title>Unlocking Continuous Delivery: How Feature Flags Transform Software Development</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/unlocking-continuous-delivery-how-feature-flags-transform-software-development/</link>
				<pubDate>Thu, 16 Jan 2025 06:45:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/unlocking-continuous-delivery-how-feature-flags-transform-software-development/</guid>
				<description>Feature flags enable teams to release new features incrementally, gather user feedback early, and quickly respond to issues, supporting safer and more frequent deployments. Real-world examples like Azure DevOps show that this approach allows for controlled rollouts, continuous monitoring, and ongoing improvements based on user input. Development managers should consider adopting feature flags to improve delivery speed, reduce risk, and ensure features better meet user needs.</description>
			</item>
			<item>
				<title>Sprint Review Recipe</title>
				<link>https://engineering-leadership.hinshelwood.com/recipes/sprint-review-recipe/</link>
				<pubDate>Tue, 17 Sep 2024 00:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/recipes/sprint-review-recipe/</guid>
				<description>Step-by-step guide for running a Sprint Review, including presenting the increment, gathering feedback, updating the backlog, forecasting, and addressing stakeholder questions.</description>
			</item>
			<item>
				<title>Risk Mitigation: Agile Usable Products vs Documentation in Traditional Project Management</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/risk-mitigation-agile-usable-products-vs-documentation-in-traditional-project-management/</link>
				<pubDate>Thu, 13 Jul 2023 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/risk-mitigation-agile-usable-products-vs-documentation-in-traditional-project-management/</guid>
				<description>Delivering working software in small increments helps teams identify and address risks early, adapt to changes quickly, and get real feedback from users, while relying mainly on documentation can slow response to shifting needs. Documentation is still important, but focusing on usable products provides more value in fast-changing environments. Development managers should prioritize building and validating working software while maintaining just enough documentation to support adaptation and clarity.</description>
			</item>
			<item>
				<title>DOD has made it illegal to do waterfall</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/dod-has-made-it-illegal-to-do-waterfall/</link>
				<pubDate>Tue, 01 May 2018 01:02:03 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/dod-has-made-it-illegal-to-do-waterfall/</guid>
				<description>The US Department of Defense has updated its procurement rules to require agile, iterative development instead of traditional waterfall methods, following high-profile failures like the FBI’s Sentinel project. Agile approaches have proven to deliver higher success rates, lower costs, and reduced risk, and these changes are now influencing government and vendor practices across the US and UK. Development managers working with government clients should adopt agile methods to align with new regulations and improve project outcomes.</description>
			</item>
			<item>
				<title>Create a Release Management pipeline for Professional Developers</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/create-a-release-management-pipeline-for-professional-developers/</link>
				<pubDate>Thu, 04 Dec 2014 12:15:56 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/create-a-release-management-pipeline-for-professional-developers/</guid>
				<description>This guide walks through setting up an automated release management pipeline using TFS/VSO and Azure, showing how to build, deploy, and parameterize a legacy web app across multiple feedback environments. Key takeaways include the importance of automating builds and releases, using environment-specific parameters, and streamlining approvals for smoother deployments. Development managers should consider investing time upfront to automate and parameterize their pipelines, as this reduces manual errors and accelerates feedback cycles.</description>
			</item>
			<item>
				<title>Are Your Teams Empowered to Change Requirements Based on User Feedback? If Not, You’re Probably Not Very Agile</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/are-your-teams-empowered-to-change-requirements-based-on-user-feedback-if-not-you-re-probably-not-very-agile/</link>
				<pubDate>Wed, 17 Jul 2024 06:45:01 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/are-your-teams-empowered-to-change-requirements-based-on-user-feedback-if-not-you-re-probably-not-very-agile/</guid>
				<description>Empowering teams to update or delete requirements based on user feedback is essential for true agility and delivering maximum value. Regularly engaging with the product team, keeping the backlog dynamic, and being willing to pivot or remove features ensures your product stays relevant and user-focused. Review your processes to make sure your teams have the authority and support to make these changes.</description>
			</item>
			<item>
				<title>Scrum Myth Debunked: Unfinished Work is Allowed in Scrum</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/scrum-myth-debunked-unfinished-work-is-allowed-in-scrum/</link>
				<pubDate>Sat, 24 May 2025 15:30:17 +0100</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/scrum-myth-debunked-unfinished-work-is-allowed-in-scrum/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>There is no place like production</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/there-is-no-place-like-production/</link>
				<pubDate>Mon, 28 Dec 2020 14:12:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/there-is-no-place-like-production/</guid>
				<description>To deliver real value and reduce risk, teams must release features to production quickly so real users can provide feedback, since assumptions and testing environments cannot replace actual usage. Key measures like customer satisfaction, product usage, and employee satisfaction help validate value, and releasing early also offers financial benefits through capital expenditure write-downs. Prioritize getting small increments into production to maximize learning, value, and organizational savings.</description>
			</item>
			<item>
				<title>Nexus Guide</title>
				<link>https://engineering-leadership.hinshelwood.com/guides/nexus-guide/</link>
				<pubDate>Tue, 17 Sep 2024 00:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/guides/nexus-guide/</guid>
				<description>Explains the Nexus framework for scaling Scrum with multiple teams, detailing roles, events, and artefacts to coordinate product delivery and manage cross-team dependencies.</description>
			</item>
			<item>
				<title>How Do You Know How Long It Takes to Deliver Value?</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/how-do-you-know-how-long-it-takes-to-deliver-value/</link>
				<pubDate>Fri, 26 Jan 2024 11:00:51 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/how-do-you-know-how-long-it-takes-to-deliver-value/</guid>
				<description>Measuring and improving Time to Market is essential for delivering value quickly and staying competitive. Key metrics like lead time, cycle time, time to pivot, time to learn, and time to fix help teams identify bottlenecks and make better decisions. Focus on streamlining processes, automating tasks, gathering fast feedback, and building cross-functional teams to reduce delivery times and ensure you are delivering what customers need most.</description>
			</item>
			<item>
				<title>Turning User Feedback into Actionable Work: A Guide to Maximizing Product Value</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/turning-user-feedback-into-actionable-work-a-guide-to-maximizing-product-value/</link>
				<pubDate>Wed, 10 Jul 2024 06:45:01 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/turning-user-feedback-into-actionable-work-a-guide-to-maximizing-product-value/</guid>
				<description>Turning user feedback into actionable work quickly is essential for delivering real product value and staying truly agile. Teams that engage users regularly, prioritize feedback effectively, and integrate it into each Sprint see higher satisfaction and better business results. Review feedback weekly, involve stakeholders, and empower your team to act fast so your product evolves in line with user needs.</description>
			</item>
			<item>
				<title>Manifesto for Agile Software Development</title>
				<link>https://engineering-leadership.hinshelwood.com/guides/manifesto-for-agile-software-development/</link>
				<pubDate>Tue, 17 Sep 2024 00:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/guides/manifesto-for-agile-software-development/</guid>
				<description>Outlines core Agile values and principles for software development, emphasising collaboration, adaptability, working software, customer focus, and continuous improvement.</description>
			</item>
			<item>
				<title>Transforming Scope Creep into Success: Embrace Agility and Deliver Value in a Changing Market</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/transforming-scope-creep-into-success-embrace-agility-and-deliver-value-in-a-changing-market/</link>
				<pubDate>Wed, 04 Dec 2024 06:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/transforming-scope-creep-into-success-embrace-agility-and-deliver-value-in-a-changing-market/</guid>
				<description>Scope creep is often a sign that traditional fixed-scope approaches are failing in today’s fast-changing market. Focusing on delivering customer value, embracing flexible planning, and actively seeking feedback helps teams adapt and succeed. Development managers should shift from rigid scope management to Agile practices that prioritize value and responsiveness to change.</description>
			</item>
			<item>
				<title>Scrum is built on empiricism, transparency, inspection, and adaptation</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/scrum-is-built-on-empiricism-transparency-inspection-and-adaptation/</link>
				<pubDate>Mon, 24 Feb 2025 16:30:29 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/scrum-is-built-on-empiricism-transparency-inspection-and-adaptation/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Quality enablement with Visual Studio 2012</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/quality-enablement-with-visual-studio-2012/</link>
				<pubDate>Wed, 15 May 2013 03:13:20 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/quality-enablement-with-visual-studio-2012/</guid>
				<description>Explores how Visual Studio 2012 supports continuous quality enablement, automated testing, and rapid delivery in modern software development for higher user satisfaction.</description>
			</item>
			<item>
				<title>Naked ALM: starting with why and getting naked</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/naked-alm-starting-with-why-and-getting-naked/</link>
				<pubDate>Thu, 02 May 2013 03:06:42 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/naked-alm-starting-with-why-and-getting-naked/</guid>
				<description>Explores the importance of understanding purpose in Application Lifecycle Management, focusing on transparency, customer value, and continuous improvement in software delivery.</description>
			</item>
			<item>
				<title>My first Scrum team in the wild</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/my-first-scrum-team-in-the-wild/</link>
				<pubDate>Sun, 03 Apr 2011 21:44:22 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/my-first-scrum-team-in-the-wild/</guid>
				<description>A real-world account of guiding a new Scrum team through their first sprint, covering estimation, story points, sprint planning, and handling unfinished work.</description>
			</item>
			<item>
				<title>The Evolution of Product Management in the Agile Era</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/the-evolution-of-product-management-in-the-agile-era/</link>
				<pubDate>Thu, 18 Jul 2024 06:45:01 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/the-evolution-of-product-management-in-the-agile-era/</guid>
				<description>Agile product management replaces long release cycles with short, frequent delivery, enabling faster feedback, reduced risk, and more responsive adaptation to customer needs. Building quality in from the start and using practices like continuous integration and a clear definition of done minimizes defects and waste. Development managers should focus on shorter cycles, continuous feedback, and embedding quality throughout the process to stay competitive and maximize business value.</description>
			</item>
			<item>
				<title>Automated Testing in a modern application lifecycle</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/automated-testing-in-a-modern-application-lifecycle/</link>
				<pubDate>Tue, 25 Sep 2012 04:33:30 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/automated-testing-in-a-modern-application-lifecycle/</guid>
				<description>Explains the role of automated testing in modern software development, covering types, integration, benefits, challenges, and tools for maintaining code quality.</description>
			</item>
			<item>
				<title>The Definition of Done: Ensuring Quality without Compromising Value</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/the-definition-of-done-ensuring-quality-without-compromising-value/</link>
				<pubDate>Wed, 27 Sep 2023 09:59:46 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/the-definition-of-done-ensuring-quality-without-compromising-value/</guid>
				<description>The Definition of Done (DoD) ensures every release meets clear quality standards, while acceptance criteria define specific content requirements. Mixing acceptance criteria into the DoD can undermine transparency and adaptability, but consistently required quality measures should be added to the DoD itself. Review your acceptance criteria regularly and only update the DoD if it preserves both clarity and flexibility in your team&amp;rsquo;s delivery.</description>
			</item>
			<item>
				<title>Maximise Your Scrum Process: Leveraging Azure DevOps for Agile Success</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/maximise-your-scrum-process-leveraging-azure-devops-for-agile-success/</link>
				<pubDate>Wed, 03 Apr 2024 17:21:43 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/maximise-your-scrum-process-leveraging-azure-devops-for-agile-success/</guid>
				<description>Azure DevOps can be customised to effectively support Scrum by focusing on simple, value-driven backlogs and adapting processes like area and iteration paths to fit your team&amp;rsquo;s structure and workflow. Metrics and common agile tools are optional, so tailor your setup to your team&amp;rsquo;s needs rather than following defaults. Use Azure DevOps features like tagging, board views, and backlog management to streamline refinement, planning, and execution, and regularly review and improve your processes for better results.</description>
			</item>
			<item>
				<title>Why should I use Visual Studio ALM</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/why-should-i-use-visual-studio-alm/</link>
				<pubDate>Wed, 07 Jan 2015 15:39:20 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/why-should-i-use-visual-studio-alm/</guid>
				<description>Visual Studio ALM offers a comprehensive set of features beyond just source control and build, covering requirements, project, change, quality, feedback, defect, release, and analytics management in one integrated platform. Replacing it with tools like Git and Jenkins means losing most of this functionality and facing significant integration and maintenance challenges. Development managers should carefully assess what capabilities they need and consider the long-term effort required to replicate Visual Studio ALM’s end-to-end support before switching tools.</description>
			</item>
			<item>
				<title>How to Set and Achieve Effective Sprint Goals</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/how-to-set-and-achieve-effective-sprint-goals/</link>
				<pubDate>Fri, 29 Sep 2023 12:12:59 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/how-to-set-and-achieve-effective-sprint-goals/</guid>
				<description>Sprint Goals are essential for guiding teams toward delivering real value each Sprint, acting as a clear commitment that balances detail and big-picture alignment. Effective Sprint Goals are collaboratively crafted, reviewed by stakeholders, and should be specific, measurable, and relevant to the product vision. Development managers should ensure their teams focus on creating meaningful Sprint Goals that drive value and accountability, using frameworks like SMART or OKR as needed.</description>
			</item>
			<item>
				<title>Why &#39;Definition of Done&#39; is Crucial for Success in Scrum</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/why-&#39;definition-of-done&#39;-is-crucial-for-success-in-scrum/</link>
				<pubDate>Tue, 14 Nov 2023 07:00:30 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/why-&#39;definition-of-done&#39;-is-crucial-for-success-in-scrum/</guid>
				<description>The Definition of Done sets clear quality standards for all work, ensuring every deliverable meets your organization&amp;rsquo;s expectations regardless of the specific feature or project. It aligns teams, reduces defects, and protects your brand by making sure nothing is released before it is truly ready. Regularly review and adapt your Definition of Done with your team to maintain high quality and customer satisfaction.</description>
			</item>
			<item>
				<title>Increment</title>
				<link>https://engineering-leadership.hinshelwood.com/tags/increment/</link>
				<pubDate>Mon, 05 May 2025 10:17:24 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/tags/increment/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Definition of Done</title>
				<link>https://engineering-leadership.hinshelwood.com/tags/definition-of-done/</link>
				<pubDate>Mon, 05 May 2025 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/tags/definition-of-done/</guid>
				<description>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.</description>
			</item>
			<item>
				<title>Working Software</title>
				<link>https://engineering-leadership.hinshelwood.com/tags/working-software/</link>
				<pubDate>Tue, 11 Feb 2025 10:17:24 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/tags/working-software/</guid>
				<description>Working Software is a fundamental artifact in Agile, Scrum, and Lean frameworks, serving as the tangible output of a team&amp;rsquo;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.</description>
			</item>
	</channel>
</rss>
