The Five Ingredients for True Agility in Software Development

Published in

Be the Revolution

5 min readMar 8, 2018

Businesses gargle themselves on their individual-driven culture, the importance of their values and the deep respect they have for their employees. Sadly, the messages sent are quite different when you see the plethora of processes put in place to ‘enable’ the workforce.

Let’s find out what should be considered when you are looking to improve your velocity through an agile strategy.

Where Are You Starting From?

While visiting enterprises, I am often asked what additional processes must be put in place to ‘drive’ agility in an upcoming project. Few will take the time to look at their current work environment and reflect on the foundation they want to build agility over. Agility cannot thrive in a culture of control.

If the department entrance is controlled by a time clock or if you ask employees to fill in timesheets, are you implying that they are time thieves?
If you’re preventing your software developers from accessing production environments directly, are you telling them they’re a bunch of incompetents and may set your servers on fire?
If analysts are the only ones allowed to design the product, it is because your developers are mentally challenged and can’t understand the business domain and propose good solutions themselves?

Challenge yourself with these types of ‘What then?’ questions:

Could you do without a DBA?
Could you have developers directly interacting with customers?
Could anyone review pull requests?
Could you do without a dress code?

I’m not telling you that these suggestions can be implemented everywhere. In fact, in many places this would not make sense. What I’m saying is that you have to ask yourself these questions. You cannot accept guidelines or directives without understanding the motivation behind them. Be an original!

Removing Friction

Low friction is the explanation that comes up most often when we analyze the dazzling successes of the likes of Netflix, Google or Tesla. These companies trust the person closest to a problem to make quick decisions and apply the most appropriate solutions. Can we live by this philosophy and progressively adapt our teams where applicable?

A Recipe for True Agility

The ideas supporting an agile strategy may be so simple that many will predict this cannot bring the intended results.

You do not impose agility. You need to create an environment where true agility will be allowed to naturally emerge. Hence, the ‘agile process’ oxymoron needs to be challenged. Strategies promoting agility have a higher chance of success and are based on the following principles.

Goal

If you do not explain to someone why they are tasked with something, it will be difficult for them to ask the right questions and independently make the right decisions. Worse, it could be impossible for your developers to detect changes in the requirements and quickly pivot to other solutions.

Human Capital

To build a great product, you need a team composed of great people. A common mistake here is to invest in processes and strict supervision rather than selecting great contributors based on their characters traits and technical excellence. Take the time to build an autonomous team rather than infantilize your workforce.

Direction

Forget the big Hollywood styled missions with infrequents deployments and stressful milestones. Today, everything changes too fast. The concept of destination has been replaced by that of a constant, accelerated and endless evolution. Set a general direction instead and steadily progress toward it while adjusting for a moving target. Experience one-day sprints with the simple goal of being in a better position tomorrow than you were today. Repeat 365 times.

Empowerment

Setup your teams so that no one needs to ask permission to execute on something if they think that’s the right thing to do. If they have the expertise and are close to the issue at hand, they have to take action themselves. If they feel uncertain in their abilities, they should feel encouraged to ask for help. Here, the concept of appointing decision committees, technology custodians and process managers must be eliminated. You must remove single points of knowledge. It’s no longer your code, your server or your architecture. All can intervene anywhere to accomplish the mission.

At INGENO, we have adopted the DevOps model where teams of 2 to 5 highly skilled full stack developers will handle everything. From daily talks with the customer, architecture and design, test driven development and continuous deliveries to production, they do it all. These teams have all the necessary administrative accesses to all environments and tools required to support their daily activities. They to not need permission from anyone to make decisions and move forward immediately.

Liability

With great powers come great responsibilities. Being liable in a DevOps model is not synonymous with being the one who will be blamed when something bad happens. Being liable simply means you will be called upon to correct a situation if the broken item is managed by your team. When a developer has to support his code, his application, his architectural choices and his clients in production, he quickly develops an understanding of what works well and is not too risky.

There are no kings inside the Gates of Eden. — Bob Dylan

Do not spend efforts building barriers… Those who still defend their territories by creating processes and permission systems should instead focus on human capital.

Invest all your energy in promoting autonomy, team spirit and direct actions from people in the best position to solve a problem. If you believe that innovation is key to the future success of your business, value the simplicity of being able to make a decision and act on it quickly.

At your own company, how are you addressing the 5 principles of true agility?

Be the Revolution!