Scrum过渡过程中存在的文化问题

Question

我的团队已经尝试向Scrum过渡了一段时间，但似乎已经存在的文化正在阻止团队转向新的思维方式，甚至导致它向相反的方向移动。

作为参考，团队有两名线经理、一名项目经理、一名产品负责人和五名开发人员。

• 开发人员从不与产品所有者直接联系。虽然可以说是由直线经理来填补这个角色，因为他们定义了团队的工作，但PM却否认了这一点。
• 项目经理坚称她是“Scrum的领导者”。
• PM还坚称，直线经理是Dev团队的一部分，因为所有敏捷团队都有“团队领导”的角色，LMs对工作的直接监督也很好，因为他们毕竟是技术领导，这是一个有效的Scrum角色。
• PM还坚持每日停摆作为一种报告工具。
• 每日站立是由LMs运行的，他们使用它来跟踪每天的进度，监督每个开发人员，评论他们的方法，并分配新的任务。
• 每个用户故事1-3天被LMs视为每个用户故事的硬限制，而不是细分指南。如果开发人员在用户故事上超过2天，他会收到一封关于开发人员如何在最后期限内交付的电子邮件。
• LMs坚持集体所有权意味着每个特性都应该有一个人负责它的发展。

奖励：

• 当我在一次会议上以一种即兴的方式提出这些观点时，几乎有人告诉我，我愚蠢地建议将LMs从开发过程中删除，因为它们是那些具有商业知识的人，或者因为我是新来的人而提出建议。
• 几个小时后，我通过devs CCed向LMs发送了一封电子邮件，总结了我引用了相关文章的观点，我收到了一封电子邮件-- CCing中所有的人--都是关于我一直在研究的一个功能的问题，以及它是如何花了很长时间的。

在这种情况下，我能做些什么来帮助开发人员向Scrum思维方式过渡，并避免破坏团队的士气呢?由于这种情况，每天需要10%-15%的工作时间来进行监控和监督？

Answer 1

关注的是单个问题，而不是方法论，并让每个人都参与进来。与其直截了当地提出改变，不如建议团队每隔几周举行一次定期回顾会议，目的是讨论哪些进展顺利，哪些不顺利，哪些可以改进。这应该是确定要解决的具体问题、决定这些问题是否值得解决的起点，并就可能采取的补救行动提出建议。 回顾是团队中每个人(包括利益相关者和负责交付的人员)诚实、公开地讨论团队目前做得好的事情，以及导致痛苦或问题的事情的机会。这不仅包括过程/人工问题，还可能是持续存在的技术问题或技术解决方案。这是一个团队的问题，作为一个整体来讨论确定的问题是否真的需要解决，或者它是一个团队可以接受的问题，或者这个问题完全存在于团队的控制之外，它可能需要升级。 例如，如果您说开发人员没有机会为将要完成的工作提供估计值，那么技术风险可能不会像其他情况那样快速地被识别，或者提供的估计可能不现实。 整个团队都要讨论这些问题，并决定这些问题是否是真正影响软件交付的问题；如果团队认为这些问题需要解决，那么团队中的每个人都有机会提出改进建议，而负责交付软件的人员也有机会倾听并提出他们的担忧--最终，他们是那些在出错时负有责任的人，因此他们的参与是至关重要的。 请记住，方法不应该是目标，目标应该是有一个开发过程，使团队能够有效地管理风险，在团队周围存在任何限制因素的情况下，以最好的方式响应业务需求，并且只需要获得满足每个人期望的工作软件。