<?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>Agile &amp; Scrum Quotes | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/category/knowledge/quotes/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Thu, 01 Oct 2026 12:40:47 +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>Agile &amp; Scrum Quotes | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<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>
					<comments>https://www.scrumexpert.com/knowledge/building-the-right-product-vs-building-the-product-right/#respond</comments>
		
		<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>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/building-the-right-product-vs-building-the-product-right/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</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>Eight Steps For Implementing Successful Change in Scrum</title>
		<link>https://www.scrumexpert.com/knowledge/eight-steps-for-implementing-successful-change-in-scrum/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 03 Mar 2025 16:02:37 +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=8256</guid>

					<description><![CDATA[Implementing Agile and Scrum in software development organization means a big change. In her book &#8220;The Great ScrumMaster&#8220;, the Agile coach Zuzana Šochová recommends an eight steps journey for a successful transformation to the Scrum approach. The second important concept about change management describes a process for implementing successful change in eight steps. It addresses those change phases. First, you set the stage. Next, you decide what to do and make it happen. And finally, you make it stick. Create a Sense of Urgency The very first step before you implement any change is to create a sense of urgency. Make the change necessary, because until you feel pain in your current processes, there is no need for improvement. And it doesn’t matter if the desired change is huge, like an Agile transformation, or small, like using Git instead of CVS. Without good motivation and a good reason there will be no change. Be honest and transparent in presenting both the opportunities and the threats; otherwise you might lose the trust of others. Guiding Team As one individual, it’s hard to change anyone. You should focus on early adopters and encourage them to become part of your team. You need people who are passionate, good communicators, and leaders. Make the group diverse. It shouldn’t follow any organizational structures if it is to access a broader audience. In general, if there are three of you, you already have the ability to create a snowball effect by attracting others. Creating a change <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/eight-steps-for-implementing-successful-change-in-scrum/" title="Eight Steps For Implementing Successful Change in Scrum">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Adding Business Value with Agile Software Development</title>
		<link>https://www.scrumexpert.com/knowledge/adding-business-value-with-agile-software-development/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 22 Jan 2025 22:19:56 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[delivering value]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8206</guid>

					<description><![CDATA[One of the key element of Agile Software Development approaches like Scrum is to emphasize delivering quickly business value over having a long-term rigid plan. In his book &#8220;Project Myopia&#8221;, Allan Kelly discusses the issue of identifying and delivering value. Agile software development focuses on the small. Agile aims to deliver lots of small increments rapidly. One of the key techniques of agile software development is that of breaking work down. This is a learnable skill. Again and again the agile solution to tackling a request is to break it down to smaller items. Teams initially build Minimally Viable Products and Walking Skeletons. Epic stories get broken down to smaller stories which are themselves get broken down to task. To someone of an agile mind being told: “We need all or nothing, if we don’t have the whole thing…, everything on our list is a must” is like a red rag to a bull. Experience shows that almost everything is decomposable when looked at in the right way and with the right toolkit. The all or nothing cry is often made without anyone actually trying to decompose the work. So, look again at the thing that we call “a project”. The aim of the project originators is to create value by delivering the project. Goal displacement occurs in the gap between value identification and delivery because the goals of each activity are not the same as the overall goal: Success in value identification means identifying and communicating potential business value, <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/adding-business-value-with-agile-software-development/" title="Adding Business Value with Agile Software Development">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Sharing Team Members in Scrum</title>
		<link>https://www.scrumexpert.com/knowledge/sharing-team-members-in-scrum/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 23 Dec 2024 12:00:34 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[people]]></category>
		<category><![CDATA[scrum team]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6053</guid>

					<description><![CDATA[We all know that there are three roles in Scrum teams : product owner, scrum master, and the development team. Modern software development can sometimes require a high level of specializations that could be beyond the capabilities of the Scrum team members. UX and Web design, database administration, performance testing are some examples of activities that require specific expertise only for a limited amount of time. How do you deal with it? Can you share team members across multiple scrum teams? In his book “Scrum Shortcuts without Cutting Corners”, Ilan Goldstein discusses the question if a software development specialist can be a member of multiple Scrum teams. In the previous section, I mentioned a 50 percent allocation for deep specialists. This “fractional assignment” is not overly popular across the Scrum community, and for good reason. James Shore and Shane Warden, authors of The Art of Agile Development (2007), put this down to the fact that “fractional workers don’t bond with their teams, they often aren’t around to hear conversations and answer questions, and they must task switch, which incurs a significant hidden penalty.” I totally agree that ideally you want all team members dedicated 100 percent to the team. That being said, I have often found it unnecessary (from a requirement perspective) and unrealistic (from a budgeting perspective) to have deep specialists, such as database administrators, dedicated full time to a development team. That doesn’t mean I disagree with Shore and Warden, nor does it mean there aren’t occasions when <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/sharing-team-members-in-scrum/" title="Sharing Team Members in Scrum">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Velocity is a Lagging Indicator</title>
		<link>https://www.scrumexpert.com/knowledge/velocity-is-a-lagging-indicator/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 03 Dec 2024 17:32:00 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[metrics Agile]]></category>
		<category><![CDATA[velocity Agile]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8150</guid>

					<description><![CDATA[Velocity is one a key metrics used by Scrum teams to measure the rate at which an Agile team delivers value to the customer. In his book “Escape Velocity – Better Metrics for Agile Teams”, Doc Norton explains why velocity is not the ideal metric for Scrum teams. In this quote, he explains that Velocity is a lagging indicator. These metrics tend to be weak indicators for the short-term and are much more reliable for confirming long-term trends. Velocity is also a lagging indicator. It is a measure taken at the end of a series of steps. We plan, we prioritize, we work, we test, and then we measure. Lagging indicators are abstract Lagging indicators tend to be aggregate or abstract. They don’t provide detailed insight into the operations, rather they provide an indication of results. Net profit is a lagging indicator for a company. While it tells us about how the company is doing, it gives us no indication of why the organization was or was not successful. Let’s look at another lagging indicator; unemployment. The unemployment index is a lagging indicator. It tells us whether or not unemployment is on the rise or decline, which in turns tells us if the economy is doing poorly or well, respectively. An increase in unemployment means a sagging economy. A decrease in unemployment means a growing economy. But there is nothing about unemployment that tells us why the economy is performing in a particular manner or how we might go about <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/velocity-is-a-lagging-indicator/" title="Velocity is a Lagging Indicator">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Velocity is a Agile Measure of a Complex System</title>
		<link>https://www.scrumexpert.com/knowledge/velocity-is-a-agile-measure-of-a-complex-system/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Thu, 01 Aug 2024 16:39:33 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[metrics Agile]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7946</guid>

					<description><![CDATA[Velocity is one of the key metrics used by Agile teams to measure the rate at which a team delivers value to the customer. In his book &#8220;Escape Velocity – Better Metrics for Agile Teams&#8221;, Doc Norton explains why velocity is not the ideal metric for Scrum teams. In this quote, he discusses the complexity of the system that underlies the velocity metric. This is ultimately quite significant. Velocity, while a simple concept, is actually a measure of output for a complex system. Think about the number of factors that go into a velocity measurement. There is the organizational mission, the broader business objectives, and the objective of the product itself. There are product owners, designers, architects, developers, testers, subject matter experts, security specialists, database specialists, governance, and production specialists involved. There are stand-ups, planning meetings, and retrospectives. There are epics, stories, and tasks all tracked on a board or in a system with multiple lanes representing different key states in the delivery of each single piece of work. After all these individuals interact with one another, responding to change, and collaborating with the customer in pursuit of working software, we take a single measurement. That single measurement represents the interactions of the individuals and all of their adaptions to change in the delivery of working software. Velocity is a simple measure of a very complex system. To measure creative work by throughput alone is to not measure it at all; quality and impact are essential. While a simple measure <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/velocity-is-a-agile-measure-of-a-complex-system/" title="Velocity is a Agile Measure of a Complex System">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>A Definition of Done Checklist for Agile Teams</title>
		<link>https://www.scrumexpert.com/knowledge/a-definition-of-done-checklist-for-agile-teams/</link>
					<comments>https://www.scrumexpert.com/knowledge/a-definition-of-done-checklist-for-agile-teams/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 23 Jan 2024 21:45:23 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[scrum team]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7765</guid>

					<description><![CDATA[The Definition of Done (DoD) is a common understanding within the Scrum team on what it takes to make your software ready to be released. In their book &#8220;Managing the Unmanageable&#8221;, Mickey Mantle and Ron Lichty propose an extensive list of what a Definition of Done should include. You could use do these elements to create your own DoD for your Agile team. The project kickoff is often the right time to get agreement around the question “When is a feature, task, or sprint done? What constitutes ‘done’?” Defining “done” is a joint exercise with the business, the development team, project management, QA, and sometimes others to define when each feature can be declared done. In addition to being coded, will it need Design review Peer review (or pair programming) Code review Unit testing Check-in to source control Commenting in source control Performance testing Refactoring Any changes required to build it communicated to the buildmeister Online help written and integrated Built out of source control Unit tests passed on the source control build Automated regression tests for the integrated application passed on the new source control build Bugs fixed Installation scripts written Tested on multiple platforms, browsers, configurations, etc. Story or use case test plan updated Documentation written Product managers’, product owner’s, and/or customers’ acceptance that it meets expectations Task hours recorded Tasks closed out It’s important for the team to agree to the elements of “done” and agree to deliver them. It’s infrequent that two teams agree on the <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/a-definition-of-done-checklist-for-agile-teams/" title="A Definition of Done Checklist for Agile Teams">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/a-definition-of-done-checklist-for-agile-teams/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Breaking Silos in Agile Software Development</title>
		<link>https://www.scrumexpert.com/knowledge/quotes/breaking-silos-in-agile-software-development/</link>
					<comments>https://www.scrumexpert.com/knowledge/quotes/breaking-silos-in-agile-software-development/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 06 Nov 2023 15:27:23 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[scrum team]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7692</guid>

					<description><![CDATA[Most teams I work with have three distinct roles; BA, Developer, and QA. Most teams I work with have three distinct phases of their work; gather requirements, build, verify. Even on agile teams, these separations exist. There are clear delineations in the process and clear segregation of responsibilities. But this segregation is a contributor to erratic velocity. How many “agile” teams do you know of where the BA group is an iteration ahead of the developers who are an iteration ahead of QA, leaving us with a three-iteration cycle time and significant lag in our feedback loops between the groups? Tighten the loops. Get people working together in not only close proximity, but close time-frame. Involve the developers and QA in the formation of requirements. Push QA to the front and automate, automate, automate. Don’t let manual testing be a bottleneck. Start development before you’ve polished the requirements. And don’t wait until the end to test it all comprehensively. Source: Escape Velocity – Better Metrics for Agile Teams, Doc Norton, https://leanpub.com/escapevelocity Breaking silos between business analysts, software developers and software testers is a key challenge to achieve the benefits of Agile software development and Scrum. You can achieve this by using techniques and approaches that force the different specialists to work together. Among those, you can include Behavior-Driven Development (BDD), DevOps, test automation or backlog refinement. Another approach is to build cross-functional Agile teams where the members have multiple skills, often described as T-shaped. This metaphor is used to describe <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/quotes/breaking-silos-in-agile-software-development/" title="Breaking Silos in Agile Software Development">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/quotes/breaking-silos-in-agile-software-development/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
	</channel>
</rss>
