Ed Toner不仅希望他的IT员工能够接受敏捷原则，也希望他的业务部门的同事能够这样做。
因此，内布拉斯加州的CIO Toner在与它所服务的州的各个部门签订的合同中，都规定了敏捷原则(特别是需要他们持续参与软件开发和部署的部分)。
他解释道:“项目能否成功完全取决于你对这个项目的参与度，合同上就是这么说的。”他指出，大多数部门主管现在都已经明白，要么成为项目的合作伙伴，要么接受项目失败的可能性。
这是现实，Toner说。
“我们当中有一组人只是一味地发送需求;但他什么也没做，所以其实他没什么可抱怨的。这是一个极端。但是我们还有其他人会过来看看情况如何，这些最终变成了非常成功的项目，因为他们受到了足够多的关注，”他补充道。
像今天的许多首席信息官一样，Toner将敏捷思维带到了他的企业IT部门，以此来确保它实施和支持的软件能够最大限度地满足组织的需求。
然而，首席信息官和管理专家表示，创建敏捷企业不仅需要在IT部门实施敏捷方法。经验丰富的领导者同时表示，最成功的敏捷环境是企业业务部门也采用敏捷原则的环境。他们说，要做到这一点，最好的办法就是让CIO来带头。
Toner已经接受了这个挑战。正如他所说:“我向他们展示了如果以不同的方式工作将会如何受益。”
让业务部门也参与进来
三年前，当Toner成为该州的首席信息官时，Toner开始了他的敏捷实施，将IT团队从使用瀑布式方法转移到今天的敏捷和瀑布相结合的策略。他整合了IT基础设施以更好地支持敏捷方法。他也引进了熟练使用面向敏捷的编程语言(如.NET和Java)的工作人员，让他们在有400名员工的IT部门教授其他人语言和敏捷原则。
他还提到了合同语言，明确了其他部门需要如何参与敏捷原则以确保项目的成功。“我们在开始使用敏捷的每一个项目时，都会谈论业务相关方参与流程的必要性。我让每个机构的主管签署这份合同，并致力于这种发展方式，”他说。
Toner提供了早期的胜利，展示了IT使用敏捷所产生的更好的结果。
“为了让业务部门也参与到敏捷当中，我必须向他们证明这一点。这在很大程度上是一种心态上的展示，”他说。“但是在项目做了一年左右的时间后，有消息说我们将在几周内交付产品，而不是几个月。这时候，敏捷自然而然地开始被所有人所接受了。”
培养敏捷文化所面临的挑战
首席信息官需要在整个企业中培养敏捷，而不仅仅是在IT内部，这是有充分理由的。
在业务单元中引入敏捷，可以确保IT更好地了解业务需求，从而更好地与业务目标保持一致。它可以确保整个组织从其IT投资中获得更好的价值。Scrum.org的首席执行官兼产品负责人Dave West表示，这有助于企业更好地利用技术实现转型。West谈到敏捷意味着能够迅速为市场带来变化。
但是在整个企业中推广敏捷的确是一项挑战。
首先，“敏捷”这个术语本身就让人感到迷惑。首席信息官和IT团队将它理解为一种方法论，而在传统词典的定义中，业务部门可能将它理解为具有快速移动的能力。
因此，首席信息官需要帮助其他高管理解敏捷是一种交付应用程序的方法，它需要业务部门和IT部门以新的方式合作。首席信息官需要向他们的同事推销这种新的合作关系。他们必须做到这一点，而不是通过背诵敏捷宣言或滔滔不绝地使用技术术语来让自己陷入困境。
与此同时，首席信息官和IT部门却仍在为敏捷原则本身而奋斗，大多数人仍在为在IT内部更全面地实施敏捷实践和支持技术而努力。West估计，大多数(70%到80%)的企业IT部门在某种程度上对他们的一些软件项目使用了敏捷原则，但是还有许多项目依旧被遗留技术所阻碍，旧的组织文化仍然将IT视为仅仅是用来提供商品服务的成本中心或者其他。
West补充道，这使得IT很难变得敏捷，因为当他们试图以敏捷的方式工作时，可能会遇到来自业务部门的阻力。
“例如，当你正在进行为期两周的冲刺时，你可能希望企业能够迅速做出决策，但是业务部门可能会说，‘哦，不，我们还有更重要的事情要做，’”West说。
与此同时，推动敏捷企业的首席信息官还必须挑战根深蒂固的孤立思维文化，即每个部门都只关心什么对自己最有利，而不是了解其需求如何适应整体组织的优先事项。
敏捷的好处和局限性
Denis Goulet正在将他在商业软件开发中的敏捷经验带到他作为IT部门专员和新罕布什尔州CIO的职位上，但他在构建敏捷企业时遇到了各种障碍。(他将敏捷企业定义为“致力于增量交付和拥有相互问责文化的企业。”)
他说，一些商业领袖不愿意担当产品负责人的角色，因为他们已经被IT在开发冲刺期间所需要的时间所淹没。
“我们问的问题越来越多，这让人们很恼火，他们会问，‘这真的是最好的办法吗?’”他说。“在持续交付模式中，人们可能会感觉到你对他们的要求越来越高。但其实你并没有。你只是在项目的整个过程中逐步提出问题，而不是放到项目末期。但是迈出这一步才是最困难的。”
Goulet说，他一直在努力让企业接受敏捷，同时也在克服这些障碍。在这个过程中，他借鉴了敏捷的经验，寻求渐进式和可持续的改变。他创建了业务和IT的联合小组，期望两者能够共同解决问题。他提高了团队的权限和责任，让团队成员知道他希望他们能够尽早地发现并解决问题，而不是推迟到最后。他确立了一个渐进式交付的标准。他强调了这些变化以及它们将带来的成功。
“我做了很多宣传工作，”他说。“我不会说我们都必须实施敏捷，而会说怎样才能让大家做得开心。我从来不使用敏捷术语。我通常会说，‘我们会这样做，这样做的风险会更小，成本也会更低，而且会让用户更早地获得好处。’”
最终其他人也会认为首席信息官需要采取这种方法——实施敏捷并取得成功，然后与他们的管理层的同事分享这些成功案例，让他们接受这种新的工作方式。
“这需要一个更像推销员、企业家、更能推销新思维方式的CIO。你应该用直白的商业语言谈论价值、结果和业务挑战，并尽可能远离方法和技术。”Ralph Loura说道，他曾是首席信息官和首席技术官，现在是成熟公司和初创公司的技术顾问。
他补充道:“在我看来，最常见的工作不是在整个组织中发起大规模的敏捷活动。这太抽象了，无法有效推广。相反，成功的首席信息官会培训五六个人，然后挑选几个小项目，让他们以一种非常友好的方式实现这一目标。然后你就可以拥有足够的动力，并带动整个组织。”
他说，我们的目标是开发一个遵循敏捷原则的企业(即使他们不使用术语)，我们不需要谈论旧系统或IT积压项目，只需要说，“我们有一系列的选择，可以根据优先顺序进行选择。”
IT和业务的平衡
不过,咨询和服务公司StarCIO的总裁兼首席信息官Isaac Sacolick，同时也是《推动数字化:领导者通过技术实现业务转型指南》一书的作者，他警告说不要将太多的敏捷方法强加于企业。
他说，首席信息官的确需要企业能够理解敏捷原则带来的价值主张，首席信息官需要企业领导者成为产品的负责人。
因此，首席信息官需要带着他们的同行们一起踏上征途，这样他们就可以帮助识别那些具有正确思维和气质的员工来承担产品负责人的责任。CIO必须与业务领导者合作，确保他们能够以支持敏捷开发的方式工作。
“当你采用敏捷交付的时候，你要弄清楚一些文化问题是如何区分优先级的，以及什么是最小可行的产品。这需要一个最了解价值主张的人(即产品负责人)与技术团队进行紧密合作。”他说。“但同时，敏捷所要求的很多东西需要IT经理、开发人员、测试人员、Scrum团队的紧密配合。这是一个非常典型的IT执行案例。”
Toner对其中所需要的平衡了然于胸。
他说他并没有对敏捷的想法进行长篇大论的解释，而是试图向业务同事推销他们通过不同的工作方式所能获得的价值。他认为这是一种选择，要么是参与较少、等待时间较长的传统方法，要么是一种新的合作方式，他们将在几周内推出新功能，支付较少，但需要更多的参与。
即使是心有不甘的商业领袖也会被这种方式吸引过来。Toner引用了刚刚提交要求的那个部门负责人的案例。Toner在项目交付后联系了他，询问他是否认为更早、更频繁地参与进来会有助于他帮助IT确定更多需要的特性和功能。回答是肯定的。
Toner说，这种共识正是他在企业中推广敏捷的方法。正如他解释的那样:“我想要传达的信息是:要想实现自己的目标，有时候找到一个合适的方法是非常重要的。”
京公网安备 11010502049343号