作者：李洁（Jerry Li），CSP，CSM，Scrum中文网资深敏捷顾问和培训师，敏捷教练
前几天，与一位兄弟一起吃饭，他聊起了他们公司的敏捷实施情况。
他自豪地说；“我们公司已经完全按照Scrum的形式，对组织结构进行了重组。原先的职能式组织结构已经消失，不再存在产品部、项目管理部、开发部、测试部等职能部门，而是改为清一色的产品事业部。产品事业部由一个个Scrum团队组成，目前所有的研发人员都已经分配到固定的Scrum团队中。各个产品事业部正在热火朝天地赶版本。。。。。。”
听到这里，我问了他一个问题：“你们的专业能力建设，是怎么考虑的，具体由谁来负责？”
他先是一愣，然后告诉我：“目前组织中没有专门的人员负责这件事情，应该是由各个Scrum团队在自己搞。”
我O(∩_∩)O，告诉他：“这顿饭该你请了！请听我细细道来。。。。。。” Read more →
跨职能团队就是指在团队里面的每一个人都具备完成所有工作的所有技能，这或许是敏捷中最流行和持续存在的一个误区。
这显然是不正确的。跨职能团队的成员具有各种技能，但这并不意味着每个成员都具备所有技能。
敏捷团队拥有专家成员是可以接受的
敏捷团队拥有专家成员是完全可以接受的。（注：本文提到的专家成员是指在团队里面只擅长某个方面的单一技能的团队成员。）
Read more →
昨天, 去看最新上映的星战8
其中有一段剧情是这样的, 卢克·天行者担心自己没有能力教导下一代绝地武士, 尤达大师现身对他说了一段话, 大意是:
[“yes you can teach them, you can pass knowledge, pass experience, pass…, pass failure, yes, failure, is the most important thing… we are something they grow to beyond, that's the true meaning of masters.
你有能力教导她, 你可以传递知识, 传递经验, 传递…, 传递你曾经失败的经历, 是的, 失败的经历是最重要的, 在我们的帮助下, 他们将超越我们, 这就是一位Master真正的意义. "
*现场听记，可能与原文有出入 ]
Read more →
敏捷实践编年史（敏捷联盟版）记录了上世纪六十年代至今敏捷相关实践的发展史，其英文原版材料来自于国际敏捷联盟网站(AgileAlliance.org) .
原文链接: https://www.agilealliance.org/agile101/practices-timeline
本文由国内知名敏捷教练李洁（Jerry Li）和廖靖斌（Eric Liao）翻译成中文版本。
1968年:“康威定律（Conway’s Law）”
“康威定律”被提出并概括为:“任何组织，在设计系统（不仅限于信息系统）时，产生的设计在结构上必然会复制自身组织的沟通结构。”长期以来，“康威定律”都只是被当成民间传说，而非得到充分论证的科研成果，尽管最近有些研究为其提供了一些学术支持。（直到90年代中期，软件开发的人际交互方面仍然在很大程度上为软件工程学术研究忽视。）
Read more →
我最近写了篇博客回答了这个问题：“一个Scrum团队是否可以变得足够的优秀以至于他们不再需要Scrum Master了？”，在这篇文章中我发现了一个与此密切相关的话题：假设Scrum Master不会消失，那么Scrum Master的职业发展路线是什么？
根据我的经验，Scrum Master的职业发展路线通常会有如下的四个方向：
Read more →
Henrik Kniberg & Eik Thyrsted Brandsgård
2016年12月
原文授权链接: http://blog.crisp.se/2016/12/30/henrikkniberg/agile-lego
翻译&审校：
李洁(Jerry Li) 何强 龚正 姚宇宏(Ella Yao) 陈婧(Elina Chen) 申健(Jacky Shen)
统筹&出品：申健(Jacky Shen)
2017年1月
中译文链接：http://www.jackyshen.com/2017/01/31/planning-as-a-social-event-scaling-agile-at-lego/
— “什么？一个150人的团队会议只要（2天）1天？”
— “对啊！每两个月一次。运行得非常好。”
— “但是为什么这样？怎么做到的？”
Read more →
“ 人们并不抵制改变，他们抵制的只是被改变。”
- - 《Fearless Change》的作者Linda Rising
本文介绍敏捷变革的一些经典模型，做为撬动组织变革的杠杆，供大家参考实践。如下图所绘：
敏捷团队喜欢以一种刚刚好的方式处理需求。我们采用最低限度地、逐渐细化并保存在产品待办项（Product Backlog）中的特性描述文字，来替代传统长篇大论的需求文档。
我们发现用户故事是最好的描述方式，这种形式能够捕获到特性足够多的信息，并促进产品负责人和团队在后续进一步交流。用户故事是从人（通常是系统的用户或者客户）渴望新功能的视角来对特性进行描述。
用户故事一般会采用以下这种简单格式进行描述：“作为【某类用户】我【想要/能/需要…】以便【满足什么用户价值】”。尽管这种描述格式有其优越性，但只要能围绕着故事进行交流，用户故事可以以任何形式进行描述。
Read more →
很多项目都不会一开始就完全就绪——例如，需要分配人员和准备工作。为了处理这些项目开始前的任务，很多团队使用了“迭代0”的做法。虽然理解其由来，但我仍然感到担心。以下是我的理由。
停止“迭代0”的三个理由：
首先，尽管很难相信，但绝大多数的项目都是可以立刻启动的。我所听过的所有声称需要在Scrum项目启动前完成的事项有：需要组建团队，包括调配人员到项目上或雇佣新人；需要获取或者设置硬件设备；需要写一个初始的产品待办列表（即使只是高度概要的）。然而现实情况是：诸如技术环境、初始产品待办列表之类的事项都可以在第一个迭代中完成（一个完全是正常的和传统模式的迭代一），同时至少还可以交付了某些潜在可发布产品增量。
Read more →
