Morbidity And Mortality
Podcast: Play in new window | Download (53.8MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
In medicine there is a review process that doctors and students/residents use to review a failed case or one that ends with negative outcome. This typically means loss of life but not always, it could come from amputating the wrong limb, etc. It’s were a lot of the policies that hospitals have come from. It is called a morbidity and mortality. In these meetings the doctors, students, and residents involved present a case for their peers to review and discuss what could have been done differently. They review the cases to see what they can do in the future to avoid similar outcomes.
“Blame is not placed in these meetings.”
In medicine the idea of a Morbidity and Mortality conference is to look back on a case after the fact, when the emotions around it have died down some. The doctors will put together a case study from what happened and then discuss it with colleagues. While we don’t exactly do this for failed sprints/projects in development it might be something worth looking trying.
In agile development, specifically SCRUM, we have a similar process that we do at the end of each sprint. This is the Sprint Retrospective. It takes place after the Sprint Review before the next sprint starts. The Retrospective provides the team a way to inspect their process and look for ways to improve. However the ways of addressing and dealing with failure are not restricted to just the Sprint Retrospective or to just Agile/SCRUM. They can be applied to failure in waterfall methodologies or to entire project failures. The idea is to review what happened to cause the failure and work as a team to determine how to prevent it from happening in the future.
Episode Breakdown
Successful Sprint Retrospective
The purpose of the Sprint Retrospective is to provide a chance for introspection into the team and it’s processes.
11:57 When it Happens
It takes place after the Review but before the next sprint starts. Typically it is scheduled for 2-3 hours. The meeting is held with the team in person.
13:44 Who Participates
“Either people don’t tell the truth with management, or it becomes a place for power games with that.”
The entire team participates in the retrospective. However, management is not to be in the room. The retrospective is organized and run by the SCRUM master. This can be a problem if there are members of management such as lead developers on the team.
15:45 What Takes Place
During the retrospective the team reviews the previous sprint talking about what went well and what did not. There are several different ways to go about reviewing the previous sprint. Typically each member is provided a chance to list what they want to improve or remove from the sprint process.
Common Causes of Sprint Failure
A sprint fails if all of the items sprint backlog are not complete by the end of the sprint. The Sprint Backlog is the stories that are chosen from the Product Backlog to be worked on in a particular sprint. This may or may not include testing depending on your workplace. It doesn’t count as a failure if a story is dropped or removed from the sprint based on business needs.
22:14 Team Over-Commits
The most common reason for failure is that the team over-commits what they can do. This may be because of poor estimations or unexpected interruptions during the sprint. Tasks may seem easy on the outset but when you get into them are more difficult.
24:25 Poor Task Assignment
“When someone is doing resume driven development so you have a backend developer that is wanting to do front end.”
Another problem that can cause failure is when the team members don’t appropriately assign themselves tasks. This could be members taking on tasks they are not ready or able to complete. It could also be members avoiding certain unpleasant tasks hoping someone else will do it.
27:21 Changes to Team Structure
Changes to the team structure can drastically detriment a sprint or project. Adding new members to a team or replacing members will effect the teams ability to perform and should be taken into account when committing stories to a sprint. Sometimes team members get pulled from a team during the sprint by management and the sprint and team suffers. If this happens the team should stop the sprint then recommit based on new team size and dynamic.
29:04 Scope Creep
“It’s a fundamental principle of software development that you don’t write to something while you’re reading it.”
Scope creep occurs when the acceptance criteria changes after the story has been committed and the sprint started. Once a story is committed it becomes immutable. Another story may need to be created to address the changes. The story could also be dropped from the sprint to be readdressed later. Allowing scope creep to happen is like running a race where the finish line keeps changing.
31:10 Poor Acceptance Criteria
Poor acceptance criteria will cause problems through out the sprint and lead to the previous problems. A disconnect between the developers on a team from unclear criteria can cause a sprint to suffer. Even if the developers and testers are on the same page the PO and customers may expect something different if it is not clear. This should be one of the easiest things to avoid but so many teams suffer because of their criteria.
Effects of Failure on the Team
“Most people really don’t want to fail.”
The whole team will likely be stressed as they have been working extra to avoid the failure.
34:38 Placing Blame
It may seem easy to place blame on external sources or individual team members. It may be the case that the team failed because of an external resource. It could also be that one or more members of the team are not pulling their weight or not doing what they have committed to do. Both of these circumstances can be very frustrating for members of the team that are working hard and even taking on extra.
37:00 Overreacting in Planning
“Either they’re trying to recover or they’re trying to hedge their bets.”
Failure also makes a team want to take on less work in the next sprint. This may be a good idea to get a win and bring morale back up. However, you have to avoid overreacting to this and taking on too little work.
38:57 Role of Management
Management has a vital role to play in how the failure effects the team. A positive outlook from managers can help a team quickly recover from failure. Management may lean toward negative reinforcement, however this is rarely successful in the long run. This is the removal of privileges or extras to motivate a person to work harder. It can be a strong motivator to do just enough to succeed, workers don’t want to try new things for fear of failure.
Reviewing the Failure
42:55 Don’t Blame Each Other
“This is something we’ve all been tempted to do especially when you know exactly who’s fault it is you failed.”
The most important thing when reviewing a failure is to not play the blame game. The purpose of reviewing what happened isn’t to place blame but to find a better way to doing things so they team as a whole succeeds.
43:43 Find the Root Cause
The goal is to find the root cause of the failure and identify ways it can be addressed. Look into what happened within the sprint to cause the failure. Then discuss ways that it could have been solved or mitigated earlier in the sprint.
44:45 Process vs Personnel
“If you get the process sorted out the personnel problems will show up.”
Problems tend to fall into either a problem with the process or problems with personnel. The retrospective is best a determining problems based on the process. Personnel problems are a bit trickier to find the root cause.
47:23 The Five Why’s
One of the best ways to get to the root of a problem is the 5 Why’s. In this technique you continue to ask why until the root is found. Doing so will help you distill the cause of a problem from it’s symptoms. Once you’ve reached the root reverse the order to see if the problem logically flows from that root.
Planning For Success
“The reason this happens between the review and the next sprint is so you can implement the plan in your next sprint or iteration.”
49:50 Putting a Plan in Place
Once you’ve identified the problem the team needs to put a plan in place to prevent that from happening again. Part of the reason for iterative building is to improve processes along with development. Implement the plan in your next sprint/iteration.
50:35 External Resources
Sometimes, however, these problems come from external resources that your team does not control. For these set a plan for what to do if one or more resources is not available. Have a fail over in case the resource goes away for good.
51:50 Problems Within the Team
If the problem is personnel or other team members then the team as a whole needs to work with them. This may mean working with them to better allocate their time and efforts. It could also mean having them do less per sprint if they are split between teams. Sometimes it means talking to management about replacing that person.
IoTease: Project
FixD
“No more unclear check engine lights.”
FixD is IoT for your car. Instead of having to go to the mechanic you can plug it in and get diagnostic info on phone. There are a lot of times that your check engine light will come on for silly reasons like you didn’t put on the gas cap properly. A lot of places like Auto Zone will check this for free, they have a machine that plugs into the car’s on-board computer and reads the error code. They then go inside and look up the code online. This device plugs into your car and sends not only diagnostics but the error code to an app on your phone that then looks it up and gives you actionable information about what is going on with your car.
Tricks of the Trade
Humans are not fungible. One is not the same value as another. You can’t ever actually “replace” someone, although you may be able to get someone in who does better or creates a different dynamic. However, you won’t get a drop-in replacement even if you were to replace them with their identical twin.