项目是独特的，不同的项目要根据不同的环境选择相关的实践和流程。每个实践和过程都是基于特定环境而实施的，可以尝试，也可以改变。因为我们周围所面临的环境是不确定的，所以应该根据当前的环境及时调整流程以适应环境。
    在成熟的组织中，我们看到了相互集成的更重的过程和方法。集成越紧密，系统的可感知质量、完整性和弹性就越大。然而，在敏捷项目中，重点是团队和客户之间的交互，而不是过程和工具。这里的挑战是如何减少过程，消除任何修饰，从而实现敏捷性，但不以质量或系统的完整性为代价。回顾的结果是敏捷团队检查和调整其工作方式的关键驱动因素。敏捷方法从本质上讲是不那么规定性的，所以它们很容易裁剪。然而，一个人不应该草率地立即开始剪裁。在调整它之前，应该花足够的时间采用一些知名的方法。否则，它可能导致功能失调的行为，将更难撤消和纠正。一些流程是可以定制的，比如团队在Sprint期间如何管理和维护Sprint backlog；应该使用哪些工具进行问题跟踪、版本控制、构建和部署；使用哪些度量标准，以及如何报告和解释趋势；以及何时何地采用和适应实践，如结对编程、持续集成、探索性测试等等。
    就像回顾过程一样，裁剪可以包括以下步骤:

    • 确定范围：根据团队的反馈调整流程。
    • 确定持续时间：裁剪所需的时间量，并观察裁剪的影响。
    • 确定影响：通过让利益相关者参与决策部分。
    • 确定可重复使用的资源：如组织过程资产、最佳实践、
    • 行业范围的实践：并查看它们在当前环境中的适用性。
    • 审查并确认定制流程确实在按照预想的方式工作。
    • 将改进过程与干系人进行社会化，使其得到充分理解、接受、相关和一致——不仅在当前项目中，而且在未来的项目中也是如此。