<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>software architecture | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/tag/architecture/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Wed, 24 Jun 2026 14:23:19 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	

<image>
	<url>https://www.scrumexpert.com/wp-content/uploads/favicon.png</url>
	<title>software architecture | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Architecture and Agile: the Meeting of the Undead</title>
		<link>https://www.scrumexpert.com/videos/architecture-and-agile-the-meeting-of-the-undead/</link>
					<comments>https://www.scrumexpert.com/videos/architecture-and-agile-the-meeting-of-the-undead/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 09 Jun 2026 19:09:39 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[software architecture]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8765</guid>

					<description><![CDATA[Twenty years ago, Architecture was murdered in its sleep by Agile, as part of the assassination plot against the arch-enemy Waterfall. Fast-forward to today, and Agile isn&#8217;t looking too healthy either: reduced to hollow-eyed cargo culting and pointless rituals, wading through the debris of methodology pop culture, or bloated to a monstrous parody of itself in order to scale. But death aside, they are both still among us, and moaning for brains. Why? One reason might be that the problems that Architecture and Agile set out to fix have not been solved. Or they need continuous solving, and in the absence of new life to tackle them, we animate our dead. What are these problems, and how do we see them today? Have we learned anything from the death of these two grand attempts at fixing software development, and their refusal to lie down even in the face of death? Is there still something that can be found in the black hearts of the undead that can be of use in addressing the problems we face? Should Agile and Architecture be revived or put out of their misery for good? Will we be able to? What new kind of life do these two half-lives point towards? What acts of bravery will be required of us going forward with Agile Architecture? Video producer: https://ndcoslo.com/]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/videos/architecture-and-agile-the-meeting-of-the-undead/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>How to Sell a Big Refactoring or Rewrite to the Business?</title>
		<link>https://www.scrumexpert.com/videos/how-to-sell-a-big-refactoring-or-rewrite-to-the-business/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 03 Dec 2025 15:50:43 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[software architecture]]></category>
		<category><![CDATA[technical debt]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8512</guid>

					<description><![CDATA[In the world of software development, dealing with legacy code is often a necessary evil, especially for successful, fast-growing companies. But how do Agile teams tackle this challenge smartly and sell the idea of refactoring to the business? This presentation discusses the often-misunderstood realm of large-scale refactoring and rewrites, presenting a nuanced approach that contrasts with the traditional &#8216;never rewrite&#8217; dogma. It presents real-world case studies where companies have successfully navigated their technical debt, uncovering crucial insights. Specifically, the video identifies two key properties of these successful rewrites that can make or break your efforts. Understanding these properties enables Scrum teams to strategically manage technical debt without losing your competitive edge. This session is not just a theoretical discussion but a practical guide, concluding with a systematic approach for your team&#8217;s refactoring or rewrite projects. Video producer: https://ndcoslo.com/]]></description>
		
		
		
			</item>
		<item>
		<title>A Guide To Software Reengineering: When and How</title>
		<link>https://www.scrumexpert.com/knowledge/a-guide-to-software-reengineering-when-and-how/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 25 Mar 2024 16:27:01 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[software architecture]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7817</guid>

					<description><![CDATA[Many successful digital products have evolved haphazardly over the years, accumulating messy architecture and code that require extensive rewrite efforts to sustain reliability and innovation velocity in the long term. We outline pragmatic steps for refactoring platforms. What is Software Reengineering? Software reengineering refers to the extensive process of revisiting, restructuring and rebuilding aging software from its core &#8211; beyond just adding incremental features or superficial user interface facelifts. It fundamentally transforms legacy platform internals, seeking increased qualities around maintainability, scalability, reliability, deployment agility, operability and security over the long run. More practical information is available here: https://modlogix.com/services/re-engineering/. Reengineering efforts methodically analyze existing architectures, validate capabilities, simplify convoluted code flows, dismantle unnecessary complexity, and design modular target state blueprints, balancing business continuity with strategic progress goals. The reworked systems then exhibit principles like abstraction, loose coupling, encapsulation and continuous integration, easing future evolvability at an optimized total cost of ownership. There is careful deliberation around what gets rearchitected versus what remains, how rapidly changes get introduced, and when existing implementations get retired with parity assurances. Mastering the interplay of old and new is key in sustained migrations. While rebuilding software perfectly risks over-engineering and not realizing returns, pragmatic incremental upgrades deliver outsized benefits, improving the underlying health and responsiveness of products users rely on daily. Why Reengineering Gets Necessary Typical catalysts include: Code Entropy Messy constructs accumulate across changing teams over time, increasing costs towards sustaining and enhancing platforms. Institutional knowledge loss compounds difficulties for new engineers. Legacy Tech Debt <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/a-guide-to-software-reengineering-when-and-how/" title="A Guide To Software Reengineering: When and How">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>An Introduction to Evolutionary Design</title>
		<link>https://www.scrumexpert.com/videos/an-introduction-to-evolutionary-design/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 19 Oct 2020 06:27:16 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[software architecture]]></category>
		<category><![CDATA[XP eXtreme Programming]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6441</guid>

					<description><![CDATA[Modern software development inspired by Agile approaches welcomes changing requirements, even late in the process, but how can we write our software so that those changes don’t create a mess? Evolutionary design is the key. It is a technique that emerges from Extreme Programming (XP), the method that brought us test-driven development (TDD), merciless refactoring, and continuous integration (CI). In this presentation, James Shore shares what he has learned about agile software design and architecture through in-depth animations of real software development projects. You will see how designs evolve over time and you will learn how and when to use evolutionary design for your own Scrum projects. https://www.youtube.com/watch?v=QJRAeoOHewo Video producer: https://yowconference.com.au/]]></description>
		
		
		
			</item>
		<item>
		<title>Agile Architecture Roadmapping</title>
		<link>https://www.scrumexpert.com/videos/agile-architecture-roadmapping/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 07 Mar 2017 15:14:18 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[software architecture]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4219</guid>

					<description><![CDATA[In the Agile world, software architecture is about making design decisions with just enough anticipation. Too much anticipation leads to overly heavy architectural constructs that may never be used (YAGNI); too little anticipation leads to expensive refactoring and potentially fatal build-up of technical debt. This session presents an approach for Agile architecture roadmapping with just enough anticipation. The approach consists of principles and practices that help address questions like * How do we anticipate and embrace changes in our solution’s environment? * What are good roadmapping strategies, and how do organizations choose the right strategy in a particular context? * Should we do “up-front” architecting and, if so, how much? * How can we organize architectural decision making in Agile teams? * What tools should architects use to achieve “just enough” anticipation? It presents experiences from software architects who have used this approach in practice in multiple organizations. Their experiences show more realistic stakeholder expectations and better prioritization of required architectural improvements. This presentation is based on Risk- and Cost-Driven Architecture (RCDA), an approach developed by CGI that has proven to support solution architects globally in a lean and Agile manner. RCDA is a recognized architecture method in The Open Group’s architect certification program. Video producer: http://www.sei.cmu.edu/saturn/]]></description>
		
		
		
			</item>
		<item>
		<title>Technical Dependency Communication in Scaling Agile</title>
		<link>https://www.scrumexpert.com/knowledge/technical-dependency-communication-in-scaling-agile/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 28 Nov 2016 15:43:47 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[scaling Agile]]></category>
		<category><![CDATA[software architecture]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=3949</guid>

					<description><![CDATA[Developing large software systems automatically generate some technical dependency issues. If this is often managed by software architects in traditional projects, how do you communicate this technical dependencies when you are organized using an Agile approach? This is the topic discussed in the paper written by a Swedish research group. As Agile approaches are increasingly adopted by large software development organizations with distributed teams, the Agile breakdown of complex tasks create large challenges due to the technical dependencies between teams. This is not new, but with Agile the technical dependencies do not become more or less, they just become more obvious and this is actually a possibility for practice to deal with them. The research paper tried to answer two main questions based on a case study: * What are the challenges associated with technical dependencies between teams in a large-scale agile software development? * What affects the likelihood of a challenge to occur? The following technical dependencies are considered: * Unpredictability: teams find difficult to know beforehand what changes, issues, surprises, failures and successes they will come across during the development of a feature. * Conflicting priorities: a team might depend on a component that has lower priority in the backlog of another team. * Difficulty to understand overlapping and short release cycles when teams are constantly changing priorities in each sprint To mitigate the challenges created by these technical dependencies, the authors wrote that &#8220;one has to start with mitigating one challenge and then continue to exploit the <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/technical-dependency-communication-in-scaling-agile/" title="Technical Dependency Communication in Scaling Agile">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Why We Need Architects (and Architecture) on Agile Projects</title>
		<link>https://www.scrumexpert.com/videos/why-we-need-architects-and-architecture-on-agile-projects/</link>
					<comments>https://www.scrumexpert.com/videos/why-we-need-architects-and-architecture-on-agile-projects/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Thu, 05 Dec 2013 11:28:37 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[software architecture]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1727</guid>

					<description><![CDATA[The rhythm of Agile software development is to always be working on the next known, small batch of work. Is there a place for software architecture in this style of development? Some people think that software architecture should simply emerge and doesn&#8217;t require ongoing attention. But it isn&#8217;t always prudent to let the software architecture emerge at the speed of the next iteration. Complex software systems have lots of moving parts, dependencies, challenges, and unknowns. Counting on the software architecture to spontaneously emerge without any planning or architectural investigation is at best risky. So how should architecting be done on agile projects? It varies from project to project. But there are effective techniques for incorporating architectural activities into agile projects. This talk explains how architecture can be done on agile projects and what an agile architect does. [youtube Oyt4Ru7Xzq0] Video producer: JDD Conference]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/videos/why-we-need-architects-and-architecture-on-agile-projects/feed/</wfw:commentRss>
			<slash:comments>3</slash:comments>
		
		
			</item>
		<item>
		<title>Best Practices to Integrate Software Architecture Needs in A Scrum Project</title>
		<link>https://www.scrumexpert.com/knowledge/best-practices-to-integrate-software-architecture-needs-in-a-scrum-project/</link>
					<comments>https://www.scrumexpert.com/knowledge/best-practices-to-integrate-software-architecture-needs-in-a-scrum-project/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 28 May 2013 14:32:58 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[software architecture]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1516</guid>

					<description><![CDATA[Modern Agile software development approaches like Scrum recommend a &#8220;just in time&#8221; vision of application development that tends to make people focus only on the activities that are directly useful for the current sprint. How can you include an activity with a long-term perspective like enterprise software architecture in the iterative process of Scrum? Author: Markus van Aardt, Adamantium Software Engineering, http://www.adamantiumse.com/ Agile approaches have brought a renewal in software development and delivery practices over the last decade. Yet, iterative and incremental development methods have been around since the 1980’s and are not really that new. What made Agile stick was the community created by The Agile Manifesto’s rehash of an old idea. Agile approaches are different in that they look outside the boundaries of software development into the softer areas of software requirements, product delivery and people management. They provide a management tool to improve the ability of software engineers to deliver better solutions, in less time and at a lower cost than what was possible with the traditional Waterfall process and even Boehm’ Spiral model. But that is not where this story ends. I find it often quite amusing how technology trends manage to overrun conventional wisdom as a new truth and immediately negating everything that has gone before. This is the case with Agile and Scrum. So when I recently encountered a senior IT executive who believed his project was exempt from architectural impact due to an Agile development model, I was surprised – in a bad <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/best-practices-to-integrate-software-architecture-needs-in-a-scrum-project/" title="Best Practices to Integrate Software Architecture Needs in A Scrum Project">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/best-practices-to-integrate-software-architecture-needs-in-a-scrum-project/feed/</wfw:commentRss>
			<slash:comments>2</slash:comments>
		
		
			</item>
		<item>
		<title>Managing Technical Debt in Large Software Development Projects</title>
		<link>https://www.scrumexpert.com/videos/managing-technical-debt-in-large-software-development-projects/</link>
					<comments>https://www.scrumexpert.com/videos/managing-technical-debt-in-large-software-development-projects/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Thu, 29 Mar 2012 18:49:44 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[software architecture]]></category>
		<category><![CDATA[technical debt]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=1016</guid>

					<description><![CDATA[The nice metaphor of technical debt introduced some 18 years ago by Ward Cunningham has slowly taken roots in our collective conceptual toolbox, as a nice way to express some of the pains that software projects suffer from. Most software developers who have had some experience with significant, long-lived projects can feel it, sometimes point to it, but more than often can’t do much about it. In most cases, technical debt is seen as something very negative, burdening projects forever under increasing amount of interests. But some technical debt can be deliberate, more akin to borrowing to make an strategic investment, and this is especially the case for architectural-level debt. When does this architectural debt actually make sense? Should it always be repaid? How can we constructively reason about technical debt, before and after incurring it? The question often boils down to another question we are familiar with: what is the value of software architecture, this invisible ingredient of many challenging systems? This presentation explores different facets of technical debt and the various means that have been proposed to assess, mitigate, evaluate or reduce technical debt. It looks also at it as some form of a tactical investment, when technical debt is not just a “bad thing” as long as incurred in full knowledge on the consequences. It is important to integrate the reduction of technical debt into every Scrum sprint. The best approach is to put it into your workflow so that it prevents debt from becoming a massive <a class="mh-excerpt-more" href="https://www.scrumexpert.com/videos/managing-technical-debt-in-large-software-development-projects/" title="Managing Technical Debt in Large Software Development Projects">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/videos/managing-technical-debt-in-large-software-development-projects/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Agile Architecture</title>
		<link>https://www.scrumexpert.com/knowledge/agile-architecture-2/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 31 Oct 2011 08:52:56 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[documentation]]></category>
		<category><![CDATA[software architecture]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=778</guid>

					<description><![CDATA[Upfront Modeling is fine, documents describing the intended architecture are fine, and so forth. But the architecture, and our learning about it, can improve. Speculative software architecture should be made concrete and not of concrete. Agile architecture comes from the behavior of agile architecting &#8211; hands-on master-programmer architects, a culture of excellence in code, an emphasis on pair-programming coaching for high-quality code/design, agile modeling, design workshops, test-driven development and refactoring, and other hands-on-the-code behaviors. Source: Practices for Scaling Lean &#38; Agile Development &#8211; Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Craig Larman and Bas Vodde, Addison Wesley, ISBN 978-0-321-63640-9]]></description>
		
		
		
			</item>
	</channel>
</rss>
