Timeline for How do big development teams learn from their mistakes?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 11, 2020 at 20:31 | comment | added | Stack Exchange Supports Israel | @CaptainMan That's still blaming, even if there's no punishment. | |
| Sep 11, 2020 at 19:18 | comment | added | Al rl | @RobinBennett From your example it looked liked you needed to chain 5 why question. This feels super arbitrary and the end results may be doubtful. | |
| Sep 11, 2020 at 18:18 | comment | added | Captain Man | @user253751 There may be a better way to phrase it. Think of it like finding who/what failed. Then if it were a person not punishing them. So you find who/what is at fault but you do not punish them (unless of course they actually did something worthy of punishing like telling a lie). You may need to take corrective action like training them, but that's not a punishment. Sometimes these are called "blameless retrospectives." | |
| Sep 11, 2020 at 15:04 | comment | added | Robin Bennett | @Alrl - if it's not obvious, you're supposed to stop when you have found enough things that you can fix that you feel confident that it won't happen again. | |
| Sep 11, 2020 at 12:26 | comment | added | Al rl | This seems useless and just forces you to push the responsibility in someone else's yard and not improve any process. Also always asking 'why' seems to be akin to emulating a child always asking why until you stray far away from anything remotely useful. | |
| Sep 11, 2020 at 10:50 | history | edited | Robin Bennett | CC BY-SA 4.0 |
added 419 characters in body
|
| Sep 11, 2020 at 0:28 | comment | added | Graham | I used to be a specialist in safety-related software. The main point to grasp there is that everyone gets stuff wrong. So asking "why did Bob build something wrong?" after the fact is the wrong question. The right question is "when Bob builds something wrong, who would spot it?" and then you can engineer your system so that two people have to screw up for the bug to leave the building. | |
| Sep 10, 2020 at 18:26 | comment | added | Stack Exchange Supports Israel | "An important factor here is not to assign blame" - but you just implied Bob was to blame! | |
| Sep 10, 2020 at 12:26 | comment | added | Manziel | We have used the "5 why" technique and I found it to be of limited use. The results are very unstable and with a slight change on level 2/3 you will end up in completely different directions. For example, I might not question Bob's competence but ask "why has Bob to check it manually (as opposed to an automated test". Anyways, I found that in the end this will always end up somewere outside or at the border of the teams influence like staffing, the business strategy is changing every few months, a product that can do X was sold to solve problem Y, etc | |
| Sep 10, 2020 at 11:16 | comment | added | Robin Bennett | @Jim - I've expanded that section a bit. The answers did lead to Bob, but only after 2 'whys'. If you keep going you discover how the company can prevent the same thing happening again. | |
| Sep 10, 2020 at 11:13 | history | edited | Robin Bennett | CC BY-SA 4.0 |
added 587 characters in body
|
| Sep 10, 2020 at 10:50 | comment | added | Jim |
An important factor here is not to assign blame as blame ... does not seem that easy though unless there is a template format to achieve this.E.g. even in your answer the why's seem to lead to Bob or finger point at Bob
|
|
| Sep 10, 2020 at 9:59 | history | answered | Robin Bennett | CC BY-SA 4.0 |