Skip to main content

Culture that accepts a slight risk of failure (NOT reckless failure) in the interest of being faster and more agile

Let’s start with a few options:
(A)
Be fast, risk failure and if needed quickly recover to succeed.
(B)
Be slow and successfully launch.
Obviously the option A does NOT apply to companies that are building planes, ships, cars, medical equipment and what not. However, it does apply to a lot of other IT organizations.
In option A, I am NOT talking about recklessly failing. I am talking about leading a team and trusting them without watching every single line of code and without introducing too many gates during the development of a project while the developers are what I call “in the zone”. As long as you have professionals on your team, you really need to use “let the baby out of the crib” methodology and allow them to fall as they are learning to walk as a team.
When I say “fail”, I also don’t mean failing foolishly breaking every rule in the architecture book; that’s being foolish and not fast. I am talking about the culture where risking normal failures is NOT looked down upon. It is all about keeping the levels of this risk within normal boundaries and that requires a skill.
This is what “Be Agile” could mean. Let’s call it “The Function of Being Agile”:
We don’t need books and certifications. It just boils down to the above Function of Being Agile that we need to stick to; everything else is catering “Be Agile” approach to your company and it may mean that you implement what Scrum organizations put in place, or it may mean that you deviate from it in order to best achieve the goals in your work environment.
How do you gauge if you are on the right path?
It is simple. If the number of your failures is increasing over time and it is actually slowing you down, than you have to revisit the whole approach.
If the number of your failures is the same or less and you are not slowing down your development and deployments, then you are on the right path as long as those failures are not critical to the business. The goal is to keep iterating and NOT repeat the failures.
At the end of the day, if you have the culture that does NOT look down upon slight failures, your team will have so much fun which typically leads to amazing results. It is beautiful to watch the work in action. You can’t really measure every step of the way, but what you can measure is how much more value you provided to your customers. That’s the measure that matters at the end.
Thank you for reading this article. You can follow me here or you can check out my personal blog: http://www.almirsCorner.com
Almir Mustafic


Comments

Popular posts from this blog

Leaders/Mentors in my life

I have been blessed in my software engineering career with great leaders. Some of them challenged me in technical skills. Some of them challenged me in my organization and leadership skills. Some of them challenged me in both. And all of them made me a better software engineer, a better senior engineer, a better solutions architect, a better teammate, and a better leader. If you are a student, find yourself a mentor. If you are a junior software engineer, find yourself a mentor. If you are an experienced software engineer, find yourself a mentor. Remember, you write your own definition of success and you are your own critic. That may mean that you TRY to perfect every stage of your career, or that may mean that you skip some stages in your career. Remember, you are in control. That’s all I wanted to say today :) Keep geeking out. Almir

Daylight saving time and A Software Engineering state of mind ?

You may be wondering what the Daylight saving time has to do with a software engineering state of mind. When thinking about writing this article, at first I thought to start with the following joke and I am: “ Did you know that the Daylight saving time was started because a software developer coded a function that does smart timezone and configurable calculations and then this developer created a problem to solve to use the algorithm; hence, the Daylight saving time was born. ” This is a joke, but  on a more serious note , this brings me to a state of mind in software engineering that make this joke a reality to some degree. How many times did we find ourselves in situations where we learned something new in programming and we looked for ways to apply it at any cost? How many times did we see a cool new feature from a creator of a framework and we decided to use it even though that was not the right solution for the problem or maybe there was no problem to solve in the ...

Language of Software Engineers and scrum-master skills (quick thoughts)

Language of software engineers and skills of scrum-masters? All software developers speak the same language and that is pseudo-code :) However, there are still communication issues among software engineers specifically with other teams. That's where the role of great scrum-masters fits in. That great scrum-master does not necessarily need to be technical but he/she needs to have the skills of hearing roadblocks that engineers communicate in their technical language. I said "hearing" and hearing is not the same as listening. Listening is just a pre-requisite for hearing. Once you hear it, now you need to know how to action it and mobilize the right people. Coaching comes along with all of this, but that is a separate topic because it is also a responsibility of the tech manager. These skills separate great scrum-masters from others. Almir Mustafic P.S. Disclaimer: On any given day, I wear a hat of a solutions architect, engineer, scrum-master and tech manager.