<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Frequent Releases on Engineering Leadership in AI &amp; Software</title>
		<link>https://engineering-leadership.hinshelwood.com/tags/frequent-releases/</link>
		<description>Recent content in Frequent Releases 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/frequent-releases/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Velocity isn’t how many story points a team burns down</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/velocity-isn-t-how-many-story-points-a-team-burns-down/</link>
				<pubDate>Mon, 10 Mar 2025 16:30:02 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/velocity-isn-t-how-many-story-points-a-team-burns-down/</guid>
				<description>Velocity is about how quickly your team delivers value, not just story points completed. Focus on measuring time to build, self-test, deploy, and learn from user feedback, as these are actionable and within your control. Start tracking these metrics to improve your delivery speed and effectiveness.</description>
			</item>
			<item>
				<title>Stop Hiding Behind Complexity and Start Delivering Continuously</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/stop-hiding-behind-complexity-and-start-delivering-continuously/</link>
				<pubDate>Mon, 24 Feb 2025 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/stop-hiding-behind-complexity-and-start-delivering-continuously/</guid>
				<description>Complexity is not a valid reason to avoid continuous delivery; organisations like Azure DevOps and Starbucks have proven that even large, complex systems can achieve frequent, reliable releases with the right investment in automation, process improvement, and culture change. Key actions include automating everything, adopting trunk-based development, using feature flags, shifting quality left, and iterating on pain points. Development managers should focus on measuring and improving flow metrics and value delivery, prioritising organisational commitment to overcome resistance and realise the benefits of continuous delivery.</description>
			</item>
			<item>
				<title>Engineering can fix technical debt, but leadership has to invest in it</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/engineering-can-fix-technical-debt-but-leadership-has-to-invest-in-it/</link>
				<pubDate>Mon, 03 Mar 2025 16:30:35 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/engineering-can-fix-technical-debt-but-leadership-has-to-invest-in-it/</guid>
				<description>Fixing technical debt requires leadership investment, not just harder work from engineers. Success comes from funding automation, better testing, and empowering teams to address issues directly. If continuous delivery is not happening, leaders should reconsider their priorities and support the necessary improvements.</description>
			</item>
			<item>
				<title>Testing in Production Maximises Quality and Value</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/testing-in-production-maximises-quality-and-value/</link>
				<pubDate>Thu, 13 Feb 2025 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/testing-in-production-maximises-quality-and-value/</guid>
				<description>Testing in production using audience-based deployment enables faster feedback, safer incremental releases, and better alignment with real user needs compared to traditional Dev-Test-Staging pipelines. Microsoft’s shift to this model, driven by feature flags, progressive rollouts, and real-time monitoring, has improved quality and innovation while reducing risk and overhead. Development managers should consider moving away from environment-based branching and invest in automation, observability, and team upskilling to maximise value and responsiveness.</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>Stop Testing Quality In: How Shifting Left Builds Better Software, Faster</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/stop-testing-quality-in-how-shifting-left-builds-better-software-faster/</link>
				<pubDate>Mon, 18 Aug 2025 06:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/stop-testing-quality-in-how-shifting-left-builds-better-software-faster/</guid>
				<description>Relying on testers to catch issues late in the process increases costs, slows feedback, and undermines product trust; instead, quality should be built in from the start by moving tests and feedback as close to the engineer as possible. Key practices include automating builds and tests, adopting continuous integration and delivery, using test-driven development, and incrementally improving code quality. Development managers should focus on empowering engineers to own quality, relentlessly shortening feedback loops, and making incremental improvements to achieve faster, more reliable releases.</description>
			</item>
			<item>
				<title>Do More Staging Environments Really Reduce Deployment Risk</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/do-more-staging-environments-really-reduce-deployment-risk/</link>
				<pubDate>Wed, 26 Feb 2025 16:30:31 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/do-more-staging-environments-really-reduce-deployment-risk/</guid>
				<description>Adding more staging environments does not actually reduce deployment risk; it only delays issue discovery and creates a false sense of security. Real risk reduction comes from investing in automated testing, continuous integration, and quality practices built into the development process. To minimize downtime and deployment risk, focus on modern engineering practices rather than adding more pre-production gates.</description>
			</item>
			<item>
				<title>Every delay increases the risk of failure</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/every-delay-increases-the-risk-of-failure/</link>
				<pubDate>Mon, 10 Feb 2025 11:00:51 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/every-delay-increases-the-risk-of-failure/</guid>
				<description>Delaying software releases increases the risk of failure and falling behind competitors. Frequent, smaller releases lead to higher success rates and faster recovery, as shown by industry research. Focus on delivering quickly and iterating rather than waiting for a perfect release.</description>
			</item>
			<item>
				<title>Stop Promoting Branches</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/stop-promoting-branches/</link>
				<pubDate>Thu, 06 Feb 2025 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/stop-promoting-branches/</guid>
				<description>Promoting code through multiple environment branches slows delivery, increases risk, and adds unnecessary complexity. Instead, use simple branching models like GitHub Flow for continuous delivery or Release Flow if you must support multiple live versions; avoid outdated models like Git Flow and never rely on reverse integration. Focus on merging changes directly into main, use feature flags for releases, and keep branching lightweight to deliver value faster.</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>Still Deploying Manually? Why Automation Is the Bare Minimum for Modern Engineering (and Your Business Survival)</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/still-deploying-manually-why-automation-is-the-bare-minimum-for-modern-engineering-and-your-business-survival/</link>
				<pubDate>Mon, 11 Aug 2025 07:00:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/still-deploying-manually-why-automation-is-the-bare-minimum-for-modern-engineering-and-your-business-survival/</guid>
				<description>Manual deployments put your business at serious risk due to inevitable human error, as shown by real-world failures that have caused massive financial losses. Automation of builds, deployments, tests, and quality checks is now the minimum standard for professional software development, enabling faster, safer, and more reliable releases. To protect your business and deliver value consistently, eliminate manual steps and automate every part of your delivery pipeline as soon as possible.</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>Why Organisations Believe Their Software Is Too Complex for CD</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/why-organisations-believe-their-software-is-too-complex-for-cd/</link>
				<pubDate>Mon, 24 Feb 2025 10:51:31 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/why-organisations-believe-their-software-is-too-complex-for-cd/</guid>
				<description>Software complexity is often used as an excuse to avoid continuous delivery, but real-world examples like Microsoft’s Azure DevOps team show that even large, complex systems can achieve frequent releases by investing in quality practices and addressing technical debt. The main barrier is not complexity but the willingness to make necessary improvements. Development managers should focus on fixing underlying issues rather than blaming complexity.</description>
			</item>
			<item>
				<title>Rethinking Dev-Test-Staging-Production Pipelines for Safety</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/rethinking-dev-test-staging-production-pipelines-for-safety/</link>
				<pubDate>Fri, 21 Feb 2025 16:30:30 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/rethinking-dev-test-staging-production-pipelines-for-safety/</guid>
				<description>Traditional Dev-Test-Staging-Production pipelines give a false sense of security because staging environments do not truly reflect production, leading to missed issues and wasted resources. Modern teams should focus on releasing to small user groups in production and using real feedback to guide rollouts. Consider shifting from heavy pre-release testing to faster, data-driven feedback in production to improve safety and efficiency.</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>Why Engineering Teams Use Staging Environments for Risk Reduction</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/why-engineering-teams-use-staging-environments-for-risk-reduction/</link>
				<pubDate>Fri, 14 Feb 2025 16:30:01 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/why-engineering-teams-use-staging-environments-for-risk-reduction/</guid>
				<description>Staging environments are intended to reduce risk but often lead to wasted time, delayed feedback, and extra costs without truly preventing failures. Modern practices like feature flags, progressive rollouts, and real-time monitoring can help teams deploy safely to production while reducing waste. Consider whether maintaining staging environments is actually benefiting your team or just adding unnecessary overhead.</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>Embrace Simplicity: How to Transform Complexity into Continuous Delivery Success</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/embrace-simplicity-how-to-transform-complexity-into-continuous-delivery-success/</link>
				<pubDate>Thu, 27 Feb 2025 07:00:10 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/embrace-simplicity-how-to-transform-complexity-into-continuous-delivery-success/</guid>
				<description>Complexity is not a valid excuse for avoiding continuous delivery; with organisational commitment and a willingness to modernise, even legacy systems can be transformed for faster, more reliable releases. Key steps include honestly assessing your product, investing in ongoing improvement, and addressing technical debt rather than ignoring warning signs. Leaders should prioritise resources and foster a culture that values continuous improvement to avoid costly failures and achieve lasting delivery success.</description>
			</item>
			<item>
				<title>let-us do the maths</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/let-us-do-the-maths/</link>
				<pubDate>Wed, 30 Apr 2025 15:30:52 +0100</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/let-us-do-the-maths/</guid>
				<description>Slow release cycles mean customer needs go unmet and competitors gain an edge. Microsoft’s shift from a two-year delivery cycle to three-week sprints allowed them to deliver features in days, improving customer satisfaction and competitiveness. Accelerate your delivery process to stay relevant and meet customer demands faster.</description>
			</item>
			<item>
				<title>There a common belief that rollback is the ultimate safety net</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/there-a-common-belief-that-rollback-is-the-ultimate-safety-net/</link>
				<pubDate>Thu, 13 Feb 2025 15:53:38 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/there-a-common-belief-that-rollback-is-the-ultimate-safety-net/</guid>
				<description>Relying on rollback as a safety net is risky, especially for stateful applications where it can cause data issues and failures. Safer approaches include progressive delivery methods like feature flags and canary releases, which help detect and limit problems early. Teams should focus on making deployments safe to fail rather than assuming rollback will fix mistakes.</description>
			</item>
			<item>
				<title>Deploying Windows OS Directly to Production: Then vs Now</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/deploying-windows-os-directly-to-production-then-vs-now/</link>
				<pubDate>Sat, 22 Feb 2025 16:30:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/deploying-windows-os-directly-to-production-then-vs-now/</guid>
				<description>Microsoft now deploys Windows updates directly to production using a gradual, ring-based rollout that starts with internal users and expands outward, guided by real-time feedback and telemetry. This approach catches issues early and enables safe, incremental releases even across complex environments. Development managers should consider adopting similar staged deployment strategies to improve release quality and responsiveness.</description>
			</item>
			<item>
				<title>Branch promotion is a relic of slow, manual software delivery</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/branch-promotion-is-a-relic-of-slow-manual-software-delivery/</link>
				<pubDate>Sat, 08 Feb 2025 16:30:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/branch-promotion-is-a-relic-of-slow-manual-software-delivery/</guid>
				<description>Branch promotion slows down delivery and adds risk, while modern teams merge changes into the main branch as soon as they are ready and use feature flags to separate deployment from release. Testing in production-like environments and instant rollbacks improve speed and safety. Focus on managing the flow of work, not branches, to streamline delivery.</description>
			</item>
			<item>
				<title>Frequent releases are not just a technical strategy</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/frequent-releases-are-not-just-a-technical-strategy/</link>
				<pubDate>Fri, 07 Feb 2025 16:30:01 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/frequent-releases-are-not-just-a-technical-strategy/</guid>
				<description>Frequent releases help teams learn from real users and avoid wasting effort on features that may not work, as shown by Microsoft’s costly Windows 8 failure. Research shows that teams releasing often recover faster and reduce costs. To reduce risk and improve outcomes, prioritize frequent releases and adapt based on user feedback.</description>
			</item>
			<item>
				<title>Too many teams overcomplicate their branching strategies</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/too-many-teams-overcomplicate-their-branching-strategies/</link>
				<pubDate>Thu, 06 Feb 2025 09:38:01 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/too-many-teams-overcomplicate-their-branching-strategies/</guid>
				<description>Many teams make branching too complex, which slows delivery and adds risk. Simple models like GitHub Flow or Release Flow help teams move faster and deliver value more consistently. Focus on minimizing branching complexity to improve speed and reliability.</description>
			</item>
			<item>
				<title>We don’t have time for automation, but manual testing slows releases and quality</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/we-don-t-have-time-for-automation-but-manual-testing-slows-releases-and-quality/</link>
				<pubDate>Mon, 07 Apr 2025 15:30:01 +0100</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/we-don-t-have-time-for-automation-but-manual-testing-slows-releases-and-quality/</guid>
				<description>Relying on manual testing slows releases, overwhelms testers, and lets bugs slip through, making it impossible to keep up with rapid changes. Automation is essential for maintaining both speed and quality in software development. Teams should prioritize moving to automated testing to avoid bottlenecks and improve release reliability.</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>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>If software is not delivered, it is not valuable</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/if-software-is-not-delivered-it-is-not-valuable/</link>
				<pubDate>Sat, 01 Mar 2025 16:30:03 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/if-software-is-not-delivered-it-is-not-valuable/</guid>
				<description>Undelivered software provides no value, and long development cycles increase risk, cost, and missed opportunities. Research shows that teams releasing software frequently are more successful and efficient. To maximize value and learning, prioritize frequent delivery to users.</description>
			</item>
			<item>
				<title>Staging Environments Do Not Prevent Production Failures</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/staging-environments-do-not-prevent-production-failures/</link>
				<pubDate>Fri, 28 Feb 2025 16:30:01 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/staging-environments-do-not-prevent-production-failures/</guid>
				<description>Staging environments do not truly prevent production failures because they cannot fully replicate real-world conditions, often giving teams a false sense of security. Leading teams now deploy changes incrementally to real users in production, using monitoring and automated safeguards to catch issues early. Consider shifting focus from pre-production testing to safer, controlled releases in production to reduce risk and respond faster to problems.</description>
			</item>
			<item>
				<title>Every unreleased feature is a cost</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/every-unreleased-feature-is-a-cost/</link>
				<pubDate>Wed, 05 Feb 2025 16:30:01 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/every-unreleased-feature-is-a-cost/</guid>
				<description>Unreleased features create hidden costs and risks, as work that is not delivered provides no real value. Evidence shows that frequent releases reduce failure rates and improve stability, while long cycles lead to more rework and missed opportunities. Focus on shipping regularly to ensure your team&amp;rsquo;s efforts translate into actual value.</description>
			</item>
			<item>
				<title>Live Site Culture &amp; Site Reliability Engineering</title>
				<link>https://engineering-leadership.hinshelwood.com/articles/live-site-culture-site-reliability-engineering/</link>
				<pubDate>Wed, 17 Jun 2020 13:23:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/articles/live-site-culture-site-reliability-engineering/</guid>
				<description>To stay competitive in a fast-changing market, teams must adopt DevOps and continuous delivery, shifting from infrequent releases to deploying updates daily. This requires faster feedback, shared responsibility for quality and operations, and new ways of working, as shown by Microsoft&amp;rsquo;s Azure DevOps team. Development managers should consider evolving their team structures and practices to support rapid, customer-focused 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>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>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>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>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>Unlocking Unrealised Value: The Key to Elevating Your Product Development Strategy</title>
				<link>https://engineering-leadership.hinshelwood.com/videos/unlocking-unrealised-value-the-key-to-elevating-your-product-development-strategy/</link>
				<pubDate>Tue, 11 Feb 2025 06:00:40 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/videos/unlocking-unrealised-value-the-key-to-elevating-your-product-development-strategy/</guid>
				<description>Unrealised value, or the features your users need but you have not built or identified yet, is often overlooked but crucial for product success. To unlock this value, focus on understanding your users, validate assumptions with small experiments before full development, and increase deployment frequency to speed up feedback and learning. Make it a priority to continuously learn from your market and adapt your product strategy to stay relevant and maximise impact.</description>
			</item>
			<item>
				<title>Git Flow should have died years ago</title>
				<link>https://engineering-leadership.hinshelwood.com/signals/git-flow-should-have-died-years-ago/</link>
				<pubDate>Sun, 09 Feb 2025 16:30:00 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/signals/git-flow-should-have-died-years-ago/</guid>
				<description>Git Flow is outdated and causes unnecessary delays and complications for modern software teams. Long-lived branches and complex merges slow down delivery and increase risk. Switch to simpler workflows like GitHub Flow or Release Flow to speed up development and focus on delivering value.</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>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>Continuous Delivery</title>
				<link>https://engineering-leadership.hinshelwood.com/tags/continuous-delivery/</link>
				<pubDate>Fri, 21 Mar 2025 13:37:32 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/tags/continuous-delivery/</guid>
				<description>Continuous Delivery is a software delivery practice that focuses on producing software in short, reliable cycles, enabling teams to release updates at any time. Originating from the need for more efficient and responsive software development processes, it involves delivering small, incremental improvements directly to users from the initial stages of development. This approach, as defined by Jez Humble, emphasises the ability to safely and quickly implement changes, such as new features, configuration adjustments, and bug fixes, into production. The importance of Continuous Delivery lies in its capacity to facilitate rapid validation of assumptions and collection of user feedback, which are crucial for refining products and achieving valuable outcomes. By automating essential processes like testing, integration, and deployment, Continuous Delivery not only mitigates the risk of errors but also enhances software quality and accelerates the time it takes to deliver value to users. Teams that adopt this practice can more effectively respond to market demands and stakeholder input, thereby fostering a culture of continuous learning, innovation, and adaptability within their organisations.</description>
			</item>
			<item>
				<title>Internal Developer Platform</title>
				<link>https://engineering-leadership.hinshelwood.com/tags/internal-developer-platform/</link>
				<pubDate>Mon, 24 Feb 2025 13:04:45 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/tags/internal-developer-platform/</guid>
				<description>An Internal Developer Platform (IDP) is a unified environment designed to enhance the development lifecycle by enabling teams to efficiently build, test, and deploy applications. Originating from the need to simplify infrastructure management and application dependencies, an IDP allows developers to concentrate on delivering value rather than dealing with operational challenges. This platform cultivates a collaborative and innovative culture, empowering teams to experiment and iterate quickly within a structured framework. By embedding best practices into the development process, an IDP promotes reliability and predictability in software delivery. It also facilitates continuous integration and continuous delivery (CI/CD) practices, which are vital for maintaining competitiveness in rapidly evolving markets. By automating repetitive tasks and standardising workflows, an IDP boosts productivity and shortens lead times, enabling organisations to swiftly adapt to changing customer demands. Ultimately, the long-term advantages of an Internal Developer Platform lie in its capacity to foster a sustainable development ecosystem that aligns with organisational objectives, thereby driving innovation and operational excellence. This alignment is essential for nurturing a resilient and adaptive organisational culture focused on continuous improvement and value delivery.</description>
			</item>
			<item>
				<title>Azure Pipelines</title>
				<link>https://engineering-leadership.hinshelwood.com/tags/azure-pipelines/</link>
				<pubDate>Tue, 11 Feb 2025 10:17:24 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/tags/azure-pipelines/</guid>
				<description>Azure Pipelines is a cloud-based service designed to automate the processes of building, testing, and deploying applications, thereby enabling teams to deliver value in a predictable and sustainable manner. Originating from the need for efficient software development practices, it integrates seamlessly with various version control systems to facilitate continuous integration and continuous delivery (CI/CD). This capability allows teams to implement code changes frequently and reliably, significantly reducing manual errors and accelerating feedback loops while enhancing collaboration among cross-functional teams. The importance of Azure Pipelines lies in its ability to streamline workflows and improve overall efficiency throughout the software development lifecycle, supporting a diverse array of programming languages and platforms to meet varied project needs. By offering a consistent framework for managing builds and releases, it promotes a culture of continuous improvement and innovation. Furthermore, its integration with Azure DevOps tools, such as Azure Boards and Azure Repos, fosters a cohesive project management environment that enhances visibility into the development process and aligns teams towards shared objectives. This systemic approach ultimately drives organisational agility and resilience, with long-term benefits including increased deployment frequency, reduced lead times, and a heightened focus on delivering high-quality software that aligns with customer requirements.</description>
			</item>
			<item>
				<title>Deployment Frequency</title>
				<link>https://engineering-leadership.hinshelwood.com/tags/deployment-frequency/</link>
				<pubDate>Tue, 11 Feb 2025 10:17:24 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/tags/deployment-frequency/</guid>
				<description>Deployment Frequency is a key metric that measures the rate at which software is released into production, playing a vital role in contemporary product development. It originates from the need for organisations to enhance their responsiveness to customer needs by facilitating quicker feedback loops and adjustments. By optimising deployment frequency, teams can not only release features and fixes more frequently but also validate their assumptions and learn from real-world usage promptly. This concept is crucial for cultivating a culture of continuous improvement and innovation, allowing teams to experiment, iterate, and adapt to market changes effectively. A high deployment frequency reflects a mature DevOps practice characterised by automation, collaboration, and efficient processes that enable rapid delivery without sacrificing quality. Additionally, it fosters a sense of accountability and ownership among team members, as they can directly observe the impact of their contributions on end-users. By prioritising deployment frequency, organisations can establish a sustainable delivery rhythm that enhances customer satisfaction and drives long-term business success through consistent value delivery and adaptability. This systemic approach not only promotes resilience and agility but also ensures that teams remain competitive in an ever-evolving digital landscape.</description>
			</item>
			<item>
				<title>Frequent Releases</title>
				<link>https://engineering-leadership.hinshelwood.com/tags/frequent-releases/</link>
				<pubDate>Tue, 11 Feb 2025 10:17:24 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/tags/frequent-releases/</guid>
				<description>Frequent releases are the practice of delivering small, incremental updates to products or services on a regular basis, originating from agile methodologies and widely adopted in DevOps environments. This approach is essential for organisations seeking to swiftly respond to user feedback and market dynamics, ensuring consistent value delivery to stakeholders. By segmenting larger projects into manageable releases, teams can mitigate deployment risks, as smaller updates are easier to test and validate. This practice cultivates a culture of continuous improvement, enabling teams to iterate based on real-world usage and feedback, which is vital for maintaining a competitive edge in adapting to evolving customer needs and technological advancements. Additionally, frequent releases promote collaboration among developers, testers, and product owners, fostering a cohesive environment for product enhancement. They also contribute to a sustainable development pace, reducing the risk of burnout associated with large, infrequent releases, which in turn boosts team morale and builds stakeholder trust through visible progress and tangible outcomes. By integrating frequent releases into their operational frameworks, organisations can ensure they remain responsive and relevant in a rapidly changing market landscape.</description>
			</item>
			<item>
				<title>Release Management</title>
				<link>https://engineering-leadership.hinshelwood.com/tags/release-management/</link>
				<pubDate>Tue, 11 Feb 2025 10:17:24 +0000</pubDate>
				<guid>https://engineering-leadership.hinshelwood.com/tags/release-management/</guid>
				<description>Release Management is a systematic approach to planning, scheduling, and controlling the deployment of software releases to testing and live environments. Originating from the need for structured software delivery, it plays a critical role in ensuring that software is released in a predictable and sustainable manner, aligning with both organisational objectives and customer expectations. Effective release management minimises deployment risks, enhances interdepartmental collaboration, and keeps all stakeholders informed and engaged throughout the release process. This practice allows teams to deliver value incrementally, facilitating rapid feedback and adaptation, and fostering a culture of continuous improvement where each release serves as a learning opportunity. It integrates well with Continuous Delivery and Agile methodologies, optimising workflow and maintaining quality at every stage. Unlike Agile Planning or Product Management, which focus on strategic development aspects, Release Management is operational, concentrating on the tactical execution of software delivery. It necessitates a comprehensive understanding of technical and organisational dynamics, making it essential for modern product development. By establishing clear release processes, organisations can better respond to market changes and customer feedback, ultimately enhancing customer satisfaction and loyalty.</description>
			</item>
	</channel>
</rss>
