<?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>Knowledge | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/category/knowledge/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Mon, 19 Oct 2026 09:53:55 +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>Knowledge | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>When Software Delivery Outruns the Pipeline: Rethinking CI/CD Throughput</title>
		<link>https://www.scrumexpert.com/knowledge/when-software-delivery-outruns-the-pipeline-rethinking-ci-cd-throughput/</link>
					<comments>https://www.scrumexpert.com/knowledge/when-software-delivery-outruns-the-pipeline-rethinking-ci-cd-throughput/#respond</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 19 Oct 2026 09:49:55 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Headline]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[Agile testing]]></category>
		<category><![CDATA[continuous delivery]]></category>
		<category><![CDATA[devops]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8879</guid>

					<description><![CDATA[With AI code generation, software developers create code faster than before. But how can the QA engineers and the CI/CD system absorb this increased workload? In this article, Sergei Cherednichenko suggests some approaches on how to deal with this situation. Author: Sergei Cherednichenko, https://linkedin.com/in/sergei-cherednichenko/ Software delivery teams produce changes faster than many continuous integration and continuous delivery (CI/CD) systems can comfortably absorb. The pressure appears in familiar places: pull-request queues grow, reviews become less thorough, flaky tests interrupt builds, merge conflicts remain unresolved, and resource-intensive validation slows the path to production. Across CircleCI projects, average throughput grew 59% year over year. For the median team, feature-branch throughput increased 15% while main-branch throughput declined 7%. Main-branch success rates fell to 70.8%, the lowest in over five years and well below CircleCI’s recommended 90% benchmark (Figure 1). DORA’s 2024 research found a similar pattern: increased artificial intelligence (AI) adoption was associated with an estimated 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability. AI-assisted development amplifies the problem by increasing the volume of code entering the system, but the larger issue is throughput: the delivery pipeline needs to control flow as carefully as it processes individual changes. (click on figure to enlarge) Figure 1. The delivery gap: year-over-year change in CI throughput by branch type. (Source: CircleCI, The 2026 State of Software Delivery.) Image courtesy of Sergei Cherednichenko. Distributed and data-streaming systems offer a useful model. When producers send work faster than consumers can process it, the system applies <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/when-software-delivery-outruns-the-pipeline-rethinking-ci-cd-throughput/" title="When Software Delivery Outruns the Pipeline: Rethinking CI/CD Throughput">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/when-software-delivery-outruns-the-pipeline-rethinking-ci-cd-throughput/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>The Agile Job Seeker</title>
		<link>https://www.scrumexpert.com/knowledge/the-agile-job-seeker/</link>
					<comments>https://www.scrumexpert.com/knowledge/the-agile-job-seeker/#respond</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 21 Sep 2026 15:14:04 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Headline]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[people]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8845</guid>

					<description><![CDATA[How do you approach a job search with an Agile mind? In this article Mark Haynes discusses how to plan your quest for a new job using the Scrum framework and concepts like sprints or user stories.. Author: Mark Haynes, https://www.linkedin.com/in/donald-mark-haynes-csm-745a609/ Think small and incrementally. Keep the big picture in mind, but focus on tasks you can accomplish in a few hours a day. Concentrate on one doable task at a time. Give yourself small assignments, then work them to completion, and move on to the next. Don’t obsess over things that will take months, or anything you have already accomplished. If you need to revisit it, then do that as a separate task. The job search, skill assessment, and skill development are all interrelated. Don’t get trapped rationalizing that you need more experience before you apply. Ask: How do I get experience? This is an excellent time to conduct a skills assessment and create a career development plan. Create a list of targeted skills. Think tools, techniques, and experience. Look for opportunities to pursue them. Constantly changing goals will lead to a spiral of self-doubt and indecision as you hit roadblocks. Pick a path. If you choose multiple paths, then work on them separately. Where do you start? It doesn’t matter. What matters is that you start now. There are jobs available, even in a bad economy. When is it a good time to look for a job? Always. You need market data. It gives a perspective on what <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/the-agile-job-seeker/" title="The Agile Job Seeker">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/the-agile-job-seeker/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Be Strongly Agile: Show Your Weaknesses</title>
		<link>https://www.scrumexpert.com/knowledge/be-strongly-agile-show-your-weaknesses/</link>
					<comments>https://www.scrumexpert.com/knowledge/be-strongly-agile-show-your-weaknesses/#respond</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 15 Sep 2026 15:31:28 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[change]]></category>
		<category><![CDATA[people]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8842</guid>

					<description><![CDATA[I am frequently amused when the same people who believe that it is not possible to get the requirements for a product correct up front, and therefore want to use Scrum for development, will in the next breath explain how they aren’t quite ready to start using Scrum because they haven’t worked out all of the details of their Scrum approach! This type of thinking is poorly aligned with fundamental Scrum principles. When employing Scrum, you shouldn’t worry about getting things perfect up front. You can’t! And trying to be perfect up front will force you to guess at the expense of important learning that you will get only by applying Scrum and seeing what happens. In my experience, most teams’ first couple of sprints aren’t all that pretty. That’s OK. My only expectation of any Scrum team is that it be better in the next sprint than it was in the previous sprint. So, don’t delay getting started. Whatever you think you know now about your use of Scrum, imagine how much more you will really know after you start and finish the next sprint! Also, don’t expect your Scrum adoption to be problem free. I can guarantee that at some point your organization will encounter impediments that make performing Scrum difficult. Scrum makes visible the dysfunctions and waste that prevent organizations from reaching their true potential. What it does not do is tell organizations how to solve those issues. That hard work is up to the people in <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/be-strongly-agile-show-your-weaknesses/" title="Be Strongly Agile: Show Your Weaknesses">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/be-strongly-agile-show-your-weaknesses/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Building the Right Product vs Building the Product Right</title>
		<link>https://www.scrumexpert.com/knowledge/building-the-right-product-vs-building-the-product-right/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Fri, 28 Aug 2026 20:47:23 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[product management]]></category>
		<category><![CDATA[product owner]]></category>
		<category><![CDATA[requirements]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8834</guid>

					<description><![CDATA[In his book &#8220;Specification by Example &#8211; How successful teams deliver the right software&#8221;, Gojko Adzic had some interesting quotes about building the right product. &#8220;In the last decade, the software development community has strived to build software the “right” way, focusing on technical practices and ideas to ensure high-quality results. But building the product right and building the right product are two different things. We need to do both in order to succeed. To build the right product effectively, software development practices have to provide the following: * Assurance that all stakeholders and delivery team members understand what needs to be delivered in the same way. * Precise specifications so delivery teams avoid wasteful rework caused by ambiguities and functional gaps. * An objective means to measure when a piece of work is complete. * Documentation to facilitate change, in terms of both software features and team structure.&#8221; Source: &#8220;Specification by Example &#8211; How successful teams deliver the right software&#8221;, Gojko Adzic, Manning This idea of &#8220;building the right&#8221; product is also the center of the &#8220;Software Testing is Dead&#8221; presentation made by Alberto Savoia at the Google Test Automation Conference 2011.  I strongly agree that you cannot have a successful project without good requirements (which mean also good domain experts and product owners). We should however not forget that the right product would not be used if it is not working right. Keeping also the focus on building quality into the application is mandatory. You must do both, <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/building-the-right-product-vs-building-the-product-right/" title="Building the Right Product vs Building the Product Right">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>The Eleventh Commandment of Software Development</title>
		<link>https://www.scrumexpert.com/knowledge/the-eleventh-commandment-of-software-development/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Thu, 06 Aug 2026 17:52:49 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[change]]></category>
		<category><![CDATA[people]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8826</guid>

					<description><![CDATA[During my software development career, I have seen a good deal of software development approaches or methodologies used in different organizations. When a new and supposedly better approach is promoted, some people tend to adopt it with an attitude that could sometimes be close to a religious zeal. Software companies have noticed this and they now employ “product evangelists”. As a consequence, new believers are often rejecting completely what has been done previously. They adopt a “us against them” attitude, especially when the new approach is still a small movement fighting against an established methodology. This has been the same for Agile, the latest approach on the block, even if the words of the Manifesto for Agile Software Development (“while there is value in the items on the right, we value the items on the left more.”) try to avoid this “forget the past” situation. Most agile coaches agree also that it is more important to make choices according to the context than to apply a prescriptive checklist, but for some people it is easier to follow blindly a model than to absorb a philosophy. You know the proverb: “Give a man a fish, and he will eat for a day. Teach him how to fish and he will eat forever”. It is however easier to learn how to work with JUnit than to create efficient unit testing cases. Pure agilists quickly fond their “enemy”: the Waterfall, a dinosaur of software process that should be lead to extinction, buried with <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/the-eleventh-commandment-of-software-development/" title="The Eleventh Commandment of Software Development">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Sacred Agile: Religious Approaches to Software Development</title>
		<link>https://www.scrumexpert.com/knowledge/sacred-agile-religious-approaches-to-software-development/</link>
					<comments>https://www.scrumexpert.com/knowledge/sacred-agile-religious-approaches-to-software-development/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 12 May 2026 16:19:04 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[change]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8737</guid>

					<description><![CDATA[You know that when you deal with this type of topic, you are writing about a touchy subject. When I write that Agile has sometimes been sacralized, my aim is not to hurt any religious or philosophical belief, but rather to see how men behave when adopting new ideas. Raised as a catholic, what will follow is mainly comparison of the respective adoption patterns of Christian and Agile, but I think that it might apply to other philosophical and technological approaches. Ultimately, my conviction is that the values you are trying to respect in your daily personal and professional life are more important than what you claim to be. And sometimes laughing a little bit at ourselves can help to put things in perspective. The year zero of the Agile movement is linked to the creation of the Agile Manifesto and its 12 principles. Like the 10 commandments, they should regulate the life of the Agilists. Like all texts, the Manifesto is subject to interpretation (exegesis) and to translation choices for non-native English persons, like me. This leads naturally to many different “flavors” of Agile based somewhat on differences as theoretical as theological quarrels. Some of the early Agile approaches, like the oriental Christian churches of the beginning of the Christian era, are now mostly forgotten. I doubt that there are still many practitioners of Feature Driven Development or the Crystal methodology. Agilists, initially considered by traditional project management followers as “cowboys” or “anarchists”, quickly also devised a name for <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/sacred-agile-religious-approaches-to-software-development/" title="Sacred Agile: Religious Approaches to Software Development">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/sacred-agile-religious-approaches-to-software-development/feed/</wfw:commentRss>
			<slash:comments>2</slash:comments>
		
		
			</item>
		<item>
		<title>How Software Testing Supports Better Performance</title>
		<link>https://www.scrumexpert.com/knowledge/how-software-testing-supports-better-performance/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 29 Apr 2026 20:37:31 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8729</guid>

					<description><![CDATA[Have you ever asked yourself why some apps, websites, and software tools feel smooth, fast, and easy to use from the first click? The answer often comes back to software testing. It plays a quiet but very useful role in making software work in a clean, stable, and comfortable way. When testing is done with care, the final product feels more polished, more responsive, and more ready for daily use. That is why software testing is closely linked with better performance for Scrum teams. How Testing Builds A Strong Base For Performance Good performance starts with a strong base. Software testing helps create that base by checking each part in a careful and practical way. When teams test features step by step, they get a clear idea of how the software is performing in normal use. This makes the whole system more balanced and more dependable. Performance is not only about speed. It is also about smooth flow, stable response, and easy movement from one screen to another. Testing helps support all of this. It gives developers useful feedback so they can shape the software in a better way before it reaches users. Testing Helps Software Run Smoothly When software is tested early and regularly, it becomes easier to keep everything running in a clean manner. Each function gets reviewed properly, and this supports better response time. A button click, a page open, a search result, or a payment step can all feel more natural when testing has been done <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/how-software-testing-supports-better-performance/" title="How Software Testing Supports Better Performance">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>How Software Quality Assurance Supports Long-Term Product Success</title>
		<link>https://www.scrumexpert.com/knowledge/how-software-quality-assurance-supports-long-term-product-success/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 28 Apr 2026 21:53:17 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8727</guid>

					<description><![CDATA[Have you ever used an app or website and felt happy because everything worked in a smooth and simple way? That good feeling does not happen by chance. Behind that easy experience, there is usually a strong quality process. Software quality assurance helps products stay useful, stable, and trusted for a long time. It supports Scrum teams in building software that people enjoy using again and again. When a product works well from the start and keeps improving over time, users feel comfortable with it. They trust it more. They return to it more often. This is one of the main reasons quality assurance matters for long-term product success. It is not only about checking errors. It is also about helping Agile teams build a product that stays strong as user needs grow. Quality assurance supports a product at every stage. It helps teams review features, check user flows, test performance, and confirm that updates fit the original purpose of the product. With this kind of steady support, software can stay clear, useful, and dependable for years. Why Quality Assurance Matters For Long-Term Success A successful product is not only one that launches well. A successful product is one that keeps serving people in a useful way over time. Quality assurance helps make that possible by giving structure to the full development process. When teams test early and review often, they understand the product better. They can see how each feature connects with the full user experience. This makes future <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/how-software-quality-assurance-supports-long-term-product-success/" title="How Software Quality Assurance Supports Long-Term Product Success">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Nine Questions for a Good Scrum Team Structure</title>
		<link>https://www.scrumexpert.com/knowledge/nine-questions-for-a-good-scrum-team-structure/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 14 Apr 2026 14:07:40 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[scrum team]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8723</guid>

					<description><![CDATA[In his book “Succeeding with Agile”, Mike Cohn present nine questions that you should ask for a current or proposed team. Questions should be asked iteratively&#8230; until you answer “yes” to each. Here are the questions: * Does the structure accentuate the strengths, shore up the weaknesses, and support the motivations of the team members? * Does the structure minimize the number of people required to be on two teams (and avoid having anyone on three)? * Does the structure maximize the amount of time that teams will remain together? * Are component teams used only in limited and easily justifiable cases? * Will you be able to feed most teams with two pizzas? * Does the structure minimize the number of communication paths between teams? * Does the structure encourage teams to communicate who wouldn’t otherwise do so? * Does the design support a clear understanding of accountability? * Did team members have input into the design of the team? Reference: “Succeeding with Agile”, Mike Cohn, Addison-Wesley, 463 pages, IBSN 978-0-321-57936-2 Besides the cultural bias (in Italy, one pizza will usually feed one person, but it might be different in the USA&#8230;), you could use these questions for every Agile project that you are currently running or plan to run to check the quality of your Scrum team.]]></description>
		
		
		
			</item>
		<item>
		<title>How Continuous Validation in Scrum Improves Content Readiness for AI Search</title>
		<link>https://www.scrumexpert.com/knowledge/how-continuous-validation-in-scrum-improves-content-readiness-for-ai-search/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Thu, 09 Apr 2026 15:37:28 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8719</guid>

					<description><![CDATA[The era of traditional search is rapidly fading into the past, giving way to smart algorithms and generative responses. Simply filling a website with keywords to rank high is no longer enough. Modern systems analyze the depth, veracity, and structure of content with the meticulousness of an experienced QA engineer. The team of experts at Netpeak is confident that agile methodologies are what enable the creation of such high-quality content. An agile approach transforms chaotic text writing into a streamlined production cycle with measurable results. Scrum as the Foundation of Data Quality Implementing Scrum methodology into the content creation process is a game-changer for the entire marketing team. Instead of endlessly preparing one massive piece of content, the team works in short, clear, and effective sprints. This allows for constant testing of hypotheses and checking data readiness at each intermediate stage. AI search requires impeccable logic, the absence of factual errors, and the avoidance of so-called &#8220;hallucinations&#8221; in texts. Short content development cycles enable editors and optimizers to quickly adjust the data structure. To achieve the ideal result, the team completes the following list of tasks within each work sprint: Fact-checking. Checking technical page markup. Analyzing readability for algorithms. Testing query responses. Validating the structure of all headings. Assessing the relevance of link mass. Verifying the uniqueness of each paragraph. Continuous validation within each sprint ensures that every piece of information passes a rigorous filter. Testers and editors now work together to identify weaknesses even before publication. This rhythm minimizes <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/how-continuous-validation-in-scrum-improves-content-readiness-for-ai-search/" title="How Continuous Validation in Scrum Improves Content Readiness for AI Search">[...]</a>]]></description>
		
		
		
			</item>
	</channel>
</rss>
