Categories
Techniques

Technique #1 – The Five Whys

Chances are good you’ve heard about the five whys. It is a iterative troubleshooting technique that was created by Toyota to determine root causes of defects in their manufacturing process.

You see the five whys technique in primarily in manufacturing methodologies like Kaizen, Six Sigma and Lean Manufacturing.

The technique is very easy to grasp. You start with problem you want to solve and ask the question “Why do we have that outcome?” and then you ask “Why?” and create you first response/answer that is as specific as possible. Then, based on that answer, you ask again “Why is that answer the way it is?”. You keep repeating this, completing the exercise after the fifth iteration or finding the root cause of the problem/issue. If you’ve ever hung out and had a conversation with a curious four year old, it is like that. At its best it forces you to let go of your assumptions of what you think something is and shows you the way dig for the real why of the way it is.

Why do I need to do this five times?

You don’t. There is nothing special about the number of times, it is a arbitrary number that seems like a good, generally attainable goal. The idea is if you can get all the way to a solid fifth answer, you are probably at or near the root cause you are searching for.

It isn’t the number, it is the process. Sometimes you can arrive at the root cause quickly and don’t need the repetition. The iteration produces the rigor to continue to question if you are really at the right answer.

But I’m not in manufacturing?

Doesn’t matter. Manufacturing, services, sales, marketing, anything you can think of has processes for creating the deliverable you are trying to sell. If it involves a process and you need a quick way to break down causality in order to improve, the five whys is a great technique to utilize.

What is the benefit?

There are a lot of benefits in using the five whys when you are planning and executing a software project:

  • It is easy to learn.
  • Provides a common language for your team to analyze problems.
  • Provides a method to quickly identify root causes, so you know what issue to focus on.

A simple five whys example

The easiest way to try this is to grab any issue you have right now and try to solve for the root cause of the issue. The issue you try to solve can be ANYTHING.

Example:

  • I can’t make myself a cup of coffee
  • Again? Why?
  • There is no coffee in the kitchen
  • Why?
  • I didn’t buy any when I was last at the store
  • You fool! Um, why?
  • I didn’t realize I was out
  • Why is that?
  • I forgot to look before I went shopping
  • Why?
  • I didn’t make a list
  • << Head::Desk >>

Yes it is silly. Yes there could be many other reasons why I can’t make coffee or forgot to check my pantry, but these are the answers for me, at this time. If I want to make sure I never have to go without coffee again, I better concentrate on making a list before I go shopping.

My problems are a little more complicated?

Most problems are. Most problems stay complicated and seem unsolvable because we don’t break them down into parts, we take them at face value in all of its complexity. I’ve been doing this for over a decade and still, sometimes when an issue first lands on my desk, my impulse is to take it at face value as one big hot mess. When this happens, my brain begins to freeze up and shut down. Right then I know I need to break things down and start applying my tools (like the five whys).

Things to keep in mind when practicing

In order to end up with the most valid answers and hopefully the correct root cause, keep these things in mind:

  • Issues have have many root causes. If there are multiple answers to a why, break each of them out into their own line of questioning.
  • Take the time to verify your answers.
  • Focus on the processes, not the people running the process (hint: it is never human error)
  • The why should always be from the customers viewpoint (even if they are an internal customers). This focuses you on the OUTCOME of the process. No one cares if your code or process is poetic. They care if it works for them.
  • Be specific with your answers, refine them until they are as laser focused as possible.
  • Write the answers and responses down, this gives you something to focus on and makes it easier for your brain to engage with the process.

Download the worksheet

I have a handy dandy worksheet that can get you started using the 5 whys and focused on the iterative process.

Categories
Getting Started

A note on using this guide

The techniques and recipes set out in this blog are meant to be adapted to your own process. You could choose to follow them exactly and you would achieve great results, but I ultimately don’t think that is practical or sustainable. Why? You don’t live or work in a vacuum, and because of that you will need to follow this process when adopting these techniques and recipes:

  • Practice the technique.
  • Evaluate the process.
  • Modify the process.
  • Rinse and repeat.

The cornerstone of effective change is the process of engaging and adapting. Engagement comes from repetition and I call that working your process. If you engage and then adapt, you will find what works best for you and your business. A single test run will bring better results, but the actual gold is to repeat the techniques again and again and glean what works.

Mileage may vary

It is ok if these techniques don’t seem to apply to you. Not everything is useful to everyone. I’ve made a very successful career out of constantly expanding my toolbox and using the right tool at the right time. I’ve gotten proficient in adapting other people’s tools for my own use and this collection of adaptations are what I think will have value for your process. I would be doing you a disservice if I didn’t encourage you to work the exact same process to adapt these techniques to your specific circumstances. When I adapt and then adopt something, I have the advantage of experience to tell me what to change to fit how I want and need to work. Hopefully all of these techniques are bite sized enough to make then easy to wrap you head around, use quickly, and see effective results. 

Adapt, Adopt and Ignore

Use what you need to move forward, ignore the rest. It is ok to leave good ideas behind. Maybe they weren’t for you at this time and place. Don’t hold onto things that seem really great but simply don’t work for you. Don’t beat yourself up, it is ok. The important thing is to begin the process of adopting and adapting in order to get your project completed.

Evaluation is key

If a technique doesn’t work for you or doesn’t produce the results you want, try to figure why it didn’t work before modifying it. Did the breakdown occur because of sloppy implementation or is it just not right for how you operate the business? Finding out that why and pinpointing the failure points is hard. How do you reliably figure out what really went wrong? Never fear, there is a technique for that. Next up, we are going to get familiar with the 5 whys.

Categories
Getting Started

What is a software architect anyway?

You may have never heard of a software architect, that is ok, no one in our industry can decide on any job titles. What is the difference between a Coder, Programmer, Software Engineer, Software Developer, Front End Developer, Web Developer or Full Stack Developer? Depending on the position requirements and company culture all of these job titles might have the same job duties but be labeled differently at different companies.

Same with Software Architects.

Wikipedia defines a Software Architect as:

A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms.

~Wikipedia

They use the term as a broad umbrella and define different types of IT or Software Architects within the same article: enterprise architect, application architect, solution architect, system architect, cloud architect.

Unfortunately most of the difference in the job titles and what these positions actually do ARE ONLY OF A CONCERN FOR PEOPLE IN THE INDUSTRY.

In other words, jargon for people who care about jargon. Just another way to exclude others from understanding your field.

Why Should We Care?

We shouldn’t care about the labels, we should care about what the role ideally does within your team (even if it is a team of one, it is still a hat you wear when creating a software project).

The problem is that most decision makers within small enterprise still think of software teams as being comprised of four roles: designer, developer, project manager and systems administrator. Oftentimes the “Team” is one person and they wear all these hats. Just because you have fewer resources, doesn’t mean the roles magically go away.

Understanding how the smaller the team is, the more roles each individual must take on is key to avoiding a major project pitfall: decisions by inaction. This concept is really a longer topic for another time. Back to the why…

I want to change the way you think about who is creating your software.

If you even think about your project team as having more than one role you are probably still missing what I consider a key component and concept of software development: the Software Architect. When this concept is clear to you, you will be able to make better, clearer decisions; without understanding it you are spinning your wheels and might not even know it until too late.

Why is this so important?

Your Software Architect role is the role that provides the project road map to the rest of the roles on your team. They make sure the project goals are front and center and decide on the standards and rules of how to implement the project. All the other roles need to be taking their ques from the architect.

Without this concept clearly defined, the team plays the “who is driving the bus?” game. Sometimes the developer makes the key decisions, sometimes the project manager or designer or sysadmin do, but none of them are using the same playbook or necessarily where they are ultimately going. Not knowing how they are getting from point A (start of the project) to point B (successful delivery of the project) creates underlying tension and manifests itself as extra time and overhead.

This is why I want to train you to think like the architect: to create the map to guide your team to successfully create the software you need. By following the recipes and techniques I’m going to outline, you will start thinking this way and when you implement like an architect your projects will become less expensive and easier to understand and complete. Saving you time, money and emotional dollars.

Categories
Getting Started

A Brief Introduction

Welcome to the SME software cookbook. I’m glad you found me and I have a lot to share with you. I want to dramatically change the way you think about and create software for your business. I am going to create a cookbook of techniques and recipes to teach SME (Small & Medium Enterprise) business how to successfully create software.

Who is this for?

The cookbook is for non-developers, small business owners, IT managers, anyone who needs to build a small piece of custom software to help their business grow and feels like they can’t do it because:

  • They aren’t technically minded and don’t have anyone on staff that knows how to make a software project happen.
  • They feel like the software creation process is a big black box that you throw money into and nothing comes out but endless screaming.
  • They have had a big, bad, no good, HORRIBLE experience with a developer(s) or software company in the past.
  • They don’t want to be a developer. There is too much to learn.
  • It is too risky and scary, like moving through fog at night with no idea where you are and your phone is at 1%.

If that is you, you are in luck

I don’t want to train you as a developer. I don’t want to train you as a project manager. I want to train you (or even better, someone who reports to you) to be someone who can easily put together a small software project, hire a developer, meet your milestones, CRUSH your deliverables and make everyone wildly happy. In other words, I want to train you to think like a software architect, no degree required.

It isn’t that hard.

You have got to be kidding me?

Nope. Really. It isn’t that hard. We definitely MAKE it that hard for ourselves because of a lack of organized thinking and a software industry that makes software for developers, by developers.

If we organize ourselves and change how we think of the software project as a task, we can get our software built.

I should know, that is what I do.

I’ve been a developer, technical project manager and above all a software architect for over 15 years. I’m built applications for small business and large enterprises.

I have learned over the years that most business owners have been taught ideas about software and information technology that do not serve them and make them avoid innovation as something that is too expensive and out of reach.

It is time to change all that and find a better way.

Come along for the ride…

Over the next six months I’m hoping to change the way you think about building software so you can more easily innovate, automate and effect change for the better within your business, without breaking your budget.