主动通报进度
进度的控制、汇报是项目经理的一项重要职责。然而，很多刚刚走向管理岗位的人却是通过询问的方式来掌握进度信息。这种方式不仅效率低下，而且，更严重的是信息的真实性、准确性都不可靠。项目成员在被询问进度的时候可能会因为害怕被责备而慌报进度，心存在事后可以赶上进度的侥幸心理。笔者则是要求团队成员对自己负责的任务的进度主动通报。这里我用的词是“通报”而非“汇报”。汇报是指下级对上级之间的。而在一个敏捷团队中，项目的进度应该是每个成员都要关心的事情，并非项目经理一人要关心的事。因此，每个人的任务进度信息要传达给项目组的其他所有成员，所以称其为“通报”。具体的实施笔者则是要每人在每个任务有实质性进展或存在个人通过努力仍然无法解决的问题时，在即时通讯工具中知会所有人。
团队成员通报的进度信息，项目经理要及时通过检查相关产出物（artifacts）以评价其真实性和准确性，并有效得评估风险。比如，笔者曾经带领团队从事 SOA 系统开发，在这种系统中，本系统同其它系统之间的联调工作相当重要，笔者则要求负责联调的人及时提交联调过程中的抓包文件以及系统日志文件，并知会团队成员对这些联调产出物进行评审。
建立和使用团队的共同词汇
一个团队的沟通要顺畅，团队成员在沟通时必须要采用统一的词汇来表达相同的意思。词汇的统一可以减少不必要的误会和解释，可以减低沟通成本，提高沟通效率。譬如，笔者所带领的团队，由于是所开发的系统是基于 SOA 架构的，其共同词汇主要有抓包、码流、路由等，所有团队成员对这些词汇的含义的理解是一致的。
任务认领
传统项目管理中，任务是由项目经理分配的，团队成员总是被安排做这个做那个。而根据Fredrick Herzberg 的双因素理论（Dual-factor theory），我们不难想到工作的报酬某种程度上是工作本身。任务本身也可以成为一种激励形式。因此，让员工选择他喜欢做的事情，远比安排他做事情的好。因此，在敏捷项目中任务相反是由团队成员主动认领的。项目经理更多的是考虑这个团队需要做什么事情，并将这些代办事项公布出来由团队成员认领。比如，基于 story 驱动的开发，所有 story 的分析是全员参与的，而具体某个 story 的开发任务则可以由开发人员自行认领。这样，可以使团队中的每个成员对本次迭代的所有 story 都有所了解，而其个人所开发又是其最感兴趣的、最擅长的。从而减低了风险。
项目经理只有在当前任务的认领情况有问题时才对其进行调整。
同样，其它的任务也可以采用任认领的方式落实到人。而项目经理要做的是向其他团队成员说明需要完成的事情，并定义完成的标准，据此跟踪任务的进度。比如，对于联调工作，笔者会先确定需要联调的接口以及对方系统，然后由团队成员认领这些任务，据此形成联调接口列表。同时，定义了任务完成的标准是相关联调产物（抓包文件、系统日志文件）通过评审。
定义完成的标准（Definition of Done）
所谓完成的标准，简单得讲就是一个任务做到什么程度才算是完成，要输出那些产出物（artifacts）。可能现在仍然有不少团队要求其成员提供诸如日报、周报之类的工作报告，其中自然少不了每件任务的完成情况，这个完成的情况通常是以百分比来计算。但是，也许大家不难发现一个情况，比如，某个成员报告中写明某个任务的进度是 100％，也许这个人工作态度是很诚实的，能力也不差，但是，当项目经理真正检查这个任务的进度（比如通过评估其产出物）才发现这个任务的进度是 0，根本没有完成——实际所“完成”并非项目经理、或者团队所期望。其原因在于，定义任务时没有定义其完成的标准，此时任务的执行者往往只是照着自己的理解去“完成”任务的。
笔者所带团队常见的完成标准如下：
开发人员开发某个 Story，其编码完成的标准可以定义为：其负责的 Story 经过单元测试（要求提交单元测试时产生的系统日志文件到配置库），并且该 Story 通过由测试人员定义的预测试用例。开发人员在完成编码、单元测试后主动召集测试人员及其他人员对其负责的 Story 进行演示，演示时要求其展示各个预测试用例的执行结果，只有演示通过了，该 Story 的编码才算真正完成。而一个 Story 的开发完成，则是定义成其通过 Story 测试。
某个文档写作任务的完成标准可以定义为：初稿发出评审后，没有发现如何问题，或者评审者提出的意见初稿作者均已处理，且处理的结果经过评审者的确认。这样一个文档的写作才算完成，其进度可以报告为 100％，否则，仅仅完成初稿，而初稿未经评审，其进度最多算 40％（甚至都不到！）。