想敏捷吗? 转变您的人员功能

在当今的软件行业中,有许多组织希望成为敏捷组织。 CEO和CTO希望在其传统的瀑布式组织中实现敏捷转型

他们通常的方法是与知名的敏捷咨询公司合作 ,这可以帮助他们实现这一转变。 咨询机构(如果需要的话,可以是…或“变革代理人”)向他们展示他们需要采取的步骤,为敏捷而需要遵循的流程。 的确,在过去十年左右的时间里, 敏捷转型工作已成为咨询行业非常赚钱的业务。

然而,许多这样的转型演出却失败了。 变更代理人无法带来所需的变更,或者一旦顾问的工作结束,组织就会恢复其旧习惯。 有时候, 一些项目团队能够在日常工作中采用敏捷实践,但是这项工作旨在实现的组织转型并未实现。

发生这种情况的原因有很多(…组织间政治;咨询机构在尝试实施敏捷实践时变得教条主义;咨询机构没有获得影响交付的自由手……等等),并且每个机构都应进行单独分析自己的。

但是我觉得其中一个重要原因是对敏捷的误解,认为它是“过程”而不是“思维定势”

在我作为招聘人员的职业生涯中,我曾与许多人(……具有广泛的经验水平……)交谈,他们声称自己在做敏捷……或想做敏捷。 我已经与那些认为自己的组织在敏捷方面做得不够好的人进行了交谈。

这是因为许多人以及因此的组织相信,敏捷是关于在软件生命周期的各个阶段遵循一系列有益的流程和礼节。

假设如果团队以某种方式执行需求收集,评估,设计,开发,测试,部署或发布,那么它就是敏捷的。 重点是学习这些方式。 故事板,迭代计划,站立会议,scrum,结对编程,TDD,自动化,CI,CD,每两周发布一次等。当组织希望变得敏捷时,它会聘请顾问来向他们精确教授这些实践。

尽管这些实践至关重要,但事实是,项目(……和组织……)并不敏捷。 他们要么敏捷,要么不是

敏捷不仅是这些实践,而且是这些实践背后的人们的思维方式。 因此,组织只能像其员工一样敏捷。

以配对编程为例。 如果您的开发人员不愿意在同一段代码上一起工作; 如果他们没有开放的心态来提供和接收有关其代码的反馈; 那么他们就不敏捷。 即使他们遵循“实践”。

而且,如果您的组织有将人视为“资源”的心态,那么迟早就会将结对编程视为浪费“资源利用”。

如果您的团队在沟通中既不透明也不接受反馈,那么您的忙碌,站立和回顾将毫无意义。 它们只是一种仪式形式。

即使要做TDD,团队也需要在思考代码之前建立思考单元测试的心态。 他们需要建立使用单元测试来驱动解决方案设计的心态。

很多时候,组织倾向于通过设置那些“酷”的开放式办公空间,将自己改造为平坦的层次结构,甚至让团队通过敏捷/ Scrum认证来复制典型敏捷公司的外观。 但是,如果这些组织中的人员(尤其是领导人员)拥有分等级的思维方式,那么他们将永远不会敏捷。

从情节提要到DevOps的所有内容都需要转变观念。

这就是敏捷转型的真正挑战。 学习或遵循新的做法可能很困难,但是改变心态要困难得多。 变革演出失败,因为变革推动者无法改变组织的思维方式。

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

那么,敏捷转型如何成功?

在我看来,答案在于敏捷宣言的 最初重点人员 工具和技术的 互动

如果您希望您的组织变得敏捷,请先认真考虑一下您的员工及其互动方式。

要敏捷,您需要以下人员:

  • 思维开放,能够改变他们对软件工程和交付的看法。
  • 热衷于在每个项目中学习/采用新的实践,技能,领域和技术。
  • 欢迎不断变化的需求,即使在开发后期也是如此。
  • 沟通透明。
  • 毫不犹豫地提供反馈,谦虚地接受反馈。
  • 团队合作者,而不是“个人贡献者”。
  • 足够成熟以建立自组织的团队。

这就是您公司的网守的位置,即RECRUITMENT功能。 您的招聘团队需要开始评估上述素质的候选人。 如果这意味着与每个候选人进行更长的对话,那就这样。 您的招聘人员应该毫不犹豫地与应聘者进行长时间的对话,或者如果他们不符合上述条件,也不要害怕拒绝他们。

您的招聘流程必须经过调整,以评估候选人是否透明,合作且谦虚。 与他们配对解决问题,看看他们如何合作。 给他们建设性的反馈,看看他们如何接受。 让他们沉浸在案例研究/角色扮演中,看看他们的行动以及他们对变化的反应。

筛选出即使面对理性也拒绝改变方法的“我的道路或高速公路”候选人。 他们想要回音室,而不是敏捷团队。 筛选出“是的人”,他们盲目地遵循您的方法并同意您所说的一切。 他们将无法组建自组织的团队。

通过招募合适的人才,您的招聘职能可以成为您实现敏捷转型的第一个变革推动者。

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

一旦有人进来,您公司的监护人,即PEOPLE功能就会出现。

人事团队需要营造一种环境,以促进员工之间的开放式互动并使他们感到值得信赖 。 是的,在此方面,删除小隔间或层次结构很有帮助。 但是最有帮助的是非正式的工作文化 。 人员团队可以通过消除组织中不必要的官僚主义和繁文tape节来实现这种文化。 具有讽刺意味的是,People团队经常被指控首先引入官僚主义和繁文tape节!

敏捷宣言背后的主要原则之一是“围绕有动机的个人建立项目。 给他们所需的环境和支持,并相信他们能够完成工作 。”

好吧,如果您要记录每个员工的时间和时间,并告诫他们不要花费“ 9个小时的办公时间”,那么您就不信任他们,对吗?

直到今天,仍然有一些组织限制将互联网的免费使用作为一项政策。 不是因为缺乏带宽,而是因为缺乏信任。

如果人力资源部设计的过程繁琐,那么有多少员工会被激励去提供有意义的反馈?

为了变得敏捷,组织需要将其People团队重新构想成推动者而不是监督者。 通过设置正确的环境,人员团队可以成为您进行敏捷转型的第二个变革推动者。

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

这就是为什么,我呼吁那些想要敏捷的组织:

如果您聘请了敏捷咨询公司来帮助您进行转型,请不要限制他们影响项目团队的工程和交付实践。 让咨询公司还影响您如何雇用员工以及如何照顾他们。 也许可以从咨询公司的招聘人员和人员团队中获得有关如何制定职能策略的想法。 并且请让您的招聘人员和人力资源部门直接参与此类工作。

因为仅当您转换Recruitment and People功能时,敏捷转换才会成功。