Explained to management that a plan (which intends to predict the future) is simply fluff, vapor, a list of assumptions without a factual basis.
Planned a list of sprints. Wrote a burndown chart. Forgot to put in summary estimates.
Started executing on the list of sprints.
After the first two or three, management started to realize that the "plan" was just a burndown list, with no "dates", "risks", "assumptions" or anything like a traditional waterfall project plan.
At this point, of course, it's too late. We've already completed one sprint and are most of the way through the second. The horse is out of the barn. The bell was already rung.
So management demands some stuff.
The total budget. We said "Add up the sprints that are important to you. Just draw a random line, anywhere you're happy. That's your budget." No one likes this, because it's too much control. "How can you justify that?" they asked. "Easy. We build in priority order until you cancel the project."
What we did have to add was a tentative duration for each sprints. Ours are of variable size: 2 to 4 weeks. A list of 10 sprints was about 26 weeks -- 6 months. After that, we stopped putting down numbers.
The list of "assumptions". We just refused this. "Write your own". They couldn't think of any on their own. That was that.
The list of "risks". Again, we asked what scared them. If they were bothered by something, then perhaps they should change the priority in the burndown to address that.
A due date. We turned this around and asked them to prioritize the burndown around dates and budgets and risks that were important to them. We didn't much care what order -- it's their call as managers.
After two more sprints, they stopped making "waterfall" requests and started prioritizing and managing the burndown.
Interestingly, they never asked about scope creep. Managers who ask "how do you control scope?" are actively rejecting incremental development. They're trying not to get it.
When managers want to know how Agile methods "prevent" scope creep, they're (a) labeling the learning process as "creep" (which is bad) and (b) resisting the idea that learning leads to scope changes. The only way you even have scope "creep" is when you commit to a specific scope irrespective of any learning that may happen. Agile methods only commit to a next sprint, not a comprehensive scope. If you don't commit to a scope, it can't creep because it doesn't exist.
I'm in the process of trying to do this right now. We've got an on-site Customer Development department and I can tell you they are key in trying to grab buy-in for an iterative development process.
If you've already got a track record of delivering projects late and over budget due to large and unmanageable chunks not getting done, that's a good start in convincing the stakeholders of your projects to get the ball of change rolling.
Process can prove itself, but only with the right parties in support of it. Your key is getting other team players to see value in what you're trying to do.
For us, it comes down to approaching things from a customers perspective. We need to constantly come back to the customer to make sure that what we're building is what they envision. We want to streamline the process to stop wasting everyone's time.
Now of course, different parts of Agile work for different organizations and very few companies that actually use Agile processes are doing so in a purist sense.
Through trial and error figure out what works for your business, culture and team. There is nothing that says you can't gradually adopt the overall process and cherry pick the parts that work the best for your business model.
From my (admittedly limited) experience, make sure that all your programmers are involved with the decision to switch to Agile/Scrum/whatever, and that they're all in favor of it - or at least not going to actively oppose it. I've seen resistance from team members when Agile/Scrum was perceived to be mandated from above without their consent/input. It's hard enough to retrain managers without having to constantly convince your team as well.
Around here it started with one team who wanted to go ahead and be more Agile using Scrum. This team was the "pilot team" and went for a few sprints (3 months). They were coached by someone from the inside who was already reading and learning about Scrum. Doing a "pilot" instead of a complete switchover helped to gain acceptance from management and refractive team members.
Having a "let's try it" attitude really help to get customers into the process also (internal customers here, but customers none the less).
And to make it stick, you have to take note of the progress made and the advantages it brings to you and your team (it can be better performance, better communication with team members/customers, better results, happier customers, etc.)
发布评论
评论（6）
您可能对无畏变革：引入新想法的模式一书感兴趣林恩·曼斯和琳达·瑞辛。 它是将敏捷方法引入组织的经验概要。
You may be interest in the book Fearless Change: Patterns for Introducing New Ideas by Lynn Manns and Linda Rising. It is a compendium of experience in introducing agile methods into organizations.
我们所做的：
向管理层解释计划（旨在预测未来）只是无稽之谈，是一系列没有事实依据的假设。
计划了一个冲刺列表。 写了燃尽图。 忘记输入摘要估计。
开始在冲刺列表上执行。
在前两三个之后，管理层开始意识到“计划”只是一个燃尽清单，没有“日期”、“风险”、“假设”或任何类似于传统瀑布项目计划的内容。
当然，此时已经太晚了。 我们已经完成了一个冲刺，并且已经完成了第二个冲刺的大部分工作。 马已经出了马厩了。 铃声已经响了。
所以管理层需要一些东西。
总预算。 我们说“把对你来说很重要的冲刺加起来。只要在你满意的地方画一条随机线。这就是你的预算。” 没有人喜欢这样，因为它的控制力太大。 “你怎么能证明这一点呢？” 他们问过。 “简单。我们按优先顺序建造，直到你取消该项目。”
我们必须添加的是每个冲刺的暂定持续时间。 我们的尺寸不同：2 至 4 周。 10 个冲刺的列表大约需要 26 周——6 个月。 此后，我们不再写数字。
“假设”列表。 我们只是拒绝了这一点。 “自己写”。 他们自己想不出任何办法。 就是这样。
“风险”列表。 我们再次询问他们害怕什么。 如果他们被某些事情困扰，那么也许他们应该改变燃尽图的优先级来解决这个问题。
截止日期。 我们扭转了局面，要求他们优先考虑对他们来说重要的日期、预算和风险。 我们不太关心什么订单——这是他们作为经理的决定。
经过两次冲刺后，他们停止提出“瀑布”请求，并开始优先考虑和管理燃尽。
有趣的是，他们从未询问过范围蔓延的问题。 经理们会问“你如何控制范围？” 积极拒绝增量开发。 他们试图不得到它。
当管理者想知道敏捷方法如何“防止”范围蔓延时，他们（a）将学习过程标记为“蔓延”（这是不好的），并且（b）抵制学习导致范围变化的想法。 范围“蠕变”的唯一方法是，无论可能发生什么学习，都致力于特定的范围。 敏捷方法只致力于下一个冲刺，而不是全面的范围。 如果你不承诺一个范围，它就不会蔓延，因为它不存在。
What we did:
Explained to management that a plan (which intends to predict the future) is simply fluff, vapor, a list of assumptions without a factual basis.
Planned a list of sprints. Wrote a burndown chart. Forgot to put in summary estimates.
Started executing on the list of sprints.
After the first two or three, management started to realize that the "plan" was just a burndown list, with no "dates", "risks", "assumptions" or anything like a traditional waterfall project plan.
At this point, of course, it's too late. We've already completed one sprint and are most of the way through the second. The horse is out of the barn. The bell was already rung.
So management demands some stuff.
The total budget. We said "Add up the sprints that are important to you. Just draw a random line, anywhere you're happy. That's your budget." No one likes this, because it's too much control. "How can you justify that?" they asked. "Easy. We build in priority order until you cancel the project."
What we did have to add was a tentative duration for each sprints. Ours are of variable size: 2 to 4 weeks. A list of 10 sprints was about 26 weeks -- 6 months. After that, we stopped putting down numbers.
The list of "assumptions". We just refused this. "Write your own". They couldn't think of any on their own. That was that.
The list of "risks". Again, we asked what scared them. If they were bothered by something, then perhaps they should change the priority in the burndown to address that.
A due date. We turned this around and asked them to prioritize the burndown around dates and budgets and risks that were important to them. We didn't much care what order -- it's their call as managers.
After two more sprints, they stopped making "waterfall" requests and started prioritizing and managing the burndown.
Interestingly, they never asked about scope creep. Managers who ask "how do you control scope?" are actively rejecting incremental development. They're trying not to get it.
When managers want to know how Agile methods "prevent" scope creep, they're (a) labeling the learning process as "creep" (which is bad) and (b) resisting the idea that learning leads to scope changes. The only way you even have scope "creep" is when you commit to a specific scope irrespective of any learning that may happen. Agile methods only commit to a next sprint, not a comprehensive scope. If you don't commit to a scope, it can't creep because it doesn't exist.
根据我的经验，团队转型不是问题。 这是管理的转变。
In my experience, transitioning the team isn't the problem. It's transitioning management.
我现在正在尝试这样做。 我们有一个现场客户开发部门，我可以告诉您，他们是争取迭代开发过程支持的关键。
此处对此问题有一些很好的答案。
如果您已经有过由于无法完成大量难以管理的工作而导致项目延迟交付和超出预算的记录，那么这是说服项目的利益相关者推动变革的良好开端。
流程可以证明自己，但前提是有合适的各方支持。 你的关键是让其他团队成员看到你正在尝试做的事情的价值。
对我们来说，归根结底是从客户的角度来处理事情。 我们需要不断地回馈客户，以确保我们正在构建的产品符合他们的设想。 我们希望简化流程，以停止浪费每个人的时间。
当然，现在敏捷的不同部分适用于不同的组织，并且很少有真正使用敏捷流程的公司是在纯粹的意义上这样做的。
通过反复试验找出适合您的业务、文化和团队的方法。 没有什么说你不能逐渐采用整个流程并挑选最适合你的业务模式的部分。
I'm in the process of trying to do this right now. We've got an on-site Customer Development department and I can tell you they are key in trying to grab buy-in for an iterative development process.
Some great answers on this one here.
If you've already got a track record of delivering projects late and over budget due to large and unmanageable chunks not getting done, that's a good start in convincing the stakeholders of your projects to get the ball of change rolling.
Process can prove itself, but only with the right parties in support of it. Your key is getting other team players to see value in what you're trying to do.
For us, it comes down to approaching things from a customers perspective. We need to constantly come back to the customer to make sure that what we're building is what they envision. We want to streamline the process to stop wasting everyone's time.
Now of course, different parts of Agile work for different organizations and very few companies that actually use Agile processes are doing so in a purist sense.
Through trial and error figure out what works for your business, culture and team. There is nothing that says you can't gradually adopt the overall process and cherry pick the parts that work the best for your business model.
根据我（诚然有限）的经验，请确保所有程序员都参与了转向敏捷/Scrum/其他方式的决定，并且他们都赞成它 - 或者至少不会积极反对它。 当敏捷/Scrum 被认为是在未经团队成员同意/意见的情况下由上层强制执行时，我看到了团队成员的抵制。 如果不不断说服你的团队，对经理进行再培训就已经够困难的了。
From my (admittedly limited) experience, make sure that all your programmers are involved with the decision to switch to Agile/Scrum/whatever, and that they're all in favor of it - or at least not going to actively oppose it. I've seen resistance from team members when Agile/Scrum was perceived to be mandated from above without their consent/input. It's hard enough to retrain managers without having to constantly convince your team as well.
在这里，它始于一个想要继续使用 Scrum 并变得更加敏捷的团队。 这个团队是“试点团队”，进行了几次冲刺（3个月）。 他们接受了内部人员的指导，而该人员已经在阅读和学习 Scrum。 进行“试点”而不是完全转换有助于获得管理层和屈光团队成员的认可。
拥有“让我们尝试一下”的态度也确实有助于让客户参与这个过程（这里是内部客户，但仍然是客户）。
为了坚持下去，你必须注意所取得的进展以及它给你和你的团队带来的优势（可以是更好的绩效、与团队成员/客户更好的沟通、更好的结果、更满意的客户等）
Around here it started with one team who wanted to go ahead and be more Agile using Scrum. This team was the "pilot team" and went for a few sprints (3 months). They were coached by someone from the inside who was already reading and learning about Scrum. Doing a "pilot" instead of a complete switchover helped to gain acceptance from management and refractive team members.
Having a "let's try it" attitude really help to get customers into the process also (internal customers here, but customers none the less).
And to make it stick, you have to take note of the progress made and the advantages it brings to you and your team (it can be better performance, better communication with team members/customers, better results, happier customers, etc.)