Franklin D. Roosevelt once said, “The only thing we have to fear is fear itself”. Well, that and “the unknown”. So many of us working in software product development have an irrational fear of situations that are perceived as strange or foreign. It is common when a person cannot define something, they become uncomfortable. Resistance to the unknown, or change, can be the very thing stopping you from embracing Agile.
The Unknowns and The Knowns
One’s thoughts and actions are based on experience. Only with time we can gain the experience to define and label our unknowns, making them known.
Let’s take this one step further. With experience also comes our ability to predict outcomes. The more we experience the more we can predict. If you can predict the outcome, you can control it. Which means you can control success and quality.
To summarize, with time and experience we can define, plan, and control predictable outcomes and quality. Wow, that sounds wonderful. This, in many ways, was the foundation of traditional large-scale project management methodologies. Build a process framework that allows you the ability to define, plan, and control predictable outcomes and quality.
Spoiler Alert: Change Happens
Software Product Development is far from predictable. The speed at which technology is changing is incredible. The speed at which user expectations are changing is just as quick.
Let’s face it, change is the new norm.
- We don’t have the time needed to gain detailed experience
- We don’t have the time needed to categorize and define
- We just can’t control the number of unknowns
- And it is a real challenge to use traditional processes to define, plan, and control predictable outcomes and quality
The Struggle Is Real
As an organization or an individual, controlling outcomes is a fundamental need. We desire to limit risk by controlling the unknowns. But setting this as a goal is something that is increasingly difficult to achieve.
Holding on tight to these beliefs is not an option. And in creeps the “Unknowns” and our buddy Fear.
Striking a Fear/Trust Balance, Enter the Agile Mindset
In today’s software development climate, it is not realistic to think we can eliminate all the unknowns. So, it is important to strike a balance between fear and trust. This starts with the acceptance that change happens.
The agile mindset introduced concepts that help us strike that balance. Most important is that change happens in software product development, and we need to embrace it with controls and processes that welcome change.
Trust, by its very nature, is based on the belief that someone or something is reliable, good, honest, and effective.
Building Trust
Moving past fear is not easy. But there are things you can do to bridge the gap.
- Do your homework, find an agile framework or set of processes that best match your company and its maturity level
- Put in place a well-rounded team to empower and distribute responsibility
- Welcome conflict as a way to embrace ideas
- Get the right people on the team and the wrong off the team. You need full commitment and accountability
- Pilot a project to gain confidence
- Focus on results. Set small objectives that built up to the larger mission
- Be flexible and willing to change the approach if it’s not working
Gaining experiences with agile practices will help you build that trust. Keep in mind that you will not be able to fully define, plan, and control predictable outcomes and quality. Instead you will have a framework that factors in change as a constant, and controls risks while promoting quality.
Time to Send Fear Packing
There will always be unknowns. Using the agile mindset to abate the fear of the unknowns is the best way to combat Fear. It is not easy to move past the “this is how we have always done it” comfortable way to the “this is how I stop freaking out” and welcome change way.
So, kick Fear to the curb and start trusting your new best friend – Agile.
Jim Dunn
Related Posts
-
Good Agile. Bad Agile.
There are Good Agile teams and there are Bad Agile teams. Building great software…
-
Good Agile. Bad Agile.
There are Good Agile teams and there are Bad Agile teams. Building great software…