• 可以放慢脚步:BA效率不是通过击键来衡量的
  • 业务分析的通配符身份
  • 是的,您可以在Covid-19期间实际上有效地提出要求!
2015年6月15日星期一10:09

敏捷专注于...容量均衡!

撰写者

不久前,我收到了来自美国西北部某人的电子邮件。他们正在考虑采用敏捷方法,并且想让我的大脑围绕“敏捷发展”的后勤工作。这是一种介绍,但它也是一种评估。

他们正在评估我是否知道我在说什么,以及他们是否允许我帮助他们。他们还在评估文化适应性。但是我也在评估。他们是否“准备好”尝试敏捷,是否认真对待敏捷,是否具有自我意识,我想与他们合作。

这是一轮很棒的电子邮件交流,并引发了一些有趣的后续活动。但我记得今天很想与您分享一次谈话。

背景

但是首先,我们需要设置一些上下文。这是一个非常大型的制造组织的一个部门中的一个IT组。团队中大约有25个人被分为4个小组,这些小组与他们所支持的应用程序或功能保持一致。有一个主任,每个小组都有一个经理/技术负责人。

这是一个初创部门,因此IT小组仅成立了大约3年。它们的大小是静态的-因此在可预见的将来不会增长。

他们支持100多个应用程序;其中许多是由该组织利用的企业应用程序驱动的,因此,他们的工作中有一个遗留组件。他们还在为正在开发的新产品线构建新的应用程序集。

当我问主任为什么他要考虑采用敏捷实践时,他说:

鲍勃,我们真的在努力跟上外部需求。有一种看法是“我们永远需要更新或发布任何东西”。我们还有一个相当严重的质量问题,返工率很高。随着事情的变化或时时刻刻,我在计划工作方面也遇到了难以置信的困难。
我希望“敏捷”能够帮助或解决其中的大多数挑战。

工作

一旦评估取得进展,我就他们正在进行的项目工作提出​​了一系列问题:

  • 您的“投资组合”中目前有多少个项目? 〜125
  • 您是否根据利益相关者的要求致力于其中的几个? 〜80
  • 您目前实际在工作多少? 〜45
  • 您(和您的团队)认为他们的能力是什么-即25个人可以在其中进行合理进展的并行项目?也许20-25

我对这一系列问题的反应令人震惊。当我使用自己的个人经验时,我可以看到为每个团队加载了1个主要项目和1个备份项目,因此相当于8个并行运行的项目。如果您想稍微伸展一下,也许可以将其舍入到〜12。

所以包装 发现 向上:

  • 我认为组织能力不超过12个项目
  • 他们认为产能大约是这个项目的两倍,约有25个项目
  • 实际上,他们在大约45个项目上进行了近两倍的工作
  • 他们在利益相关者的积极承诺上完成了近80个项目的近两倍
  • 项目组合跟踪系统可以“跟踪”〜125个项目

不,我没有弥补。回到他们的挑战,我将他们归结为以下几点:

  1. 我们没有履行我们的项目承诺,并且
  2. 我们有质量问题

您会说这是问题所在吗?

戴上“咨询帽”片刻,不,你不能回答“取决于”。您会推荐这家公司做些什么来扭转局面,并开始更可靠地交付质量更好的软件?

我的建议包围了他们疯狂地尝试以少做多的精神错乱。通过做太多事情,或者超出团队的合理能力,他们正在自我搅动。或多任务处理如此之多,以至于降低了他们已经有限的容量和生产力。

从本质上来说,对他们来说,感觉就像他们在做很多事情,在努力工作,甚至疯狂地工作。他们是。

但是现实是,他们没有把事情做好。当他们设法交付某些东西时,他们筋疲力尽,从而影响了质量。

多任务是敌人,敏捷是能力均衡游戏

我试图通过他们认为他们在“玩”的东西太多的想法来引导他们。通过显着减少并行项目的数量,专注于更少的并行项目,然后尝试完成这些并行项目,它们可能会获得更好的结果。

我一直在敏捷课程中这样说。那:

  • 多任务不是一种有效的策略,实际上您会浪费时间进行知识工作的任务切换;
  • 忙碌或纯粹的努力不一定与结果相关。
  • 处理一小批(任务,用户故事,项目)事物(完成)总是最好的;
  • 最终,该重点生产了更高质量的产品。

使您的工作和承诺与合理的能力保持一致也很重要。显然在这种情况下,每个人拥有三个承诺项目可能不是一个好主意。与这些东西的大小无关,在这种情况下,它们很大。

在他们看来,这似乎意味着还有更多工作要做,但他们没有交付。迟早会兑现这一诺言,但不兑现战略,这对所有人都是显而易见的,并且完全失败。

但是他们让我做

我从这个小组那里听到的最大的反馈,不仅仅是从主任那里,是他们不能“放慢脚步”或“做不到”。他们将此问题归咎于高层领导。高级领导层对组织能力的期望远远超出其能力的现实,但他们不能拒绝。他们无法退缩,也无法要求领导者更深思熟虑地确定其投资组合的优先级。

他们沉迷于他们无限能力的疯狂,并且害怕向领导团队讲述真相。相反,他们忽略了根本问题,继续流连忘返。

我的回归论点是它们是问题的一部分。实际上,由于它们使每个人都可以期待容量的增加,因此它们激发了人们的期望值。我还解释说,他们的领导团队可能非常意识到自己没有能力。即日期缩短,范围缩小和产品质量差。

许多传统软件和IT组织都在玩这种“游戏”:

领导者不断要求更多,直到您说“不”
而且,团队不会说“不”或“我们已满”,并继续致力于更多。

尽管这是阴险的,但由于它已经对有限的容量产生了负面影响。而且,这通常会导致螺旋式下降,直到有人鼓起勇气说出真相并调整组织的能力来满足项目要求。

因此,尽管组织的高级领导疯狂地参加聚会,但我将根本原因直接放在IT组织的领导上。他们不得不以某种方式停止同意越来越多地立即缩减其“承诺”。

在这一点上,我有点在开玩笑,他们感谢我的时间,几乎把我踢出了门(我们不再交换电子邮件)。我的猜测是他们至今仍在搅拌。

包起来

我之前在其他文章中已经推荐过此方法,但我认为它与此处相关。我要你复习一个 视频 由Henrik Kniberg担任Scrum产品负责人。这是一个15分钟的视频,做得很好。

在视频播放大约5-7分钟后,Henrik指出了产品负责人最重要的用语。我希望您观看视频并抓住那一刻。我认为这不仅与产品负责人有关,而且与我的潜在客户和许多其他组织有关。哎呀,这对我们所有人都很重要。

因此,正如他所说,您必须每天练习!

保持敏捷,我的朋友们,
鲍勃

不要忘记在下面留下您的评论。

罗伯特·加伦

罗伯特·鲍勃·加伦 是RGCG L.L.C的总裁兼首席顾问。基于NC的Cary敏捷方法指导&培训顾问。他是一位经验丰富的敏捷教练,活跃于敏捷社区并定期撰写文章。&讲授与敏捷方法有关的所有主题。鲍勃写了这本书 Scrum产品所有权,重点放在团队交付中的角色和驱动价值上。鲍勃可以在 [email protected] 并通过他的LinkedIn进行联网 个人资料.

©BA Times.com 2020

麦格雷戈徽标白色网站