5 ms·

I'm not sure this was your intention, but you have just described how folks are supposed to do postmortem and retrospectives at most agile shops, as well as how

I'm not sure this was your intention, but you have just described how folks are supposed to do postmortem and retrospectives at most agile shops, as well as how Toyota created the kanban process and implemented the andon cord. It's strange and probably not useful if it's based around assigning guilt. But if it's based around trying to uncover a root cause in process or system deficiency and solving that, then no, it doesn't seem strange to me. You can modify your code to use the API correctly, but if your team doesn't get the documentation fixed or the test environment to sync back up with the production API, your team is not solving the issue. Your code can cause headache for everyone after runs in production for a month, but unless your team begins to do code review, you're not solving the issue. In a very literal sense, the idea of the team finding an issue and resolving it (apology or not) is extremely important and one of the few ways for an organization to improve rather than decay over time. The apology is almost a formality.

Buttons840 6y ago
Maybe I've been watching too many Star Trek reruns, but the thought comes to mind: "Blame is irrelevant, apologizing is irrelevant." I've been part of such retrospectives, and no blame is given, and no apologies are given. There is no hesitation to lead the investigation into "your own code". "Your code" might end up being what needs to change, but it was not alone in causing the fault in the entire system. Another though experiment (stripped of all moral judgement): Alice writes some code which runs as part of a larger system for 10 years. No problems are identified in the system. Bob writes some code. After Bob's code is integrated with the rest of the system, problems are identified in the system. Changes are made to Alice's code which resolve the problems. Who is at fault? You probably find it hard to identify who is at fault without knowing more details. You need details so you can form your own personal moral judgments. Perhaps a better question is: Can we ever objectively identify who is at fault? And does it matter?
- roosterdawn 6y ago
  This is a great question. To me, the only answer is (as I believe you're alluding to) "who" is at fault is not relevant when compared to "what" is at fault. In this case, the problem is the lack of proper systems level integration testing, and neither Alice's nor Bob's code in isolation, and the "who" that ends up being at fault should be the management chain of command that allowed the state of things to allow such a scenario to occur. As management decides to want to prevent such embarrassing and costly blunders, they should resolve to invest more in the process and tooling that prevents such situations from being possible. Of course, it is also possible for management to shirk such responsibility and push that responsibility (without corresponding process ownership) onto the ICs. It's quite common in low performing organizations.

Buttons840 6y ago

Maybe I've been watching too many Star Trek reruns, but the thought comes to mind: "Blame is irrelevant, apologizing is irrelevant." I've been part of such retrospectives, and no blame is given, and no apologies are given. There is no hesitation to lead the investigation into "your own code". "Your code" might end up being what needs to change, but it was not alone in causing the fault in the entire system. Another though experiment (stripped of all moral judgement): Alice writes some code which runs as part of a larger system for 10 years. No problems are identified in the system. Bob writes some code. After Bob's code is integrated with the rest of the system, problems are identified in the system. Changes are made to Alice's code which resolve the problems. Who is at fault? You probably find it hard to identify who is at fault without knowing more details. You need details so you can form your own personal moral judgments. Perhaps a better question is: Can we ever objectively identify who is at fault? And does it matter?

roosterdawn 6y ago
This is a great question. To me, the only answer is (as I believe you're alluding to) "who" is at fault is not relevant when compared to "what" is at fault. In this case, the problem is the lack of proper systems level integration testing, and neither Alice's nor Bob's code in isolation, and the "who" that ends up being at fault should be the management chain of command that allowed the state of things to allow such a scenario to occur. As management decides to want to prevent such embarrassing and costly blunders, they should resolve to invest more in the process and tooling that prevents such situations from being possible. Of course, it is also possible for management to shirk such responsibility and push that responsibility (without corresponding process ownership) onto the ICs. It's quite common in low performing organizations.