Should You Always Aspire to be Agile?
Since 2001 term agility has become almost synonymous with efficiency. But the imposition of agile software development practices don't always translate into best practices.
Agility has been one of the terms associated with software development since the 2001 introduction of the term in the context of the Manifesto for Agile Software Development. Nearly two decades later, though, people have started questioning if it still relevant used as a framework for best practices.
Why Agility Doesn’t Deliver
Agility was what companies that were attempting to achieve digital transformation aspired to. While they attempted to pull this shift after years of waterfall practices, what most ended up doing, according to Masood, was just: "Implementing waterfall with shorter term check-in."
Another reason the practice of agility does not live up to the efficiency it is intended to deliver is that it only works well for small teams. The ideal team size for agile is just five to seven members; it doesn’t work as well for larger teams and breaks down altogether once teams grow to 50 or more engineers.
"It’s very difficult to implement agile practices at that level,” Masood explained.
As teams grow in size, face-to-face communication is often replaced by other forms of communication to bridge remote workers, whether via text, email, or Slack. Then they also need to set up more meetings, which runs counter to the agile idea of minimal meeting. The teams cannot maintain agility all the time and so incorporate the waterfall approach meant to be supplanted by agile.
Agility and Autonomy
Another problem is that the businesses that plan multi-year digital transformation projects typically do so as a “top-down initiative,” when agile only really works well as a “bottom-up” model. For the most part, a CIO makes the decision to adopt agile and will often even bring in outside consultants to implement it, rendering agile into a framework that is forced upon the teams.
For agility to be effective, though, it has to start with the team. They have to arrive at this process in by being “self-organized,” setting their own timelines for sprints based on what they have learned to expect from software implementation. Ideally, one team would set up a pilot program that can then be extended team by team to roll out to the rest of the organization.
But in most organizations the agile mandate comes down from the top rather than being initiated by the teams who are the ones who need to carry it out. It all stems from taking the factory assembly line as a model for software development. It doesn’t work for software, Masood explained, because it is constantly changing and evolving and can’t be boxed into a static process.
“This is why so many digital transformation projects fail,” she pointed out. If the goal is to get the development to move at the speed of a startup, it really needs to come from teams with individual level buy-in.
Keeping the End in Mind
Stephen Covey identified one of the seven habits of highly effective people as having the end in mind. For software development that means meeting the expectations and needs of the customers. However, businesses often make the mistake of getting bogged down in the development process and following specs that they forget why they’re building the product in the first place.
Delaying production for bells and whistles they don’t care about is losing sight of what really matters.
“In today’s world where things are moving so quickly, you have to be fast with the resources you have at your disposal and be quick enough with just enough features in the product to satisfy customer demand,” said Masood.
The Measurements that Matter
“Humans optimize for whatever is quantified,” Masood explained. We lose sight of the forest while they’re tallying up the trees.
Whatever metrics they have in place for work efficiency is what’s going to end up defining the focus. Consequently, processes become an end in themselves. Agile development breaks down the larger “overarching goal” into easily quantified “issues and tickets.” That leads to employees creating tickets “just to hit the metrics” and for the organization to “lose sight of the bigger picture.”
Moving Beyond Agile
There is a role for leadership in software development, though not in imposing agility. “What I believe leaders should focus on motivate their workers to measure what matters,” Masood said.
Instead of measuring quarterly results in terms of the number of tickets completed, they need to ask questions that indicate if they are shipping to customers what is valuable to them.
That means looking at metrics like the following:
- What percentage of people used the feature that shipped?
- In the last quarter how many products did you release that customers used?
- Did customers vote with usage by actually using or with dollars in buying the product?
In today’s fast-paced get-your-order-to-you-today to meet expectations set by Amazon’s level of service, it’s already taken for granted that there will be some agility in place. As a result, “agility is no longer a differentiator, no longer something companies should be aiming for.”
The way forward is not to force engineers to follow the agile manifesto but to set out a flexible and responsive approach that draws on user feedback to produce data-driven smart recommendations
She’s optimistic that in 2020: “We will see the rise of the end user movement.”
“I think that’s where we’re headed, and agile will become a dinosaur term.”