Though there are many ideas on how to implement scrum within an organization, starting with one team is certainly a consistent thread. So good work on starting that way. From there find someone with experience in implementing agile. A contractor, a colleague, or advice at meetup groups. Here's a link to one I have attended in the DC area - http://groups.google.com/group/dcnova-scrum-user-group
From there, my opinion is to adapt scrum to your team. It's size, it's need for adjustment, etc. Everyone has opinions, but if your team doesn't buy it, it's not worth it. Don't take that as a license to cut things from scrum. Keep the daily standups, the commitment, the retrospectives, the demo (etc), but adjust the size of the sprint, etc.
I recently saw a compelling presentation that advocated implementing pieces of scrum/agile as the team/business was ready. See this gentelman's site for details - http://www.dragile.com/
A big key is to not get lazy - do scrum. And have a high standard. If you're going to go it alone (which can be dangerous) - read your heart out. Read examples, talk to others, go to meetups, etc. Don't let your inexperience in scrum sour your team to it.
In my experience with learning to manage a team using agile there are two critical components to making agile/scrum work. I think that Jody's point about not being lazy is really important, with the more free-flowing work pattern of agile it can be easy to succumb to skipping meetings or other such nonsense.
Get a good web based task tracker. This allows developers to login and see what they need to do and will help track progress. I've been very happy with Pivotal Tracker (www.pivotaltracker.com). Of course the tracker is only worthwhile if you actually keep it up to date, which leads me to point two.
Having meetings EVERY day. The daily standup discussed in the scrum and agile books is by far the most important aspect of the routine. Keep the meetings short, do it in the same place at the same time every day. Update the task tracker during this meeting and keep it organized.
Transitioning a team from waterfall can be difficult. Having everyone on the team read about scrum is important. Also, understand that not every aspect of the scrum model will work in your environment. Facilitate an open discussion about what aspects of the model you want to adopt as a team. The more input you get from the team the more buy-in you'll have.
How to move a team from waterfall development model to scrum model ?
Strategizing Phase: Well, the first step off course is the thought for change. Then comes the buy-in from the Management, and the Product Development Teams.
Release Planning and Virtual Product Discovery: Ideally, you would start by identifying all stakeholders and identifying all the requirements by using the Agile Release planning method - which is a really lean way of doing Release Planning. You would identify virtual products at this stage if not already identified.
Team Forming and Infrastructure: Next step would be forming cross functional teams based on what virtual products need to be built. This step can be tough. It may require RE-organization. Cross functional teams mean there will be no requirements gathering team, or software development team, or QA team. You would have to pull a experienced lot of people from each department to form a cross functional team. A Scrum Master and a Product for each team will have to be appointed. Basic infrastructure will need to be established for the cross functional teams to operate smoothly, without interruption.
Start Sprinting With Team(s): Start following the Scrum/Agile principles and have them Sprint. Capture various artifacts and use them to inspect and adapt.
WALAH you are Agile!
What all are the steps that one need to follow to achieve a smooth transition. What would be the acceptance curve and will it be successful altogether?
Steps are mentioned above in order. Acceptance curve varies based on how well you execute the steps I mentioned above. Lastly Yes, off course it will be successful. 100% guaranteed successful.
Kidding, I wish I could guarantee that, but I can't. :) What I suggest is this - When you read my statement "Yes, off course it will be successful", the hope you might have got, just hold on to that hope and take that first step!
I happened to be a part of a team which was migrating from waterfall to scrum. If the teams large and distributed, I don't think its easy for everyone to migrate to scrum all at once as a change in organization takes certain amount of days/months/years.
Once such approach that you may like to try is Tracer Bullet, although this term is used more in agile world, but you can surely prove your point to get the buy-in and lead by example if you/your team is stuck in the middle of waterfall and scrum and are looking to go nowhere in quick time.
发布评论
评论（5）
首先，团队需要想要变革，并且业务必须支持它。
没有固定的步骤顺序，成功率可能会有很大差异，这很大程度上取决于您的具体情况。
我建议您阅读 Mike Cohn 的书 Succeeding with Agile，其中提供了一些极好的建议对于这样的转变。
First the team needs to want the change, and the business has to support it.
There isn't a set sequence of steps, and success can vary widely, as much depends on your particular situation.
I'd recommend getting Mike Cohn's book Succeeding with Agile, which gives some excellent advice for such a transition.
尽管关于如何在组织内实施 Scrum 有很多想法，但从一个团队开始无疑是一致的思路。以这种方式开始真是太好了。从那里找到具有实施敏捷经验的人。承包商、同事或聚会团体中的建议。以下是我在华盛顿地区参加过的一个活动的链接 - http://groups。 google.com/group/dcnova-scrum-user-group
从这里开始，我的观点是让 Scrum 适应您的团队。它的大小、是否需要调整等等。每个人都有意见，但如果你的团队不买账，那就不值得。不要将此视为从 Scrum 中删除内容的许可。保留每日站立会议、承诺、回顾、演示（等），但调整冲刺的规模等。
我最近看到了一个引人注目的演示，提倡在团队/业务准备就绪时实施 Scrum/敏捷。有关详细信息，请参阅这位绅士的网站 - http://www.dragile.com/
一个重要的关键是不要获取懒惰——做 scrum。并且有很高的标准。如果你打算单独行动（这可能很危险）——请读懂你的内心。阅读示例、与其他人交谈、参加聚会等。不要让您在 Scrum 方面的缺乏经验让您的团队对此感到厌烦。
另一个很好的链接，提供了一个团队实施 Scrum 的经验示例。
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
Though there are many ideas on how to implement scrum within an organization, starting with one team is certainly a consistent thread. So good work on starting that way. From there find someone with experience in implementing agile. A contractor, a colleague, or advice at meetup groups. Here's a link to one I have attended in the DC area - http://groups.google.com/group/dcnova-scrum-user-group
From there, my opinion is to adapt scrum to your team. It's size, it's need for adjustment, etc. Everyone has opinions, but if your team doesn't buy it, it's not worth it. Don't take that as a license to cut things from scrum. Keep the daily standups, the commitment, the retrospectives, the demo (etc), but adjust the size of the sprint, etc.
I recently saw a compelling presentation that advocated implementing pieces of scrum/agile as the team/business was ready. See this gentelman's site for details - http://www.dragile.com/
A big key is to not get lazy - do scrum. And have a high standard. If you're going to go it alone (which can be dangerous) - read your heart out. Read examples, talk to others, go to meetups, etc. Don't let your inexperience in scrum sour your team to it.
Another good link for an example of one team's experience implementing scrum.
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
根据我学习使用敏捷管理团队的经验，有两个关键要素可以让敏捷/Scrum 发挥作用。我认为乔迪关于不要偷懒的观点非常重要，在敏捷的更自由流动的工作模式中，很容易屈服于跳过会议或其他类似的废话。
获得一个优秀的基于网络的任务跟踪器。这允许开发人员登录并查看他们需要做什么，并将有助于跟踪进度。我对 Pivotal Tracker (www.pivotaltracker.com) 非常满意。当然，只有当您真正保持最新状态时，跟踪器才有价值，这让我想到了第二点。
每天都开会。 Scrum 和敏捷书籍中讨论的每日站会是例程中迄今为止最重要的方面。保持会议简短，每天在同一时间同一地点举行。在此会议期间更新任务跟踪器并使其井井有条。
将团队从瀑布式转型可能很困难。让团队中的每个人都了解 Scrum 非常重要。另外，请了解 Scrum 模型的每个方面并非都适用于您的环境。促进关于您希望作为团队采用该模型的哪些方面的公开讨论。您从团队获得的投入越多，您的支持就越多。
In my experience with learning to manage a team using agile there are two critical components to making agile/scrum work. I think that Jody's point about not being lazy is really important, with the more free-flowing work pattern of agile it can be easy to succumb to skipping meetings or other such nonsense.
Get a good web based task tracker. This allows developers to login and see what they need to do and will help track progress. I've been very happy with Pivotal Tracker (www.pivotaltracker.com). Of course the tracker is only worthwhile if you actually keep it up to date, which leads me to point two.
Having meetings EVERY day. The daily standup discussed in the scrum and agile books is by far the most important aspect of the routine. Keep the meetings short, do it in the same place at the same time every day. Update the task tracker during this meeting and keep it organized.
Transitioning a team from waterfall can be difficult. Having everyone on the team read about scrum is important. Also, understand that not every aspect of the scrum model will work in your environment. Facilitate an open discussion about what aspects of the model you want to adopt as a team. The more input you get from the team the more buy-in you'll have.
制定战略阶段：
嗯，偏离路线的第一步是改变的想法。然后是管理层和产品开发团队的支持。
发布规划和虚拟产品发现：
理想情况下，您首先需要使用敏捷发布规划方法来识别所有利益相关者并识别所有需求 - 这是一种真正精益的发布规划方法。如果尚未识别，您将在此阶段识别虚拟产品。
团队组建和基础设施：
下一步将根据需要构建的虚拟产品组建跨职能团队。这一步可能很艰难。它可能需要重新组织。跨职能团队意味着不会有需求收集团队、软件开发团队或质量保证团队。您必须从每个部门抽调大量经验丰富的人员来组建一个跨职能团队。必须为每个团队指定一名 Scrum Master 和一名产品。
需要建立基本的基础设施，以使跨职能团队能够顺利、不间断地运作。
与团队开始冲刺：
开始遵循 Scrum/敏捷原则并让它们冲刺。捕获各种工件并使用它们进行检查和调整。
WALAH，你很敏捷！
步骤已按顺序在上面提到。接受曲线根据您执行上述步骤的情况而有所不同。
最后是的，当然会成功。 100%保证成功。
开玩笑，我希望我能保证这一点，但我不能。 :)
我的建议是——当你读到我的那句话“是的，当然会成功”时，你可能已经有了希望，只要坚持这个希望，迈出第一步！
Strategizing Phase:
Well, the first step off course is the thought for change. Then comes the buy-in from the Management, and the Product Development Teams.
Release Planning and Virtual Product Discovery:
Ideally, you would start by identifying all stakeholders and identifying all the requirements by using the Agile Release planning method - which is a really lean way of doing Release Planning. You would identify virtual products at this stage if not already identified.
Team Forming and Infrastructure:
Next step would be forming cross functional teams based on what virtual products need to be built. This step can be tough. It may require RE-organization. Cross functional teams mean there will be no requirements gathering team, or software development team, or QA team. You would have to pull a experienced lot of people from each department to form a cross functional team. A Scrum Master and a Product for each team will have to be appointed.
Basic infrastructure will need to be established for the cross functional teams to operate smoothly, without interruption.
Start Sprinting With Team(s):
Start following the Scrum/Agile principles and have them Sprint. Capture various artifacts and use them to inspect and adapt.
WALAH you are Agile!
Steps are mentioned above in order. Acceptance curve varies based on how well you execute the steps I mentioned above.
Lastly Yes, off course it will be successful. 100% guaranteed successful.
Kidding, I wish I could guarantee that, but I can't. :)
What I suggest is this - When you read my statement "Yes, off course it will be successful", the hope you might have got, just hold on to that hope and take that first step!
我碰巧是从瀑布迁移到 Scrum 的团队的一员。如果团队规模庞大且分散，我认为每个人都不容易立即迁移到 Scrum，因为组织的变更需要一定的天/月/年。
您可能想尝试的这种方法是 Tracer Bullet ，虽然这个术语在敏捷世界中使用得更多，但是如果您/您的团队陷入瀑布和 Scrum 的中间并希望很快就无处可去。
I happened to be a part of a team which was migrating from waterfall to scrum. If the teams large and distributed, I don't think its easy for everyone to migrate to scrum all at once as a change in organization takes certain amount of days/months/years.
Once such approach that you may like to try is Tracer Bullet, although this term is used more in agile world, but you can surely prove your point to get the buy-in and lead by example if you/your team is stuck in the middle of waterfall and scrum and are looking to go nowhere in quick time.