A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

I have been writing about the factors that affect the efficiency of a Scrum team, and how to make improvements in those (refer the previous article). In this post, I will take another topic that can cause a reduction in the efficiency of the Scrum team; so if you can handle this particular aspect, then you will see an improvement in efficiency.
This post talks about the geographic differences between team members and how this impacts the overall productivity of the team. In today’s world where teams can be anywhere, and where there is a huge cost differential by having development teams in lost cost geographies, the amount of complications that can arise due to these geographical distances is immense. The most common scenario that I have seen is the case where the development team is almost entirely based in India, or there are some team members in India, and some in the United States. Further, since it is important that the Product Owner / Product Manager is close to the customer (or in the case of a shrink wrapped product, close to the market), it is typical that the Product Owner is based in the United States (or in other case, in some European country). This can complicate things a lot, especially given the closer relationship between team members in the Scrum development methodology.
The team had adopted Scrum as their method of development, but soon started running into problems. Just doing the Sprint Planning meeting was a logistical nightmare with a time difference of between 12:30 and 13:30 (depending on the time of the year) between the 2 geographical time zones, and even though everybody wanted to cooperate, it was quite obvious that the time difference would lead to people having inconvenient meeting times (and the bigger problem was that Sprint planning meetings are typically expected to last 4 hours or more, where the team would get together and break down the Sprint Backlog items in discrete items that would then need to be estimated). The temptation to rush through the meeting was immense, and this lead to clearly defined cases where user stories were not broken down enough that the estimation turned out to be inaccurate, and this affected the amount of work that got completed during the Sprint cycle vs. the tasks that were committed.
Another major problem was related to the availability of the Product Owner; now it many times expected that things go better if the Product Owner is available when the team members have queries about the work that they are doing; if there are delays in getting these queries answered, it only takes more time to complete the work, and this affects the productivity of the team. We saw that the team was running into a number of such issues which were affecting their productivity.
In the next part of this series, we will talk about some of the steps that were taken to try and improve the productivity of the team and reduce the affect of the issues discussed above.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>