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 a series of posts that talk about what a team can do to improve its efficiency, and as a result, improve its velocity (refer previous post). In this post, I will continue with this topic, and provide some more commentary on how to improve the Velocity of a Scrum team.
For many software companies that are in the service industry, I have heard frequent issues from their project managers about how quickly resources can be moved between teams depending on their need (and depending on specific requests from clients for technical capabilities and so on). So, the specific problem from some of the project managers was, that they get people who do not have experience, spend a lot of time in terms of training these younger workers, and when a person is sufficiently trained, many of these people are pulled out when newer projects are unveiled, where the amount of money per person is higher, or where there is a need to ensure that the client is happy with the level of technical expertise you get.
Nothing wrong with that, since it is seen as being in the best interests of the company, but it does have its own byproducts, specifically when the teams are following the Scrum based method of development. Consider that Scrum is different from the traditional development methodologies where the team members are assigned roles, and project manager and leads do the assignment with team members having to follow whatever they are assigned to do.
In Scrum, team members have a much higher amount of responsibility, undertaking to do the task breakdown, estimation, and driving the schedule; the managers in the team are more of coaches and the whole process is not a top driven approach. It takes time for team members to understand the philosophy, takes time for them to learn the processes and to unlearn the waterfall model. So, when the team members are suddenly moved out and new ones are brought in, even training in Scrum is no substitute for experience that one gains by being part of a Scrum team. This can cause havoc to the team members efficiency, and impact heavily their work done in the cycle and the Velocity of the team.

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>