
用数字沟通——来自敏捷精灵的忠告
因为不知道如何反击,技术人员不得不听从业务人员的要求。这已经是老生常谈了。问题何在?开发人员用数字主要是进行计算的,而业务人员使用数字辅助决策。在下面的故事中,“敏捷精灵”鼓励一个开发人员用数字来描述与计算无关的问题。

因为不知道如何反击,技术人员不得不听从业务人员的要求。这已经是老生常谈了。问题何在?开发人员用数字主要是进行计算的,而业务人员使用数字辅助决策。在下面的故事中,“敏捷精灵”鼓励一个开发人员用数字来描述与计算无关的问题。
风险管理所处理的就是把风险发生的几率和对项目的冲击减少。敏捷开发中迭代的性质,间接使风险管理成为项目周期的一部份。敏捷开发的社区上就是否需要明确指定风险管理、Scrum去管理所有类型风险的能力、以及谁应该负责风险管理作出讨论。
在采纳敏捷时陷入困境了么?Amr Elssamadisy主持了一个话题讨论,主题是关于造成采纳敏捷流程很困难的原因。他为听众提供了三种模型,用以理解在采纳敏捷时可能见到的问题。
Scrum团队没有指定的领导,一切都靠自组织。一个全球最负盛名的交响乐队也完全取消了指挥的角色,演奏过程中的领导权是共享的,整个团队共同做出决策。他们在团队合作中积累到不少教训和方法,任何Scrum团队都能从中受益。

敏捷的“自组织团队”模式需要团队成员们具备新的技能——包括他们曾寄希望于项目经理具备的人际交往技能。此时,管理不再是多余的东西,它对帮助团队学习新的沟通和协作方式起到了非常重要的作用。本文为如何传授新的技巧给出了一些策略,并提供了一些相关资源。

敏捷教练Michael Spayd告诉我们:不管是承包商还是永久雇员,都可以担任“咨询师”的角色,并且应该思考与客户一起制定咨询合同或是设计伙伴关系——不是为了完成金钱交易,而是按照“咨询师”自己的价值观与喜好来工作,并要帮助客户产出卓越的绩效。

一个新人需要多久才能真正融入你的团队并发挥效力?"学习"过程对于敏捷方法论是必不可少的。但是对于不同的团队成员,新人需要向他们学习的东西并不相同:在站立会议上,一句“我昨天做了(难以理解的内容)……”给新人带来的问题要多于它所提供的帮助。Pat Kua建议利用一些实践,来减少团队中新人的“启动时间(setup time)”。
相对传统的管理方式来说,有些组织采取了“放权式”的管理,可他们的绩效产出确实超越了采用“命令与控制”方式进行管理的竞争对手了吗?Rotman管理学院系主任Roger Martin发现这种“大有前途的”方法却经常失败。他的分析结果是:失败的原因来自“责任病毒(Responsibility Virus)”;他提供了一系列工具,帮助那些希望解决自己身边类似问题的人。书评人Deborah Hartmann认为这本书能够很好地解释为什么仅改进流程是不够的。