Learning from failures
We have all heard the startup success stories – The ones where people had a turnover of R 100 million within one year with a minimal amount of effort.
With this in mind, I am reminded of a friend who decided to start a coffee shop. He was going to make a small fortune. He spent quite a bit of money to get licenses in place, kitchen appliances, print menus, tables etc.
Some businesses do not come cheap! After the opening night (which we celebrated with him), no business came through the door again.
His business failed.
What really matters?
Many people start analysing the situation and why they failed. Though analysis might be important, it often leads to analysis paralysis – even in the unpacking of the past.
It’s often more valuable to ask the following questions:
- What – what happened, what is the situation and what caused things to play out like they have?
- What did you learn from it?
Changing our thinking to learning enables us to get over our failures and move forward making better decisions.
Wastage and learning
If we use learning as a measurement of growth, it’s important that we learn the right things. We need to position ourselves and our business to learn as much as we can about our customers.
I am sure you’re saying: “Yes, but this is a great excuse that cannot be measured!”. The art of learning is focused on learning. We need to learn about things that matter.
Wastage in software development
Historically, the software developer will receive guidance from the business analyst about what needs to be built, whereas the project manager will determine what is important.
We know the following in the software development sphere:
- Resources are expensive
- Resources are scarce
- Not all solutions are critical
- A select few reports and enhancements are in use a few months after it was released
With this in mind, what can we do to cut down wastage? For starters, we can ask:
- How much value will this feature add compared to the development required?
- Is this feature part of the critical roadmap, quick win or a nice to have feature?
- If you’re fully agile or use lean methodology, ask how the idea can be tested without writing a single line of code?
The goal is learning. Don’t write code unless there is definite proof of the value that it will add.
Remember – the customer is at the heart of everything you do.
The support stream – BAU
When running a business as usual (BAU) in the support stream, there are often a lot of issues at any one time that need to be resolved at the same time.
In the IT space, we have support tickets on a Kanban board, agile methodologies and other restrictions to get developers to operate like machines. They need to push out code – which is often never used.
The reporting team spend weeks aggregating data for reports – which are only used once – if ever.
To avoid wastage, it’s vital to break down any support ticket to fit into one of the four urgent-important quadrants. Below is an example of where different tickets reside.
Business needs to focus on that which is important.
The way to measure this is by learning about what is truly important to our customers.
We should always learn from our failures.
Simply be effective.