敏捷就是“团队快乐”

团结一致确保目标统一是敏捷的特点

结一致

抱成一团还是一盘散沙,这是个很简单的选择。但工作中,一个传统职能组织中的每个人都能够团结一致,相互帮助、相互补位又是一种很难达到的状态。

对于传统职能桶式的组织而言,虽然成员的岗位归属在一个组织中,但各自有各自的职能目标。比如产品要出需求,技术要写码,测试要进行测试。各职能之间与其说相互配合,不如说相互打架,各自都觉得自己没责任,同时都觉得上游不负责,下游事儿太多,苦活累活都自己干了还不讨着好。

敏捷团队首先定义了明确的团队目标,并通过口头沟通和可视化看板明确这些目标,同时这个目标是衡量团队成员工作成果的唯一体现。因此,当流程中某一节点出现问题时,由于大家共同关注的是产品的上线和价值,组织成员为了确保最终目标的达成,能够相互补位,对自己手头的事情也会根据当前的情况作出适当的调整以适应变化。比如,当需求太多而技术开发不完时,产品不是幸灾乐祸地觉得自己出活快,骂技术水平低,而是能够停下来一起分析细化需求,帮助开发更好理解,同时调整backlog迭代范围,以保障小版本上线;而当测试积压时,开发可以主动介入测试,与测试人员一起快速消灭待测代码。

敏捷团队能够团结一致,荣辱与共,这是一种文化,也只有具备这种文化的团队,才能在瞬息万变的市场中找到方向。

队伍纪律严明是敏捷的条件

伍纪律严明

不深入理解敏捷宣言,很容易误入歧途地认为敏捷就是没有规矩.恰恰相反,一直真正优秀的敏捷队伍,一定是纪律严明的.这种严明,不是军事化管理,而是为了更好地适应敏捷定义的各种约束。

敏捷团队人人平等,但为了组织更好的协作,清晰地定义了Scrum Master、Product Owner等角色和职责,确保每个人都能够在自己最擅长的领域发挥最大的价值;同时敏捷团队要求组织成员进行每日站会,养成良好的Face to Face沟通习惯;另外,对卡片故事、看板、燃尽图等工具的使用也有清晰的要求。敏捷试图通过最简单、直接的方式进行沟通协作,并使信息透明,以提高效率;而传统的职能团队或虚拟项目组也有很多制度,目的是告诉下游“我是按规矩做的,这个问题责任不在我”。

快速响应变化是敏捷的条件

速反应

天下武功,唯快不破。快于好总是一对冤家,因为我们总认为产品交付“必须能拿得出手”才能体现我的价值,这个观点毒害了一批又一批职场新人。因为价值是最后的结果,过程基本都是炮灰,为了炮灰精雕细琢是最可耻的浪费。

很多没有经历过敏捷的同学有满腔热血,也亟需证明自己,从被别人认可中找到快感,于是很简单的事情,不憋出个龟波气功的大招是绝不会发射的。一个功能讨论,从国外是怎么发展的,竟品是怎么做的,到我们这么做的优势和特点被多少论文论证过,然后是精美的、华丽的Axure原型,交互效果另前端的同学都叹为观止,最后的PDF写了100多页文档。这种认真令人感动,这种方式令人痛恨。

真正的敏捷,不是为了形式敏捷,而是为了最后的价值实现。价值不是凭空想的,也不是拍着脑袋做的,而是用户愿意用,愿意为其买单才能体现的。如果沉浸在自己的完美主义中,不断优化完善,跟自娱自乐烧钱玩没什么两样。失败不可耻,浪费自己和团队的时间、浪费投资人的金钱、因为懦弱没有勇气面对用户才是最可耻的。为了用户的认可,别顾忌那可笑的面子,睁开眼睛享受用户的谩骂吧,2周/版本的迭代速度,就足以把一切谩骂都甩在屁股后面。

享受敏捷的快乐才能持续推进敏捷实践

在其中

别愁眉苦脸,别郁郁寡欢,别目光呆滞,嘿,这里可是敏捷团队,我们都是产品的主人,我们都是创业者!

一个真正睿智的管理者,是不会天真的认为只靠KPI就能带来好的结果的,如果你不能让员工从工作中找到快乐和成就,就等着自己成为他们职业生涯的垫脚石吧。

所有人都喜欢激励,敏捷对团队成员而言,激励可不仅仅是产品最终被用户认可,更多的是体现在了每一个小的迭代周期中,自己消灭了一些卡片,获得了直接的反馈同时分享出去,并且在过程中能够与团队成员并肩作战,享受大家的鼓励和用户的抱怨。也只有快乐并充实的工作,才能让敏捷焕发出如此强大的生命力!

分享到:
  1. 对敏捷团队的理解深表认同,敏捷团队就是一支为了共同目标而战斗的特种分队。队员间有生死兄弟般的友谊,互相信任。在执行特殊任务的过程中,拥有敏捷的身段,对于战场瞬息万变的情况能够迅速反应,最终能够夺取任务的最终胜利。

    • 没错,对目标理解不一致是很多团队最致命的问题,战场形式瞬息万变,只有真正的团队,才能响应变化,迅速反映并找到突破口。

  2. 团队协作的好自然就反应敏捷了,反应敏捷就表示团队肯定是特别和谐的,这是相互的。