怎样保证每个团队成员高效地工作，使组织产生最大的效益，是每一个经理最大的挑战。为了能够帮助项目团队成员在软件开发中实现团队的自我管理，让团队找到自身的问题，实时地反映项目的进度，让团队成员知道每天应该做什么......为了解决这些问题，我们的日常开发以Scrum为基本框架，并特别强调团队的自我管理。具体做法是：
短迭代
每两个星期一个Sprint。每个Sprint给几个客户做演示。产品负责人会根据演示的反馈以及原先的发布计划重新整理Product Backlog，并由此产生下一个Sprint的计划。因此团队的每个Sprint的任务是由业务驱动的。
用户故事
产品负责人会在计划会议开始之前整理成用户故事。产品负责人在整理用户故事过程中会注意收集真正客户想要的东西，理解客 户的意愿，而不是业务以及技术上怎样实现。在计划会议会议中，给团队成员解释需求，团队成员会根据对需求的理解提出可能的方案(当然也有可能是多个方案)，分出任务，对任务做出估计。
但是这些估计也是比较粗略的，很多时候需求还是不能很明确，但是一般达到大家能够对用户故事有一个基本的理解，能够开始 着手，能够做出大体的估计的程度就可以。
在Sprint过程中，还会不断发现新的需求，或者采用或者否决一些方案。这些都是每个Scrum团队在 Sprint中动态调整的。
迭代开始时，避免任务分配到个人
在计划会议会议中，用计划游戏，每个人都参与估计，每个人都要求理解用户故事。在Sprint中，每个成员根据一些简单的原则来认领任务(比如从上到下优先级，不超过最大并发任务数)。通过结对编程、Wiki等一些知识共享的手段，多数人很快就能胜任各种任务。
周期性的例会
在例会中团队成员汇报进度(做了什么)，承诺(根据当前情况，下一步要做什么)，需求(有哪些困难，需要其他成员或者组织的帮助)。团队会重新估计剩下的任务，如果需要，项目成员和产品负责人一起调整Sprint Backlog。
其次，合理使用信息辐射器(Information Radiator，另见The Ideal Agile Workspace)，我们目前使用的信息辐射器包括：Sprint Backlog，这是整个项目团队自我管理的核心，实时反映项目的状况。通过Sprint Backlog可以了解到任务分配，项目进展(燃尽图)，缺陷，困难等等。Sprint Backlog上的不同类任务用不同颜色区分，一目了然。很容易就可以了解任务分配，Sprint的瓶颈以及困难在哪里。