PS：敏捷方法都受到精益运动的影响（大多数（如果不是全部）敏捷宣言签署者的书架上都有改变世界的机器）。有人可能会说敏捷方法是精益概念（用于新产品开发）到软件开发的转变；其他人会说敏捷和精益共享相同的理论（例如参见 Jeff Sutherland 的文章 第一次 Scrum：是 Scrum 还是精益？）。对我来说，有明显的相似之处（很容易映射整个 关于敏捷实践的丰田生产系统“House”），我发现精益有助于理解敏捷的工作原理以及如何有效地实施敏捷流程。所以我使用精益作为附加工具箱。但对我来说，如果实施得当，Scrum 已经具备了使您的开发流程变得精益的一切。所以没有必要混合它。就应用它（Shu）。
A few things to consider:
Scrum is about empowering the team as opposed to command and control management style.
There is no manager in Scrum, there is a ScrumMaster which is a servant leader.
The ScrumMaster is responsible for the Scrum process, making sure it is used correctly and maximizes its benefits.
The ScrumMaster has to remove impediments so that the team can do his job in a productive way.
Scrum implements transparency with a minimal set of practices/roles/ceremonies and there is no real paperwork.
There is no real PMO type work in Scrum, most of PMO work is (considered as) waste.
So please, keep your PM habits away :)
And during an adoption, I'd recommend to do it as in the book (Shu), don't try to adapt it for now (Ri) (see Alistair Cockburn on Shu Ha Ri). I wouldn't even consider things like Scrumban (a modified version of Scrum using Kaban for continuous flow, no more iterations) at the start.
PS: Agile methods have all been influenced by the Lean movement (most, if not all, Agile manifesto signatories had The Machine That Changed The World in their shelves). Some could say Agile methods are a transposition of lean concepts (for new product development) to software development; others would say Agile and Lean share the same theory (see for example Jeff Sutherland's article The First Scrum: Was it Scrum or Lean?). To me, there are obvious similarities (it would be easy to map the whole Toyota Production System "House" on Agile practices) and I find Lean useful to understand how Agile works and how to implement an Agile process efficiently. So I use Lean as an as an additional toolbox. But to me, Scrum has already everything to make your development process lean, if well implemented. So there is no need to mix it. Just apply it (Shu).
Yes, Scrum and the PMO can live together. They're concerned with different things though, so the edges where the two meet are going to have to give a little. There will be some conflict at the intersection. Traditional PMBOK approaches are a poor fit to product development domains like software development, but there's quite a bit of smart statistical controls in the PMBOK, and skilled project managers who can be taught to manage flow rather than schedule are precious.
Neither Scrum nor Lean nor the Toyota organization suggest that either hierarchy or directed authority are off-limits. The definition of "Self-Organization" has been significantly stretched by software developers over the years until it has become largely indistinguishable from "Self-Determination", which was never the intention.
Toyota, for example, is a very hierarchical organization that depends very much on command and control. The difference is that it's a Learning Organization and managers at Toyota are required to have mastery of the work done in their purview, and have a duty to teach that work to workers. Team members at Toyota who envision possible improvements to their work and to the process are coached by their managers through the scientific process to prove their ideas. It helps that the process isn't shaped to fit the organization, but that the organization shifts to fit a process that is continually improved.
There is always an element of command and control in any organization. Even Scrum teams are subject to it. Even if a work team itself is perfectly flat, a Product Owner can still call the ball. Software teams have seniors and juniors, and their opinions are not perfectly equal. On Lean teams, managers are expected to be masters of the work, or have, as Toyota calls it, "towering technical competence". If management isn't skilled or is too far from the work, then they'll likely make bad decisions about the work. This is the real problem, and Self-Directed Work Teams (SDWT) are a predictable result of workers seeking to insulate themselves from poor management. SDWT is not the best answer, but it might be the limit of what an organization might achieve.
And finally, Scrum is not a project management methodology - at least not from the perspective of the rigor of the PMBOK or of Lean. But then, the application of the PMBOK to software development without significant modification to account for the nature of product development is often a fool's errand, so efforts to displace the PMBOK on software teams is understandable.
At best, Scrum is a timebox planning methodology. That's still valuable if it's the thing you need, but there's nothing inherent in software work management that suggests you need timeboxes like sprints and iterations. In fact, the upwelling of interest in iteration-less approaches like Kanban and Flow-Based management are a testament to this.
In the end, there a heck of a lot of orthodoxy built up around Scrum now that wasn't introduced by Scrum's founders and leaders, and often isn't supported by them. The same can be said about how PMOs operate. Focus on the principles of flow and learning cultures and you might be able to avoid the blind alleys and myths that gather around methodologies once they've been in the mainstream for five years or so.
Has anyone tried to incorporate different ideas (scrum, six sigma, pmp, lean?)
Essentially all of the above derive from the Japanese Quality Movement in the early 1980's. It's all about increasing quality by reducing waste, called Muda in Japan
Lean was Toyota's implementation of the Quality Philosophies and Six Sigma was General Electric's attempt to Americanize Lean based on corporate culture of the day.
Fast forward 20 years and the IT industry have realized that all this 'lean' thinking is a great idea for building better quality software, faster. In what has been labelled Agile.
XP (extreme programming) and SCRUM are just two different implementations of Agile techniques.
Traditional management and software management is coming up against these new ways of thinking.
You can't have it all. Either your focus is on command and hierarchy (DO AS YOUR TOLD, traditional approach) vs Collaboration and working together to reduce wastes and deliver amazing things to customers (LETS DO IT TOGETHER, new model).
If you want to go deeper on this, the best approach is to read back on the original LEAN philosophies and then see how you think they can best be applied to project management. Many of best project management ideas were already considered as part of the original Lean movement, read the book 'The Toyota Way' and look into Lean that is where you can find your own answers.
Your question doesn't make sense since scrum is a project management framework but here are some things to consider:
Quality is the sole responsibility of the Team; not any PM.
Not sure what you mean by "artifacts", but the few scrum has (backlog, burndown) are maintained by the PO and Team under the guidance of the ScrumMaster.
There were no "best parts" to waterfall to want to consider continuing to use once you embrace Agile.
There is no "paperwork" in scrum; its considered waste.
People try to combine things all the time. But most of the time they get the WORST of all worlds; not the best. Most mistakes teams make in implementing scrum is to make excuses for why they can't do it the right way. Then they claim it would be better to combine in something else and just make a mess of the whole thing.
First you need to know what kind of team you have. Then start from that knowledge and use the appropriate methodology for your team. Rather than trying to use some methodology for your team. Do a methodology for your team. That means see what they are comfortable doing and what they think would benefit all of them.
For example: Usually when a team failed using RUP, it wasn't because they didn't follow the guidelines, but because they tried to follow all of them.
Generally I think it's better if developers don't have to do paperwork and logistics. Either they are bad at it or they would be more productive doing development.
The above the wiki for the very excellent Dan North who proposed the idea of Behaviour Driven Design (Premise: The way we think depends on the language we use and this can be applied to software also).
Well, first of all, Scrum is a project management process, so asking if Scrum and project management can coexist is like asking if water and H2O can coexist.
Second, the PMBOK defines the project manager role as having responsibility for the success of a project. Similarly, in Scrum the Product Owner is responsible for ROI, so the responsibilities of these roles are similar even if their duties are different. Scrum eschews a command-and-control management structure, emphasizing the need for self-managed and self-empowered teams that collectively make commitments and own delivering on those commitments under the principle that the people who do the work make and own the commitment... no responsibility without authority. In Scrum, the Product Owner provides guidance to the team via the product backlog prioritization and by the defined acceptance criteria for each backlog item ("Here's what I need done and here's the functionality that must exist for me to be happy"). The Product Owner also has the final say as to whether something is done or not; if the team doesn't complete a backlog item to the Product Owner's satisfaction for any reason then the Product Owner can reject the work. I'd say that makes the Product Owner a very powerful and important role in Scrum... IMO the most important role in terms of project success.
I think the way I read your post is that the PM does 2 things:
1) Creates artifacts necessary for the business (like compliance)
2) Manage the project
As far as #2 goes, that job becomes encompassed in the PO and SM roles. The PM continuing to do it will add confusion and hurt the process.
As for #1, that is a vital role. If the business needs this, why not add the creation of these artifacts as part of the definition of "done" and add them to the team as a member who performs this specialized task. Alternatively, you could do this outside Scrum with no one even aware that it's happening, then perhaps providing those artifacts to the PO.
Scrum is project management, just not the way project managers do it, but as Scrum does it. In short, Scrum does the compelte opposite of what people think of and are tought about project management. So, from that angle, I would say no.
On the other hand, project managers can be very efficient Product Owners.
发布评论
评论（10）
需要考虑的一些事情：
所以，请保持你的 PM 习惯 :)
在采用过程中，我建议按照书中的方式进行 (Shu)，现在不要尝试适应它 (Ri)（请参阅 舒哈日）。我什至不会在一开始就考虑 Scrumban（Scrum 的修改版本，使用 Kaban 实现连续流程，不再迭代）之类的事情。
PS：敏捷方法都受到精益运动的影响（大多数（如果不是全部）敏捷宣言签署者的书架上都有改变世界的机器）。有人可能会说敏捷方法是精益概念（用于新产品开发）到软件开发的转变；其他人会说敏捷和精益共享相同的理论（例如参见 Jeff Sutherland 的文章 第一次 Scrum：是 Scrum 还是精益？）。对我来说，有明显的相似之处（很容易映射整个 关于敏捷实践的丰田生产系统“House”），我发现精益有助于理解敏捷的工作原理以及如何有效地实施敏捷流程。所以我使用精益作为附加工具箱。但对我来说，如果实施得当，Scrum 已经具备了使您的开发流程变得精益的一切。所以没有必要混合它。就应用它（Shu）。
A few things to consider:
So please, keep your PM habits away :)
And during an adoption, I'd recommend to do it as in the book (Shu), don't try to adapt it for now (Ri) (see Alistair Cockburn on Shu Ha Ri). I wouldn't even consider things like Scrumban (a modified version of Scrum using Kaban for continuous flow, no more iterations) at the start.
PS: Agile methods have all been influenced by the Lean movement (most, if not all, Agile manifesto signatories had The Machine That Changed The World in their shelves). Some could say Agile methods are a transposition of lean concepts (for new product development) to software development; others would say Agile and Lean share the same theory (see for example Jeff Sutherland's article The First Scrum: Was it Scrum or Lean?). To me, there are obvious similarities (it would be easy to map the whole Toyota Production System "House" on Agile practices) and I find Lean useful to understand how Agile works and how to implement an Agile process efficiently. So I use Lean as an as an additional toolbox. But to me, Scrum has already everything to make your development process lean, if well implemented. So there is no need to mix it. Just apply it (Shu).
是的，Scrum 和 PMO 可以共存。不过，他们关心的事情不同，所以两者相遇的边缘必须做出一些让步。在路口会有一些冲突。传统的 PMBOK 方法不太适合软件开发等产品开发领域，但 PMBOK 中有相当多的智能统计控制，并且能够学会管理流程而不是进度表的熟练项目经理非常宝贵。
Scrum、精益和丰田组织都没有表明等级制度或直接权威都是禁止的。多年来，软件开发人员大大扩展了“自组织”的定义，直到它与“自决”基本上无法区分，而这从来都不是他们的本意。
例如，丰田是一个等级森严的组织，非常依赖命令和控制。不同之处在于，它是一个学习型组织，丰田的管理者需要掌握其职权范围内完成的工作，并有责任向工人传授这项工作。丰田的团队成员如果设想对其工作和流程进行可能的改进，他们的经理会通过科学流程进行指导，以证明他们的想法。它有助于流程不是为了适应组织而设计的，而是组织进行转变以适应不断改进的流程。
任何组织中都始终存在命令和控制的因素。甚至 Scrum 团队也受到它的影响。即使工作团队本身完全扁平化，产品负责人仍然可以发号施令。软件团队有前辈和后辈，他们的意见并不完全平等。在精益团队中，管理者被期望成为工作的主人，或者像丰田所说的那样，拥有“卓越的技术能力”。如果管理层不熟练或距离工作太远，那么他们很可能会对工作做出错误的决定。这才是真正的问题，而自我导向工作团队 (SDWT) 是工人寻求使自己免受不良管理影响的可预见结果。 SDWT 不是最好的答案，但它可能是组织可能实现的目标的限制。
最后，Scrum 不是一种项目管理方法——至少从 PMBOK 或精益的严格性角度来看不是。但是，如果不考虑产品开发的本质而进行重大修改，将 PMBOK 应用于软件开发往往是一件愚蠢的事情，因此在软件团队中努力取代 PMBOK 是可以理解的。
Scrum 充其量是一种时间盒规划方法。如果这是您需要的东西，那仍然很有价值，但是软件工作管理中没有任何固有的内容表明您需要冲刺和迭代等时间盒。事实上，人们对看板和基于流程的管理等无迭代方法的兴趣不断高涨就证明了这一点。
最后，现在围绕 Scrum 建立了很多正统观念，但这些观念并不是由 Scrum 创始人和领导者引入的，而且通常也得不到他们的支持。 PMO 的运作方式也是如此。专注于心流和学习文化的原则，一旦方法论成为主流五年左右，你也许就能避免围绕方法论的死胡同和神话。
Yes, Scrum and the PMO can live together. They're concerned with different things though, so the edges where the two meet are going to have to give a little. There will be some conflict at the intersection. Traditional PMBOK approaches are a poor fit to product development domains like software development, but there's quite a bit of smart statistical controls in the PMBOK, and skilled project managers who can be taught to manage flow rather than schedule are precious.
Neither Scrum nor Lean nor the Toyota organization suggest that either hierarchy or directed authority are off-limits. The definition of "Self-Organization" has been significantly stretched by software developers over the years until it has become largely indistinguishable from "Self-Determination", which was never the intention.
Toyota, for example, is a very hierarchical organization that depends very much on command and control. The difference is that it's a Learning Organization and managers at Toyota are required to have mastery of the work done in their purview, and have a duty to teach that work to workers. Team members at Toyota who envision possible improvements to their work and to the process are coached by their managers through the scientific process to prove their ideas. It helps that the process isn't shaped to fit the organization, but that the organization shifts to fit a process that is continually improved.
There is always an element of command and control in any organization. Even Scrum teams are subject to it. Even if a work team itself is perfectly flat, a Product Owner can still call the ball. Software teams have seniors and juniors, and their opinions are not perfectly equal. On Lean teams, managers are expected to be masters of the work, or have, as Toyota calls it, "towering technical competence". If management isn't skilled or is too far from the work, then they'll likely make bad decisions about the work. This is the real problem, and Self-Directed Work Teams (SDWT) are a predictable result of workers seeking to insulate themselves from poor management. SDWT is not the best answer, but it might be the limit of what an organization might achieve.
And finally, Scrum is not a project management methodology - at least not from the perspective of the rigor of the PMBOK or of Lean. But then, the application of the PMBOK to software development without significant modification to account for the nature of product development is often a fool's errand, so efforts to displace the PMBOK on software teams is understandable.
At best, Scrum is a timebox planning methodology. That's still valuable if it's the thing you need, but there's nothing inherent in software work management that suggests you need timeboxes like sprints and iterations. In fact, the upwelling of interest in iteration-less approaches like Kanban and Flow-Based management are a testament to this.
In the end, there a heck of a lot of orthodoxy built up around Scrum now that wasn't introduced by Scrum's founders and leaders, and often isn't supported by them. The same can be said about how PMOs operate. Focus on the principles of flow and learning cultures and you might be able to avoid the blind alleys and myths that gather around methodologies once they've been in the mainstream for five years or so.
有人尝试过融合不同的理念（scrum、6 sigma、pmp、精益吗？）
本质上，上述所有理念都源自 1980 年代初的日本质量运动。
这一切都是为了通过减少浪费来提高质量，在日本称为Muda
精益是丰田的实施质量理念
六西格码是通用电气根据当时的企业文化将精益美国化的尝试。
快进 20 年，IT 行业已经意识到所有这些“精益”思想对于更快地构建质量更高的软件来说是一个好主意。在被标记为敏捷的内容中。
XP（极限编程）和 SCRUM 只是敏捷技术的两种不同实现。
传统管理和软件管理正在与这些新的思维方式发生冲突。
你不可能拥有一切。您的重点要么是命令和层次结构（按您吩咐的去做，传统方法），要么是协作和共同努力，以减少浪费并为客户提供令人惊叹的东西（让我们一起做，新模式）。
如果您想更深入地了解这一点，最好的方法是回顾最初的精益哲学，然后看看您认为如何最好地将它们应用到项目管理中。许多最好的项目管理理念已经被认为是最初的精益运动的一部分，阅读《丰田之路》一书并研究精益，您可以在其中找到自己的答案。
谷歌：首先介绍七种类型的 Muda。
Has anyone tried to incorporate different ideas (scrum, six sigma, pmp, lean?)
Essentially all of the above derive from the Japanese Quality Movement in the early 1980's.
It's all about increasing quality by reducing waste, called Muda in Japan
Lean was Toyota's implementation of the Quality Philosophies
and Six Sigma was General Electric's attempt to Americanize Lean based on corporate culture of the day.
Fast forward 20 years and the IT industry have realized that all this 'lean' thinking is a great idea for building better quality software, faster. In what has been labelled Agile.
XP (extreme programming) and SCRUM are just two different implementations of Agile techniques.
Traditional management and software management is coming up against these new ways of thinking.
You can't have it all. Either your focus is on command and hierarchy (DO AS YOUR TOLD, traditional approach) vs Collaboration and working together to reduce wastes and deliver amazing things to customers (LETS DO IT TOGETHER, new model).
If you want to go deeper on this, the best approach is to read back on the original LEAN philosophies and then see how you think they can best be applied to project management. Many of best project management ideas were already considered as part of the original Lean movement, read the book 'The Toyota Way' and look into Lean that is where you can find your own answers.
Google: the seven types of muda for a start.
你的问题没有意义，因为 scrum 是一个项目管理框架，但这里有一些需要考虑的事情：
Your question doesn't make sense since scrum is a project management framework but here are some things to consider:
我认为你的方向是错误的。
首先你需要知道你拥有什么样的团队。然后从这些知识开始，为您的团队使用适当的方法。而不是尝试为您的团队使用某种方法。为你的团队制定一个方法论。这意味着看看他们喜欢做什么以及他们认为什么会让他们所有人受益。
例如：通常，当一个团队使用 RUP 失败时，并不是因为他们没有遵循指南，而是因为他们试图遵循所有指南。
一般来说，我认为如果开发商不必做文书工作和后勤工作，那就更好了。要么他们不擅长，要么他们在开发方面会更有成效。
I think you are going it from the wrong side.
First you need to know what kind of team you have. Then start from that knowledge and use the appropriate methodology for your team. Rather than trying to use some methodology for your team. Do a methodology for your team. That means see what they are comfortable doing and what they think would benefit all of them.
For example: Usually when a team failed using RUP, it wasn't because they didn't follow the guidelines, but because they tried to follow all of them.
Generally I think it's better if developers don't have to do paperwork and logistics. Either they are bad at it or they would be more productive doing development.
今天发现了这个有用的链接，关于软件行业的项目交付记录令人震惊。这解决了你的确切问题。
建议您浏览此网站以获得更多想法：
http://behaviour-driven.org/SoftwareIndustryRecordOfFailure
以上是非常优秀的 Dan North 的 wiki，他提出了行为驱动设计的想法（前提：我们的方式认为取决于我们使用的语言，这也可以应用于软件）。
Found this useful link today, regarding The software industry has an appaling record for project delivery. Which address your exact question.
Suggest you browse around this site to get more of an idea:
http://behaviour-driven.org/SoftwareIndustryRecordOfFailure
The above the wiki for the very excellent Dan North who proposed the idea of Behaviour Driven Design (Premise: The way we think depends on the language we use and this can be applied to software also).
首先，Scrum 是一个项目管理流程，因此问 Scrum 和项目管理是否可以共存就像问水和 H2O 是否可以共存一样。
其次，PMBOK 将项目经理角色定义为对项目的成功负责。同样，在 Scrum 中，产品负责人负责 ROI，因此即使这些角色的职责不同，但他们的职责是相似的。 Scrum 避开了命令和控制的管理结构，强调需要自我管理和自我授权的团队，根据工作人员做出并拥有承诺的原则，集体做出承诺并自己履行这些承诺。没有权力就没有责任。在 Scrum 中，产品负责人通过产品待办事项优先级排序和每个待办事项项目定义的验收标准（“这是我需要完成的工作，这是让我满意的功能必须存在”）向团队提供指导。产品负责人对于某件事是否完成也拥有最终决定权；如果团队出于任何原因未能完成积压工作以使产品负责人满意，那么产品负责人可以拒绝该工作。我想说，这使得产品负责人在 Scrum 中成为一个非常强大且重要的角色……在我看来，它是项目成功方面最重要的角色。
您可能想阅读 这篇关于选择产品负责人的博文，了解有关产品负责人角色的更多信息。
Well, first of all, Scrum is a project management process, so asking if Scrum and project management can coexist is like asking if water and H2O can coexist.
Second, the PMBOK defines the project manager role as having responsibility for the success of a project. Similarly, in Scrum the Product Owner is responsible for ROI, so the responsibilities of these roles are similar even if their duties are different. Scrum eschews a command-and-control management structure, emphasizing the need for self-managed and self-empowered teams that collectively make commitments and own delivering on those commitments under the principle that the people who do the work make and own the commitment... no responsibility without authority. In Scrum, the Product Owner provides guidance to the team via the product backlog prioritization and by the defined acceptance criteria for each backlog item ("Here's what I need done and here's the functionality that must exist for me to be happy"). The Product Owner also has the final say as to whether something is done or not; if the team doesn't complete a backlog item to the Product Owner's satisfaction for any reason then the Product Owner can reject the work. I'd say that makes the Product Owner a very powerful and important role in Scrum... IMO the most important role in terms of project success.
You might want to read this blogpost on selecting the Product Owner for more information on the Product Owner role.
我认为我阅读您的文章的方式是 PM 做了 2 件事：
1）创建业务所需的工件（例如合规性）
2）管理项目
就第 2 点而言，该工作包含在 PO 和 SM 角色中。首相继续这样做会增加混乱并损害进程。
至于#1，这是一个至关重要的角色。如果业务需要这样做，为什么不将这些工件的创建添加为“完成”定义的一部分，并将它们作为执行此专门任务的成员添加到团队中。或者，您可以在 Scrum 外部执行此操作，甚至没有人知道它正在发生，然后可能将这些工件提供给 PO。
I think the way I read your post is that the PM does 2 things:
1) Creates artifacts necessary for the business (like compliance)
2) Manage the project
As far as #2 goes, that job becomes encompassed in the PO and SM roles. The PM continuing to do it will add confusion and hurt the process.
As for #1, that is a vital role. If the business needs this, why not add the creation of these artifacts as part of the definition of "done" and add them to the team as a member who performs this specialized task. Alternatively, you could do this outside Scrum with no one even aware that it's happening, then perhaps providing those artifacts to the PO.
Scrum 是项目管理，只是不是项目经理的方式，而是 Scrum 的方式。简而言之，Scrum 的做法与人们对项目管理的看法和看法截然相反。所以，从这个角度来说，我会说不。
另一方面，项目经理可以是非常高效的产品负责人。
Scrum is project management, just not the way project managers do it, but as Scrum does it. In short, Scrum does the compelte opposite of what people think of and are tought about project management. So, from that angle, I would say no.
On the other hand, project managers can be very efficient Product Owners.
答案是绝对肯定的。
顺便说一句，这是一个很好的问题。
有关此内容的更多详细信息，请访问：http://www.blog.pmmetrics.com/#!SCRUM-Traditional-Project-Management-Chaos-in-IT-Industry/uiho7/577428320cf2e26a9986aa33
The answer is an absolute YES.
Great question by the way.
More detailed information on this can be found here: http://www.blog.pmmetrics.com/#!SCRUM-Traditional-Project-Management-Chaos-in-IT-Industry/uiho7/577428320cf2e26a9986aa33