早在2014年，我就采访过先锋集团(Vanguard)的信息官John Marcante，向他提问了培养领导力的方法，当时我很想了解他如何在新的数字技术领域中发展IT组织。在采访开始前，我了解到，如果敏捷开发运用得当就可以增加软件的产出，减少缺陷并确保技术与业务成果之间紧密结合。但是，在交谈中，我了解到，敏捷也可能对员工敬业度产生重大影响。
但是Marcante认为，在雇用敏捷顾问并开始培训之前，请确保你的技术环境能够应对持续交付的难题。
Martha Heller：为建立一支敬业的IT员工队伍，你做了什么?
John Marcante：我们制定了一项“新工作方式”计划，业界称该计划为“敏捷开发”。真正的敏捷始于组织的最高层，我的老板，也就是执行官兼董事长Tim Buckley致力于创建一个敏捷的组织。我们致力于建立一种以结果为导向，跨职能的团队文化，这些团队可以测试，学习和快速发展。
我们还从基于项目的方法转变为基于产品的方法，由专职的业务专家来充当产品负责人。我们使这个人与“全栈团队”为伍，因为这个团队将实现结果所需的所有十八般武艺结合在一起。产品负责人负责指导团队取得业务成果，例如提高潜在客户的转化率，而不是按时交付项目。
领导者的职责由于敏捷和产品管理而发生了巨变。在项目模型中，**者通常以命令和控制的方式来管理成本，进度，功能和交付，但这已经是老黄历了。当今的**者在增强员工敬业度的同时也放权给团队，取得恰当的成效并排除万难。
自动化的持续交付正是人们开发软件所希望采取的方法。他们希望在跨职能团队中互相学习。他们希望能取得重大成果，而不是仓促编写一定数量的代码。他们希望看到自己的工作所带来的好处，并且希望立竿见影。
你对正在寻求新工作方式的信息官有什么建议?
因为人们都希望在可以持续交付的环境中工作，所以没有合适的技术基础架构就无法实施敏捷性。你可以用“敏捷吊舱”来组织团队并开发软件，但是，如果该软件在发布前一直无人问津，那么这不算持续交付。千万不要这么做——创建一个跨职能团队，指派他们实现一个成果，然后对这个团队说：“祝你在季度发布时好运”。你最终必须重构那些旧的应用程序，以实现连续的交付周期。
多年来，我一直强调，敏捷不是一项IT计划，这是全公司的事情。话虽如此，但身为信息官，我们必须为好马配好鞍。如果你延迟发行，你就会使人气馁，IT就会沦为绊脚石。如果你几年前问我，我会认为变革管理是顶梁柱。实际上，有了敏捷，技术才是顶梁柱。
敏捷还要求人们承诺为组织培养新的技能。不要用了解敏捷的人来取代你所有忠诚的员工。我对此已经见惯不怪了，这么做大错特错。因为你再也无法获得员工的忠诚和敬业。我们正在走更为艰辛的道路，即将我们现有的组织转变为敏捷型组织并提高员工技能。
你曾经提过，要真正实现敏捷性就必须具备合适的技术。为了将环境现代化，你都做了些什么工作?
从2014年开始，我们豪赌云技术。我们先在云架构上花费大量时间，然后再到公共云执行操作。一旦有了合适的架构并选择了公共云提供商，我们便决定在公共云开展所有的开发工作。
现在，我们设计了业界称为API的可重用组件，以便我们可以轻松地在全世界分发软件，从而自动对功能进行扩展。如今，我们三分之二的开发团队都在这种持续交付的环境中运作。
当我们转向连续交付模式时，有董事会成员问我：“你快速部署软件的同时保证质量和安全性吗”?我回答说“是的，我们可以保证”。当你使用连续交付管道时，你可以在开发人员每次修改软件时自动测试质量并检查安全风险。你可以在几分钟(而不是几周)的时间内自动运行所有功能和回归测试，而无需业务和IT手动测试软件。
此外，你可以在软件开发过程的早期自动运行所有安全检查。这比让安全架构师屡次检查代码或在最终交付软件前检查代码的做法更好。以前，在过程后期发现的任何安全风险都可能会导致不能向客户按时交付软件!自动化的安全检查可以节省时间并降低风险。
有了自动测试和检查，我们还见证了可衡量的交付速度提高了。到2019年8月，我们已部署了比2018年全年还要多的业务功能。这是敏捷，持续交付和大规模产品管理所带来的成果。
你如何知道敏捷计划正在使员工更敬业?
2014年，我们在参与度评分方面落后于内部和外部基准，如今，我们在这两项指标上均**。改进催生一种文化，这种文化强调员工敬业度，使员工可以互相学习并看到工作收益。我们收到大量来自员工的推荐，这也是一个很好的措施。我们的技术员工鼓励自己的朋友来这里工作。
