How do we react to failure?
I would like to believe that most, if not all Scrum practitioners will respond that we should learn from failure, hopefully even embrace it.
Recently a colleague of mine mentioned to me that our company practices Scrum very differently from his previous employer. Both organizations have the same Scrum on the surface, the same ceremonies, minimizing the amount of work in progress, and getting stories to done. A few minutes into our discussion I asked him "Did your boss ever ask why a failure occurred?" Of course they did was his response. I asked what their goal of asking why was. What I learned is that instead of asking "why?" in an effort to understand the root cause of the failure and how to avoid it, they asked that question to determine whose head to put on the platter in case someone needed to take the blame. It seemed he worked for an organization that was not interested in learning and improving and instead more interested in CYA (Cover Your A**).
When management asks "why?" it can be for a number of reasons. In a CYA organization, failure is not embraced, but shunned and is usually hidden to avoid getting in trouble. In that type of organization, your boss asking "why?" is too often followed by a reprimand or in some cases a pink slip. A company with a learning mindset asks "why?" to grow and become better than they currently are. Does this mean that repeated failure due to neglect or other issues are not addressed, absolutely not, there is always work for the human resources department. These companies would rather have an employee admit they made a mistake then try to cover it up. In these organizations the individual's peers and management, if needed, will jump in to correct the mistake and then ask "why?", not to figure out who to fire but to figure out how to avoid it from happening again. These companies value their employees and understand that they are human so they work to find the root cause of mistakes and put procedures and processes in place to avoid them in the future.
A learning organization practices the mantra of fail fast. The second word is the more important part, FAST; some people see fail and don't understand the value. Really it means the organization has embraced a culture of learning. If failure happens quickly after the fault that caused it, it is much easier to learn from the failure, than when the cause (fault) and effect (failure) are separated too far in time, hence, fail fast.
Failing fast is very much an aspect of the third lean principle of development as written about by Mary and Tom Poppendieck. The third principle is Create Knowledge / Amplify Learning. In failing and subsequently learning we create knowledge about why the failure occurred, the challenge of course is what we do with that knowledge. A learning organization will endeavor to spread and share that knowledge, and if needed put guardrails in place to prevent the situation in the future. Dun & Bradstreet Credibility learned the value of embracing failure when their CEO late one night created the failure wall, not a wall of shame, which it could be misinterpreted as. Really it was a wall of sharing and learning.
In Scrum sprints help us to fail fast. A team cannot go off the rails for more than a sprint. At the sprint review the stakeholder will let the team know if they are on target. I strongly encourage my team to run experiments and to involve the stakeholder during the sprint when they can. When there is a question about which style of user Interface would work best, we quickly mock both up and allow the stakeholder to choose. If there is a performance or ease of use question about different technologies, we quickly work up the different solutions after doing research to narrow the field down to just 2 or 3 options. We always time box these experiments and set a clear completion criteria for them because it is easy to let them get out of hand. Once we have our answer we throw away the pieces from the solutions we are not using and move forward with the selected answer. Our DevOps team members help the team experiment with how best to build and deploy the solutions. As team members come up with potential improvements similar experiments are done. As some of these are run in production we have monitoring in place to make sure we don't negative impact the user experience.
As an organization fails and learns they collect the processes that work well and call them best practices. There ends up being a set of best practices that is collected and that changes over time. A learning organization runs experiments to learn how to do what it doesn't yet know how to do well and to determine if best practices can be improved upon. These experiments maybe what user interface works better for their clients, what technologies best align with their aims, etc. I am not suggesting you necessarily run experiments in production, although you most definitely can. What I am suggesting is that each company determine what are their best practices, they communicate these to all employees and each time someone has an idea how to improve those, they vett out the idea and then create an experiment to test it out. Based on the outcome the company will make alterations to their best practices as appropriate. The companies that do this continue to grow and thrive.
As an organization adopts agile, there is a spectrum of how agile the organization, or any team within the organization is. I think that it is helpful to have a roadmap to be able to explain where we are at any point and where we are headed. I find the following agility roadmap very useful in that regard.
Recently a colleague of mine mentioned to me that our company practices Scrum very differently from his previous employer. Both organizations have the same Scrum on the surface, the same ceremonies, minimizing the amount of work in progress, and getting stories to done. A few minutes into our discussion I asked him "Did your boss ever ask why a failure occurred?" Of course they did was his response. I asked what their goal of asking why was. What I learned is that instead of asking "why?" in an effort to understand the root cause of the failure and how to avoid it, they asked that question to determine whose head to put on the platter in case someone needed to take the blame. It seemed he worked for an organization that was not interested in learning and improving and instead more interested in CYA (Cover Your A**).
Companies must values success, without success a company doesn't thrive, but they should also value failure and more to the point failing fast. If that sounds odd to you, please read on.
When management asks "why?" it can be for a number of reasons. In a CYA organization, failure is not embraced, but shunned and is usually hidden to avoid getting in trouble. In that type of organization, your boss asking "why?" is too often followed by a reprimand or in some cases a pink slip. A company with a learning mindset asks "why?" to grow and become better than they currently are. Does this mean that repeated failure due to neglect or other issues are not addressed, absolutely not, there is always work for the human resources department. These companies would rather have an employee admit they made a mistake then try to cover it up. In these organizations the individual's peers and management, if needed, will jump in to correct the mistake and then ask "why?", not to figure out who to fire but to figure out how to avoid it from happening again. These companies value their employees and understand that they are human so they work to find the root cause of mistakes and put procedures and processes in place to avoid them in the future.
A learning organization practices the mantra of fail fast. The second word is the more important part, FAST; some people see fail and don't understand the value. Really it means the organization has embraced a culture of learning. If failure happens quickly after the fault that caused it, it is much easier to learn from the failure, than when the cause (fault) and effect (failure) are separated too far in time, hence, fail fast.
Failing fast is very much an aspect of the third lean principle of development as written about by Mary and Tom Poppendieck. The third principle is Create Knowledge / Amplify Learning. In failing and subsequently learning we create knowledge about why the failure occurred, the challenge of course is what we do with that knowledge. A learning organization will endeavor to spread and share that knowledge, and if needed put guardrails in place to prevent the situation in the future. Dun & Bradstreet Credibility learned the value of embracing failure when their CEO late one night created the failure wall, not a wall of shame, which it could be misinterpreted as. Really it was a wall of sharing and learning.
In Scrum sprints help us to fail fast. A team cannot go off the rails for more than a sprint. At the sprint review the stakeholder will let the team know if they are on target. I strongly encourage my team to run experiments and to involve the stakeholder during the sprint when they can. When there is a question about which style of user Interface would work best, we quickly mock both up and allow the stakeholder to choose. If there is a performance or ease of use question about different technologies, we quickly work up the different solutions after doing research to narrow the field down to just 2 or 3 options. We always time box these experiments and set a clear completion criteria for them because it is easy to let them get out of hand. Once we have our answer we throw away the pieces from the solutions we are not using and move forward with the selected answer. Our DevOps team members help the team experiment with how best to build and deploy the solutions. As team members come up with potential improvements similar experiments are done. As some of these are run in production we have monitoring in place to make sure we don't negative impact the user experience.
As an organization fails and learns they collect the processes that work well and call them best practices. There ends up being a set of best practices that is collected and that changes over time. A learning organization runs experiments to learn how to do what it doesn't yet know how to do well and to determine if best practices can be improved upon. These experiments maybe what user interface works better for their clients, what technologies best align with their aims, etc. I am not suggesting you necessarily run experiments in production, although you most definitely can. What I am suggesting is that each company determine what are their best practices, they communicate these to all employees and each time someone has an idea how to improve those, they vett out the idea and then create an experiment to test it out. Based on the outcome the company will make alterations to their best practices as appropriate. The companies that do this continue to grow and thrive.
As an organization adopts agile, there is a spectrum of how agile the organization, or any team within the organization is. I think that it is helpful to have a roadmap to be able to explain where we are at any point and where we are headed. I find the following agility roadmap very useful in that regard.
 |
| Agility Roadmap |
The journey starts in the smallest circle as agile tools and process are adopted. This usually fairly quickly extends on out to include the practices. From there the adoption usually slows in most organizations that did not start out as agile as they learn to adopt the principles of agility and then shift the organization so that as a whole that value the Scrum values. Finally the organization is ready to take on a learning mindset where everything is truly agile. At this point a software house will almost always be adhering to the lean principles of development, or will be well on their way to doing so. As the arrows along the sides shows spots on the map that are lower down are easier to see as there is tangible evidence of them, but the spots higher on the map are the ones that bring a company greater value.
A team or organizations path along the agility roadmap is rarely a straight unidirectional line. With a map we can always check where we are and redirect as needed. Where is your team or organization on the roadmap?
A team or organizations path along the agility roadmap is rarely a straight unidirectional line. With a map we can always check where we are and redirect as needed. Where is your team or organization on the roadmap?
Stay Agile.
Comments
Post a Comment