Tomb Raider: Underworld post mortem

Gamasutra - Features - Postmortem: Crystal Dynamics' Tomb Raider: Underworld

Very interesting article, mostly because Eric Lindstrom mentions a couple of good examples of anticipated risks which nevertheless became reality, regardless of mitigation efforts.

"It is particularly interesting to note that much of what went wrong in development involved pitfalls that we anticipated but still fell into despite our efforts to avoid them. It's important to note that most postmortems talk about "What Went Wrong" and not just "What We Did Wrong" because sometimes you make mistakes, but other times you suffer from acts of god and do your best to cope.

A Game Developer article last year ("What Went Wrong?" December 2008) specifically questioned why game development seems to make the same mistakes over and over. In light of that, some of the "wrongs" will be discussed in terms of how our methods to avoid known issues fell short."

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"