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.

Delivering to multiple clients – need to deliver through the Sprint rather than one deliverable at the end

We all learn things as we see stuff happening, and one of the items that I learnt was about a team that had changed to using the Scrum model of development, and was learning how to deal with multiple clients. Consider the case of large software companies such as Microsoft, Apple, and many others, where there are many different groups working on different products. However, the products that they are working on have many common needs, such as code for showing UI, code for handling calls to various media items such as disk drives, CD devices, cameras, etc. It does not make sense for separate teams to write their own code for such handling, and hence it is far more feasible for there to be a single team that works on developing these technologies, and the output of these common teams is used by the various product teams.
One of the biggest problems faced by such common teams (or we can call them technology teams) is their need to match their output schedule to the schedules of the various product teams, and this is something that remains in flux. Different products have their own schedules (with these typically not being very flexible, since there could be the need to meet a specific timeline such as having a new version of the product ready for Christmas, or to be available to meet the perception of financial analysts, or to thwart the release of a competitive product, and so on). So, the common situation is that when the technology team starts interactions with the various product teams (and we can call them the client teams), they are presented with schedules that do not seem to easily integrate with each other. One team may want a specific release near the end of a month, while for another group, there is a ‘drop dead’ need to have specific features in by the middle of the month. Reconciling them is easy if one of the teams is much stronger in terms of influence, since then the schedule will be driven by the more powerful team. However, when this is not the case, then the release timelines can get difficult.
There was one such team that was run by a colleague of mine. His team used to work on the traditional waterfall, and that was a disaster zone since they had to forever be ready to release for some team or the other. After much consultation, the team decided that a Scrum model would work better, especially since they could time the length of their Sprints, and have software available in a fairly good state at the end of every Sprint. So, they worked out a Sprint schedule whereby they worked out a Product Owner, and all requests needed to go through the Product Owner, and the time period of every Sprint was 4 weeks.
However, by the start of the second Sprint itself, it became clear that 4 weeks was just not making it. They had expectations from client teams that would just not work based on a release every 4 weeks (for example, there was a team that was very near release, and needed quick support for bug fixes – so they needed a turnaround time of a week for getting a new release that fixed bugs; the monthly cycle would just not work for them).
The technology team did an evaluation, and really did not want to move away from the 4 week sprint cycle (they felt that they were not mature enough in Scrum to try and handle a Sprint cycle of 1-2 weeks, and wanted to ensure that their team got a month to work and release features). Eventually, they came out with a solution that seemed complicated, but that seemed to work. They would still work on a 4 week Sprint cycle, but added some additional tasks to the Sprint backlog for coordinating a weekly release. This required some dedicated coordination from the ScrumMaster and some team members and went through some additional challenges, but after around a month, they were able to do this in a way that met the needs of the client teams. The team would ensure that when tasks were added for the Sprint backlog, there was an effort to time the expected output of the tasks, and then testing was added so that at the end of every week, a release was possible with a high level of quality. One could call this as saying that they had moved to a Sprint cycle of 1 week, but this was not true, specifically when it came to planning for the Sprint (that was done one a monthly basis).

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>