<?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 Blogs | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/category/knowledge/blogs/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Wed, 12 Dec 2018 14:52:57 +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 Blogs | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>The Goals of Agile Documentation</title>
		<link>https://www.scrumexpert.com/knowledge/goals-agile-documentation/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 20 Aug 2018 15:07:15 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[documentation]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=5262</guid>

					<description><![CDATA[As the Agile Manifesto stated that it prefers &#8220;working software over comprehensive documentation&#8221;, some early Agile adopters jumped to the conclusion that documentation was useless. Thus Scrum software developers should only concentrate in creating working software with code that was the most easier to understand. The Agile Manifesto however also said that there is some value on the left side of the comparison and in her tow blog posts Birgitta Böckeler reminds us that Agile documentation fulfills some important goals. Birgitta Böckeler starts her blog post explaining that there is value in documentation, that there is no fixed rules about how much documentation is enough and finally that documents have different audiences from software developers to final users. Then she follows by listing four goals that documentation can have for Agile and Scrum teams. 1. Creating a shared understanding Some things might seem to be clear in the heads of the members of the Scrum teams but with a slightly different point of view, like the software architecture for instance. Creating a document helps team members to discuss formally the topic and achieve a common understanding. Birgitta Böckeler proposes to create a wall of shared understanding with the main things that Agile members team should agree upon. She provides some tips on how to select the items that should appear on this wall. 2. Expose complexity Even if Agile software developers should strive for simplicity, there are often some points that might require more explanation, like a data migration plan <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/goals-agile-documentation/" title="The Goals of Agile Documentation">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Predictability and Team Goals</title>
		<link>https://www.scrumexpert.com/knowledge/predictability-and-team-goals/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 13 Sep 2017 13:10:47 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[people]]></category>
		<category><![CDATA[scrum team]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4571</guid>

					<description><![CDATA[Agile software development teams often use the notion of &#8220;velocity&#8221; to measure their ability at delivering value to the customer. In his blog post, Norberto Herz discusses the concept of &#8220;predictability&#8221; as a measure of the team&#8217;s health. His blog post starts with a series of interesting questions: can the company sell “predictability” to its customers? Is predictability a new application feature? Is predictability A team quality or a team goal? From a product management perspective, Norberto Herz defines predictability as a way of achieving the team goals and adds that the team needs to feel its own bias for being a predictable one. it is the responsibility of the manager to encourage the team to be predictable and to supply the tools to achieve this goal. The blog post the describes the situation an actual team and presents its journey to being more predictable. A very interesting part of this story is the discussion about the root causes that prevented the team to achieve this goal, like the lack of metrics. The team refactored its process and achieved the following results after four sprints: * The team was estimating quicker and more precisely. * The product vision was shared by the entire team. * Deviations in the roadmap were being foreseen and corrective actions were being taken. Read the complete blog post on http://ourbit.norbertoherz.com//2016/11/01/about-predictability-and-team-goals/]]></description>
		
		
		
			</item>
		<item>
		<title>Giving Better Feedback</title>
		<link>https://www.scrumexpert.com/knowledge/giving-better-feedback/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 03 Apr 2017 16:36:17 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[communication]]></category>
		<category><![CDATA[people]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4308</guid>

					<description><![CDATA[The first value of the Agile Manifesto is about &#8220;individuals and interactions over processes and tools&#8221;. Communication is fundamental inside and outside the Scrum team. In his article &#8220;Watch Your Words: Feedback Analysis&#8221;, Tom Bartel give some hints on how to improve the feedback process especially in a negative context. Tom Bartel presents the concept of feedback based on the example of a new manager that has to deal with a subordinate making mistakes. Using this example, the blog post discusses the problem of conflict avoidance. After a first version of the conversations, the blog post analyzes the things that can be improved and proposed a second version of the same conversation. We can all make a good use of the conclusion of the this blog post: &#8220;This is an act of caring: Taking the time to follow up sends the message that Jared’s development is important to Robert. A good manager is a coach, and a good coach pushes his people.&#8221; Read the full article on https://www.tombartel.de/blog/watch-your-words-feedback-analysis/]]></description>
		
		
		
			</item>
		<item>
		<title>Agile Coaching Exit Strategy</title>
		<link>https://www.scrumexpert.com/knowledge/agile-coaching-exit-strategy/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 06 Mar 2017 18:03:13 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[coaching Agile]]></category>
		<category><![CDATA[people]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4217</guid>

					<description><![CDATA[When do you need to stop coaching an Agile team? In his blog post &#8220;An Exit Strategy for the Agile Coach&#8221;, Len Lagestee discusses this question and explains how he will gradually work to be ready to leave and let the Scrum team be ready to carry the Agile values on its own. Len Lagestee starts providing a definition of his Agile coaching: &#8220;My entire mission as a coach can be summed up by answering one question: How fast can I make myself no longer necessary?&#8221; This is motivated by the urgent need of change by organizations. He shares some of the characteristics that he uses to determine if organizations are gaining agility and resilience: self-healing, taking ownership of the change, experimentation, natural growth and delivering value. The post continues by explaining the process of one of his coaching mission, from the first days to getting close to the end. He explains how he starts by teaching Agile values and principles and being an example when they start applying new techniques like user stories. Then he starts to observe and assess the confidence level of the Scrum team and practice &#8220;just enough coaching&#8221;. Finally, he emphasizes the creation of communities of practices where people can share, learn and grow. His conclusion is that &#8220;If I come back to an organization 6 months after leaving and I wanted to understand how well an organization is doing on their journey, I believe my first questions would be “How are the communities doing? <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/agile-coaching-exit-strategy/" title="Agile Coaching Exit Strategy">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Switching From Scrum to Kanban</title>
		<link>https://www.scrumexpert.com/knowledge/switching-from-scrum-to-kanban/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 06 Feb 2017 17:11:31 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[kanban]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4122</guid>

					<description><![CDATA[Scrum and Kaban are two Agile approaches that could be used in software development, depending also on the context of the software development tools. In his blog post &#8220;Ditching Scrum for Kanban — The best decision we’ve made as a team&#8221;, Grant Ammons shares some thought on why he successfully changed it process from a Scrum to a Kanban perspective. The software development team managed by Grant Ammons first decided to start using Scrum to implement more discipline in its process. Scrum brought some benefits to the team as they start writing light specs and more cooperating with a product manager. The team liked the stand-ups and grooming sessions that kept everyone aligned on the work. The retrospectives also helped adapting the process to the team needs and improving it. However, there were soon also some issues with Scrum. The main one was that it was very hard to plan two weeks of work accurately . The team was mainly overestimating the amount of work it could achieve, which lead to carrying over tasks from the previous sprint to the current one. This was hurting the morale. This is why the team switched to Kaban and removed the sprint goals. This improved the morale and didn&#8217;t hurt the team capacity to deliver. Grant Ammons wrote as a main point &#8220;It turns out that cramming to make sprint deadlines was not the major motivating factor to get work done.&#8221; The conclusion of the blog post is that &#8220;Kanban works well for our team <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/switching-from-scrum-to-kanban/" title="Switching From Scrum to Kanban">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Modifying the Definition of Done</title>
		<link>https://www.scrumexpert.com/knowledge/creating-a-new-definition-of-done/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 23 Jan 2017 16:17:30 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[definition of done]]></category>
		<category><![CDATA[sprint]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=4030</guid>

					<description><![CDATA[Having a good Definition of Done (DoD) might be one of the most important technical asset of a Scrum team. This makes the difference between delivering at the end of the sprint fully completed business features or half-baked software. In his blog post &#8220;Changing the Definition of Done&#8221;, Ken Rubin discusses the situation where a Scrum team might want to change an existing Definition of Done. Ken Rubin starts with the case of a Scrum team that wanted to remove one check from its Definition of Done, because of technical problems that would have prevented them to deliver any results at the end of the sprint. There might always be some issues that could prevent a Scrum team to respect all the items listed in its Definition of Done. Thus the team could be catch the bad habit of taking shortcuts every time it meet a difficulty and Ken Rubin is against weakening the DoD during the sprint. If the issue isn&#8217;t considered a major one, you can always do a sprint review, but you have to fully inform the stakeholder of the items are not fully &#8220;done&#8221;. There is however no problems to make the DoD stronger if the team can do it without jeopardizing the delivery of software. In all cases, Ken Rubin recommends to change to the Definition of Done between the Scrum sprints. His conclusion is that &#8220;The definition of done is an important list of criterion that a Scrum team uses to determine if the <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/creating-a-new-definition-of-done/" title="Modifying the Definition of Done">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Technical Debt Management Future</title>
		<link>https://www.scrumexpert.com/knowledge/technical-debt-management-future/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 24 Oct 2016 14:39:55 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[technical debt]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=3792</guid>

					<description><![CDATA[Technical Debt is defined as the eventual consequences of poor or evolving software architecture and software development within a codebase. In a blog post published for the Software Engineering Institute (SEI), Robert Nord has provided the keys points discussed in a seminar Managing Technical Debt in Software Engineering, an event that discussed both the past and the future of managing technical debt. The International Workshop on Managing Technical Debt is organized every year since 2010. Robert Nord starts by describing the landscape of the technical debt issue, the visible and the invisible parts. The event tried to get a better definition of the core concepts of technical debt, producing a conceptual model. It produced also a vision on how to manage technical debt across different perspectives, like software economics or education. The conclusion of the author is that &#8220;The convergence of efforts on these multiple fronts is necessary to make software development technically and economically sustainable. Otherwise, the friction that slows down the machinery of software evolution will threaten the discipline&#8217;s ability to maintain the code base on which society depends.&#8221; Read the full blog post on https://insights.sei.cmu.edu/sei_blog/2016/08/the-future-of-managing-technical-debt.html]]></description>
		
		
		
			</item>
		<item>
		<title>Story Points Explained</title>
		<link>https://www.scrumexpert.com/knowledge/story-points-explained/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 12 Sep 2016 15:50:00 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[estimating]]></category>
		<category><![CDATA[metrics Agile]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=3688</guid>

					<description><![CDATA[Metrics are an important part of Agile project management approaches like Scrum. One of the most used measures to estimate the amount of work are the story points. In this small article, Pedro Gustavo Torres explains what they are, why you need them and how to use them. Pedro Gustavo Torres provides many definitions of story points. One of them is &#8220;a unitless measure of magnitude for work yet to be done, based on relative sizing.&#8221; He explains also why you should use story points based on the difference between accuracy and precision. He wrote &#8220;Accuracy and precision are not the same thing. Precision is a lot more expensive. Precision is always desired, but accuracy creates more value. However, story points provide sufficient accuracy when working in nondeterministic systems.&#8221; It is very difficult to create a precise time estimate. Story points provide an estimate that is accurate enough to define the effort that should be included in Scrum sprints. With historical data, the team can assess the relationship between time and points. However, story points cannot be related to a specific duration, but rather with a duration interval. Read the complete blog post on https://www.scrumalliance.org/community/articles/2016/february/story-points-explained-the-what-why-and-how]]></description>
		
		
		
			</item>
		<item>
		<title>Scaling with an Agile Leader</title>
		<link>https://www.scrumexpert.com/knowledge/agile-leadership/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 17 May 2016 19:27:54 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[people]]></category>
		<category><![CDATA[scaling Agile]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=3441</guid>

					<description><![CDATA[Using an Agile approach for software development does not necessarily guarantee success. As Henrik Kniberg wrote at the beginning of his blog post &#8221; Even if the entire organization is neatly organized into scrum teams, you can still end up with an unaligned mess!&#8221;. Having an Agile leader can help preventing the unaligned mess. At the beginning of the blog post, Henrik Kniberg explains that you should maybe first try to avoid complexity and search simplicity in your organization. If you cannot simplify, then might need an Agile leader. He defines this role as someone that will focus entirely on coordinating the different teams. He will keep the moving parts in sync and keep an eye on the big picture. If Agile has leadership roles at the team level, there is no formal role when you have multiple teams. Henrik Kniberg provides an example of what an Agile leader will do: 1. What does winning look like? Vision/Mission. 2. What’s the plan? Strategy and tactics. 3. What’s the score? Progress, status, feedback loops 4. What is preventing us from winning? Continous improvement, people, teams, strategy, tactics. The blog post explains then in more details what the Agile leaders do at the budgets and estimates or cross-functional collaboration for instance. The post also discusses what kind of person is suitable for the role. Henrik Kniberg conclusion is that &#8220;I hope this doc helps you improve the success rate of your large multi-team efforts. But don’t forget – scaling is a last <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/agile-leadership/" title="Scaling with an Agile Leader">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>Continuous Improvement Without Blame</title>
		<link>https://www.scrumexpert.com/knowledge/continuous-improvement-without-blame/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 07 Mar 2016 17:06:51 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Blogs]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[retrospective]]></category>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=3273</guid>

					<description><![CDATA[The frontier is somewhat thin between analyzing things for continous improvement in Agile and blaming people for failure. In this blog post, John Allspaw discusses how Etsy wants to consider mistakes, errors, slips or lapses with a perspective of learning. he explains how having blameless post-mortems on outages and accidents are part of this approach. John Allspaw presents the concept of &#8220;Just Culture&#8221; where you make effort to balance safety and accountability. People should be able to give detailed account of problems without fear of punishment or retribution. People can explain why their actions made sense to them at the time, which help to understand the cause of the failure. Here are some of the principles of the &#8220;Just Culture&#8221;: * Encourage learning by having these blameless retrospectives on outages and accidents. The goal is to understand how an accident could have happened, in order to better equip ourselves from it happening in the future * Give people the authority to improve safety by allowing them to give detailed accounts of their contributions to failures. * Encourage people who do make mistakes to be the experts on educating the rest of the organization how not to make them in the future. * Accept that there is always a discretionary space where humans can decide to make actions or not. The conclusion of the article is that &#8220;Failure happens. In order to understand how failures happen, we first have to understand our reactions to failure.&#8221; Read the complete blog post on <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/continuous-improvement-without-blame/" title="Continuous Improvement Without Blame">[...]</a>]]></description>
		
		
		
			</item>
	</channel>
</rss>
