写点什么

我们需要规定性的敏捷教练方法吗?

  • 2014-09-19
  • 本文字数:1654 字

    阅读完需:约 5 分钟

指导团队时,敏捷教练通常使用一种“不干涉的”描述性方法。那么,团队在应用敏捷时,这种教练方法是不是始终都是最佳的解决方案呢?那种规定性的“亲自动手的”教练方法能否更加高效呢?你应该怎么做呢?

Robert Galen 写了一篇名为《世界需要更为规定性的敏捷教练》的博客,在这篇博客中他向称为“温和的、鼓励性的、影响型的”教练方法发起了挑战,虽然很多时候敏捷教练们都在采用这种方法:

我要开诚布公地讲,在敏捷中自我管理型团队非常的重要。我希望团队凭自己的力量对事情进行分类。但是我也在想,我们作为教练应该偶尔提供一些指导意见,而不要总是说“视情况而定”——特别是在我们面对完全崭新的一个团队时,他们实际上并没有什么经验。

他用 Shu-Ha-Ri 的比喻解释说,不同的团队需要不同类型的教练方法:

对于 RI(专家级)级团队,我希望教练给予相对宽泛和简单地指导。然而,当同一个教练遇到一个刚刚建立的 SHU(初学者级)级团队时,我希望他们给团队一些规定性的指导意见。并且,向团队明确地阐明组织约束,比如,帮助团队建立他们的完成标准。

Bob 提出五个主要因素,你可以用它来看看你的敏捷教练风格是不是过于温和了:

  1. 不愿意“告诉”团队要做什么
  2. 不愿意插手“叫停”
  3. 不了解平衡的时机
  4. 缺乏对视情况而定和规定性的比较
  5. 害怕投身其中

在一篇名为《什么是 scrum?…… …真的吗》的博客中,Niklas Björnerstedt 分享了他对 Scrum 定义的想法。按照他的说法,Scrum 原本就是有一定的规定的,而这正是它得以流行的原因。但是,在某些情况下实施规定性的 Scrum 却会成为错误的方式。

有很多真正杰出的 Scrum 大师,但也有大量教条的、不明就理的传道士。如果你的环境不适合 Scrum,他们总是回答说:改变你的环境使其适合 Scrum。如果你们自己能够掌控这些变化,那么这个建议就很不错。但是,如果你试图的改变涉及到核心的竞争力,那么这个建议就太可怕了。

在一篇名为《 Scrum 已死》的博客中,Andrew Kallman 和 Ted Kallman 说明了教练何时应该采用“亲自动手”的教练风格,而何时应该改为“不干涉”的方式:

从个人的层面来讲,每个人在“敏捷”之旅中都将经历一个类似的过程。在他们惊叹地发出“啊哈”之前,将额外需要深入实际的教练、指导和支持。但从他们“明白了”(真正的明白了)的那一刻起,他们就可以成为高效的团队成员,教练或指导者就可以更多地采用“不干涉”的方式去指导团队成员了。

而同样的道理也适用于团队。团队与之前讲过的个人是类似的,正在实施敏捷的团队有 58% 处于“啊哈”之前的位置。以某些合理的、商业的价值标准来看,他们算不上是高效的。他们或者只是走了走形式或者彻底地失败了。这些团队在通往“啊哈”的旅途中需要更具规定性的敏捷方法(比如亲自动手的教练或指导)。42% 的团队处于“啊哈”之后的位置,可以采用尽量“不干涉”的方法去引导、教练和指导(比如允许其自组织、自管理等等)。

Mike Carey 在描述性与规范性上发表了一篇博客,他在文中探讨了如何以非规定性的方式去部署敏捷框架。他解释了为什么团队在采用敏捷时可能希望得到教练的直接指导:

纯粹的敏捷开发人员一直都在推行尽量“不干涉”的方法。我最感兴趣的是,密切结合的一些敏捷开发人员如何形成了一种特定的方法。与这些人的交流通常可归结为“无论他们想干什么你都应该让他们干,但是如果你是个好教练,他们真的获得了这样的原则,那么他们会更喜欢继续使用我推荐的方式。……。问题是,他们得接受过一定的指导。你不能把团队丢给他们自己;你必须给予他们某种方式的支持。我不是说所有敏捷团队都需要一个专职的敏捷教练,但是他们需要有人来确保他们按照敏捷原则和环境的调整的方向,他们失败(不是如果)时会得到支持。

针对以非规定的方式进行指导的敏捷教练,他的建议是“改变你努力去表达你的意思的说话方式”:

当他们极力想要改进结果时,以及努力尝试一些别的东西时,弄清楚你为什么推荐某个实践。你要提议这个推荐的做法,但最好采用描述性的方法去解释它,而不是规定性的方法。

查看英文原文: Do We Need Prescriptive Agile Coaching?

2014-09-19 03:451253

评论

发布
暂无评论
发现更多内容

【译】JavaScript 代码整洁之道-变量篇

KooFE

JavaScript 大前端 变量 6月日更 整洁代码

react源码解析3.react源码架构

全栈潇晨

React React Hooks react源码

树莓派上的自动化---自动发送IP地址到邮箱

IT蜗壳-Tango

树莓派 IT蜗壳教学 6月日更

六一限定,致每一个追光者

脑极体

Grpc-go源码刨析

王博

【Flutter 专题】115 图解自定义 View 之 Canvas (四) drawParagraph

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 6月日更

Rust从0到1-泛型-trait

rust 泛型 Trait generic

网络攻防学习笔记 Day32

穿过生命散发芬芳

网络攻防 6月日更

基于MySQL Binlog 实现可配置的异构数据同步

王博

让你编程能力秃飞猛进的好习惯

程序员鱼皮

Java c++ Python 大前端 自学编程

NQI质量基础设施“一站式”服务平台开发解决方案

源中瑞-龙先生

开发 解决方案 NQI 质量基础设施“一站式”

GitOps系列一:为什么协作技术对GitOps至关重要?

极狐GitLab

Dubbo 服务在线测试

青年IT男

dubbo

【Vue2.x源码学习】第一篇-源码环境搭建

Brave

源码 vue2 6月日更

chia奇亚挖矿系统开发案例介绍丨chia奇亚挖矿源码功能

系统开发咨询1357O98O718

《面试官:谈谈你对索引的认知》系列之B+树

架构精进之路

MySQL 索引结构 6月日更

40 图|硬核解析用 Mac M1 玩转 SpringCloud

悟空聊架构

Spring Cloud Mac SpringCloud Alibaba m1 6月日更

如何理解梯度下降算法Gradient Descent algorithm John 易筋 ARTS 打卡 Week 49

John(易筋)

ARTS 打卡计划

算法训练营 - 学习笔记 - 第八周

心在飞

认识微前端:一种用于前端 Web 开发的微服务

devpoint

大前端 SPA

算法设计与分析——递归详解

若尘

算法 递归 6月日更

架构抉择之分合矩阵

凌晞

架构

Java 中 HashSet 的 removeAll 性能分析

落日楼台H

Java 性能 HashSet removeAll 集合删除

项目又延期了

escray

学习 极客时间 朱赟的技术管理课 6月日更

Spring Cloud Alibaba 实战

Damon

微服务 SpringCloud Alibaba 6月日更

面试官问我redis的string应用场景,我是这么回答的!

李阿柯

php lua redis 面试

springboot+mongo多数据源简单配置

Mars

mongo 多数据源配置

记录下PVE 装openwrt 后 pve 本身不能上网问题

三爻

云原生中定时弹性伸缩之CronHPA实战

雪雷

6月日更

[万字总结] 一文吃透 Webpack 核心原理

范文杰

大前端 webpack 6月日更

拉仇恨!webhook + 企业微信给同事做了个代码提交监听工具

程序员小富

Java GitHub 编程 程序员 代码

我们需要规定性的敏捷教练方法吗?_Scrum_Ben Linders_InfoQ精选文章