Some reasons big business is not satisfied with agile.

Some reasons big business is not satisfied with agile.

It is strange when you accidentally discover information, and it makes perfect sense. Those kinds of happy accidents of knowledge are called serendipity. Without any conscious effort, knowledge comes together, and you have fresh insight. This week, fate came calling, confirming what I have experienced throughout my Agile career. Today, I want to discuss it on the blog.

The State of Agile Survey is the pulse of the reformation in the business community. Trends and the adoption of business agility are under constant scrutiny, with developers, scrum masters, and thought leaders offering their opinions through an annual survey. I was not surprised by what I saw. Large organizations need help with Agile, and satisfaction with agile adoption is shrinking. Based on my experience in the field, I am not surprised.

The survey notes that satisfaction levels went from 72% to 59%. The principle reason was twofold. First, leadership needs to be more willing to adapt to agile working methods. Finally, lack of leadership acceptance creates organizational resistance to teams that use agile to get work accomplished. The result is poor customer satisfaction, developer burnout, and corporate anxiety.

I want to begin with the first cause of this dissatisfaction: intransient leadership—agile promises to deliver software faster and more efficiently. Before the widespread adoption of Agile, developers and technology teams would toil away on a software project only to have an executive or marketing professional tell them they did not build what they wanted. It drove many of us insane. With its focus on empiricism and short cycle times, Agile ensured that changes could be incorporated early. I also demanded that technology professionals and business people work closely together. It solved one problem, but blending business people and technology people created a culture clash within organizations.

Bill Pfleging and Minda Zeflin, in their book "The Geek Gap," point out that business people and technology people have different motivations. A technical person is motivated to build things that work. Business people are motivated by control, influence, and likeability in that order. Thus, business people will attempt to exert control and impact on people who want technology to work. It creates friction because these two world views are often incompatible. For example, a significant customer needs an upgrade for a product, and the manager promises it to his CEO and the shareholders without consulting the technology people.

Forced to deliver on commitments made before their input, technology people endure the brunt of the workload, resulting in resentment and unnecessary stress. Likewise, business people see the technology staff as aliens because of their eccentric nature, passionate focus on problem-solving, and desire to create elegant solutions to business problems instead of those that are good enough.

Additionally, there are extreme power imbalances in the business world where business professionals have the power to set budgets, hire, and fire. In contrast, technology professionals are responsible for delivering working solutions under those constraints. When things go wrong, the technology professional often pays the price while business people evade the consequences.

Nichole Derr points out in her blog that old command and control leadership styles and authoritarian leadership styles are not working in our current situation, and according to the World Economic Forum, 86% of respondents consider we have a severe leadership crisis. Narcissism, arrogance, and authoritarianism dominate corporate boards and C-suites, creating a situation where leaders behave in a "do as I say and not as I do" fashion. It further undermines credibility with technical professionals.

So arrogant authoritarian leaders are more interested in controlling and influencing organizations. These leaders often have huge power imbalances over the people who do the work. The second cause of the decline in agile satisfaction levels is the need for organizations to embrace agile working methods. Business people and middle managers, in particular, live a precarious existence. A manager wants to look competent, employable, and promotable but knows that standing out exposes them to risk. It breeds mediocrity in organizations and creates a culture of conformity. The Harvard Business Review wrote a seminal article in 1977 entitled, "Managers and Leaders Are They Different?" In the article, the authors point to three characteristics of business managers.

1)      The manager focuses attention on procedure and not substance.

2)      The manager communicates to subordinates indirectly by 'signals.'

3)      Managers play for time.

If empiricism, rapid cycle times, and responding to change are not essential to leaders, then the managers and line employees will not embrace them. The signals are clear, and it is to give agility lip service and play for time. Technology people will always pay the price for failure.

It creates a bleak situation where business people expect the benefits of Agile without engaging in the personal changes to make it successful throughout the organization. Instead of building software that delights customers, teams are pressured to meet unrealistic deadlines. It leads to frantic overtime, rushed delivery, and shortcuts that compromise quality. I have experienced this situation my entire career and look forward to helping business leaders develop healthier patterns of behavior, which will make Agile more successful than it is.

It is difficult to be enthusiastic about today's technology world with its pressures, layoffs, burnout, and threats from Artificial Intelligence. However, it will improve with better leadership and embracing the Agile manifesto's values and principles. The leadership will have to concentrate on business agility and quality. Otherwise, failure is a distinct possibility; ask Boeing.

Until next time.

Edward J Wisniowski

Edward J Wisniowski

Ed Wisniowski is a software development veteran. He specializes in improving organization product ownership, helping developers become better artisans, and attempting to scale agile in organizations.
Sugar Grove, IL