考虑到敏捷是一种团队驱动方法，组织机构大多为整个团队、项目或组织机构单元进行敏捷转型。然而，除此之外还有一些专业人士，他们开始独立使用敏捷实践，或是自己作为一个人的团队来运用敏捷方法。那么个人如何采用敏捷，又能从中获得哪些好处呢？

Fiona Hanington撰写了一篇博客文章我能否先于我的团队成为一名敏捷的技术沟通者，在其中探讨了单独采用敏捷的可能性。首先她描述了她自己是如何受到敏捷鼓舞的，以及在她的单元还未明确是否会采用敏捷的时候，她打算如何开始走上敏捷的道路并改变自己的工作方式：

我是否需要等待我们团队其他成员就绪，才能够使用敏捷？又或者敏捷方法论中是否有什么内容是我作为一个个体，现在就能够融入自己工作中的？

鉴于她所在的组织单元尚未开始向着敏捷的转变，她意识到存在一些限制：

在我的组织单元里，我们目前工作在传统的“瀑布模型”环境中：首先是需求，其次设计，接下来执行，随后进行测试，测试之后则是bug修复，而后就可以发布beta版本，随之而来的是更多的bug修复，最后则是商业发布。我绝对需要顺从这样的结构。在其中的每个阶段，我都要面对确切的交付期限，而且——同样地，我依靠规划文档和其他组的工件。即使我想，也无法忽视这样的结构。因此，在很大程度上，我必须等待我们的组织单元转变到敏捷，而后我自己才能真正成为一名敏捷的技术沟通者。

为了通过自己的努力变得敏捷，Fiona研究了若干她可以尝试的敏捷实践。她阐述了如何在日常工作中聚焦于客户需求——通过对输入的要求进行询问。她还探讨了使用敏捷规划技术的可能性，例如将工作分解为小任务，使用个人任务板来将自己所做的工作可视化，专注于短期规划并响应变化，对将要进行的任务使用时间箱、看板和优先级设置。总之，她认为个体采用敏捷来改进工作方法是完全可行的：

我期待最终能够跻身一支成熟的跨职能敏捷团队，但我不必空等，而是现在就可以开始努力。即使在我们传统的瀑布模型环境中，我也已经开始在每天的工作生活中引入一些敏捷原则。或许有些讽刺的是，迄今为止我所采取的这些步骤，让我自己感觉与团队的联系比以前更加紧密了，哪怕我是从一个不同的模型中借鉴了这些步骤。

在博客文章将敏捷转变作为个人的行为中，Len Lagestee探讨了对个人来说，转向敏捷将意味着什么。

经历一场组织机构转型或是置身于敏捷环境之中，对个人来说将是一场独特体验——不论我们在此之前是否已经有了敏捷经验。改变或许自然而然的到来，或许会引发一定程度的焦虑。

Len分析了采用敏捷的个人之旅，首先是了解敏捷是什么，并对敏捷实践进行尝试。他明确表示每个人都需要根据自己的节奏采用敏捷：

不必让任何人告诉你应该从哪里开始，或是应该如何感受。弄清自己身处境地，并决定要想达到下一个层次需要做哪些事情。

Phil Johnson提出了这样一个问题，开发者是否能独自使用敏捷？

然而，有一些独自工作的开发者——他们要么是受环境所限，要么是由于自己独立工作的渴望——作为只有一名成员的团队。他们是否被排除在使用敏捷方法管理器开发工作的行列之外，或者说这些独立开发者是否能够采用敏捷？

Phil解释了为何他认为个体可以使用敏捷，以及为何能从中获益。他给出了一份敏捷实践列表，包含以下内容：

• 创建清晰定义的小块工作（也即用户故事）
• 坚持在每天开始工作前进行“每日立会”
• 跟踪完成任务所花时间，以及在一个sprint中完成的任务数
• 与客户频繁沟通，提供定期更新和产品发布，征集反馈和输入

你是否先于你的团队开始独立的使用敏捷实践，或者正作为一个人的团队采用敏捷的工作模式？你是否从独立采用敏捷中获益？