在成为Scrum Master（SM）之前，我曾担任过许多团队的技术负责人。工作内容之一就是做决定，而且我认为自己做得挺好：坚定果断是我性格的一部分。
然而，当我成为Scrum Master之后，这样的性格并没有为我带来多少好处。我开始意识到：要想做一名成功的Scrum Master，我需要从做决策转为提问题。
然而这不符合我一贯的风格，在过去也未给我带来任何成功，因此在一开始的时候我是很挣扎的。
但是，当我不断从提问的过程中受益时，我会很乐意和大家分享我最爱问的问题。其中大部分问题在团队中都很容易被问到，无论你是Scrum Master还是PO。
2个关于估算的问题
我经常会要求团队进行一个粗略的估算，并不是要求让他们按照估算去做（因为我不是要求他们承诺，估算和承诺不是一回事儿），我确实只是需要一个粗略估计。
在这种情况下要做得好，得这样问：我并不是在要求一个具体的估算值，而是当我问你的时候你脑海里浮现出的是什么：几小时、几天、几个星期、几个月或者是几年？
当然，我知道这些时间有些是重叠的——几个星期可能就比一个月长。但是如果从团队那里得到类似“哦，只要几个星期”的估计时，通常已经足够做决定了，包括可能要求团队做出更确切的工作评估。
当我要求确切的工作评估时，我通常会问另一个问题：
你对这个估算有多大的信心？你在这里要去发现：他们对此抱有多大的信心以及团队其他成员是否赞成，一个预估如果有90%的人抱有信心，那么它极有可能是精确的。
3个关于团队决策的问题
作为Scrum Master或是PO，有时候我会想知道团队在做决定的时候做了哪些考虑。
通常我会问这样三个问题：
- 你在做出决定前你还考虑过其他三个选项吗？
- 如果我们继续按此方向进行，可能发生的最糟糕的情况是什么？
- 要做些什么才能让这个决定成为最佳决策？
你可能不问这三个问题，也不在团队每次做决定的时候问同样的问题。你不问这些问题是因为作为一名Scrum Master或PO，你有权利否定团队的决定。但是，你同样有义务去理解团队对此决策的信心。
设计这些问题是为了发现不同的见解，因为当你直接问“要做些什么才能让这个决定成为最好的？”而有人回答说“所有事情”时，这就有可能会出问题。
2个关于开会的问题
我真的不喜欢开会，如果我被扔到一个一头有蛇，另一头在开会的的走廊上，我不确定自己会跑向哪边。所以我会尽量将开会次数及参会人数保持到最少。
而且在会议开始时我会问两个问题：
- 在场的各位都需要开这个会吗？
- 还有其他人在这里吗？
问第一个问题是想看看：如果少一两个人这个会议是否还能继续？
我经常看见敏捷团队过于追求团队协作，成员总会觉得每次开会他们都需要参加，甚至是和他们不相干的会议。曾经有JavaScript的程序员，参加了关于数据库供应商发布的最新版本是否值得升级的讨论会。
如果你团队成员对开会这件事过分热心，那你需要感谢他们对协同工作的用心，但是要明确告知他们不需要出席每个会议。
建立团队规范，如果团队成员在会议中不能创造价值或者没有收获，那他就不能参加这个会议。
当然，你必须明确告诉大家，这并不代表他们可以选择每个会议（要不要参加），以防止这个规定被滥用。最后，团队作为一个整体有权否决某人不愿意参加某个会议的想法。
第二个问题是为了确定是否有人缺席？
尽管我真的很讨厌开会，但有的时候会议真的需要很多人。尽管我认为开会和开会的人越少越好，但是有的会议是值得的，而这些会议因为有了合适的参与者而产生更多价值。
1个在“闲逛”时提的问题
在成为Scrum Master后，我花了更多时间在交流上，这就是传统的走动式管理。
举例来说：如果我看到程序员和测试员在进行一场重要的谈话，我可能会走过去听他们在说什么，因为也许我能给他们提供一些帮助。（当然了，不要每次都走过去，尤其是他们看起来是在讨论私事的时候）。
有时候我听得到的讨论可能是对其他人有价值的，比如：我认为一个技术作者，应该了解程序员和测试员会怎样做决定。
所以我会问：有其他人需要知道这件事吗？
如果答案是肯定的，那我会尽量找一个人将这些信息分享出去。
1个在每日站会时提的问题
在每日站会中，我会去关注团队的燃尽图，并思考他们怎样在sprint结束时完成所有计划。但是，当我问同一个团队他们是否能完成所有事情时，答案通常是肯定的。
如果我认为他们的预测不现实，我会看着燃尽图并且问道：你知道我想了解的是什么吗？
我可能会得到这样的答复：有成员没有更新自己的工时。或者有人会解释说：他们的进度目前的确有点落后，但是他们已经学会了很多东西而且马上就会提速赶上。（我发现这种说法很少实现，因为我经常听到这样说）。
也许他们认为正在加快速度，但我不是这样想的，这是个发现不同假设的问题。