Categories

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.

Learn about Scrum – Why does Scrum fail – Dealing with teams working across differnet geographies, optimization techniques

Scrum by itself is normally not a reason for failure of projects, it is more likely that there is a process implementation issue, or a logistics issue that has caused such failures. In a series of posts, I am trying to post some of incidents and examples that I have seen where the Scrum project has gone through significant challenges, or failed. So, in previous posts, I have the following examples: Sponsors not confident, Not able to empower the team, Problems in Daily Scrum, Team not ready to move to Scrum. In this post, I take another example where there is already a challenge present in terms of cross-geographical differences, and how the intense engagement required during some of the stages caused a problem. Now, if you were to truly dissect this problem, you could see the same problem when you are doing more of a Waterfall, except that in those cases, the deeper level of customer engagement is visible in the beginning of the cycle, and is not needed to that high level as you move ahead in the cycle.
So, what the team did was to take the current mixture of Waterfall and iterative development, with the current Product Manager in another geography that was located at a different timezone with a difference of around 13 hours (basically meaning night-day or day-night). Before the team moved to using Scrum, there were a lot of discussions about going in for the Scrum model, and how it would work for the cross geography connection. One advantage was that it was only the Product Owner who was in a different geography, and so there was less of the logistics of getting the Product Owner for discussions. And this was a Product Owner who had worked with the team in the past in the waterfall based method.
And yet, after the first month or so, inspite of the worries, things were proceeding more or less on the same way that they were in terms of interactions, and all. The problems started emerging after the first Sprint, a time when in the past, the Product Owner would have started reducing the interaction in real time, not needing meetings at common times (since reviews and other evaluations could be done through an offline mode, over email). However, when using Scrum, after the first Sprint, the team again needed intense interactions with the Product Owner for the fresh set of features, and there were issues about managing the logistics, and convincing the Product Owner. One could sense that the Product Owner was making an effort, and by the time of the third Sprint, things started getting more complicated. The Product Owner would push back on the number of discussions required, and also on trying to get a common meeting time. Just setting up those meetings would take more time and effort, and this started showing on the productivity of the team (since they could sense the discomfort of the Product Owner). By the end, the product was delivered, but things had started getting tense and strained.
What could be done ? For the next time, we had long discussions with the Product Owner on the type of interactions, made some compromises regarding the number of meetings per week, pushed the team to stay late once in a while so that 1 meeting could be held at a time convenient for the Product Owner, and that did make things better.

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>