组织多半会为整个团队、项目、和组织单元进行敏捷改革，鉴于敏捷是一个团队驱动方法。但也有专家开始使用单独的敏捷实践，或将敏捷作为一个人团队来实施。个人如何采用敏捷，以及能获得什么样的好处呢？
Fiona Hanington发表了一篇博文“当我的团队不够敏捷时，我可以成为一个敏捷技术沟通者吗？”，其中她谈论到了个体采用敏捷的可能。她开始解释她的灵感来自敏捷训练，尽管尚不清楚她的单位何时采纳敏捷方法，她想自己开始敏捷并改变她的工作方式：
在我能做之前我需要等剩下的团队采取敏捷方式吗？或者有任何可以使我融入现在工作的敏捷方法吗，作为一个个体？
因为她的单位还没有过渡到敏捷模式，她意识到会有一些局限性：
在我的单位，我们目前工作在一个传统的“瀑布流”环境：首先是需求，其次是设计，然后执行、测试，bug修复，然后beta版本，接着是更多的bug修复，再就是商业发布。我绝对必须遵守这个结构。沿着不同阶段我有某些可交付成果，同样，我依靠规划文档与其它组的工件。即使我想，我也不能忽视这个结构。在很大程度上，我必须等我的单位变得敏捷，在我自身能够真正成为一个敏捷技术沟通者之前。
Fiona探索了几个她可以自己变得敏捷的实践方法。她阐释了如何在日常工作中专注客户需求，通过询问提来的需求。并且她讨论了使用敏捷规划技术的可能性，像将工作分成几个小任务，使用个人任务板使工作可见，在短期内集中规划并应对变化，对她即将做的任务使用时间定量、看板和优先级设置。她的结论是，单独采用敏捷方式是可能的：
当我期待着最终成为一个成熟的跨职能团队的一部分时，我不需要等待开始。即使是在传统的瀑布流环境，我也能将敏捷带入我日常工作生活中。也许有些讽刺的是，我所采取的步骤让我觉得比以前更属于这个团队了，尽管我从一个不同的模型借鉴过来的。
在博客“让你的敏捷改革个人化”中，Len Lagestee探讨了如果让一个个体变得敏捷这意味着什么。
通过组织变革或渗入敏捷环境的个人旅程将对你是一个独特的体验。你可能曾经经历过敏捷或是根本没有。变化会很自然地来临或产生某种程度上的焦虑。
Len探讨了采用敏捷开发的个人旅程，以首先意识到敏捷是什么并尝试敏捷实践开始，他清楚表明，个人必须按照自己的节奏采取敏捷：
不要让任何人告诉你你该在旅途中的哪一部分或你应该如何感知。找到你所在的环节并决定应该做些什么来走到下一级别。
“一个孤独的开发者能使用敏捷吗？” Phil Johnson问了这个问题。
然而也有些开发者，要么是渴望要么是环境因素，作为一个男或女开发团队独自工作。他们排除了使用敏捷方法来管理自己的开发工作吗？敏捷可以被单独的开发者采取吗？
Phil解释了为什么个体可以采用敏捷并从中受益。他列出了敏捷实践的清单，包括以下几方面：
-
创建明确定义的，小块的工作（即用户故事）
-
在每天工作开始前保持每日“站立”
-
跟踪你用多长时间来完成任务并且在一个迭代中能完成多少任务
-
经常与客户沟通，提供定期更新与产品发布，征求反馈与建议