文章频道为您提供Leangoo实践，以及Scrum,敏捷,精益创业,产品创新等领域专业文章。
在进行CSM（认证Scrum Master）授课时，我听到的最常批评之一是“Scrum团队有太多的会议了”。
由于Scrum具有每日Scrum站会、Sprint计划会议、Sprint评审会议、Sprint回顾会议，甚至可能还有产品待办列表精化会议，也就不难理解为什么人们会这样评论。
但是让我们看看这是不是真的。
一个实验
这里有一个实验，我希望你能试试，尤其是如果你认为Scrum会议太多。
从5-10中选择一个随机数。然后回想一下，你的团队是什么时候开始以敏捷方式开始工作的，或者他们是什么时候开始能较好地以敏捷方式工作的。
在你的工作日历（无论是在outlook、Google、苹果日历，或者其他什么程序）中，定位到这个月。现在，记得你在上一段中选择的随机数吗？再向前回滚随机数所对应的月数。
Read more →
《2018 State of Scrum》报告由美国Scrum Alliance发布。从实践者、教练、讲师等角度来探寻规模化敏捷转型中的问题，有助于理解、比较和思考敏捷方法在不同行业的效果。
本文摘取了部分精华数据，翻译成中文，供华语敏捷社区参考。鼓励大家在培训和教练辅导中引用这些关键点。
昨天, 去看最新上映的星战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真正的意义. "
*现场听记，可能与原文有出入 ]
这段话可算是“服务型”领导人绝佳的写照了, 也是Scrum 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的职业发展路线通常会有如下的四个方向：
服务多个团队或更具挑战性的团队
Scrum Master典型的职业路线是从服务一个团队开始的。经过一段时间之后，团队相关的问题得到解决，团队磨合的越来越好，团队自身开始承担越来越多的责任，Scrum Master花在团队上的时间逐渐减少。
这个时候，一个好的Scrum Master将寻求更多的挑战。通常，合理的下一个步骤是服务多个团队，或者服务于需要更多支持的团队或产品。
在培养新Scrum Master的时候，我们通常倾向于把他放在一个更有可能成功的环境下，服务于一些比较容易合作的团队，既没有刺头，又没有不切实际的交付要求。但是，从一个优秀的Scrum Master发展成一个卓越的Scrum Master往往需要在更复杂、更具挑战性的环境下历练。
这也印证了成功是对额外挑战的奖励的哲理。
Read more →
Sprint评审会议可能是产品人员最重要的Scrum活动，它可以帮助您收集反馈意见，做出正确的产品决策，从而增加创造成功产品的机会。但是我发现，产品负责人并不总是清楚谁应该参加会议，应该如何开展这个会议，以及如何收集相关反馈。本文将回答这些问题，并分享我的一些建议，以帮助您在Sprint评审会上得到更多收获。
从正确的人那里收集反馈信息对于做出正确的产品决策至关重要：如果您邀请了不合适的人参与，或者关键人物未到场，那么您不太可能收到您所需要的反馈。因此，你应该确保你邀请合适的人参与。
一般来说，邀请那些你需要获得反馈来验证最新产品增量，以及可以帮助您推进产品发展的人参与。这些人通常是您的关键干系人 - 对您的产品有兴趣的人员，以及您需要去发掘的产品用户和需要你提供产品的人。这些人可能包括营销，销售，服务和支持人员以及其他业务部门的人员，具体取决于您的产品和组织。
为了鼓励干系人参与，以及管理干系人的期望，告诉他们为什么需要他们参加会议，以及他们可能会看到什么，这是很有帮助的。 Read more →
Sprint Backlog是Scrum 团队在当前Sprint必须完成的任务清单，根据Sprint backlog ，Scrum团队在Sprint的最后交付一个带有增量功能的软件。
创建Sprint Backlog发生在sprint计划会议的第二部分，每一个团队成员都需要参加。真正的重视这个过程是更好地了解Sprint中团队应做哪些工作，以及更好的做Sprint的计划的基础。尽管这样，许多团队仍然为这个事情挣扎。
我希望如下这些建议对他们有点帮助：
1.让每个队员都要参与这个过程。
2.讨论每一个用户故事应该如何实现。确定开发任务之前。
3.对于完成的标准要有明确的定义。
4.标识出所以需要完成的任务。
5.不要事先分配任务。
6.重新审视sprint的承诺。
7.不要使用过多的时间。
8. 在sprint过程中演化Sprint Backlog。
此文由Scrum中文网整理，转载请注明出处
我在之前的帖子里曾写过对sprint进行编号除了用数字之外还有其他选择吗？今天这篇帖子我来说说一些团队给sprint编号时使用的的一个非常特殊的数字—0。
Sprint0这个概念在有些团队中变得越来越常见，所以我们很有必要来思考一下它到底是不是个好的提议。
首先，假设我们赞同sprint0存在的必要性。Sprint0通常被声明为必须的，因为在scrum项目开始前有许多事情要完成。例如，需要组建一个团队。这可能涉及到要招聘或调拨一些人到这个项目来。有时，也需要采购一些硬件或至少要安装一些软件。许多项目组也在努力说服别人，说他们需要在sprint0中编写初始backlog（即使仅仅是高级别的）。
设置spint0的一个最大的问题是，它产生了例外—有些sprint或sprint类型具有与众不同的特性。比如，在sprint结束时能得到潜在的可交付的成果这一scrum宗旨就被摒弃了。毕竟，如果sprint的目标是组建团队，那么他们怎么能得到潜在的可交付的东西呢？
Read more →
用户故事可能是捕获产品功能的最流行的敏捷技术：使用用户故事很容易。但讲出有效的故事可能很难。以下十个技巧可以帮助您创建好的故事。
1. 用户第一
顾名思义，用户故事描述了客户或用户如何使用产品，它从用户的角度进行表达。另外，用户故事特别有助于捕捉特定的功能，例如搜索产品或进行预订。下图说明了用户，故事和产品功能（由圆圈表示）之间的关系。
如果你不知道谁是用户和客户，以及为什么他们会想要使用这个产品，那么你不应该写任何用户故事。首先进行必要的用户研究，例如通过观察和访问用户。否则，就有基于自己的想法和信念写出假想的故事的风险，而不是基于数据和经过验证的证据。
Read more →
2016年的Scrum联盟会员调查显示，曾经只用在软件开发领域的Scrum和敏捷实践，在IT行业之外也取得重大进展，并在非技术行业中也获得认可。这项调查结果反映了目前的一种趋势——各类公司都在使用Scrum和其他敏捷框架来进行创新和保持竞争力。
全球劳动力市场上的敏捷趋势
89%的受访者表示，在他们公司使用Scrum（或至少包含Scrun）作为实施敏捷的方法。（92%的受访者使用各种形式上的Scrum）。kanban是第二常见的，接下来就是Hybrid，然后是传统的瀑布模式。前三位的排名2015年是21%，在2016年已降至17%。
Read more →
