Naturally, we will assign tasks to team member and mark as owner. We will give a good naming of this action: Resource management. Within traditional project management, one of the things we most focus on is the resource management and tracing. Yes, I agree. The resource is really important, and we definitely should concern the ROI. But we need to consider the granularity of resource. Otherwise, we will be lost. Although you know every resource usage, that doesn’t mean you ship your feature in time. And if you focus on resource management too much, believe me, it’s easy to be failed in software development. Because you would be easily ignore “Technical Debt”, “Team Building”, “Delivery”, although you still have good reasons to business and management team in that time. So what? Reasons and reports do not mean working software.

Scrum, is the agile methodology I experienced most. It defines three roles, PO, Scrum Master, Scrum Team. And actually the three roles are one, because if one fails, then all 3 roles fail. The self-managing Scrum team is always the goal we fight for.

That’s why we always emphasize team rather than individual team member in Scrum. So “No Personal Backlog”! Personal backlog is good for management team to know every resource’s status. But it’s too bad for the team! Member will say, “At least I finished my items.” Yes, you had a bad member, and you lost a potential good team.

And that’s why I do not like some commercial/free Scrum project management software. Because it does do the personal backlog.

From Henrik Kniberg’s slides on Agile Conf 2008, you also can consider following list as bad practices to team:
• Fixed roles
• Personal backlogs
• Not helping each other
• Personal incentive models
• Implementing all stories in parallell
• Management interference

Anyway, I believe good management team will focus on “Delivery”, “Quality”, “Team/Assets” rather than focusing on resource management too much. ROI always the first rule to business, but it is not short term!

曾经推荐过这本书，然后现在有了中文版。http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches

非常值得阅读.

From my perspective, Scrum is a methodology of management and it’s quite loose, but the XP is a methodology of development and it’s quite specific. So Scrum is like a framework, you could develop your concrete process. In Scrum, the approach you apply in the development is quite free. It depends on your team’s ability and tradition. So naturally, we will consider bringing some stuffs from XP into Scrum.
 
1. Split Sprint into small iteration
Normally, 1 sprint is 1 month within same length. But sometime, it’s still too long to control and commit. So we could split it into small iterations, like 1 week per iteration. But we still will have the Sprint planning meeting to pick up and definite the scopes of next sprint, then separate the sprint backlog items into iterations according to the priority. Meanwhile the iteration planning meeting will happen in every beginning of iteration. With small iteration, it’s easy to get the velocity more accurately.

2. User story and Spike in planning
Since the product/sprint backlog could be very simple, no information very detailed and deep, it’s difficult to estimate them sometime, especially when you are not sitting together with customers/users. So a good user story would be really helpful to understand the requirement and to estimate it. The communication is still needed, certainly.

The commitment is the target of the team, so it’s tough to estimate features when we get uncertain things within it. The spike supplies the practice guidance of this situation. We could do a spike before estimate the real work and to produce the possible solutions to PO. Then we could give the correct estimation when PO confirms the solution.

3. TDD and Refactory
No methodology guideline for how to code and test in Scrum. So normally we will apply TDD and Refactory into the development. Modern IDEs (Visual Studio for .Net, Eclipse for Java, Zend for PHP …) all provide these two functions. 

4. Pair Programming
It’s difficult to involve Pair Working into scrum (I will detail this in following entry). But Pair programming is the best way to share knowledge and assure the quality.

5. Continuous Integration & BVT
CI could help us to find questions at the very beginning. BVT could ensure the major functionalities of the product won’t be broken. (Cruise Control is a good tool.)

6. Acceptance Tests
Acceptance is the guideline of the test cases. We also could create automation tests base on acceptance criteria.

7. Combined style of daily scrum and daily stand-up
In daily Scrum, team members will focus on 3 questions:
a. What I’ve done from last daily Scrum
b. What I will do in next
c. Any obstacles

Via these 3 questions, we could easily know the status. But it’s hard to know other team members’ ideas or comments. So we could plus another question:
d. Any feedbacks?
 
Although we plus this, we still need to focus and control the meeting time. If the feedback would be long, it should be discussed after the daily scrum.

今天在邮件列表里看到一本书: “Scrum and XP from the Trenches“. 虽然现在才看到这本书. 但由Jeff Sutherland和Mike Cohn作序的书真是不同凡响. 书极为犀利, 易于采纳实践.

有时候缺的就是这样的书. 我们常需要这样的recipe.

NO! I can say dev is same as Testers.

Today I just read an interesting thread. Some guy is looking for documents which mainly help to introduce the Scrum to developer.

Actually besides the Product Owner and Scrum Master, there is only one another role in Scrum. It is the “Team”! Within Scrum the team should be self-managed. In another words, there are three managers in Scrum — Product Owner, Scrum Master and the Team. And their one and only goal is achieving their commitments. The three roles do have different responsibilities, but act as a team role, the teammates in the team should share responsibilities of the same commitments. So no excuse to be blocked by specific as Dev or Tester, your goal is delivering your commitments. Dev and Tester should help each other to complete their tasks via focusing on different aspects which they are good at. Remember, your team should always act as one team, not individual team members. So never be blocked internally. Even when you think you are really blocked by your teammate, adjust youself or the team! If it’s kind of external blocking issue, ask Scrum Master for help.

But I still found one documentation which is pretty nice in that thread. “Scrum in five minutes”, http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf.

沟通，无论做什么都会强调的一点。

前阶段接受过的一个英语培训中，老师说到这么一组数字。在沟通中一些方式所占的比重，且不论数字真实与否：

文字(Words)：7%

语音语调(Tone)：38%

影像(Visual Expression)：55%

从这组数字中我们可以很明显的看到文字的地位，在沟通中文字远没有想想的重要。

前几天在《User Stories Applied》一书中也看到这么一个故事，

父亲和往常一样给女儿放水洗澡，然后让女儿试一下水温。女儿试了一下告诉父亲说：“make it warm”。而父亲试了一下水温以后发现，水不但不冷，而且还比平时的水温更高。父亲思考了一会，才意识到误解了女儿的意思。虽然同样都是“Warm”这个词，但对于成年人来说就是“increase the temperature”。然而对于他女儿来说却是“Make it closer to the temperature I call warm”。

面对面的交流尚且如此，更何况写下的文字。这也是为什么agile的开发总是那么强调沟通，强调反馈。