scrum alone is equal to agile is totally a misconception. Agile is the umbrella under which there are several methods like scrum master, kanban, lean, XP. Now you say how can a part of the umbrella fullfil the idea of an umbrella as a whole. Therefore, scrum is a part of agile.
Scrum provides you with a framework to fix/improve your development process. It should be considered as a starting point to "jelled team" and more productive team. Most likely you will go beyond standard Scrum practices soon, but as a starting point it has some attractive properties:
It is very easy to understand
It can be applied to almost any project and team
There are quite many people who make money and help companies with Scrum adoption
Yeah, I'd agree with some of the sentiment here. Be Agile is following the manifesto and assuring that you have the right alignment of priorities. SCRUM is just another variant with specific pieces written down. It is, if anything a management "tool".
With that said, remember, the tools are secondary, your people are your priority. Don't over-focus on the management style, focus instead of the people and the product.
仅实践 Scrum 的组织很可能会在软件管理和项目可见性方面取得进展。 然而，如果不采用 XP 原则（如单元测试、持续集成、结对编程等），他们很可能无法实现更高的工程质量和吞吐量潜力，从而使他们的 Sprint 产品最终“无法交付”。
Organization practicing only Scrum would most likely be seeing gains on software management and project visibility front. However, they are most likely not achieving a higher engineering quality and throughput potential by not incorporating XP principles like Unit Testing, Continuous Integration, Pair Programming etc., leaving their end of Sprint product NOT "Potentially Shippable".
People fall victim to their subjective perspectives. What I think Agile and Scrum is, another person may think somewhat differently. Luckily we have a set of guidelines in the Agile manifesto and principles and Scrum values but often companies end up becoming fixated on following the process instead of understanding it and its goals.
Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Scrum values
You can learn a lot about a company that uses Scrum by asking them about the values and how they adhere to them. This can give you an idea if the process of Scrum is just enforced without really considering the values that are linked to it.
The goal is to release quality software at the end of each iteration.
With the right influence, the values within the company can change. Unfortunately people are unpredictable so companies can slide back into bad habits when other changes are introduced. This is what makes software more challenging and exciting. It's finding ways to create the balance within the forces between technology and product.
Red flags
If a company is more focused on the process instead of the goal.
If you have to jump through all sorts of hoops and procedures to sign off the smallest change.
The company doesn't have to get the process 100% right but if they are not continuously adapting and improving to reach their goal, instead of just following a process then they probably end up with a "Half-Arsed" implementation of Agile:
We have heard about new ways of developing software by paying consultants and reading Gartner reports. Through this we have been told to value:
Individuals and interactions over processes and tools and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact
Working software over comprehensive documentation as long as that software is comprehensively documented
Customer collaboration over contract negotiation within the boundaries of strict contracts, of course, and subject to rigorous change control
Responding to change over following a plan provided a detailed plan is in place to respond to the change, and it is followed precisely
That is, while the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right.
Compliance
Some companies may have heavy compliance procedures in place that hinders being Agile. This can include governance and other regulations that cannot be escaped. This can impact the Agile methodology by making it feel more cumbersome and heavy but it doesn't mean that those processes cannot be streamlined to be more accommodating.
"I'm hearing about a lot of companies that act like they're agile but the only agile thing > they do is the Scrum process. Is this enough to be considered agile"
Short answer - yes. In my opinion anyway :-)
Of course - they have to be actually doing Scrum - rather than just sticking the name on the wall. There's a lot more to Scrum than daily stand-ups... and if that's all they're doing they're not doing it right.
Done correctly Scrum forces companies to identify the bottlenecks in how the organisation is running. By setting up regular timeboxed sprints, getting a decent feedback loop, and splitting responsibility across product owner and team appropriately you actually get useful baseline information on how to improve your process.
The organisation has to listen to that feedback - and act on it.
It's certainly not the only way to do agile. It might not even be the best way to introduce agile into an organisation. I'm more of an XP fan myself - and find that the extra practices provide a useful framework for kick-starting those process improvements.
That said - for many organisations - the biggest problem is bad split of responsibilities & the complete lack of a sane and rapid feedback loop. Scrum fixes that out of the gate.
更新：您不应该仅仅因为这个前提就解雇这样的公司。 然而，在面试过程中，您应该利用这个机会了解他们为什么只使用 SCRUM。 如果问题在于没有人支持 TDD 或 CI 等事物，那么如果您愿意成为技术主管，那么它可能很适合您。 如果是因为他们认为这些流程是“开销”、“愚蠢”或“不必要”，那么你应该对该公司保持警惕。
Using SCRUM alone is not necessarily an excuse to get more meetings. Being able to track the work that's done every day and make decisions on how to modify (by cutting or rebalancing work) the rest of the sprint is quite useful on it's own and sound agile to me. :-)
Of course, if you don't have the other components of the agile process, you will have harder time to measure the success of your work, so you might think you are on track with the sprint, but in fact be nowhere near the point you should be at to deliver quality product on schedule.
Update: You shouldn't dismiss such company on that premise alone. HOwever, during the interview, you should use the chance to understand why they are using only SCRUM. If it's a matter of not having people to champion things like TDD or CI, than it might be a good fit for you, if you are willing to become the technical lead. If it's because they dismiss these processes as "overhead" or "stupid" or "unnecessary", then you should be wary of the company.
Scrum is a project management methodology, first and foremost. Yes, if you are doing Scrum, you are probably beginning to think more about being agile, and delivering value to your customer. But it does not necessarily make you agile. For starters, Scrum doesn't talk about HOW you do software development. This is where things like XP come in - other methodologies and ideas that force you to review and change your working practices in order to become more efficient and effective.
So, rather than asking "do you do Scrum / XP / whatever" I would ask these companies about their overall processes and take a holistic view. Is the company focussing on delivery of maximum business value and driven by an ethos of continuous improvement? If so, then they are probably a lot more agile than one that says it does Scrum.
It's not possible to tell whether a team is agile just because somebody says that they're doing scrum.
There are good and bad scrum implementations but they key things about agile are:
the ability of the project and team to think flexibly
how self-organising the team is (do they have a control freak "architect" or manager? or is there a considerable amount of consensus decision making?)
It's all too easy to conform to the minimum requirements of what a team needs to do to be doing scrum without being truly agile. Those minimum requirements are only there to bring about a certain attitude and way of working.
It's possible for decision-making in a project to be ridgidly inflexible and controlled top-down and yet conform to the minimum requirements of scrum. Sadly, when I look for contracting engagements, I find the scrum-in-name only implementations outnumber the real thing by a considerable margin.
Personally, I'd choose to implement extreme programming within scrum. (In fact, Jeff Sutherland says he's never seen a top productivity scrum team that didn't do the XP practices.) However, I'm pretty confident that people could implement XP really badly too... ;-) It really comes down to the attitude in the team.
Agile is many times presented as an umbrella, set of different techniques, methods, to work in an environment supporting a change. Scrum is for project management, for development techniques there is xp, for better requirement process you can use BDD, for test TDD.
Starting with scrum is the first step on your agility way. Consider other techniques as well. It will take time, but there are real benefits. And there is nothing better than common understanding and good team spirit. Achieve that as the first.
I've noticed that just using Scrum meetings alone is a pretty clear sign that the company has not correctly implemented Agile concepts.
Think about how easy Scrum meetings are, just fire up Outlook and give everyone a daily 15 minute meeting. But, slicing everything up into quick iterations and making sure new functionally is rapidly tested by end users takes a lot more work.
I'd guess, that most managers stop reading right after the Scrum part and they lose interest. But, their daily meeting requests live on forever.
The Agile manifesto is really a philosophy that pertains to a better ways of working. Scrum is an agile methodology, so yes a company using Scrum would typically be considered agile.
It is however entirely possible to forget the Agile philosophy when trying to implement Scrum. It can be easy to get caught up in the pursuit of the perfect scrum process and neglect the individuals and their interactions.
You should be weary of the companies that neglect individuals and interactions, and instead blindly favour strict process and tools. However, this holds true regardless of their stated methodology.
发布评论
评论（14）
单独的 scrum 等于敏捷完全是一个误解。 敏捷是一个总括，其下有多种方法，如 Scrum Master、看板、精益、XP。 现在你说雨伞的一部分如何体现雨伞整体的理念。 因此，scrum 是敏捷的一部分。
scrum alone is equal to agile is totally a misconception. Agile is the umbrella under which there are several methods like scrum master, kanban, lean, XP. Now you say how can a part of the umbrella fullfil the idea of an umbrella as a whole. Therefore, scrum is a part of agile.
Scrum 为您提供了一个框架来修复/改进您的开发流程。 它应该被视为“jelled 的起点团队”和更有生产力的团队。 您很可能很快就会超越标准的 Scrum 实践，但作为起点，它有一些吸引人的特性：
另外还有一点真的不那么重要了解 Scrum 是否=敏捷。 最好专注于提高生产力，不要让自己被这些问题困扰。
Scrum provides you with a framework to fix/improve your development process. It should be considered as a starting point to "jelled team" and more productive team. Most likely you will go beyond standard Scrum practices soon, but as a starting point it has some attractive properties:
Also there it is really not so important to know whether Scrum = agile. It is better to focus on better productivity and do not bother yourself with such questions.
是的，我同意这里的一些观点。 敏捷是遵循宣言并确保您正确调整优先事项。 SCRUM 只是另一种变体，其中记录了特定的部分。 如果有的话，它是一种管理“工具”。
话虽如此，请记住，工具是次要的，你的员工才是你的首要任务。 不要过度关注管理风格，而应该关注人员和产品。
Yeah, I'd agree with some of the sentiment here. Be Agile is following the manifesto and assuring that you have the right alignment of priorities. SCRUM is just another variant with specific pieces written down. It is, if anything a management "tool".
With that said, remember, the tools are secondary, your people are your priority. Don't over-focus on the management style, focus instead of the people and the product.
仅实践 Scrum 的组织很可能会在软件管理和项目可见性方面取得进展。 然而，如果不采用 XP 原则（如单元测试、持续集成、结对编程等），他们很可能无法实现更高的工程质量和吞吐量潜力，从而使他们的 Sprint 产品最终“无法交付”。
Organization practicing only Scrum would most likely be seeing gains on software management and project visibility front. However, they are most likely not achieving a higher engineering quality and throughput potential by not incorporating XP principles like Unit Testing, Continuous Integration, Pair Programming etc., leaving their end of Sprint product NOT "Potentially Shippable".
人们成为主观观点的受害者。 我认为敏捷和 Scrum 是什么，另一个人可能会有不同的想法。 幸运的是，我们在敏捷宣言和原则 和 Scrum 价值观，但公司最终往往会专注于遵循流程，而不是理解流程及其目标。
敏捷宣言
Scrum 价值观
通过询问使用 Scrum 的公司的价值观以及他们如何遵守这些价值观，您可以了解很多有关该公司的信息。 这可以让您了解 Scrum 流程是否只是强制执行，而没有真正考虑与之相关的价值观。
目标
目标是在每次迭代结束时发布高质量的软件< /强>。
有了正确的影响力，公司内部的价值观就可以改变。 不幸的是，人们是不可预测的，因此当引入其他变化时，公司可能会重新陷入坏习惯。 这使得软件变得更具挑战性和令人兴奋。 它正在寻找在技术和产品之间的力量之间建立平衡的方法。
危险信号
合规
一些公司可能有严格的合规程序，这阻碍了敏捷性。 这可能包括治理和其他无法逃避的法规。 这可能会影响敏捷方法，使其感觉更加麻烦和沉重，但这并不意味着这些流程不能简化以变得更加方便。
People fall victim to their subjective perspectives. What I think Agile and Scrum is, another person may think somewhat differently. Luckily we have a set of guidelines in the Agile manifesto and principles and Scrum values but often companies end up becoming fixated on following the process instead of understanding it and its goals.
Agile Manifesto
Scrum values
You can learn a lot about a company that uses Scrum by asking them about the values and how they adhere to them. This can give you an idea if the process of Scrum is just enforced without really considering the values that are linked to it.
Goal
The goal is to release quality software at the end of each iteration.
With the right influence, the values within the company can change. Unfortunately people are unpredictable so companies can slide back into bad habits when other changes are introduced. This is what makes software more challenging and exciting. It's finding ways to create the balance within the forces between technology and product.
Red flags
Compliance
Some companies may have heavy compliance procedures in place that hinders being Agile. This can include governance and other regulations that cannot be escaped. This can impact the Agile methodology by making it feel more cumbersome and heavy but it doesn't mean that those processes cannot be streamlined to be more accommodating.
敏捷是一个庞大而模糊的概念。 很多事情都是敏捷的。
Scrum 是一组用于进行冲刺和发布的特定技术。 它之所以敏捷，是因为它符合敏捷宣言。
还有许多其他特定的敏捷技术（例如，所有 xDD）。
如有疑问，请将公司的实际实践与 进行比较敏捷宣言。
Agile is a big, vague concept. Lots of things are Agile.
Scrum is a specific set of techniques for doing sprints and releases. It's agile because it fits the Agile Manifesto.
There are lots of other specific Agile techniques (all of the xDD's, for example.)
When in doubt, compare the companies actual practices against the Agile Manifesto.
简短的回答 - 是的。 无论如何，在我看来 :-)
当然 - 他们必须真正做 Scrum - 而不仅仅是把名字贴在墙上。 Scrum 的意义远不止每日站立会议……如果这就是他们所做的一切，那么他们就做得不对。
正确执行 Scrum 迫使公司识别组织运行方式的瓶颈。 通过设置定期的时间盒冲刺，获得良好的反馈循环，并适当地在产品所有者和团队之间分配责任，您实际上可以获得有关如何改进流程的有用基线信息。
组织必须听取反馈并采取行动。
这当然不是实现敏捷的唯一方法。 它甚至可能不是将敏捷引入组织的最佳方式。 我自己更是 XP 的粉丝 - 并且发现额外的实践为启动这些流程改进提供了一个有用的框架。
也就是说，对于许多组织来说，最大的问题是责任和职责的不合理划分。 完全缺乏理智而快速的反馈循环。 Scrum 从一开始就解决了这个问题。
会议只是其中很小的一部分:-)
Short answer - yes. In my opinion anyway :-)
Of course - they have to be actually doing Scrum - rather than just sticking the name on the wall. There's a lot more to Scrum than daily stand-ups... and if that's all they're doing they're not doing it right.
Done correctly Scrum forces companies to identify the bottlenecks in how the organisation is running. By setting up regular timeboxed sprints, getting a decent feedback loop, and splitting responsibility across product owner and team appropriately you actually get useful baseline information on how to improve your process.
The organisation has to listen to that feedback - and act on it.
It's certainly not the only way to do agile. It might not even be the best way to introduce agile into an organisation. I'm more of an XP fan myself - and find that the extra practices provide a useful framework for kick-starting those process improvements.
That said - for many organisations - the biggest problem is bad split of responsibilities & the complete lack of a sane and rapid feedback loop. Scrum fixes that out of the gate.
Meetings are a very small part of that :-)
Scrum 所倡导的透明度将让糟糕的管理者脱颖而出。 真正拥抱 Scrum 的公司绝对值得一看。
Bad managers will be outed by the transparency that Scrum promotes. Companies truly embracing Scrum are definitely worth a look.
单独使用 SCRUM 并不一定是召开更多会议的借口。 能够跟踪每天完成的工作，并就如何修改（通过削减或重新平衡工作）冲刺的其余部分做出决定，这本身就非常有用，而且对我来说听起来很敏捷。 :-)
当然，如果您没有敏捷流程的其他组件，您将更难衡量您的工作是否成功，因此您可能会认为冲刺已步入正轨，但实际上却一事无成接近您应该按时交付优质产品的时间点。
更新：您不应该仅仅因为这个前提就解雇这样的公司。 然而，在面试过程中，您应该利用这个机会了解他们为什么只使用 SCRUM。 如果问题在于没有人支持 TDD 或 CI 等事物，那么如果您愿意成为技术主管，那么它可能很适合您。 如果是因为他们认为这些流程是“开销”、“愚蠢”或“不必要”，那么你应该对该公司保持警惕。
Using SCRUM alone is not necessarily an excuse to get more meetings. Being able to track the work that's done every day and make decisions on how to modify (by cutting or rebalancing work) the rest of the sprint is quite useful on it's own and sound agile to me. :-)
Of course, if you don't have the other components of the agile process, you will have harder time to measure the success of your work, so you might think you are on track with the sprint, but in fact be nowhere near the point you should be at to deliver quality product on schedule.
Update: You shouldn't dismiss such company on that premise alone. HOwever, during the interview, you should use the chance to understand why they are using only SCRUM. If it's a matter of not having people to champion things like TDD or CI, than it might be a good fit for you, if you are willing to become the technical lead. If it's because they dismiss these processes as "overhead" or "stupid" or "unnecessary", then you should be wary of the company.
Scrum 首先是一种项目管理方法。 是的，如果您正在实施 Scrum，您可能会开始更多地考虑敏捷性以及为客户提供价值。 但它并不一定能让你变得敏捷。 首先，Scrum 并没有讨论如何进行软件开发。 这就是 XP 之类的东西的用武之地 - 其他方法和想法迫使您回顾和改变您的工作实践，以便变得更加高效和有效。
因此，我不会问“你们做 Scrum/XP/其他什么吗”，我会询问这些公司的整体流程并采取整体观点。 公司是否专注于实现最大商业价值并以持续改进的精神为动力？ 如果是这样，那么他们可能比声称采用 Scrum 的人敏捷得多。
Scrum is a project management methodology, first and foremost. Yes, if you are doing Scrum, you are probably beginning to think more about being agile, and delivering value to your customer. But it does not necessarily make you agile. For starters, Scrum doesn't talk about HOW you do software development. This is where things like XP come in - other methodologies and ideas that force you to review and change your working practices in order to become more efficient and effective.
So, rather than asking "do you do Scrum / XP / whatever" I would ask these companies about their overall processes and take a holistic view. Is the company focussing on delivery of maximum business value and driven by an ethos of continuous improvement? If so, then they are probably a lot more agile than one that says it does Scrum.
不可能仅仅因为有人说他们在做 Scrum 就判断一个团队是否敏捷。
Scrum 实现有好有坏，但敏捷的关键在于：
遵守团队所需的最低要求太容易了去做 Scrum 却没有真正敏捷。 这些最低要求只是为了带来某种态度和工作方式。
项目中的决策可能会极其僵化并受到自上而下的控制，但仍符合 Scrum 的最低要求。可悲的是，当我寻找合同约定时，我发现 scrum-in仅名称实现的数量远远超过实际的数量。
就我个人而言，我会选择在 scrum 中实现极限编程。 （事实上，Jeff Sutherland 说他从未见过没有进行过 XP 实践的顶级生产力 Scrum 团队。）但是，我非常有信心人们也可以非常糟糕地实施 XP...;-) 这真的很重要到团队中的态度。
It's not possible to tell whether a team is agile just because somebody says that they're doing scrum.
There are good and bad scrum implementations but they key things about agile are:
It's all too easy to conform to the minimum requirements of what a team needs to do to be doing scrum without being truly agile. Those minimum requirements are only there to bring about a certain attitude and way of working.
It's possible for decision-making in a project to be ridgidly inflexible and controlled top-down and yet conform to the minimum requirements of scrum. Sadly, when I look for contracting engagements, I find the scrum-in-name only implementations outnumber the real thing by a considerable margin.
Personally, I'd choose to implement extreme programming within scrum. (In fact, Jeff Sutherland says he's never seen a top productivity scrum team that didn't do the XP practices.) However, I'm pretty confident that people could implement XP really badly too... ;-) It really comes down to the attitude in the team.
敏捷！= scrum。
敏捷是指为变革做好准备。
敏捷多次被视为一个保护伞，一组不同的技术、方法，在支持变革的环境中工作。 Scrum用于项目管理，对于开发技术有xp，为了更好的需求过程可以使用BDD，对于测试TDD。
从 Scrum 开始是敏捷之路的第一步。 还要考虑其他技术。 这需要时间，但确实有好处。 没有什么比共同的理解和良好的团队精神更好的了。 实现这一点作为第一。
Agile != scrum.
Agile is about readyness for changes.
Agile is many times presented as an umbrella, set of different techniques, methods, to work in an environment supporting a change. Scrum is for project management, for development techniques there is xp, for better requirement process you can use BDD, for test TDD.
Starting with scrum is the first step on your agility way. Consider other techniques as well. It will take time, but there are real benefits. And there is nothing better than common understanding and good team spirit. Achieve that as the first.
我注意到，仅使用 Scrum 会议就清楚地表明该公司尚未正确实施敏捷概念。
想想 Scrum 会议是多么容易，只需启动 Outlook 并为每个人提供每天 15 分钟的会议即可。 但是，将所有内容分解为快速迭代并确保最终用户快速测试新功能需要做更多的工作。
我猜想，大多数经理在 Scrum 部分之后就停止阅读，并且失去了兴趣。 但是，他们的每日会议请求将永远存在。
I've noticed that just using Scrum meetings alone is a pretty clear sign that the company has not correctly implemented Agile concepts.
Think about how easy Scrum meetings are, just fire up Outlook and give everyone a daily 15 minute meeting. But, slicing everything up into quick iterations and making sure new functionally is rapidly tested by end users takes a lot more work.
I'd guess, that most managers stop reading right after the Scrum part and they lose interest. But, their daily meeting requests live on forever.
敏捷宣言实际上是一种与更好的工作方式相关的哲学。 Scrum 是一种敏捷方法，所以使用 Scrum 的公司通常被认为是敏捷的。
然而，在尝试实施 Scrum 时完全有可能忘记敏捷哲学。 人们很容易陷入对完美 Scrum 流程的追求而忽视个人及其互动。
你应该厌倦那些忽视个人和互动，而盲目青睐严格流程和工具的公司。
然而，无论他们声明的方法如何，这都是正确的。
The Agile manifesto is really a philosophy that pertains to a better ways of working. Scrum is an agile methodology, so yes a company using Scrum would typically be considered agile.
It is however entirely possible to forget the Agile philosophy when trying to implement Scrum. It can be easy to get caught up in the pursuit of the perfect scrum process and neglect the individuals and their interactions.
You should be weary of the companies that neglect individuals and interactions, and instead blindly favour strict process and tools.
However, this holds true regardless of their stated methodology.