I am working for a company where this is an issue as well. We are trying to use Scrum, but have problems with the following:
If there is an important support issue, we have to drop everything we do to solve that issue, ruining the sprint.
Management comes directly to some developers with specific tasks they want to have done.
Some developers have specific tasks they need to do once in a while (call it support on specific old products)
Sometimes one of the developers are removed from the sprint to do an important installation.
The teams have changed often, based on ideas of improvement from management.
With all these issues it is impossible to do Scrum by the book. The velocity for each sprint is basically worthless when the number of people on the team changes all the time.
Still I have found that you get some benefits:
People work as a team and get inspired & empowered by that.
The tasks that still go through the sprint are better than if Scrum/sprinting is not used at all, as the feedback cycle is so much shorter than when not doing sprints. The concensus now is that two weeks is a good time.
Over time the velocity seems to average out after all, giving at least the ability for management to have an idea of how much work can be done over a longer period of time.
My suggestion is therefore to go for Scrum. As in my company, when management and the developers start to see some of the benefits of short cycles etc, they will start to make changes so that more of the work that is considered not a sprint task will be made into a sprint task after all. So I still see benefits of trying to do Scrum. There is no 100% correct way to do Scrum anyway, no matter how hard some books claim there is.
Define a focus factor, the ratio of time each developer can work on the Sprint content only. This focus factor accounts for the time you cannot work on the Sprint items (email, support, meetings ...).
At the Sprint Planning, only plan what can be achieved according to that focus factor: if the Team has 600 hours at 80%, you'll only plan 480 hours.
The initial value can be decided arbitrarily or based on what was achieved during the previous Sprint: 60 days planned and 45 days complete gives a focus factor of 75%.
Then it's all about time management, if the non-Scrum tasks are not interruptions, then it's better to have them at the same time (e.g. on Friday, every members of the team work on these other tasks, non on the Sprint tasks).
This focus factor does not need to be identical for every member of the team. This also allows having part-time member in a Team.
In our team we have support tasks included in the sprint. For each sprint we make an estimate how much support time each of the products are likely to need, and add those as tasks in the sprint. That way the sprint doesn't suffer, unless the support demand is a lot higher than expected (which, of course, may affect the time reserved for support in upcoming sprints).
There are many approaches for scrum, honestly I haven't seen one company that do "pure" scrum. If you will be able to organize your scrum well you may have profits from this. But you should think why you want to change your process to scrum, maby it's pointless.
I think you should try scrum and see if it was worth it.
Although I have not the biggest mileage with SCRUM but the general rule is that when SCRUM is not working as well as it should it is usually because the sprint is too focused and the team has many tasks-responsibilities that extend beyond the sprint`s scope that are not taken into account. As such these tasks are then perceived as nuisance by team inside scrum and scrum perceived as nuisance by people left outside.
We have not yet tried SCRUM all out, however I did a few experiences here on many ways it could be implemented and the best results were when the team included people from many departments (Test, QA, Implementation, Dev, Architecture, Marketing). This implies that these persons are not full time in the team but the fact that they have tasks assigned to them in the scope of the current project means that they are usually more willing to spend the time on it.
Next biggest benefits is that it is possible to set aside some buffer time for unknowns such as spurious but critical support dev. When these occur a smaller team forms up and temporarily spins off from the main scrum to deal with the issue.
Finally things like installations, configurations etc are part of the scrum and as such are tallied with it.
Another approach that I will try next is to extend the idea so that instead of the one scrum-to-rule-them-all approach I will try to get smaller teams in place for each specific needs. The main problem with this for now is that not many people can assume the role of scrum master so right not it`s more chicken and egg.
On a more general note, I used SCRUM here but I never apply things by the book. I consider these techniques and approaches as idea buckets to draw from and experiment with to get the best possible match for our needs. However for this experimentation to work it sometimes have to be done subversively (you do scrum but never formalize that you do it). I find it the best way to soften them up to adopt new approaches and to cut more easily through the inherent change resistance we always confront ourselves with.
So far, by doing this, the workflow naturally evolves towards scrum-XP-agile-TDD type and slowly get them to shun the dreadful cascade they are so encroached in. Hopefully, in time they will realize that the grass is so much greener on my side of the fence :-)
Efficiency comes from being able to focus on the tasks included in the sprint. It is not something another development model can work around. But developers being assigned 'other tasks' are still a reality, such as support, training, or technical pre-sales.
Support is inherently unplannable for most places. Training and pre-sales tend to be somewhat time-boxed, as in "Mr X spends N days with customer".
I suggest you try to divide the developers into two or more teams. Have the task of taking support during this sprint cycle between teams. That team should only have tasks that one can afford failing to meet. It should do its best to solve support issues without interrupting other teams.
We've seen good results with this.
Knowledge is spread whenever there is something the support team doesn't know, it gather info from other teams. The support team is still the team that respond to the support tickets, and learn while doing it.
The non-support teams can work much more focused on their tasks. Not having to switch tasks is very productive.
Actual time spent on support and unplanned events is given a number in hours spent on it.
It sounds like the management described aren't really on the boat with scrum. I suggest very short sprints, 1 week or so. So whenever you get a sales person or management wanting to interrupt, try them if they can wait to get their thing through and done for the next sprint that is just less than a week away. Scrum should not be something the developers are doing alone. It needs to be in the whole chain out to the customer.
I don't see how Scrum doesn't allow part timers? I have been on many scrum teams and we almost always have a resource that is not full time. Or we have a resource that is split between a couple of projects. We manage this by having the developer dedicate a specified amount of time to the project and we plan around that allotted time. Most agile project management solutions allow this style of resource management.
Very good question indeed. I have seen this statement "all members must be full-time" in almost every paper, article, book etc. I have red on Scrum but yet I haven't seen any argument to why this has to be the case. In large organizations I would expect that you will have developers that do nothing else, but in small organizations it must be very common to have developers that can't commit 100% to the sprint and Scrum is designed for small teams! The focus factor should be able to handle this just as anything else.
Where I work we have had developers get pulled off project for things like support requests or the team lead has meetings about other projects so there are times where someone gets to say, "Non-project," so it is communicated that this person isn't currently contributing to the Sprint.
发布评论
评论（9）
我在一家公司工作，这也是一个问题。 我们正在尝试使用 Scrum，但存在以下问题：
由于存在所有这些问题，不可能按照书本进行 Scrum。 当团队中的人数一直在变化时，每次冲刺的速度基本上毫无价值。
尽管如此，我仍然发现你可以获得一些好处：
因此，我的建议是采用 Scrum。 就像在我的公司一样，当管理层和开发人员开始看到短周期等的一些好处时，他们将开始做出改变，以便更多被认为不是冲刺任务的工作毕竟会变成冲刺任务。 所以我仍然看到尝试使用 Scrum 的好处。 无论如何，没有 100% 正确的 Scrum 方法，无论有些书声称有多么困难。
I am working for a company where this is an issue as well. We are trying to use Scrum, but have problems with the following:
With all these issues it is impossible to do Scrum by the book. The velocity for each sprint is basically worthless when the number of people on the team changes all the time.
Still I have found that you get some benefits:
My suggestion is therefore to go for Scrum. As in my company, when management and the developers start to see some of the benefits of short cycles etc, they will start to make changes so that more of the work that is considered not a sprint task will be made into a sprint task after all. So I still see benefits of trying to do Scrum. There is no 100% correct way to do Scrum anyway, no matter how hard some books claim there is.
定义焦点因素，即每个开发人员仅处理 Sprint 内容的时间比例。 这个焦点因素说明了您无法处理 Sprint 项目（电子邮件、支持、会议...）的时间。
在 Sprint 计划中，仅计划根据该焦点因素可以实现的目标：如果团队有 600 小时的 80%，那么您将只计划 480 小时。
初始值可以任意确定，也可以根据上一个 Sprint 期间取得的成果来确定：计划 60 天，完成 45 天，聚焦因子为 75%。
然后就是时间管理，如果非 Scrum 任务不会被打扰，那么最好让它们同时进行（例如，周五，团队的每个成员都处理这些其他任务，而不是 Sprint 任务）。
对于团队中的每个成员来说，这个焦点因素不需要相同。 这也允许团队中有兼职成员。
Define a focus factor, the ratio of time each developer can work on the Sprint content only. This focus factor accounts for the time you cannot work on the Sprint items (email, support, meetings ...).
At the Sprint Planning, only plan what can be achieved according to that focus factor: if the Team has 600 hours at 80%, you'll only plan 480 hours.
The initial value can be decided arbitrarily or based on what was achieved during the previous Sprint: 60 days planned and 45 days complete gives a focus factor of 75%.
Then it's all about time management, if the non-Scrum tasks are not interruptions, then it's better to have them at the same time (e.g. on Friday, every members of the team work on these other tasks, non on the Sprint tasks).
This focus factor does not need to be identical for every member of the team. This also allows having part-time member in a Team.
在我们的团队中，我们的冲刺中包含支持任务。 对于每个冲刺，我们都会估计每个产品可能需要多少支持时间，并将这些时间添加为冲刺中的任务。 这样，冲刺就不会受到影响，除非支持需求远高于预期（当然，这可能会影响为即将到来的冲刺提供支持的时间）。
In our team we have support tasks included in the sprint. For each sprint we make an estimate how much support time each of the products are likely to need, and add those as tasks in the sprint. That way the sprint doesn't suffer, unless the support demand is a lot higher than expected (which, of course, may affect the time reserved for support in upcoming sprints).
Scrum 有很多种方法，老实说，我还没有见过一家公司做“纯粹”的 Scrum。 如果您能够很好地组织您的 scrum，您可能会从中获利。
但你应该想想为什么要把你的流程改成scrum，也许这是没有意义的。
我认为你应该尝试一下 scrum，看看是否值得。
There are many approaches for scrum, honestly I haven't seen one company that do "pure" scrum. If you will be able to organize your scrum well you may have profits from this.
But you should think why you want to change your process to scrum, maby it's pointless.
I think you should try scrum and see if it was worth it.
虽然我对 SCRUM 的了解并不多，但一般规则是，当 SCRUM 无法正常工作时，通常是因为 sprint 过于集中，并且团队有许多任务职责超出了 sprint 的范围那些没有被考虑在内。 因此，这些任务会被 scrum 内部的团队视为麻烦，而 scrum 则被外部人员视为麻烦。
我们还没有全面尝试 SCRUM，但是我在这里就其实施的多种方式进行了一些经验，最好的结果是当团队包含来自多个部门（测试、QA、实施、开发、架构、营销）的人员时。 这意味着这些人不是团队中的全职成员，但事实上，他们在当前项目范围内分配了任务，这意味着他们通常更愿意花时间在上面。
下一个最大的好处是可以为未知因素（例如虚假但关键的支持开发人员）留出一些缓冲时间。 当这些情况发生时，会组建一个较小的团队，并暂时从主要 Scrum 中分离出来来处理问题。
最后，安装、配置等都是 scrum 的一部分，因此与之相关。
接下来我将尝试的另一种方法是扩展这个想法，这样我将尝试组建更小的团队来满足每个特定的需求，而不是采用 scrum-to-rule-the-all 的方法。 目前的主要问题是没有多少人能够承担 Scrum Master 的角色，所以这不是先有鸡还是先有蛋的问题。
更一般地说，我在这里使用了 SCRUM，但我从不按书本应用事情。 我认为这些技术和方法是可以借鉴和试验的想法桶，以获得最适合我们需求的方案。 然而，为了让这个实验发挥作用，有时必须以颠覆性的方式进行（你进行 Scrum，但从未正式表明你这样做）。 我发现这是软化它们以采用新方法并更轻松地消除我们始终面临的固有变革阻力的最佳方法。
到目前为止，通过这样做，工作流程自然地向 scrum-XP-agile-TDD 类型发展，并慢慢地让他们避开他们所陷入的可怕的级联。希望他们及时意识到，草更绿了我这边的栅栏:-)
Although I have not the biggest mileage with SCRUM but the general rule is that when SCRUM is not working as well as it should it is usually because the sprint is too focused and the team has many tasks-responsibilities that extend beyond the sprint`s scope that are not taken into account. As such these tasks are then perceived as nuisance by team inside scrum and scrum perceived as nuisance by people left outside.
We have not yet tried SCRUM all out, however I did a few experiences here on many ways it could be implemented and the best results were when the team included people from many departments (Test, QA, Implementation, Dev, Architecture, Marketing). This implies that these persons are not full time in the team but the fact that they have tasks assigned to them in the scope of the current project means that they are usually more willing to spend the time on it.
Next biggest benefits is that it is possible to set aside some buffer time for unknowns such as spurious but critical support dev. When these occur a smaller team forms up and temporarily spins off from the main scrum to deal with the issue.
Finally things like installations, configurations etc are part of the scrum and as such are tallied with it.
Another approach that I will try next is to extend the idea so that instead of the one scrum-to-rule-them-all approach I will try to get smaller teams in place for each specific needs. The main problem with this for now is that not many people can assume the role of scrum master so right not it`s more chicken and egg.
On a more general note, I used SCRUM here but I never apply things by the book. I consider these techniques and approaches as idea buckets to draw from and experiment with to get the best possible match for our needs. However for this experimentation to work it sometimes have to be done subversively (you do scrum but never formalize that you do it). I find it the best way to soften them up to adopt new approaches and to cut more easily through the inherent change resistance we always confront ourselves with.
So far, by doing this, the workflow naturally evolves towards scrum-XP-agile-TDD type and slowly get them to shun the dreadful cascade they are so encroached in. Hopefully, in time they will realize that the grass is so much greener on my side of the fence :-)
效率来自于能够专注于冲刺中包含的任务。 这不是其他开发模式可以解决的问题。 但开发人员被分配“其他任务”仍然是现实，例如支持、培训或技术售前。
对于大多数地方来说，支持本质上是无法计划的。 培训和售前往往有一定的时间限制，如“X 先生与客户共度 N 天”。
我建议你尝试将开发人员分成两个或更多团队。 任务是在团队之间的冲刺周期中获取支持。 该团队应该只承担无法完成的任务。 它应该尽力解决支持问题而不打扰其他团队。
我们已经看到了良好的结果。
听起来所描述的管理层并不真正喜欢 Scrum。 我建议非常短的冲刺，1 周左右。 因此，每当销售人员或管理层想要打断他们时，如果他们可以等待完成他们的事情并为距离不到一周的下一个冲刺完成，请尝试他们。 Scrum 不应该是开发人员单独做的事情。 它需要在整个链条中传递给客户。
Efficiency comes from being able to focus on the tasks included in the sprint. It is not something another development model can work around. But developers being assigned 'other tasks' are still a reality, such as support, training, or technical pre-sales.
Support is inherently unplannable for most places. Training and pre-sales tend to be somewhat time-boxed, as in "Mr X spends N days with customer".
I suggest you try to divide the developers into two or more teams. Have the task of taking support during this sprint cycle between teams. That team should only have tasks that one can afford failing to meet. It should do its best to solve support issues without interrupting other teams.
We've seen good results with this.
It sounds like the management described aren't really on the boat with scrum. I suggest very short sprints, 1 week or so. So whenever you get a sales person or management wanting to interrupt, try them if they can wait to get their thing through and done for the next sprint that is just less than a week away. Scrum should not be something the developers are doing alone. It needs to be in the whole chain out to the customer.
我不明白为什么 Scrum 不允许兼职？ 我曾加入过许多 Scrum 团队，但我们几乎总是拥有非全职资源。 或者我们有一个资源被分配给几个项目。 我们通过让开发人员为项目投入指定的时间来管理这一点，并围绕分配的时间进行计划。 大多数敏捷项目管理解决方案都允许这种类型的资源管理。
I don't see how Scrum doesn't allow part timers? I have been on many scrum teams and we almost always have a resource that is not full time. Or we have a resource that is split between a couple of projects. We manage this by having the developer dedicate a specified amount of time to the project and we plan around that allotted time. Most agile project management solutions allow this style of resource management.
确实是很好的问题。 我几乎在每一篇论文、文章、书籍等中都看到过这样的说法“所有成员必须是全职的”。我对 Scrum 持红色态度，但我还没有看到任何争论为什么必须如此。 在大型组织中，我希望开发人员不做其他事情，但在小型组织中，开发人员不能 100% 投入到冲刺中一定很常见，而 Scrum 是为小型团队设计的！ 焦点因素应该能够像处理其他事情一样处理这个问题。
Very good question indeed. I have seen this statement "all members must be full-time" in almost every paper, article, book etc. I have red on Scrum but yet I haven't seen any argument to why this has to be the case. In large organizations I would expect that you will have developers that do nothing else, but in small organizations it must be very common to have developers that can't commit 100% to the sprint and Scrum is designed for small teams! The focus factor should be able to handle this just as anything else.
在我工作的地方，开发人员因支持请求等问题而退出项目，或者团队负责人召开有关其他项目的会议，因此有时有人会说“非项目”，因此会传达出此人不是“项目”。目前正在为 Sprint 做出贡献。
Where I work we have had developers get pulled off project for things like support requests or the team lead has meetings about other projects so there are times where someone gets to say, "Non-project," so it is communicated that this person isn't currently contributing to the Sprint.