舒级敏捷与书籍scrum不一样
几年前，天啊，可能比现在还多，我开始想到Alistair Cockburn的《Shu-Ha-Ri》。Alistair在《Crystal Clear》和《Agile Software Development: The Cooperative Game》中谈到了这个概念。虽然我已经好几年没有读过这些书了，但在我的脑海中，“舒”的意思是初学者，“哈”的意思是熟练工，“Ri”的意思是大师。
这个想法是，当你刚开始的时候，你需要遵循一种做事的方式。随着你的进步，你会发现这种方法的局限性，最终你会发现还有其他方法可以达到同样或更好的结果。一旦你掌握了技巧，你就会不假思索地融合和适应各种方法。这就是学生成为大师的地方。
但是，我经常听到人们使用Shu-Ha-Ri的想法来要求新的Scrum团队遵守Scrum的规则。从某种意义上说，这与Alistair在《敏捷软件开发》中对Ron Fox的引用相当一致。蜀道水平的学生在没有完全理解为什么的情况下复制技术，而且蜀道意味着对单个导师的忠诚(第18页，第二版)。
当我们学习一定的武术风格时，我认为这很好，但是当我们将流程或方法应用于复杂的业务问题时呢？亚博vip9通道如果教师的教导不起作用怎么办？如果教导不适用于我们的上下文，该怎么办？如果学生盲目地应用了教导，而不理解为什么和没有修改？
我认为我们中的一些人已经将舒的概念带到了太远。我认为我们中的一些人带来了一定的傲慢，相信任何一种方法都适用于任何给定的学生在任何特定的背景下。也就是说，我确实相信，随着学生，我们通过学习通过Shu-Ha-ri进程进行了进步......这只是我的Shu在进程过程中不一定是你的舒。
我总是教导舒意味着初学者必须有一种方法可以工作。如果我们向前推出初学者的选择太多，他们将不知道如何选择，可能不堪重负。随着学生获得经验，一种方式将不可避免地有局限性和需要适应。一旦学生掌握了掌握，他们就可以根据需要调整和混合技术。
假设我想把敏捷引入一个大型复杂的组织，就像我在我的最后一篇．我可以整天教导团队水平Scrum，但它不会解决他们的基本业务问题。亚博vip9通道问题对于团队级Scrum来说太大而过于复杂。对于这个组织，舒级方法可能是Leffingwell安全模型的实施。
虽然安全比Scrum更复杂，但对于更复杂的企业需求可能是最小的。
主导聘请组织，我们将带来Scrum，XP，Lean，Kanban和安全的技能和体验，以混合一种方法，这些方法可以在最小地以规模运行该特定的企业。从接收组织的角度来看，这种方法是舒级实施......甚至认为我们已经带来了HA和RI水平的理解，以帮助制定解决方案。
即使我们有混合方法来创建舒级实施，也有更多的选项可用于解决更复杂的问题。由于客户学会，他们将学习我们舒级实施的局限性，并开始调整自己的进程。这是HA级别的理解。及时，在实践中，组织将掌握和实现ri。
总之......不要将企业敏捷的舒尔级实施与逐书实施混淆。您的组织可能需要更高级的机制来规模实施敏捷。您需要的是始终如一的方法的一种方法。一旦你有那么工作......你会学习，检查和适应，并使其成为自己的。
看看下一个帖子，你应该使用敏捷来建立你的下一个家吗？
查看上一篇文章，如何构建敏捷企业．
评论（11）
乔治·迪维迪
好贴！
正如Rob Myers在Twitter上总结的(https://twitter.com/agilecoach/status/432218029640777729）“舒不是”基础“，而是一种方式。”当对组织进行敏捷时，老师也需要一种“工作的方式”。严格“通过书”不是这样。如果书就足够了，那么就不需要老师。如果他们的情况类似于发明Scrum的情况，则Scrum的逐书实施可能只是一个组织的起点。然而，我怀疑赔率很低。
在准备教学之前，老师需要非常擅长敏捷。教师需要帮助组织找到当前“有效的方法”，考虑到组织中目前正在发生的一切，参与的人，以及他们目前所知道的。这是他们的起点。这并不能使他们有能力教导他人。作为教师，他们还没有达到蜀的水平。知道做敏捷的方法和知道教敏捷的方法是不一样的。
对我来说，这就是问题的根源。许多成功采用敏捷的人现在认为他们已经准备好成为其他人的敏捷教练了。他们已经成功了，只有一次。同样的过程实施和同样的学习方式不太可能在他们发现自己的下一个情况下起作用。
我是一个点在一个点的一部分，这是一个激发了帖子的原因;-)谢谢你的评论乔治！
亚当·塞尔顿
我同意乔治和他的大部分观点。
我对舒河日作为教练模式的看法是，我去过很多地方，那里都有一个明确的“舒河”过程。或者咨询我代替定义了“蜀”,明确地告诉我,他们会监督我,确保我不污染他们的“蜀”(再次放弃,这个不是LeadingAgile)但也有一些客户了解月从以前的教练,说“你可以进来,但是你会做“客户的方式”这是我知道迈克has experienced. Interestingly when I did not do things in this way but saw successful impact that client wanted me to codify my methods so they could use it to define the new “Shu” for the entire enterprise.
我想学习武术时，它会完全意识到我不应该从“舒”转移，所以我不会伤害自己或他人。与专业成年人合作时，他们更加了解他们在组织内的背景和问题上的知识是愚蠢的。我遇到了人们所说的“我们觉得是浪费的，我们认为我们已经解决了这种问题。”我说过“好的听起来很好，为什么我们不列出东西旨在解决，并在消除后看他们是否忽视。”那些喜欢乳头的人然后说“你说什么？！难道你不知道为什么你应该强迫那些人这样做的仪式？！“最后，我认为包括成人专业人士在他们的过程中被指导合作，作为合作伙伴和可信任的顾问在教条的舒哈·ri面前飞行。我也担心当我看到在没有转移的“蜀进程之后的其他咨询公司的客户”时，不仅完全从自己的过程中脱离，而且没有为什么他们正在做他们正在做的事情。
Praxis可以是一种更强大的方法，帮助人们了解解决实际问题的理论，然后练习这些理论。当事情失败时，他们更有可能理解为什么并且能够改编新的东西而不是继续下行规定的道路。
所以本质上，我不认为这个军事的比喻足以证明虐待的痛苦。我想这就是你在你的帖子里说的，谢谢你。：-)
艾莉森
这似乎是我们的晚餐谈话的延续。作为教练的简单愿意，专注于获得舒的团队，但一个充满舒球队的组织不会使组织本身舒！随着蜀队的组织，教练和本组织随后对上下文和障碍有更多的洞察力，以增加达组织舒的其他实践/流程/任何所需的行为/进程。
乔治·迪维迪
亚当，在帮助新团队时，我的主要目标是帮助他们观察他们的表现以及他们的选择是什么作用。在旅程中可以想象一些决定的后果可能很困难，所以我分享了我在别处看到的东西。
你描述的听起来像死胡同。它根本不会听起来很敏捷。我经常遇到只想经历仪式的人而不寻找这些仪式应该提供的好处。我经常看到高层管理层询问敏捷“通过书”，而不意识到自我组织（书中的原则）在饼干模板之后排除。
Fredrik Vestin.
我想这取决于组织来自哪里。如果组织没有任何敏捷/scrum经验，我会认为尝试“按书”做事情是正确的开始方式。帮助组织理解游戏规则，理解规则的重要性。否则，我就会看到“挑拣”的风险。例如，我们做scrum，但没有时间做专门的SM，复古花了太多时间，所以我们只能每隔一个sprint就做一次，工作被分配(这个列表会一直持续下去)。遵循这些规则的价值在于，它经常暴露出组织中隐藏的/变通的功能障碍。一旦他们得到了它，进化和创造/打破规则。
Scrum不是非常规范性的，并且巧妙地少量规则，允许它在广泛的上下文中使用。
亚当，谢谢你的评论。我全心全意地同意我们需要倾听客户并帮助他们弄清楚一个适用于它们的过程的SHU水平表达。再次......我认为Scrum不是舒级敏捷，其中有很多经历的问题。该公司已将其蜀级实施作为唯一的蜀级实施。如果我们与客户合作拿出独特的东西，我们仍然可以实现这种方式......只是它不是我的方式，或者是Scrum的方式，甚至完全是客户的方式。这是我们所有人都同意的一种方式，并准备尝试。在我们开始调整之前，我们持续多长时间，这一切都取决于组织的成熟度，但这可能是不同帖子的主题;-)很棒的评论！
艾莉森......同意，现在已经在我的脑海里几个星期了几个星期;-)即使在团队层面，Shu可以对不同的球队不同。许多公司使许多公司的错误是他们采取蜀级团队实践，并假设他们对更广泛的企业和IMO是一样的，假设几乎从不持有！
乔治......我在我们的练习中找到的是，在大型复杂的企业中，有这么多的企业废话，他们几乎没有办法他们可以自我组织成一个类似于敏捷团队的任何东西，而不是完全从其他人围绕着自己的围场组织。我已经看到这种模式尝试过多次失败，因为新团队不能长时间在这种外部压力水平的情况下存在。我们的方法是让人们尽可能快速地安全地从点A到B移动。就个人而言，我很好，敏捷不是在旅途中迈出的。我经常将基于团队的迭代和增量模型进行敏捷。它将让我们在那里的一半以上，在转换中创造较大的企业的安全，并允许新团队进行表格，交付，并开始实现敏捷方式的一些好处。他们无法检查和适应他们想要在这个阶段，因为组织其余部分有太多的连接点。由于企业开始在这些团队周围转换，因此可以有更大的开放来放手，彼此偏离这些团队的产出;并允许更多的紧急结果，更多的检查和适应和基于团队的自组织。 Many of these legacy organization are on a multi-year journey to really move the entire enterprise. In that context, I think some Shu level practices that allow the agile enterprise to begin to emerge and form is perfectly acceptable and not inconsistent with our end goals. Sure… probably not agile in the sense the word is often used. But can definitely lead to more agility in an enterprise context. Great post, thanks for the comment.
Fredrick ......我认为他们也应该用这本书敏捷。问题是谁的书？肯桑普勒的书？杰夫·萨瑟兰的书？Alistair Cockburn的书？吉姆初中的书？Dean Leffingwell的书？Mike Cottmeyer的书（尚未写入它）或他们自己的书籍如何创建以上任何或全部的指导？这就是这篇文章的重点。在敏捷中，这本书的作者就是“事实”。 Finding one way that works matters. If we have one way that works, and we follow that way consistently, and without adaptation… at least initially… we have a greater chance of being successful.
Sridhar.
迈克
我谈到了PPL，发现了敏捷作品的味道。
企业敏捷转换意味着顾问(或任何指导人员)需要是一个现实主义者，而不是一个“纯粹主义者”。大多数组织不会放弃他们现在正在做的一切，并从敏捷开始。瀑布模型和许多其他模型将共存，甚至敏捷实现也将有一个“过程包”围绕它们。
从舒到哈来难，因为心态，文化甚至org结构需要改变（绩效评估，任何人？）。