Learning From Failure

09:55 Define Failure

Before starting a project we need to define what it means to fail. In Agile, especially Scrum we spend a lot of time talking about the definition of done. We don’t talk much about what it means to fail.

The Oxford English Dictionary has three definitions for failure. Lack of success. You have not met the requirements for it to succeed. Does not mean it isn’t functioning properly based on how it’s built. The neglect or omission of expected or required action. Not fulfilling all expected functions. The action or state of not functioning.

There are three levels of failure you’ll see in the development process. Software failure happens when your code doesn’t do what it’s supposed to do. Software doesn’t do what it’s supposed to do in unit testing. This can also be found in testing, QA, UAT, but hopefully not production. Iteration failure is not your accomplishing commitments within the agreed upon time. The team did not accomplishing commitments on time. Scope creep tends to be a major concern here. Project failure occurs when your software does not meet the expectations of the client. This often results from clients not knowing what they want or need. Poor requirements often lead to clients expecting developers to be mind readers.

15:45 Common Causes of Failure

The most common reason for failure is that the team overcommits what they can do. Poor estimations from developers or management leads ot overcommitment. 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. Inappropriate task assignment can cause a regular task to drastically increase in difficulty and time to accomplish it. 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.

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. Sometimes team members get pulled from a team by management while development is taking place.

One of the most frustrating causes of failure is when Testing/QA delays the process. This can occur if the tests are not set up properly or the tester misunderstands requirements. It can also happen when QA doesn’t create tests until development is completed.

Scope creep occurs when the acceptance criteria changes after the story has been committed and the sprint started. In Scrum once a story is committed it cannot change. 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.

Poorly defined requirements/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 customers or business team 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.

26:05 Effects of Failure on Individuals

Failure can cause developers to become in irritable. It’s frustrating to not accomplish what you set out to do. Many times this can be a manifestation of other deeper feelings. This may be taken out on other team members or subordinates.

“I love me some pickled eggs but I don’t want to smell them.”

Failure leads to feelings of inadequacy and shame. We tend to hold ourselves to high standards. Self punishment can be worse than anything handed down.

Self doubt tends to creep into daily activities. You start to second guess even common or easy decisions. You also develop a reluctance to try new or innovative solutions out of fear.

Fear of future failure or the ramifications from failure becomes overwhelming. You’ll find yourself focusing on the problem and not on finding solutions. This can have a paralyzing effect on your growth as a developer.

32:40 Effects of Failure on the Team

The whole team will likely be stressed as they have been working extra to avoid the failure. They have been putting in extra hours only to not succeed. Not only are they tired but worried about the ramifications.

“We got together and decided, you know what we’re not going to work weekends anymore.”

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.

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.

37:40 Managing Up Expectation

Management has a vital role to play in how the failure effects the team. How managers view failure will determine how long it takes for the team to recover. How they treat members of a failing team will determine how long those members stay at the company.

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. Can be a strong motivator to do just enough to succeed. Workers don’t want to try new things for fear of failure.

A positive outlook from managers can help a team quickly recover from failure. Treating failure as a normal process that leads to better performance in the future will motivate a team to work harder. Instead of blaming, seeking to find ways to improve or what the team learned allows for growth both on the individual level and as a team.

41:10 Lessons To Learn From Failure

Planning and Preparation are key to success and managing failure. How much time did you spend planning the best way to achieve your goal or task before you started? How much thought did you give to anticipating hurdles or problems that might arise and to figuring out how you would handle them if they did? The vast majority of us spend little if any time on this kind of planning, despite the likelihood of our running into obstacles and unexpected circumstances. In the future, make sure to plan your general strategy, consider potential setbacks, and figure out how to overcome them, before you begin.

Set expectations early. This goes back to requirements gathering and setting the expectation that there may be delays in the process. Keep management apprised of setbacks or delays as early as possible. People get mad when they are surprised, not when they know that you will be a few days late.

Prepare for Murphy’s Law. May not be able to plan for every circumstances but don’t expect the happy path. Build setbacks into your schedule.

Log the motivation and moral issues like you would bugs, as they happen. Track the events leading up to a loss of motivation like you would read a stacktrace for a defect. By identifying the demotivating events you can better predict and account for them in future projects. Not all things can be predicted like loss of family members, etc. Here you want to be able to mitigate the damage to the team and project while a member is healing.

Understand there are variable in your control and ones not in your control. Failure makes us feel like we have no control at all. However there are several variables we can control. The trick is to identify them and exert that control properly.

49:45 Strategies for Learning

Treat failure as an opportunity for growth. We all know about Thomas Edison and the light bulb. Use failure to look at your process and how you are doing things.

Allow yourself the experience of failure. Sometimes failure is the only way to highlight problems. It’s Ok to fail, the trick is getting back up.

Use fear of failing to drive you not hinder you. It can be a motivating factor. However you have to be careful as it can be misused. When that happens people will tend toward doing just enough to not fail. You’ll end up stifling innovation and creativity.

Review your mistakes and what could have been done differently. Once the emotional aspect has had time to cool, look back at what happened. Look at what happened and list out ways that it could have been avoided. If unavoidable list out how it could have been mitigated to not cause failure.

Share what you’ve learned from the failure. While some things we have to experience ourselves to know the pain. Many times we can learn from the mistakes of others. These make great topics for lunch and learn or developer trainings.