The invisible gorilla

By Venky Krishnamurthy

Recently I read about  NASA’s Columbia mission disaster. As many of us remember, on Feb. 1, 2003, space shuttle Columbia broke up as it returned to Earth, killing the seven astronauts on board.
 

View fullsize

The Columbia Accident Investigation Board (CAIB) concluded the following in their final investigation report 

“Cultural traits and organizational practices detrimental to safety were allowed to develop,” the board wrote, citing “reliance on past success as a substitute for sound engineering practices” and “organizational barriers that prevented effective communication of critical safety information” among the problems found.
”

As per the report, some of the engineers discussed the dangers of foam falling apart with the senior management. However, the management simply ignored them and didn’t attempt to find a fix, which is a reflection of deep cultural issues at NASA. The management didn’t think this was a major problem. The report also claims that management didn’t bother to take action because of a view that the problem was unfixable, based on past experience.  

The reason I am referencing this article here is because I see a lot of similarities between this case study and the way enterprises typically operate. When the team members see a risk in the project and reports to the management, either the issue is ignored, or the team member is termed as a trouble maker.

From the leadership point of view, the takeaways for us are:

1. Give serious attention to every risk or issue raised by the team members. Don't ignore any even if it sounds stupid
2. Don’t let your past experiences stop you from finding and trying new solutions.

In large enterprises and complex programs, issues crop  up all the time. Leaders could become immune to listening to problems and start focusing only on larger issues. In fact, this pattern of giving too much importance to bigger issues and ignoring the smaller ones seem to cause major disasters in history.

As per the discipline of complexity science, many a times the weak signals carry very powerful and important information. We tend to ignore them and focus only on strong signals, thus causing major problems.

The experiment from psychologists, “The monkey business” illusion is a classic example of how we miss out on the “Gorillas” amidst chasing key goals.

The Columbia disaster could have been averted if the management listened to engineers and attempted some steps to fix the foam issue. 

Similarly, major challenges in the project schedule, scope or budget could be averted if the management listens to the weak signals. That is, small risks hidden from the "big visible charts".

Before I conclude, let me ask you two questions.

Think about your current project, visualize your project risk board"

1. Have you missed seeing any “gorillas”?
2. Have you recently ignored any issue raised by a "junior" team member?

---

KEEPING TABS - TABAR'S NEWSLETTER

If you want links to interesting reading and notifications about upcoming events in the Melbourne and Australian lean/agile/workplace change community, please signup here.

My first brush with Large-Scale Scrum (LeSS)

Venkatesh Krishnamurthy

I had my first opportunity to practice LeSS in 2006.  While I was with Valtech in Bangalore, Craig Larman, who was, the chief scientist was already in the process of forming LeSS ideas.

Being a Scrum Master at that time, I had the opportunity to work with Craig closely and watch him implement some of the LeSS principles, tech practices and structuring the organization to be nimble. 

Being a computer scientist, I got impressed with the technical practices and started making my hands dirty in integrating various tools, rolling out configuration management practices and setting up continuous delivery/integration and deployment environments. I was able to capture some of these experiences in an article I published in 2006 for Agile Journal. This is accessible here. It was aptly titled, "Tools integration in distributed environment". 

Another pet project that I worked with Craig Larman was building something called "Virtual Lava Lamp". 

View fullsize

Virtual Lava Lamp

As one could see from the screen shot above, the Lava Lamp was integrated with the Continuous integration environment(Cruise Control + SV) and build results used to trigger this lava lamp. Green indicates all good and red used to encourage the developers to fix the build.   Craig and I built this on a simple X386 machine, which was super low cost.  

All the good technical practices are covered as part of  LeSS framework and under the Technical Excellence subsection as shown below:

LeSS: Scaling Sweet Spot

By Venkatesh Krishnamurthy.

Read the first part of this series about Large Scale Scrum

There are several  frameworks, ideas and methods available for scaling Agile projects. Many are either too prescriptive detailing out practices making it too narrowly focused with no wiggle room.  The prescriptive, highly defined process destroys the principles of empirical process control. 

There are others which are purely principles based pushing the onus on users to worry about the practices.  

The secret lies in balancing the principles and the practices. This is where Large Scale Scrum (LeSS) captures the sweet spot. 

LeSS achieves the same balance as Scrum, for larger product groups. It adds a bit more concrete structure to Scrum, whose purpose is to maintain transparency and emphasize the inspect-adapt cycle so that groups can continuously improve their own ways of working. LeSS  consciously leaves the space for users to create context dependent practices. 

Find out more about LeSS training in Melbourne in February 2015. This is the first LeSS certification training in the ANZ region. 

What is LeSS (Large Scale Scrum) ?

By Venkatesh Krishnamurthy

In 2015, we are going to introduce Large Scale Scrum (LeSS) to an Australian audience. We think there are many who will be interested to hear about what LeSS is all about. How can it benefit large scale Agile projects?  What are the principles driving LeSS? How can I be LeSS certified?

My intention is to share knowledge about LeSS and at the same time, answer the above questions and beyond.  In this series of articles, you will be able to gain an understanding of LeSS and LeSS huge frameworks. 

Why LeSS?

Let me begin with "What is Large Scale Scrum (LeSS)? Essentially, LeSS is Scrum being applied to many teams working on a product development. 

As we know, Scrum is one of the most popular methods in the software development. Its popularity is due to its simplicity and powerful empirical process control. However, while multiple teams working on a product development apply Scrum, they need some additional guidance for improved collaboration and coordination. This is where Large Scale Scrum sits. 

Since LeSS is based on Scrum, the learning curve in adopting this framework is minimal. Personally, I have used LeSS on a large scale development with >100 people with no additional training on this framework.  

LeSS Principles and Themes

LeSS is fundamentally based on Scrum, and in addition, it has principles/ideas based on Queuing Theory, Systems Thinking, Lean Thinking, Empirical process control. 

 I will delve a bit deeper into the backlog grooming and other practices in the upcoming articles.

Read the Part 2 of this series "LeSS: Scaling Sweet Spot"
Find out about the upcoming LeSS course in Melbourne

Don't shoot the elephant...

By Venkatesh Krishnamurthy

Recently I came across this fascinating story by Orwell about shooting an elephant. 

Orwell, who was an English officer in Burma during 1920's,  was tasked to find the killer elephant. As he continues searching, finally finds the elephant in a field calmly eating it's food.  However, the crowd around Orwell starts jeering him to shoot the elephant and even more after seeing his gun. 

As Orwell describes in his story, 

Despite Orwell’s aversion to shooting the elephant, he becomes suddenly aware that he will lose face and be humiliated if he does not shoot it. He, therefore, shoots the elephant.  

You might be wondering, why I am sharing this story here... but wait I believe there is a huge meaning and a management lesson to be learnt from this story.  

In the above story, even though Orwell wasn't interested in shooting and killing an elephant, he was under social pressure. Orwell being in an authoritative position wanted to satisfy the crowd's hunger to look good and at the same time, he didn't want to look weak in front of them. Do you see what I see?

I see this behavioral pattern in everyday life at work and  in other social situation as well.

For example, consider the setting where one of your leaders is chairing a meeting with team members. One of the naughty team member asks a sensitive question about the unnecessary money being spent in furnishing the office when the company is struggling with cash flow. 

What happens now?  The room goes silent, and everyone would be looking at the leader to see the response. Now the ball is in leader's court, and obviously the leader has to defend. In the mean time, if the leader has a command/control leadership style, he/she cannot remain silent and show as weak. This leader now wants to demonstrate the strength in front of the team. That’s when all the insecure leaders shoot the elephant.

Many leaders shoot the elephant as a warning to others and sometimes just to satisfy their ego.

To conclude, I would say that we all come across social situations where we are expected to act in a certain way. The people around us whether our spouse and family, peers or team members wait to see our response. It is important to be mindful of the situation in a social setting without getting into social pressure.

In the Orwell's story, the "Mahoot" or the elephant trainer could have been called to take the elephant back to the forest rather than unnecessarily killing the elephant to satisfy crowd's expectation. 

Have you come across situations where your leaders have shot the elephant ?

What is common between Agile and FengShui ?

By Venkatesh Krishnamurthy

I know this is a tricky question if someone asks "What is common between Agile and Fengshui?" .  Not an easy answer ah?   

Let me give out the answer, both Agile and Fengshui has a lot of believers and followers. The followers have such a tremendous blind faith that they don't question and follow the rituals to the last letter. 

For example, I have seen Feng Shui followers setting up Aquariums, buying gold fishes, lighting scented candles to attract wealth/abundance. Whether it works, don't know.

I am seeing the same trend in Agile followers as well. If there are challenges in software delivery, stakeholders are asking the teams to just "practice" Agile and many a times some popular models like Spotify, SAFe or DAD.  

Many a times, just ignoring all the noise and just applying some common sense could solve many challenges.  

Are you a follower  surrounded with too much of noise?  Do you think ignoring this noise helps in your context?