Agile Is A Top-Down Approach
Yes, this article may sound scaremongering. I know that! But this way I thought you will open your mind to read and think about it.
A Brief Context About Agile
As you may know, Agile refers to the Manifesto for Agile Software Development written by a group of guys in 2001. The Agile Manifesto represents what they thought the Software Development should look like at that time. The group got together to discuss this topic mainly because they didn’t agree with the path that the Software Development was going and decided to commit to change it.
How People “borrowed” The Term Agile?
Since then, the Word “Agile” suffered from many resignifications and interpretations by the software community and also by other communities.
Once the word “Agile” alone doesn’t mean anything, it could be easily combined with tons of other words to create “new” concepts that benefited from the popularity of the Agile Manifesto.
Soon people creatively created concepts like Business Agility, Agile HR, Agile Contracts, Agile Teams, Agile Tools, Agile Processes, Agile Management, Agile Methodologies and so on, this list is virtually infinite. Not a criticism, just a fact!
My Preferred Definition of Agile
I’m not the creator of this definition, but I like it. It can be found on the Agile Alliance web site.
Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.
At this point, you may say that Respond to Change is only one of the four values of the Agile Manifesto, but it kind of synthetizes the agile spirit — oops just created another concept :) — in my opinion.
Why Agile Must Be a Top-Down Approach
I once read that Agile is intuitive and that’s how teams would get organized if they had a chance to choose. I also heard at a conference that “We, software developers, were already working with Agile in the old days when the user was sitting side by side with us and telling us how the software should work.”
In my opinion, Agile is anything but intuitive:
- One must work hard to make people collaborate instead of closing in silos.
- You have to think a lot to come up with valuable Working Software in short iterations.
- Software houses are still struggling to establish partnerships with customers companies and vice versa.
- A huge number of software teams make a big plan upfront and divide it into several iterations with a rigid change management process to ensure that the product will be delivered.
The world I described above is the real world and it was the way people self-organized to delivery software until now. I’m not telling that it’s good nor desirable, but that’s what could be done with the constraints and beliefs we were based on until Agile was popularized.
It is hard to say, but this is the reality of many companies that claim to have already completed their agile transformation.
To change this behavior and break the vicious cycle in the organizations, the C level must not only create a supportive environment that allows people to work and live the Agile values and principles, but ensure that all leadership layers can foster the agile practices and understand what is the company’s goal when embracing such hard-achieving journey.
Agility is now a competitive differentiator for businesses. CEOs know that they must be part of it to remain competitive in a fast-growing market. Many of the constraints of the past does not make sense anymore and to succeed in today’s market, executives have the hard mission to cultivate, in the entire organization, the belief that even new customers know more about their needs than your ten-year well-paid Product Manager team.
So don’t full yourself and lose precious time by thinking that implementing agile only at team level or change the names of the roles will make your company agile or bring any benefit at all.
