传统项目管理的问题：
传统项目管理的铁三角是范围，成本，时间，其中范围是固定项，时间和成本是变化项，但很多在此三项上单独看都成功的项目实际上是失败的。
首先，缺失了“价值”，瀑布模型开发的项目，实际使用功能和交付功能的比率很低。在技术快速演进的时代，如何获取有价值的需求成为关键问题。
敏捷管理关注价值，通过product backlog和卡片的手段聚焦需求。通过迭代开发加快对市场的响应速度。在迭代开发中，时间和成本是固定项，而范围是变化项。另外，不可能对所有的需求投入同样的力量，需求的目的决定其质量。
迭代管理，由于需要反复的回归测试，不可避免的有浪费。所以更要降低耦合，自动化回归测试，减少浪费。
在迭代过程中，明确的需求、被其它系统依赖的需求要放在前面，易变的需求、依赖其它系统的需求可放在后面，也就是先做想明白的，想不明白的在实现过程中去想。
对于价值的交付，瀑布开发是最终交付，敏捷开发是逐步交付。
其次，传统项目的铁三角还缺失了“质量”。
敏捷对质量的关注可以体现在以下几点：
在持续集成中，始终将质量作为关键性标准。
使用TDD，即测试驱动开发。
对代码随时随地的重构，这一点需要自动化的测试手段来辅助，否则，如果无法保证重构没有引入新的bug，开发人员就难有重构的信心。
敏捷管理对质量的要求是环环相扣，不可为了省事而跳过中间步骤，否则就会有缺失的环节。
价值，质量，加上约束（范围，时间和成本），这就是敏捷项目管理的新铁三角。
传统项目中，需求分析，设计，架构，编码，测试等人员都是严格分工，带来了好处是对员工能力要求较低，工作流步骤清晰。缺陷是不同部门之间存在部门墙，部门间合作需要繁琐的工作流和文档交接，效率低。
面对需要多次迭代，快速交付的项目，传统组织结构无法应对。这就需要组建相对小的特性团队，不同角色在同一个团队中紧密合作，其工作域也互相覆盖。只有拆掉部门墙，才能减少文档作业。也就是说，弱化文档是成功实施敏捷的结果，而不是敏捷的手段。
敏捷管理的工具：
看板，分成ToDo，Doing，Done三项，一定要清晰明白，可在6秒内看出当前进度。尽量用卡片和贴纸的形式，而不要用文字的百分比。
燃尽图，让程序员关心项目的整体进度。不同于传统管理方式，敏捷管理应该关注空闲的事而不是空闲的人。
早站会，5-15分钟，一定不能太长。早站会一定不要去一个个的对进度，负面管理应该一对一，正面管理才应该一群人来做。所以早站会应该聚焦于提供激励和帮助。
一个敏捷的团队，应该能集体制定目标，团队一体化，透明化，最终成为一个自组织的团队。