Doing root cause analysis the right way

Photo by Emily Mortimer

The concept of 5 whys is frequently trotted out as a formula for root cause analysis. Its proponents claim, “Just ask ‘why’ 5 times, and you will fully understand the root cause to a problem you are having!” The same concept is frequently applied to the process of researching and planning new solutions that your business can offer the market.

In case you aren’t familiar with the approach, the idea is to dig into surface-level problems to make sure actually understand the root causes. Asking “why?” 5 times as you dig deeper for each is the core of the method. Suppose our revenue is down 10% for the quarter:

  1. Why? -> Because we lost 10% of our customers
  2. Why? -> Because our customer service level suffered
  3. Why? -> Because we don’t have enough people to answer the phone quickly
  4. Why? -> Because our customer service agents are leaving for other opportunities
  5. Why? -> Because our pay and benefits aren’t attractive enough

While it is important to dig into root causes, anybody who has spent time with small children knows two things about asking questions like this: 1) there can be a lot more than 5 layers of “why?” underneath any given question, and 2) the answers sometimes stop being useful long before you run out of questions to ask.

Continue reading “Doing root cause analysis the right way”

Reviewing the Agile Manifesto

Photo by Kellen Riggin

I love the Agile Manifesto. Go ahead and visit agilemanifesto.org, bask in its turn-of-the-Millenium aesthetic, and read it again. (If you are involved in software development, you have read it before, right?) It will take 60 seconds at most, and I’ll be here when you return.

Back? Good. I recommend visiting the site frequently, it’s helpful to periodically be reminded of its principles.

Few things have resonated with me quite as strongly as the manifesto, and given its impact on the software industry, I am apparently not the only one who has experienced this. There are very few companies out there who don’t make a huge effort to proclaim themselves as Agile.

The problem is, few companies actually prioritize the principles of the Agile Manifesto, despite their claims.

Continue reading “Reviewing the Agile Manifesto”

We’re all in this together: shared responsibility and incentive alignment in software development

Coworkers collaborating in front of a computer
Image by Lagos Techie

At any business where software is built, strategic decision-makers need to have a basic competence with technology and understand the principles of software development. This knowledge and understanding must be used by all decision-makers as they take an active role in software planning and development, not just those who write the software.

Despite how important this approach is, many companies that develop software for internal use are accustomed to separating “INFORMATION TECHNOLOGY” and “THE BUSINESS”, to the detriment of the company.

Dissolving these barriers and helping everyone actively participate in the development process can be the single biggest competitive advantage most companies have available to them. Producing value with software is hard, so being one of the rare companies that can do it will put you way ahead.

Continue reading “We’re all in this together: shared responsibility and incentive alignment in software development”

“Be stubborn on vision, but flexible on details” – attitudes towards innovation and failure at Amazon

Image by Sunrise King

During a shareholder meeting in 2011, Jeff Bezos was asked a question: “If it’s still Amazon’s philosophy to make bold bets, I would expect that maybe some of them wouldn’t work out, but I am just not seeing that. So, my question is where are the losers?”

His reply is fascinating to read and gives insight into innovation at the company – specifically, his view that consistent innovation isn’t possible without acknowledging the possibility of failure.  AWS was starting to really take off at the time of that quote, but it hadn’t become as massive as it is today.  To put it in perspective, Microsoft Azure had just launched the year before – so even though most of us didn’t realize it at the time, the whole cloud thing was going to be a big deal.

Continue reading ““Be stubborn on vision, but flexible on details” – attitudes towards innovation and failure at Amazon”

The art of scoping an MVP

Image by Markus Spiske

The concept of a Minimum Viable Product has been popularized to the point that the phrase is used without even thinking about it. Perhaps you even hear and use it so often that you have to pause for a moment to even remember what “MVP” stands for.

“Let’s just get this to MVP, and take care of the rest of this later,” says the engineer, tired of having the project drag on for sprint after sprint with no shippable product in sight.

“What is the MVP for this project?” asks the executive, who doesn’t understand a complicated feature proposed for their biggest piece of software.

“Which features are considered part of the MVP, and which will we do later?” the product manager wants to know, as she builds user stories for the backlog.

All 3 of these people are talking about the same concept, but it means different things to each of them.  And that’s OK! The MVP must be defined precisely enough to be well understood by everybody on the team, even though it will impact them all differently.

Continue reading “The art of scoping an MVP”