不管是在敏捷环境还是在预测型环境，你都可以从使用敏捷实践中获益，但是，敏捷实践不一定会使你变得敏捷，为了实现敏捷，你需要使用敏捷方法/框架。这很重要，因为很多人认为，使用敏捷实践就足够了，其实并非如此。
什么是敏捷实践?
以下是敏捷实践的例子:
集体代码所有权：极限编程要求集体拥有代码，应此，每个开发人员都熟悉整个系统。
结对编程
每日站立会议
信息发射器：也称为大可视化图表，它们提供了一种有效的方法来沟通项目状态、问题或绩效，而不需要团队花费大量的工作
持续的重构
自组织
为什么它们被称为“敏捷”实践？是因为它们在敏捷环境中更常见，而且大多数是由敏捷实践者发明或推广的。然而，它们中的大多数已经以不同的形式使用了很长时间。
什么是敏捷方法/框架？
例如:
Scrum
Kanban开发方法
DSDM
ADD
这些都是要变得敏捷所需要的。
为什么单独使用实践并不能变得敏捷？
这些实践都无论在任何的环境中使用都可以使你受益，只要它们与整个系统的其他部分之间没有冲突。例如，自组织可能并不适用于所有环境，但是拥有一个大可视化图表很简单。你可以在一个成熟的瀑布模型当中使用大可视化图表和每日站立会议来改善沟通，但这并不能将瀑布变成敏捷。
敏捷方法/框架并不等同于一组实践。那么，一个敏捷方法/框架提供了什么是我们不能仅通过一组敏捷实践就能得到的呢？很简单，一个开发生命周期。生命周期告诉你应该采取哪些步骤。需要哪些角色和职责，以及需要什么样的管理工具。
如果你从来没有使用过一个合适的体系模型(例如瀑布)，而是想仅仅通过使用一些实践就试图变得敏捷，那么结果将只是一个混乱的体系，可能有效，也可能无效。
但是你可能会说，确实有人正在这样做，并且取得了成功，这只是概率问题，当你没有使用敏捷方法/框架，而是只依赖于一些实践时，成功概率要低得多，但这并不意味着你一定会失败；毕竟，很多项目从来没有被系统地管理过，其中一些项目的成功是因为它们拥有更优秀的资源、更良好的环境和更好的运气。
你可能会问，我们应不应该使用敏捷实践呢？使用敏捷实践是一个非常好的主意，但要确保它们不与项目中的其他内容冲突。我的观点是，你应该清楚你期望从这些敏捷实践中得到些什么：他们不会为你创建一套完整的体系模型，它们是有用的，但是还不够。
