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?

Help for Product Owners: Prioritizing the backlog

First Things First: Prioritizing Requirements

Karl Wiegers provides some advice on the topic of prioritizing the backlog and he throws in a spreadsheet for free as well:

"Customers are never thrilled to find out they can’t get all the features they want in release 1.0 of a new software product (at least, not if they want the features to work). However, if the development team cannot deliver every requirement by the scheduled initial delivery date, the project stakeholders must agree on which subset to implement first. Any project with resource limitations has to establish the relative priorities of the requested features, use cases, or functional requirements. Prioritization helps the project manager resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions."

You can find his spreadsheet here.

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…"

Game developer locations

For those who are looking for a nice index of game development related companies which are located in the UK:
UK game developer locations

And here is global map of "all" game development studios:
http://www.gamedevmap.com

Affinity Estimation-when there are a lot of stories to be estimated

I came across Rick Tonoli`s Blog and found a couple of very interesting articles. Still working my way through his postings, i'll praise him later in a separate article after covering his and other opinions on the topic of "affinity estimation". I didnt apply it myself, but it does sound like a good approach to get a high level estimation done without wasting too much time.

He is refering to Kane Mar's blog who in return references to Jukka Lindström who posted his comment here. I would love to test it as it sounds very intuitive. A might be more suitable for a pretty senior team, but then again, what isn't...

Here is Kane Mar's comment on it:
"We started by reading out each Story to the entire team. Lowell then asked us to arrange the stories horizontally on a wall in order of size, without talking. We placed the largest stories on the left and the smallest stories on the right. This only took a few minutes. We were then given a final opportunity to make adjustments to the ordering, again without talking.
 
...
Finally, “Affinity Estimating” helps make estimating a positive experience rather than a confrontational one. The next time you have a need to estimate a large number of User Stories, consider trying “Affinity Estimating."

Sounds like it could also be an interesting tool for team(member)s that struggle to speak their mind or or have problems with confrontations. Ball-parking new projects should/could be simpler as well.

You can find a more detailed description about how it works here.

Scalability: best practices

13 Scalability Best Practices | High Scalability

The guys at http://highscalability.com released a list of 13 best practices about scaleability, check out their website if you want to know more about it and check the comments as well. Here are their top three:

AFK Partners has release what they feel are the Best Practices for Scalability:
1. Asynchronous - Use asynchronous communication when possible.
2. Swim Lanes – Create fault isolated “swim lanes” of hardware by customer segmentation.
3. Cache - Make use of cache at multiple layers.

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