本文要点:
复杂性是隐藏在敏捷要解决的问题背后的关键力量.
过分关注于敏捷的方法层面蕴含着错用, 乱用的风险.
开发敏捷思维的第一步是理解特定环境中敏捷的目的.
了解复杂性的本质以及成功解决复杂性的原则是这种思维模式的基石.
虽然我们需要建立自己的特定环境的方法, 但琥珀指南针 (Amber Compass) 可以作为你踏上旅程的好帮手.
敏捷和复杂 - 幽灵般的威胁
为什么敏捷是一个好的思想? 如果你翻翻 Jeff Sutherland 的书, 它是这么说 Scrum 的: 事半而功倍. 乍一看, 这貌似是一个纯粹的效率问题. 但是, 如果我们询问有经验的敏捷人士为什么他们正在做敏捷, 他们通常会提出一个挑战列表, 在这些方面敏捷比其他方法更加有效: 用户并没有太弄明白自己的需求; 需求随着环境的变化而发生变化; 你不得不在设计中弄个技术替代品; 您的解决方案与许多其他事物相关, 它们都相互作用相互改变; 而且在项目内部, 你也知道会有不可预知的问题和意外. 如果我们看一下隐藏在表象之后的事实: 带来这些挑战的常见力量是什么? 答案是复杂性. 对复杂性进行掌控有一大优势. 一旦我们更加了解我们试图用敏捷解决的问题背后的复杂性, 实际上就明确了我们进行敏捷实践的目的. 这是我们可以建立敏捷文化中共同的关注点和主次概念的第一步.
敏捷方法 - 体系的诱惑
作为与敏捷 IT 组织一起工作的领导力教练, 从我的角度来看, 敏捷的框架对很多能力都有所促进, 从而为复杂性带来帮助: 迭代进度代表每次迭代的适应能力. 这意味着我们可以实验: 试试到底行不行得通, 而不是在分析和逻辑的结论上驻步不前. 同时, 我们通过保留个体的迭代来获得动量, 例如 sprint. 找机会让客户直接参与而尽可能减少中间层的过滤是另一种复杂性能力(我们可以质疑典型的需求捕获是否给我们提供了足够的未被过滤的上下文以及与客户交流的机会). 另一个将是在跨职能团队使用多样化的观点. 或 AB 测试.
但方法和流程有点像食谱: 它们能帮助采用者变得更快, 而不必理解为什么这么做好. 对于一名组织开发者来说, 从这个角度来看这种诱惑是推动整个转变的角色: 我们让人们学习敏捷流程和方法, 并且通过流程和方法逐渐复杂完善来进一步发展组织.
这种吸引力的缺点表现为这些工具可能会得很好, 也可能会得很差. 我们在回顾中选择进行什么明确的主题, 我们在制定待办工作优先级时如何运用我们的判断力, 我们是如何对客户实际需求保持开放的? 这些是理解复杂性本质的地方, 有助于我们做出决定.
例如, 在冲刺的刚性和冲刺变更的开放性上进行的切换, 实际上就是我们在稳定性与适应性之间的平衡. 如果我们做得不好, 最终我们要么会陷入复杂性理论所谓的过早转换(让事情变得过于僵化), 要么就会陷入无休止的沸腾(把事情搞得太久). 但是任何结构性规则都无法准确地告诉我们哪里是正确的平衡点 - 这取决于我们的背景.
上述情况也同样适用于协调开发团队和产品战略层面之间出现的状况. 从复杂性的角度来看, 一个好的策略可以作为一个向量: 即使不可能指出确切的最终结果, 它给了我们一个方向, 它说 "往北走", 然后让团队定义下一步. 但与此同时, 它必须也得清楚 "往南走" 其实意味着什么, 知道应该避免些什么. 目的不明确可能有很多原因. 例如, 有时企业愿景过于模糊: 我曾经在化工行业的一家公司工作过, 他的愿景是 "塑造未来", 这可以表示任何事情, 因此没有什么实质意义. 一个更好的例子就是宝马早在 2007 年就在其网页上提供的 "纲领":"我们在个人移动领域提供优质的商品和服务." 这意味着: 即使是 Mini, 其在该领域的价格也很高, 我永远不会把现代当成竞争对手. 我们不会做公共汽车或卡车. 我们看待服务, 如租赁或临时租赁 (现在作为宝马和 Sixt 的合资企业) 与生产汽车一样重要. 我们不会只去考虑内燃机. 直到今天, 这个愿景仍然有效. 另一方面, 战略导向中未解决的问题可能会对团队层面的效率和敏捷精神造成破坏性影响. 一家软件公司正在从头开发下一代产品. 公司投资者的组成变化频繁, 他们的现有客户希望利用新一代产品的前景来对现有合同进行谈判, 这些合同非常大. 因此,"先为大企业客户替换已有产品" 还是 "先进入大众市场, 之后再进行大客户的迁移" 之间出现了方向性的摇摆. 这些不安全感和优先事项变来变去会对 "敏捷" 造成致命性打击, 导致软件开发缺乏重点而非常低效. 战略没有起到应指明方向的作用.
心态的回归
因此, 为了避免掉入这一陷阱, 盲目地适应过程和方法, 有些事还得靠个人判断, 我们开发自己适当的思维方式就很重要了. 敏捷宣言是一个解决思维问题的陈述, 并且非常有意识地避免人们把它当成食谱之类的书籍来用. 我已经看到团队以此获得了收益, 他们返回头来重新审视宣言中的 12 条原则, 并找出这些原则对于他们来说意味着什么. 同时, 这是一个规范模式: 一些声明说 "这更好" 或 "做这个". 如果我们想将它应用到我们自己的情境中, 我们必须针对每一个陈述研究为什么它是一个好主意.
这是创建目标感和共同关注点再一次发挥作用的地方, 也正是对复杂性本质的理解派上用场的地方. 有个人在半年前参加过我的培训, 他告诉我说:"我现在以不同的方式看待现状." 就像他所说的: 它不是一个精确的工具或方法, 而是一种能够在特定环境中产生特定影响的能力. 结构框架和个人背景之间的总还是存在着距离, 让我举例说明一下适当的思维模式是如何予以弥补的.
我曾经不得不把一个光纤电缆退回商店, 因为不知怎么他们向我出售了一个我根本就用不上的路由器插座. 因为当时我正在忙着搬家, 所以我比规定的退货期限晚了 30 天. 好在, 这位售货员得到了处置退货的授权, 最终他接受退货了. 能达到这种高度自治的原因正是品牌所处的高端地位. 但如果他这么做呢: 首先, 他不相信我的解释, 然后他问老板行不行, 然后他几乎是在指责地对我说, 因为经常有客户试图骗他们拿钱, 吧啦吧啦...... 于是, 品牌形象就被毁了. 如果你从管理者或教练的角度来看待这种情况, 你会发现这种行为不能被结构性工具所管控. 你作为一个团队, 需要有一个明确的目标, 然后定期将目的与这些例子联系起来, 并讨论你的行动方式. 你永远不会得到一个明确的结论. 但是, 如果人们对十几个这样的例子练习了自己的想法, 那么在下一个大致相仿的情况下, 他们会以更好的方式行事.
企业灵活性 - 对通用语言的需求
当我们考虑在整个企业范围内扩展敏捷时, 组织结构和开发思维模式之间的关系就显得非常重要了. 敏捷的核心是软件开发. 如果我们想将其扩展到企业敏捷性, 那么仅仅教导每个人过程和方法就完全不够了. 我听说过一家制药研究部门, 他们在三个小时的研讨会中介绍了 Spotify 模型, 并认为这项工作已经完成. 对我来说, 这看起来完全就是个僵尸敏捷. 我们需要解决思维方式, 更具体地说, 就是敏捷 "为了什么", 以便人们可以将转变的目的与他们的需求联系起来. 人们希望有足够的理解, 以便他们可以决定哪些方法可以转化到其他环境中, 哪些方法需要构建自己的敏捷框架, 甚至敏捷在什么情况下并不是个好主意.
在我的一位客户的电信公司中, 他们在组织发展的宏观层面上做到了这一点. 他们允许 (不是命令) 本地实验与各种不同的组织结构. 他们将组织的制约因素保持在公开的范围内, 指出不够严格的地方, 有时候组织各部分之间的兼容性成了问题. 他们决定长期处理这个问题, 直到几次实验都没了什么新鲜感, 达到了足够成熟的程度, 可以根据 "如果我们可以重新开始, 我们会..." 这样的句子来得出正确的结论. 在此基础上, 他们现在正在鼓励一个更加标准化, 且多种组织管控形式浮现出来. 在下一阶段, 预计那些对他们的实验不满意的组织将融入新标准. 在整个行动过程中, 这要求许多关键人员对多样性要有耐心和宽容度. 但与此同时, 盲目的官僚主义和抗拒变革的力量也被控制在最低限度.
如果我们想要这些开放的, 上下文相关的转换发生, 就需要一个足够抽象的共同语言, 这样公司中的许多不同背景就可以映射到它中, 但同时又足够清晰, 不必花太多额外的努力, 人们就可以从共同的概念中出发, 并将它们转化为明天在自己的环境中可以做的具体事情.
这就是琥珀指南针(Amber Compas) http://www.palladio.net/managing-complexity/the-amber-compass/ 发挥作用的地方: 它是一系列帮助组织内各级人员掌握复杂性的原则, 活动和工具.
能力扶手 - 琥珀指南针
琥珀指南针就像是一个扶手, 可以引导您朝着正确的方向发展, 而没有太多的规定, 可以将其视为以特定方式邀请你进行思考. 它吸取了很多 Dave Snowden 的工作成果, 事实上, 来自 Cognitive Edge 的一些人已经参与了其早期开发. 核心, 是我们对复杂性的理解, 以 Cynefin 框架为代表. 这是一个良好的开端, 因为它是一个应急模式; 而不是说 "一切都是复杂的, 因此这样做", 它说:"根据不同的情况, 选择适当的行动线". 如果我们以此为开端, 更多地了解有序和复杂之间根本不同的内容, 我们就走上了开发我们理解复杂的心智模型之路.
下一个周期包括帮助我们把注意力集中在行动上的原则. 与上述几个相关的敏捷示例是: 消除过滤层, 调整粒度, 以及令自主性保持一致: 我们如何委派决策权, 以便组织可以对不可预测和异常的事件做出反应, 同时保持行动上的统一? 我合作的一家半导体行业的公司, 我们正在慢慢将更多的决策权下放到前线. 同时, 我们必须努力提高商业运作的共同意识, 以及因此应该共同关注什么. 我们不是通过常规的指令来做到这一点, 而是增多了对现场实例的共同讨论.
最后, 外环代表我们可以参与的活动, 其中一些我们也提到过: 实验或管理限制. 当然, 指南针的指示只能作为备忘. 但即使解释了每个关键词, 它的工作方式也允许多种多样的途径, 方法和工具, 同时也让我们知道要遵循什么方向. 因此, 罗盘本身就是一个向量, 并且适用于许多环境. 这里有一些例子:
有一家公司, 无论出于何种原因, 一直拒绝将一项战略提交到纸面上, 一名人力资源发展主管意识到, 他不得不围绕他的系统进行更严格的 "管理约束", 例如胜任力模型, 领导力开发项目等, 因为这些改变起来很慢, 而且要付出高昂的代价. 于是他制定了一项人事发展战略, 成为许多其他单位和流程的非正式锚, 这些单位和流程必须连接到稳定的东西, 从复杂性的角度来说, 他创造了一个吸引子.
一位硬件测试经理为了减少关于内部单据的抱怨, 将一条因过于严格而很不适用的边界法则 "如果我们的内部报价在测试之前没有书面确认, 测试就会被取消" 替换为一条更灵活的经验法则, 即向量:"始终确信内部客户有切实的期望."
我甚至从小学老师的角度召开了关于 "探索 - 开拓" 活动的讨论; 它关乎的即是在惯例之间的平衡, 这些惯例可以有助于迅速完成班级设置, 而新颖的, 个人的, 有时是自发的课程设计, 可以更好地适应某种特定的情况.
在我看来, 这就是扩大整个企业灵活性的关键. 我们需要远离方法和结构, 了解我们的环境如何工作以及需要关注什么, 然后我们可以回过头来决定复制哪种方法, 以及如何以不同的方式进行操作, 但同时又保持兼容.
从这里为起点: 发展你自己的复杂性 - 感悟
琥珀指南针和围绕它的复杂性导航训练就是试图去覆盖地图上那一点点白色斑块. 你会发现在复杂性方面有许多东西仍然非常学术和理论. 为了弥补这种差距并付诸实践, 还有很多工作要做, 不要陷入食谱式应用的陷阱. 我们尝试使用纸牌来做这些. 它们让你讨论实际的日常经验, 如交通或邻居, 并将它们与复杂性联系起来, 这样当最终你看到一个理论框架时, 就会针对自己已经下的结论找到通用标签. 例如, 我们在 youtube 上放置了一段视频, 让您可以通过不同的购物方式探索 Cynefin 框架 .
如果你更喜欢看书, 我推荐几本书, 有罗伯特. 阿克塞尔罗德 (Robert Axelrod) 和迈克尔. 科恩 (Michael Cohen) 的驾驭复杂性(Harnessing Complexity), 以及让博尔顿, 彼得艾伦和克里夫鲍曼的拥抱复杂性, 或者 Dave Snowden 的许多 YouTube 视频. 我还喜欢关于实际案例的书籍, 如 Stanley McChrystal 的团队中的团队,Yves Morieux 的六条简单规则, 以及 Niels Pflaeging 的Complexitools.
我看到的一个缺点是, 我们最终会得到一束花, 但我们缺少的是秩序. 让我们来解释一下: 你最紧迫的问题是 "好的, 但我现在在这里能做些什么?", 并且在复杂的背景下, 你对这个问题没有一个通用的答案. 但我们可以尝试让它更容易. 我希望琥珀罗盘能填补这一空白, 起到类型案例的作用; 它为我们提供了一个将我们的例子和想法变成秩序的地方. 因此, 我们可以掌控自己的学习周期: 尝试一种特定情境的方法, 带来一种特定于情境的体验. 我们将它与一个通用的类别或概念联系起来, 以便当我们与他人交谈时, 或者当我们将另一个上下文链接到这个类别时, 再次把它找出来. 然后, 我们不只是原样复制我们的方法, 而是考虑如何使用和调整我们的经验, 使之能够应用于新的上下文. 例如, 这就是为什么在诸如冲浪, 单板滑雪和滑板等体育项目中, 一个领域的发展很快就会使另一个领域出现新的但又截然不同的发展. 如果你喜欢, 可以把它称为有意识的好奇心. 随着时间的推移, 你会变得越来越好.
来源: http://www.infoq.com/cn/articles/navigating-complexity