Digital PM峰会2015年 - 一个敏捷回顾 - 摘要报告
背景
本周早些时候在费城，300多个数字项目经理聚集在一起2015年数字PM峰会。这是一个为期两天的活动，专注于在数字机构工作的PM。
我很幸运能被邀请参加会议，我领导的研讨会被称为“一个数字PM敏捷回顾”。我与会话的意图是收集有助于提供以下问题的清晰度的信息：
- 使用敏捷实践的数字PMS在多大程度上？这些做法是否以“纯粹”形式或正在修改，以使其更有价值的数字背景？
- 敏捷实践有助于帮助数字PMS（及其组织）以完成其工作并为客户提供价值。如果是这样，哪些？
- 敏捷实践未能帮助数字PMS（及其组织）以完成其工作并为客户提供价值吗？如果是这样，哪些？
- 目前的敏捷形式适合在数字上下文中工作，还是有些东西缺失？
50多名参与者参加了研讨会。我的假设是，他们自我选择会议的事实，他们对敏捷有一些兴趣或熟悉程度。虽然大多数问题都回应了大多数问题，但响应的数量并不一致。
会议的时间限制为45分钟。由于时间限制，我能够问的问题数量有限。能够提出更多问题并在调查中包括更多的参与者，这是一个有利的是，这是一个机会，即使只是只有很短的时间就可以与一群人联系在一起。我的希望是这里共享的信息将是讨论的开始，这将继续随着时间的推移而继续发展。
我应该在我对结果的分析中出现前面，而我试图将评论重点放在数字上，有些地方是我自己的假设和意见才能进入。
在会议的第一部分，被要求与某些问题进行回应“点投票“通过在房间周围组织的触发表上的折叠图表上的方法，表示他们对所提出的问题的回应。每个问题/主题都有一个解释，旨在确保所有参与者处于共享理解的观点，例如，当我提出了关于自组织团队的问题时，我提供了一个术语的定义，并要求参与者使用这一点响应时的定义。在会话之后，我计算了所有答复的总数。
在会议的第二部分，还要求参与者在小组中工作，以讨论和提供专门讨论以下问题的信息：
- 你的团队效果很敏捷的做法是什么？
- 您的团队不适用于哪些敏捷实践？
- 敏捷无法满足在数字背景下工作的需求吗？
关于这些响应的详细信息包括在这篇文章中。您还可以找到实际结果的幻灯片甲板幻灯片。
回顾结果
管理工作的方法
| 方法 | 回复 | 百分比 |
| 瀑布 | 10. | 20％ |
| 敏捷 | 5. | 10％ |
| 有意识的杂交 | 16. | 31％ |
| 无意识的杂交 | 19. | 37％ |
| 没有把握 | 1 | 2％ |
这里有一个有趣的事情是，68％的参与者正在使用瀑布和敏捷实践。这31％的人表示，他们的瀑布和敏捷是一个有意识的杂交，意味着它在首先练习纪律形式的敏捷（如Scrum）而发展，并且在引入敏捷后，他们的组织就会有意识地决定转向他们确定的混合方法将更有效。37％的参与者表示，在他们的组织中他们练习了一个无意识的杂交关于混合瀑布和敏捷的决定是在通过敏捷的一个原因或另一个人的发作，但没有首先尝试采用一种敏捷的敏捷方法。
比较这一点2015年SCRUM报告由这件发布Scrum Alliance.但只有4％的受访者表示，“Scrum或瀑布Scrum被引入并融入我们的瀑布法”，但63％的受访者表示他们在同一组织练习Scrum和瀑布。
跨职能团队
参与者表明，其中大多数（70％）正在与可以被描述为交叉功能的团队合作。这被定义为“......由集体拥有构建产品所需的所有技能的人组成的团队，每个团队成员都愿意不仅仅是他们自己的事情。”
| 我们有那些 | 30. | 70％ |
| 我们没有那些 | 8. | 19％ |
| 没有把握 | 5. | 11％ |
自组织团队
自我组织的团队被描述为“......赋权估计，计划和管理自己的工作，以任何方式对他们来说最有意义地成为一个团体。”我很惊喜，看看48％的受访者表示他们有自我组织的团队。
| 我们有那些 | 20. | 48％ |
| 我们没有那些 | 19. | 45％ |
| 没有把握 | 3. | 7％ |
每日起点
每日立即会议被定义为以下事件，其中以下事件是真实的：
- 团队每天见面一次，不超过15分钟。亚博vip9通道
- 此次活动的重点是团队同步并计划当天的工作。
- 这不是PM / SM / PO / Manager的状态会议。
| 我们有那些 | 15. | 37％ |
| 我们没有那些 | 26. | 63％ |
这里有趣的是，如果只有10％的受访者正在使用敏捷，这意味着另外27％正在使用混合方法，但已经发现每天的立场都是有价值的。
在会议的这一部分中提出的一个有趣的问题是（释义）“如果你每天都有哈利，而且只在项目的某些地方？”这突出了我所涉及的事情，但没有时间在会议中真正测试。如果组织使用像Scrum这样的敏捷练习，则以纪律处于纪律的方式，然后他们每天都有每日Scrums（或每日立场）。每天都没有让他们表明他们没有得到适当的培训（或自己学习）为什么我们每天做每天的Scrums，或者团队没有看到维持该仪式的价值。在我与团队合作的经验中，后者通常是对Scrum或差的实施实践的理解差的指标。
例如，一些团队决定每天做他们的做法是浪费的，因为事情不会变得那么多的日子。这通常是一个指标，即工作尚未分解成足够的足够小块以进行递增的进展。
完成的定义
在制作敏捷工作中最重要的因素之一具有明确定义的完成定义。这是在团队和业务中记录和理解的事情。亚博vip9通道理想情况下，潜在可付的定义和定义是相同的，但在某些组织中，这是不可能的。当它们不一样时，两者的澄清变得更加重要。
例如，如果一个团队进行两周的冲刺的定义，实际上是“完成”的定义，那么为海上三周手动集成测试做好准备，那么完成的不等于潜在的可运。团队和业务的每个人都必须了解这一点，并为技术债务可能回来两亚博vip9通道次冲刺我们在Sprint审查中向利益相关者宣布的工作之路下来。从严格的意义上讲，这不是理想的，但在某些情况下它是现实。
底线，这可能对数字空间更加相关，即如果您没有由组织和客户清楚地理解的完成定义，则对其的风险毫无准备。这种风险可能来自技术债务，这些债务会困扰你或来自“不开心”的客户，并希望你从你那里自由工作以使事情正确。不幸的是，76％的受访者表示他们没有完成定义。
| 我们有那个 | 10. | 24％ |
| 我们没有那个 | 32. | 76％ |
潜在的工作
只有29％的受访者表示，他们的团队在迭代中的工作会导致潜在的工作。这可能出于各种原因，包括由交付给其他孤岛的专业知识孤岛的团队，这些团队不了解他们的能力，不能有效地计划，或者在规划完成后，利益相关者频繁中断。71％的房间的受访者正在与在迭代结束时没有达到潜在可移动状态的团队合作。鉴于这对敏捷的重要性一般来说，它是一个相当有关的数字，但它看起来与对关于所做定义的问题的回应保持一致。
| 是的 | 12. | 29％ |
| 不 | 19. | 45％ |
| 我们不在迭代中工作 | 11. | 26％ |
回顾
45％的参与者练习回顾，55％不。虽然这可能只是表明在项目末尾的传统项目审查或验尸中表明偏好，但它也可能意味着55％的团队不会花时间满足并反思如何更好地工作。无论它们是练习瀑布，某种形式的敏捷，还是混合方法，这是一个非常有关的数字。
| 我们做那些 | 19. | 45％ |
| 我们不做那些 | 23. | 55％ |
集团工作的结果
好的
当被问及哪些敏捷的做法为他们的团队工作了很好，参与者提出了以下列表：
- 每日浮渣
- 打破冲刺
- 时间箱 - 可预测的工作和承诺
- 快速QA.
- 客户喜欢积压
- 适合团队焦点，可管理的碎片
- 每日工作优先考虑
- Sprint Planning - 人们积极参与 - 在团队中合作
- 经常工作时间表，人们出现
- PM“控制”的重量
- 演示展示进度并保持客户订阅
- 可付工作
- 自我组织创造了领导者
- 在有前途和交付之下
- 更多回顾性，更多的学习和处理迭代和连续反馈
- 从Sprint的尽头学习帮助团队随时改善
- 交叉团队交流
- Scrum提高了问题分辨率
- 更频繁的反馈突出显示新的范围
其中一些响应（如可移动的工作和PM“控制”）似乎表示敏捷的声音实践，或者理解它可以提供的价值。其他人，如“在有前途和交付”点缺乏清晰度，就像Scrile这样的敏捷实践如何旨在工作。
坏人
当被问及他们的团队不适合哪些敏捷的做法时，参与者提出以下内容：
- 每日Scrums不会持续15分钟 - 太多切线 - 更多的组织。统计数据并再次交易一次会议
- 对球队的压力更多
- 一些想要传统的方向
- 需要“更长”
- 同意做得超过可以完成的事情
- 开发人员/客户不明白
- 不知道你什么时候完成
- 难以销售客户对敏捷的真正福利
- 学习曲线，适应
- 很难知道我们在哪里
- 管理期望/管理预算
- UX研究 - 它在哪里适合
- 学习曲线 - 不是每个人都在同一页面上
- 保持Scrum与大团队
- 没有产品所有权
- 使用scrum板
- 积压管理
- 估计
- 用户故事
该列表与尝试采用敏捷过程的团队和组织（数字与否），特别是Scrum的团队和组织并非常用。但它确实表明某些事情是对实际纪律的做法有害的。在这些问题存在的组织中，可以像训练或教练一样简单。但是，人们的关系数码代理商也有可能与客户历史上有许多这些问题更加复杂，需要进一步调整Scrum等东西的盒子模型。
丑陋
当被问及敏捷未能满足数字上下文工作的需要时，参与者提出以下列表：
- UX-Research不适合
- 需求集合
- 数字团队并不完全致力于一个项目
- 需要进行体验
- 客户舒适
- 需要教育客户
- 服务与产品
- 如何卖掉它
- 在会议上度过的时间昂贵
- 通过固定预算购买
- 投标进程/提案适合在哪里
在许多方面，这个列表会回应上面提供的内容，并表明对敏捷（或Scrum）的旨在旨在令人难度的了解，或者只有选择的方法的不良实践。
在会议之后，我与一名与参与者进行了讨论，该参与者最初表示关注如何符合研究UX必须进入Scrum的背景。然而，通过他们如何解决它，他解释的是一种完全合理和敏捷的处理方式。有一个担心，也许他们没有“正确”。在考虑会议参与者提供的所有信息时，我认为保持这种轶事非常重要。在某些情况下，是的，敏捷实践被滥用而不提供价值。在某些情况下，敏锐的是，即使不是，敏捷就会以纪律方式实施。然而，这枚硬币的另一边是，在某些情况下，游戏中的实践要么是敏捷的方法，但敏捷方法都是敏捷的，但是有一种看法，它没有完成“正确的方式”。
包起来
虽然我与本次会议的目标是收集有助于了解当前的敏捷实践是否有助于洞察数字工作，但结果并不明确答案该问题。虽然在数字背景下，似乎很有可能是什么，在敏捷的理解和实践中可能存在差距，这导致了试图实施的人的挑战。因为这么多的数字代理需要维持敏捷和瀑布所需的能力，以满足客户的需求，这可能是可理解的风险。
我的两个最大的问题是：
1.我们如何获得更多数字代理商（敏捷与否），以定期开始进行回顾。
2.可以做些什么来帮助使用混合动力的更多数字代理商移动到有意识的混合动力而不是无意识的混合。