Agile organizations
2001 was the year things started to change. Previous to that year, delivering software, products, and services were very structured and sequential. Going from “square one” to the “finish line” took time and created regularly occurring frustrations between employees, teams, departments and clients.
Then a group of individuals gathered at a hotel to discuss ways to improve software delivery based on their knowledge and experience. The time spent there gave the world the Agile Software Delivery Manifesto. Four sets of guidance and twelve principles to help teams remove some shackles, and improve productivity and quality. It was a drastic change to the status quo in software delivery. Organizations have used a basic assembly line model, used for decades, to create products and services. The guidance it provided was entirely outside-the-box thinking, and because of that, it was not seen as a functional way to produce products. Some have called it a “marketing gimmick” or a fad. To some, it was the new shiny toy on the block that they needed. At the same time, those who have worked in the trenches of software development saw it as a welcome change.
As time moved on, more and more companies started to use “Agile methods.”
Scrum was the first set of methods that came on board and became the new way of doing things. It was created well before the manifesto, as were many of the other systems that teams use in agile development.
“ The first paper on Scrum appeared in the Harvard Business Review in January 1986. Software teams started using the Scrum agile process in 1993.” – New to Agile and Scrum.
You also have Kanban, which is even older (from the 1940s) and Extreme, programming from 1996, both in existence well before the term agile moved to the mainstream. SAFe and LeSS came into play later, and others come and go or become hybrids of them all. It has come to the point where the views of agile delivery have expanded to services. In previous blogs, other disciplines like marketing teams are using agile delivery to help get work done.
So with all this history of methods to improve efficiency and effectiveness, why is it that there is a broad sense of acceptance of agile delivery, yet there is a struggle to get it right?
“We are an agile shop.”
“We are good at using agile.”
“ We are satisfied with our agile delivery.”
In some form or another, these three comments are shared within meetings, networking events, or coffee breaks. It seems people think that doing things differently than traditional waterfall projects makes them agile. With some, it is a matter of following the steps within the methodology as strict as they can be, or it is free for all. In a recent webinar, this topic came up.
Dave Thomas, one of the creators of the manifesto, did a talk at the GOTO 2015 conference in Amsterdam on his blog post: Agile is dead. He goes into details on how what they brought forward was manipulated and turned into a buzzword.
In 2018 McKinsey and Company did a study of 2500 organizations and published a report: Leading Agile Transformation: The new capabilities leaders need to build 21st-century organizations.
In it, one of the key findings out of 2500 organizations that they researched, they found only 4% would be considered an agile enterprise. That is only 100 organizations that have the right behaviours and are disciplined enough to use them effectively to be ahead of the pack.
In 2017 AgileCxO, 2017 State of Agile Survey, & AgileCxO Partner Assessments of over 200 Organizations, and found that 80% of organizations that are using agile methodologies are struggling to mature. The other 20% are maturing although, going by the findings of the previous study, it would seem the pace of that maturation is plodding.
Look at the last of the 12th principles.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behaviour accordingly.
An agile organization should continually improve, and push forward so that they can win. When we talk about a ‘win’ we do not mean getting that sale or improving revenues. It is much more than that: employee satisfaction, the flow of information, client satisfaction, and achieving other non-monetary goals including financial goals.
Of the three comments above: “We are satisfied with our agile delivery,” shows that an organization is not agile. Could the comment be valid? Can an organization’s leadership be satisfied with their agile delivery?
Maybe they are part of that four percent in the study mentioned above where the leadership has succeeded in becoming agile and transforming the rest of the organization. The issue though, is that if they have become agile, then they wouldn’t be satisfied. Stating such implies perfection, and perfection is something to strive for yet never achieve. There will always be a need for improvement, especially in today’s world, where change is constant.
They could be complacent. Maybe leadership and their teams are just riding things out and will tactically react to change instead of strategically. Perhaps they feel the need to have those emergency firefight meetings where everyone drops what they are doing to focus on the issue at hand—sending status emails on the hour and muscling in change. Then when that is all said and done, they’ll deal with the aftermath of the burnt-out of employees and changing organization strategy without using the company’s vision to guide them.
It is a far cry that the previous two reasons are genuine. If an organization were perfect in every way with agile, that would be the place to work. Glassdoor would have five-star ratings all around, and there wouldn’t be one negative review on other sites.
So one main reason for claiming satisfaction with their agile delivery is that they do not have enough information to see the amount of value that is available to be mined for the betterment of everyone. Most people see Scrum, SAFe, LeSS, and other methodologies as agile, when in reality they not. There is something much deeper needed to be agile.
Kateřina Mňuková wrote 5 common buzzwords and myths around agile. As you read through, it helps confirm that it is a lack of understanding of the agile mindset that allows organizations to think they are agile while, in reality, they are lying to themselves. An example I have provided before is a paired car race where both cars must cross the finish line at the same time. One of the vehicles would be a Shelby Mustang, while the other is a 1982 Chevette. The time it takes to get around the track is not going to be good. Yes, the finish line will be crossed, at some point, just not as fast as it could be when both cars are high powered. In this analogy, the development teams are the Mustang, ready to get the work done. At the same time, the Chevette represents other departments, management and stakeholders who are not using the same agile values and are not in the agile mindset.
They call themselves agile because they are doing it in some parts. To get more to the truth, organizations and leadership need to make changes. It is removing doubt that agile development fails because it hasn’t worked in your organization, and others are first on the list. If it was a failure, why did the study show that 4% of organizations succeeded? Why are 20% on a maturing path to that 4%?
Like all organizations, they are basing their decisions on the data they have at that point in time, as long as they learn and understand more about being agile, and can see the potential for even more value to push past the competition. Now is the time to no longer make it a buzzword and become agile.
Updated:
10 lies CIOs tell themselves about their agile practices
Want to see how your organization is with being agile? Take our assessment to get an initial look as to the organization’s behaviours and actions with agile values.
