在此博客的第1部分中，我们介绍了需要进行团队改造的问题。 在第2部分中，我们分享了我们对敏捷的发现。 在本文中，我们与您分享我们如何以不同的方式解构和重建我们的团队，我们的方式或工作方式以及我们的产品。
正如我们在第1部分中提到的，我们认为您不能“敏捷”。 我们想做出根本的改变。 因此，我们查看了当前支配我们工作的所有规则。 我们在世界上发现了许多规则：
同类群组| 程序| 时间表| 讲师| 线性| 胜任力
我们以为：“如果我们打破其中的某些……？”。 但这将是毫无目的的。 不仅仅是不做某事，我们还为之服务吗？ 因此，拼图中的第三部分是决定我们的设计原则 。 我们从我们周围的一些相关领域（如技术和市场营销）中汲取了灵感，并决定我们的产品必须是：
- 灵活 -为人们提供更多选择，让他们在何时，何地以及如何获得绩效支持和工作经验（注意：我们很快就了解了太多选择的弊端，因此这涉及到精心选择的选择）。
- 可访问性 -脱离传统的学习管理系统（LMS），转向消费级数字平台。 在需要的时间和地点为人们提供简单的支持
- 个人 -了解我们最终用户的动机，需求和要求。 确定有意义的用户群体，而不是将所有用户视为一个整体。 定位我们的消息和资源以使其与它们更加相关。
- 包容性 -为尽可能多的人创建一个敞开的大门。 远离任何感觉被排除在外的事物。 没有HiPo（高潜力）计划！
- @需求点 —将我们的精力集中在用户所经历的痛苦或痛苦上（因为当我们直接与他们交谈时，他们告诉我们这些是什么）。 优先考虑产品，以帮助人们度过难关，例如首次成为经理。 关注人们最容易接受变化和学习的时期。
最后，我们设计的所有东西都必须通过低成本，可扩展，易于重复且易于管理的最终测试！
因此，我们从四个问题开始-步伐，意见，浪费和筒仓。 我们故意违反了规则。 我们决定了新的设计原则。 然后，敏捷成为创建能够为我们的最终用户增加最大价值的解决方案的关键推动力。 此处的关键变化是将关注点从以人力资源为中心转移到以人为中心 。
一个例子
现在让我们深入了解如何迭代管理器开发的真实示例。 出发点是我们需要解决经理所遇到的实际问题，而不是人力资源经理所面临的问题。 有很大的不同。
我们开始很小。 我们对MVP（最低价值产品）感到非常满意，这是我们可以与实际人员一起测试的“足够”的解决方案。
几乎立即出现了一个真正的（压力很大）的问题。 我们的组织需要迅速摆脱大量角色。 真的很快。 进一步确定，业务中有两个部分最担心冗余成为ER问题。 所以我们针对他们。 并不是所有的经理—只是高风险的经理。 保持工作清晰明确和有针对性的纪律，是敏捷在非技术团队中取得成功的关键部分。
我们确定了MVP是一个很小的集合，即不超过五个数字资源，并且不超过两个90分钟的小组研讨会。 在短短2周的时间内，研究，设计和启用了资源和研讨会，相当于一个敏捷“冲刺”。 近50位经理获得了使用新的消费者级应用程序的资源的权限。 没有LMS。 他们都参加了两个分开的讲习班，相隔两个星期。 这虽然很粗糙而且已经准备就绪，并且没有什么突破性的内容，但是我们很快并且反应迅速，响亮的反馈是经理们发现它们非常有用。 而且，重要的是，没有任何一个申诉或ER案件浮出水面。 仅仅四个月后，当我们回顾这些资源时，我们惊讶于它们的基础（并且写得不好），以及我们在敏捷思维方式和方法中发展自己的速度。
两年前，在将任何东西发布给任何人之前，我们本该呆了几个月。 这就是让我们变慢的原因。 否则我们会说可用时间太短了。 这就是使我们反应迟钝的原因。 或者，也许我们会推动一些电子学习并在培训框中打勾。 我们不会知道客户会看重什么。 风险始终是浪费时间，精力和金钱，并且零影响。
因此，当我们说我们作为敏捷团队工作时，在现实生活中会是什么样？ 我们将在第4部分中介绍该内容。
