Monday, February 19, 2018

Blameless Post-Mortem



Human error is a symptom—never the cause—of trouble deeper within the system.
Dave Zwieback




Failure is inevitable in any complex system. While it’s tempting to find a single person to blame, these failures are usually the results of broader design issues in our systems. We are born and raised in a culture where blaming is one of the mechanisms to overcome fear and a way to discharge pain and discomfort. The good news is that we as humans have designed systems to reduce the risk of human errors by looking into factors contributing to failure –systemic and human.

Blameless Post-Mortem mechanism essentially is a post-correction retrospective for a failure. The purpose of Blameless Post-Mortem is to find the cause of the failure happened, identifying corrective actions so the probability of occurring of future failures can be reduced, and learning.

Like retrospective, there is the prime directive for continuing successful Blameless Post-Mortem:

Whatever discover, we understand and truly believe that everyone did the best job they could, given what they knew at that time, skills, abilities, the resources available, and the situation at hand. 

In Blameless Post-Mortem following people must participate:
1.    The people involved in the decision and actions that may have contributed to the failure/problem.
2.    The people who identified the problem.
3.    The people who responded to the problem.
4.    The people who diagnosed the problem.
5.    The people who were affected by the problem.
6.    Anyone who is interested in the process.
7.    A facilitator

In a Blameless Post-Mortem meeting, participants will be doing the following:

1.     Constructing the timeline of failure. This timeline must incorporate different perspectives to understand the whole picture. People must be assured (repeatedly – by words as well as actions) that nothing will be used against them EVER.
2.    Empower all participants to speak and share their version of account detailing their contribution to failure. While people speaking few things must be observed:
a.    Don’t use “would”, “could”, and “should”
b.    List out the assumptions
c.    Actions, expected outcomes, and real outcome
d.    Understanding of timeline as actions are taken
e.    People who were on the keyboard should speak not the people who are just managing the people.
3.    Conduct 5-WHYs to find out the root cause of the failure.
4.    Identify top three action items.
5.    One or more participants voluntarily assume responsibility to materialize identified action items and inform all participants to close the loop. The action items must be measurable.

Blameless Post-Mortem must be conducted as soon after the resolution of failure – as a thumb rule within 48-hours.



The most important thing in Blameless Post-Mortem – No one is blamed for failure, everyone learned some important lesson and team/organization gained resiliency.

The facilitator of Blameless Post-Mortem must be aware of few biases which may affect the whole process:

1. Hindsight bias, also known as the knew-it-all-along effect or creeping determinism, is the inclination, after an event has occurred, to see the event as having been predictable, despite there having been little or no objective basis for predicting it. It is a multifaceted phenomenon that can affect different stages of designs, processes, contexts, and situations. Hindsight bias may cause memory distortion, where the recollection and reconstruction of content can lead to false theoretical outcomes. It has been suggested that the effect can cause extreme methodological problems while trying to analyze, understand, and interpret results in experimental studies. A basic example of the hindsight bias is when, after viewing the outcome of a potentially unforeseeable event, a person believes he or she "knew it all along".


2. Confirmation bias also called confirmatory bias or myside bias, is the tendency to search for, interpret, favor, and recall information in a way that confirms one's preexisting beliefs or hypotheses. It is a type of cognitive bias and a systematic error of inductive reasoning. People display this bias when they gather or remember information selectively, or when they interpret it in a biased way. The effect is stronger for emotionally charged issues and for deeply entrenched beliefs.


3. The outcome bias is an error made in evaluating the quality of a decision when the outcome of that decision is already known. Specifically, the outcome effect occurs when the same "behavior produce[s] more ethical condemnation when it happen[s] to produce bad rather than good outcome, even if the outcome is determined by chance."

While similar to the hindsight bias, the two phenomena are markedly different. The hindsight bias focuses on memory distortion to favor the actor, while the outcome bias focuses exclusively on weighting the past outcome heavier than other pieces of information in deciding if a past decision was correct.
 


References:
1. The DeveOps Handbook by Gene Kim, Jez Humble, Patrick Debois, John Willis
2. Beyond Blame: Learning From Failure and Success by Dave Zwieback
3. The Field Guide to Understanding Human Error by Sidney Dekker
4. Site Reliability Engineering: How Google Runs Production Systems by Betsy Beyer,‎ Chris Jones,‎ Jennifer Petoff,‎ Niall Richard Murphy
5. The power of vulnerability by Brené Brown (http://www.ted.com/talks/brene_brown_on_vulnerability)
6. Listening to shame by Brené Brown (http://www.ted.com/talks/brene_brown_listening_to_shame)
7. Hindsight bias - https://en.wikipedia.org/wiki/Hindsight_bias
8. Confirmation bias - https://en.wikipedia.org/wiki/Confirmation_bias
9. Outcome bias - https://en.wikipedia.org/wiki/Outcome_bias
10. Open source Blameless Post-Mortem tool: Morgue- https://github.com/etsy/morgue

Monday, December 4, 2017

Prediction for next decade (2018-2027) - 2018



1. Agile transformation market will thrive while large enterprises will struggle to transform.
2.  Bigdata trend will keep gaining strength in both spheres – Batch & Real time. But too many tools may kill momentum.
3. SAAS and PAAS will prevail for the small and big enterprise.
4. IAAS will thrive in enterprise data centers (Private Cloud).
5. Industry-specific cloud platforms will rise to cater regulatory and vertical-specific needs.
6. Artificial intelligence will be new playground of software developers.
7.  Digital currencies will impact financial markets in a big way.
8.  Fragmentation of Internet - There will be walls around a country or region-specific internet.
9. Applications will be pervasive in devices and appliances like phones (mobile and fixed line), TVs, automobiles, refrigerators, disk (CD/DVD/BlueRay) players, and any other computing device.
10. Indian IT workforce will shift from permanent job to contractual jobs like in the USA.
11. 3D printing will start making penetration into consumer market which will take a heavy toll on mass manufacturing based economies.
12. Fragmentation and Alternatives of Java and Enterprise Java (like Apache harmony, and Spring) will emerge stronger and official Java from Oracle will lose its sheen due to lust for its monetization by Oracle.
13.  The rise of China-based technology companies.

Friday, December 1, 2017

Top Trends of 2018

1. In software development and maintenance, fall of the waterfall will continue while Agile will be rising.
2. Agile transformation business will flourish further.
3. Agile at scale will continue to haunt.
4. The noise around budgeting, HR, sales & marketing, and other enterprise functions in the Agile adopting environment may become loud enough.
5. Containerization and micro service will keep on rising in software architecture and design.
6. The cloud-based application will penetrate further into the enterprise market.
7. Voice-based interaction and user interface will gain a further foothold in home improvement market.
8. Mobile payment will become ubiquitous.
9. Internet of things will keep growing in consumer and enterprise market.
10. Bigdata, Artificial intelligence, and user experience professionals will be in great demand.
11. Autonomous vehicle technology will be pursued further.
12. Virtual and augmented reality will start making a further inroad into enterprise training business.
13. The merger of devices will continue.

Monday, November 20, 2017

Post Agile



Recently, during an Agile meetup, I came across an interesting question - What is after Agile? This intriguing question did not leave me all day. I explored the internet but was not able to come up with anything concrete.  Agile is one of the steps in the evolution of our working style and heavily influenced by the very nature of the work. Then today, I thought, I should pen down my thoughts.
Before the industrial revolution, we were doing most of our work as craftsmanship which required a heavy dose of interpersonal relationship, col-location, rich communication, and solving unique problems every time.  The industrial revolution brought the division of labor, mechanization, and scientific management which diminished human relationships, rich communication, and problem-solving in a day to day repetitive work environment.

At present, software development is in pre-industrial revolution era where every problem is unique. Though some of us tried to utilize learnings from post-industrial revolution work culture in software development due to a unique proposition of software development, it failed repeatedly. In software development, most of the problems faced are unique, so they require unique solutions. This paradigm forces us to look into pre-industrial era work style which is very similar to Agile way of working.
I visualize at least two possible scenarios which may arise in software development area.

Scenario 1: We develop machines which can solve the problems posed by software development. The software development may turn into something like assembly line operation with the arrival of intelligent machines. Artificial Intelligence, machine learning, and general purpose components are trying to move software development in this direction.

Scenario 2: We keep on solving existing challenges using software and in this pursuit keep on discovering newer challenges. This will keep Agile or its successor alive provided we do not discover a way to replace human intellect by the machine.

So, which scenario may play out in the future? If I have to bet, I will go with the second scenario in short to medium term (approx. 30 to 50 years) and then to the first scenario. As we are discovering better and better AI algorithms in the area of assisted learning, sooner or later we are bound to discover non-assisted AI algorithm (probably using assisted AI algorithms). At that time Agile or not Agile may lose the relevance.

Wednesday, October 18, 2017

Why there is so much resistance for Agile?

I meet a lot of people who are opposed to Agile. This used to annoy me and I used to think of them as ignorant or snobs. But when I started thinking deeper and kept myself in their shoes, I realized they have their version of reality which makes perfect sense from their position.
 
In my view, this hostility (or apathy in some cases) exists on three different levels:
(a) End result sought
(b) When to use Agile based frameworks/methodologies  
(b) A lacuna in the current approach to various Agile-compliant frameworks and methodologies.
 
Let's consider an example from the business world. Different businesses have different objectives - one may run for profit maximization while other may seek sustainable profit optimization with a healthy workforce. Can Agile be used in both scenarios? Maybe not. In a given context we need to understand what is the expected end result of a way of working - Valuable outcome, sustainable pace, immediate gratification, or something else.
 
As Cynefin framework has defined five decision making contexts - simple, complicated, complex, chaotic, and disorder. Most of us try to stick to the Agile way of working in all five which essentially ruins the Agile way of working. Agile fits well in Complex context and maybe a working solution in Complicated. For Simple context, Agile is over do while for Chaotic context Agile is certainly not a way to go. For Disorder context as Cynefin framework recommend - try to contextualize in remaining four.
 
While talking about Agile, we invariably focus on utopia - no difference between employees & contractors, co-located teams, flat organizational structure, and much more. But in reality, this state doesn't  exist. Most of the frameworks and methodologies claiming to be Agile are mute about:
 
1. Distributed teams
2. Outsourcing partners
3. Expertise based silos
4. Contractual obligations
5. All team members are not expert or skilled. There are Yodas as well as Padawans
6. Even emergent architecture requires upfront thoughts
7. Divide in onsite and offshore
8. Divide among full-timers and contractors
9. Resistance to breaking away from existing organizational pyramid
10. The existence of the project
11. Usage of Agile to squeeze more out of IT and Engineering teams instead of focusing on optimizing effectiveness
12. Marketing of various non-Agile frameworks, methodologies, processes, practices, tools, and techniques by various very successful people and organizations
13. Ignoring existence of various other functions beyond IT and Engineering
14. Silence on individual performance. We are not the only a team but love our individuality too.
 
Should we abandon Agile? Certainly not. Agile is evolving and I expect that in near future, it will tackle the questions beyond today's narrow scope.
 
All this big talk is fine, but what should I do in the meantime?
 
As an Agilist, I prefer to address the underlying causes rather than any specific framework. Also, anything which questions the establishment is bound to face resistance.
 
I hope, this small write up will raise more questions which will help all of us to think little deeper.