Are You Dealing With the Correct Issue?（你在解决正确的问题吗？）
（本文的中文部分请往后翻页）
This is a real story that happened in one of the recent retrospective meetings.
Our process of performing the retrospective is each individual Scrum team will first do their respective retrospective and then all Scrum teams get together to do the team retrospective as a whole group where each Scrum teams will present their retrospective reports. Everybody in a Scrum team will talk about one or two parts of their retrospective report.
When the Scrum Master (our Scrum Master is rotated for every Sprint) of one Scrum team, could be called as Team A for the sake of convenience, pointed to the gap analysis of an unfinished user story, and reported that the root cause of it was the technical solution was not ready so it held the team from implementing it.
I doubted whether this was true, so, I asked the question, what would be the improvement action if this was the real root cause. The Scrum Master said because there was no technical solution, this indicated that the team who developed the technical solution did not do their job very well, they should refine their DoD(Definition of Done). This answer was not what I expected, because the retrospective should be focus on the team and each individual himself. The conversation continued.
I: as the team who developed the solution proposal is in another site, would you refine the DoD for them and then convince the team to accept the DoD?
Scrum Master: probably we can try.
I: if you’d start to define the new DoD for this team, what would it look like?
Scrum Master: they should consider our use cases, because our use cases are more complex.
I: if that’s true, then seems the root cause is there’s a technical solution but it was developed but not verified with all possible use cases.
I (turned to another person, Jack): was there really no practical technical solution?
Jack: the technical solution was discussed and reviewed, with all possible use cases being considered.
I (turned to the developer, Mike, who own this user story): if that’s true, why this user story was not completed?
Mike: I had already done with the coding, however, I did not commit the actual implementation to the repository, because the scripts that parse the configuration file has not been updated, if I committed the implemented code, the software would be broken, and the integration of the code would then be broken. So, I just commented out all my implemented code.
(I know the scripts were also owned by the same team in another site.)
I: So, that’s saying your work depend on the scrips who owned by another team, because this dependency was not implemented, it impacted this user story owned by you. Is this the correct sequence?
Mike: That’s true.
I (turned to Jack): Did you tell the team, and put this action item on the track?
Jack: Yes, I did tell them what should be updated, but I did not track the implementation.
I (turned to Garin): Did you tell the team, and make sure it was implemented?
Garin: No, I don't know the scripts need to be updated, I was not involved in the discussion of the solution.
I (turned to the Scrum Master): then can we say, the real root cause is, there’s a dependency between us and the other team in another site, and this dependency was not well managed?
Scrum Master: Yes. We’ll update the retrospective report, and change the improvement action.
Through asking series questions to different people, team A is able to figure out the real problem and the improvement actions that the team could implement in next Sprint. However, if I did not ask those questions, the team could end up with identifying the wrong actions because the very original root cause was completely different.
Every day, people typically spend 5% of their time to define the problem to be solved and then spend the left 95% of their time to figure out the solution and take actions. This does not create much values, except being kept very busy, because most likely, around 80% of the problems identified everyday were either wrong or not real problems.
But why?
This is because of the nature of the human beings:
- people are good at figuring out the solutions, so we often like to jump to the discussion of the solutions directly;
- it makes people happy by geting problems solved, it doesn't matter how much values were created by solving the problem;
So, we're very busy everyday, and we feel the life is very difficult, because the more "problems" we solved, the more new "problems" are created.
Then what should we do?
The correct way is: resist the tempt to jump directly to the solutions and tell yourself to spend 95% of your time to define/refine the problem, and then use the left 5% to figure out the solution and get the problem solved.
So, next time, if you're struggling with figuring out solutions of a problem without results，please stop and take one step back, ask yourself a question: is this the correct problem to be solved? With this way, every minute spent is guaranteed to be worthwhile.
这是一个真实的故事，发生在最近的一次回顾会议中。
我们执行回顾的过程是，每个单独的Scrum团队都将首先进行各自的回顾，然后所有Scrum团队会聚在一起进行整个团队的回顾，每个Scrum团队都会展示他们的回顾报告。 Scrum团队中的每个人都将谈论其回顾报告的一两个部分。
当一个Scrum团队的Scrum Master（我们每个Scrum团队的Scrum Master在每个Sprint中都会轮换），为了方便起见，可以称为A团队，对未完成的用户故事做差距分析时，指出其根本原因由于技术解决方案尚未准备就绪，因此使团队无法实施。
我怀疑这是否成立，所以我问了一个问题，如果这是真正的根本原因，那将是什么改进措施。 Scrum Master说，因为没有技术解决方案，这表明开发技术解决方案的团队做得不好，他们应该完善自己的DoD（完成定义）。这个答案显然不是我所期望的，因为回顾应该集中在团队和每个人身上。我们的对话继续。
我：由于开发解决方案提案的团队位于另一个地区，你是否会为他们完善DoD，然后说服该团队接受你的DoD？
Scrum Master：也许我们可以尝试。
我：如果您开始为该团队定义新的DoD，它会是什么样？
Scrum Master：他们应该考虑我们的使用场景，因为我们的使用场景更加复杂。
我：如果的确是这样，那么根本原因似乎是存在一个技术解决方案，虽然该解决方案已经开发，但尚未针对所有可能的使用场景进行验证。
我（转向另一个人，杰克）：真的没有切实可行的技术解决方案吗？
杰克：我们早已讨论并审查了技术解决方案，并考虑了所有可能的情况。
我（转向此用户故事的开发人员，迈克）：如果的确如此，为什么这个用户故事没有完成？
迈克：我已经完成了编码，但是，我没有将实际实现提交到代码库，因为解析配置文件的脚本尚未更新，如果提交实现的代码，那么软件将被破坏，代码的集成就会中断。 因此，我只是注释掉了所有已实现的代码。
（我知道这些脚本由另一个地区的同一团队维护。）
我：也就是说，你的工作取决于其他团队的输出，因为这种依赖关系出了问题，因此影响了你的用户故事的完成，这是正确的顺序吗？
迈克：是的。
我（转向杰克）：你是否告诉这个团队，并将这项任务追踪起来？
杰克：是的，我确实告诉他们应该更新什么，但是我没有跟踪实施情况。
我（转向加林）：你是否告诉该团队这个事项，并确保他们按要求实施？
加林：不，我不知道脚本是否需要更新，我没有参与解决方案的讨论。
我（转向Scrum Master）：那么我们是不是可以说，真正的根本原因是，我们与另一个团队之间存在依赖关系，并且这种依赖关系没有得到很好的管理？
Scrum Master：是的。我们将更新回顾报告，并更改改进措施。
通过向不同的人提出系列问题，团队A能够弄清楚了实际问题以及团队在下一个Sprint中可以实施的改进措施。但是，如果我不问这些问题，团队可能最终会确定错误的行动方案，因为问题的根本原因是完全不同的。
通常，人们通常每天花费5％的时间来定义要解决的问题，然后花费剩余的95％的时间来找出解决方案并采取行动。除了保持非常忙碌之外，这不会产生太多价值，因为很有可能每天发现的问题中大约有80％都是错误的或不是真正的问题。
但是，这是为什么呢？
这是由于人类的天性：
1. 人们善于找出解决方案，因此我们经常喜欢直接跳到对解决方案的讨论之中；
2. 通过解决问题可以使人们感到高兴，而解决问题可以创造多少价值并不重要。
因此，我们每天都很忙，我们感到生活很艰难，因为我们解决的“问题”越多，就会产生越多的新“问题”。
那么，我们该怎么做呢？
正确的做法是：抵制住直接跳到解决方案的诱惑，告诉自己要花95％的时间来定义/细化问题，然后用剩下的5％来找出解决方案并解决问题。
因此，下次，如果您正在努力寻找问题的解决方案并且没有结果时，请停下来并退后一步，问自己一个问题：这是要解决的正确问题吗？ 通过这种方式，可以确保花费的每一分钟都是值得的。
（注：本文的中文翻译由Google Translate完成，我只对其中大约10%左右的内容做了细微的调整。可以预见的是在不远的将来，机器翻译将替代绝大多数的人工翻译工作。）