Definition of impediments in SCRUM

Scrum Impediments

Laszlo Szalvay of Danube talking about "impediments" in the context of Scrum:

"In the Scrum method of agile development, a scrum impediment is defined as anything that stands in the way of a team's productivity. This can literally be anything, from a team member who isn't pulling his or her weight to an uncomfortably warm team room. But if it's keeping the team from working at optimal efficiency, it's an impediment.

Luckily, Scrum dedicates an entire role to the resolution of these impediments: the ScrumMaster. The ScrumMaster works in a variety of capacities, such as helping the Product Owner prepare the backlog or radiating Scrum artifacts, but the primary responsibility of a ScrumMaster is to remove scrum impediments and facilitate a highly performing team. To help the ScrumMaster achieve this, the team is responsible for communicating what barriers are impeding their progress. This occurs each day in the daily Scrum, when team members report on their accomplishments for the past 24 hours, goals for the next 24 hours, and what scrum impediments stand in their way. This systematized feedback loop ensures that a ScrumMaster always knows what is keeping the team from success and work to remove them."

Case Study: Fully Distributed Scrum

Fully Distributed Scrum - Agile2009, Schoonheim & Sutherland, Xebia India TBD case | Xebia Blog

Guido Schoonheim shares a case study about "fully distributed scrum". The study describes a project which involved 200 developers, located in India and the Netherlands. You can find the slides at the end of the article, interesting read.

"What is Fully Distributed Scrum?

Offshoring classically is performed in a waterfall process fashion, meaning that one party writes specifications and chucks them over the wall to the other party who then chucks a software product back after a period of time. When evolved to Agile software development, this is the last thing you want to do. However you do need to deal with the distance between your local staff and your talent in an offshore location.

The only way to get the benefits of both Agile development (hyperproductivity with high quality and motivated people) and the benefits of offshoring (lower costs, availability of talent, up/downscaling with no risk) is to apply Agile to the offshoring dilemma. Xebia has made this the core practice and differentiator of our offshored development"

Scrum FAQ

Scrum for Team System - Process Guidance

A good FAQ, should work nicely in combination with "scrum in 5 minutes" by Jeff Sutherland if you want to intend to introduce SCRUM to a team or manager/director who is not familiar with SCRUM yet. Good questions, good answers.

"This Scrum FAQ section contains a transcript of Ken Schwaber answering commonly asked questions about Scrum."

SCRUM training: games and exercises

The Agile Playground | Agile 2009

Tobias Mayer shared some games and exercises at the Agile Conference 2009 which aim at providing a deeper understanding of agile dynamics and principles. Maybe something useful for your next SCRUM workshop?

Estimations: storypoints vs hours

Refactor Your Mind » complexity

Another good posting of Tick Tonoli regarding the reoccuring topic of estimating by using abstract storypoints vs hours. I rarely managed to get the point across, maybe his explanation works better:

"During our estimation (still doing hours effort estimation) we were trying to define the tasks necessary for a story to be completed, however the story had a “task A” that would lead to several “task B’s” that were known, however no-one could (and neither should they be expected to) estimate the hours effort on the “task B’s” simply because the input from “task A” was critical to the timing! Now you’re stuck with tasks that are KNOWN, but cannot be TIMED. And then the light went on and I realized why estimation with time was so bad…You may KNOW everything you need to do (the complexity), however you may not necessarily know how LONG everything will take (the effort), in other words, you know COMPLEXITY but you cannot measure the EFFORT. It now makes sense…"

Dealing with Conflict Avoidance Teams

Agile Blog: Role of Scrum Master - Dealing with Conflict Avoidance Teams

Have you come across teams where only a few speak and the rest listen ?

Have you seen any of your team members not sharing their thoughts or participating well during Scrum meetings, retrospectives or other activities ?

Have you come across any team where there is no conflict ?

Silent Teams
The teams where you don't see conflict, I would call them as "Silent teams" for the sake of this article are silent in speech, but not really silent in their mind. The people in this teams are like any other people but all their questions, frustrations, arguments everything is going only in their mind. They never speak up or discuss things in front of a group, especially if their ideas conflict with others. But there are chances that they go and share their frustrations with some one closer to them in the team during the cafe breaks or with any other close friend.

READY and DONE in SCRUM

The Definition of READY | Xebia Blog

Defining READY

READY is defined by the Definition of READY. It is similar to the Definition of DONE, but with the following differences. Whereas with the Definition of DONE the "supplier" is the Team and the "client" is the Product Owner, it's the other way around with the Definition of READY: the Team is the "client" and the Product Owner is the "supplier". Even though I will detail the Definition of READY later, in the end it boils down to one statement: READY is when the team says: "Ah, we get it".

Even though you can put any precondition in the Definition of READY, the need for a good backlog overshadows all other considerations, so you'll definitely need to address two items: readiness of User Stories, and readiness of the Backlog.

Agile/Scrum and why it works for web user experience

Seven Reasons Why Agile And Scrum Works For Web User Experience | Usability Counts | User Experience, Social Media

I’ve seen Agile work well for products that require constant improvements, but it’s hard to adapt it to a new development unless you have some time to adjust the process while people are learning. Short projects of less than a month make it hard to do a scrum-like process. I can’t imagine using Agile for a hardware-based product.

But for the web where everything is changing, it’s great.

agile best practices | offshore best practices | distributed Scrum

Ignite Outsourcing :: Israeli Scrum conference | agile best practices | offshore best practices | distributed Scrum methodology

When Scrum was first conceived, back in 2001, distributed software development and global teams where not as common as they are today. In this lecture, Aviram Eisenberg elaborates the main contradictions between Agile best practices and offshore best practices, and how can they be combined to create a successful distributed Scrum development methodology

Scrum Checklist

Scrum checklist - Henrik Kniberg's blog

"The main target group for this checklist are teams that are relatively new to Scrum and likely to get many things wrong.

Each item is tagged by priority. I consider the priority 1 items to be pretty fundamental, I'd hesitate to even call it Scrum if a company hasn't implemented all those items (or at least has good reasons not to).

When helping companies implement Scrum I normally start by ensuring that all priority 1 items on the checklist are implemented (or intentionally skipped) before even considering priority 2 and priority 3."

...

Publisher side product owners

Agile Game Development

"Product owners for a video game project using Scrum are usually a member of the development team. The reason for this is that unlike projects outside the game industry, product owners are needed to provide a much higher level of subjective feedback. Does the control of the player feel right? Is a mechanic “fun enough”? This feedback requires daily engagement with the team.

However, in some cases the publisher will require that product ownership be placed in the hands of someone on their staff. This could be an executive producer or someone who works directly with a licensee. In some cases this makes sense. If a licensee wants to maintain oversight or the publisher wants to make sure that their franchise is well tended, then product ownership at the publisher level makes sense.

Unfortunately this usually means that the team loses the day-to-day involvement of product owner. This can lead the project down bad paths. These projects can lead to “iterative and incremental death marches” when there is a reckoning between what the game provides and what the license or franchise owner sees much later.

A solution is to divide up the Product Owner roles..."

Agile Tool Vendors

Wide Awake Developers: Agile Tool Vendors

Agile Tool Vendors
August 08, 2008

There seems to be something inherently contradictory about "Enterprise" agile tool vendors. There's never been a tool invented that's as flexible in use or process as the 3x5 card. No matter what, any tool must embed some notion of a process, or at least a meta-process.

Implementing Scrum: Blog

Scrum Blog -- Implementing Scrum -- Scrum Blog -- Comic Strips and Blog Entries for Scrum, an Agile Software Development Technique.

Implementing Scrum: Blog