Agile (with a capital “A”) has been gaining popularity, has been trending even. Many companies have done their explorative steps. Some at larger scale than others. It appeared that agile had won in global acceptance.

In recent years, more and more Agile hate articles are appearing online, and it actually even seems to become a trend.

Why is this we asked ourselves? As from personal experiences, we clearly observed companies having a demonstrable benefit from applying agile methodologies (please notice the plural), in achieving a vastly improved business agility.

Especially when having achieved first smaller scale successes, scaling business agility in the larger organization very often stumbles upon loads of resistance. Despite the obvious upsides and achievements.

We have outlined the most common arguments we encountered on transformation journeys.

1. Not enough room for innovation
2. Strict time pressure affects quality
3. Increasing complexity

As  business agility advocates, it definitely is worth exploring a different point of view, and to hear out some healthy portions of criticism from
time to time and give it all a thought.

“I don’t want agile, as it stops innovation from happening.”

In one of the more recent missions, we had been successfully building several Minimal Viable Products within timelines the organization never imagined feasible. Subsequently they evolved systematically as products with successful releases every 2^nd week. One might argue that this appears to be a textbook example of a successful agile implementation? You’d expect every business line owner to be anxious to adapt the same practices.
While raising a fair amount of interest, we encountered an extreme degree of resistance. It was perceived as detrimental to innovation!
The extreme perception was one where innovation could only flourish when you put yourself physically in the middle of a group of young talented developers; storm 3 times a day and hence come up with bright ideas, which they would refine along the road.

What’s wrong with this?

1. Stakeholders invest time into their ideas, and will have their own vision for how their features should look and work. Often, requirements are so prescriptive that individuals working on the project can be left with little room to provide input to solutions.
   It’s a sure-fire recipe for disengaged colleagues, which also means worse outcomes for the end-user.
2. It doesn’t respond to predictability, nor to the ambition to permanently deliver customer value on a permanent basis.
   In this setup the customer is nowhere to be found! It is HIPPO[1] behaviour on a micro-level.
3. It is doesn’t contribute nor to a coherent customer journey
   (several micro-kingdoms will in the best case each individually deliver isolated optimized solutions, but only builds to customer frustration). Also, it for sure does not contribute to re-usability, resource optimization or maintainability. All required in order to ensure that Return-On-Investment remains under control.

[1] HIPPO behaviour: Highest Paid Person’s (personal) Opinon

More importantly it is about creating a safe environment, within which teams can iterate without being punished for their innovation attempts. Innovation in the way of working, as well as from a product improvement focus. For sure it means defining a backlog that is a slightly less specific list of tasks, and more spikes [1]. 
It might equally mean that developers are encouraged to take more of a consultative approach, where ideas and different suggestions are welcomed. Maybe it might look like monthly bandwidth for innovation, where developers have a chance to suggest completely new ideas and explore new concepts together as temporary, alternatively composed teams. It is about one of the base principles of the agile manifesto, about fostering safe environments!!

[1] Spike: In agile software development, a spike is a story that cannot be estimated until a development team runs a time-boxed investigation. The output of a spike is an estimate for the original story.

What is the alternative?
Agile teams have processes built-in to allow for innovation. Innovation takes place in many (differentiated) ways.
First and foremost it is about explaining and sharing your business objectives for the upcoming quarter with the entire team, in order for them to understand the products they create.
When I state the entire team, than we effectively mean everyone from the product owner all the way to the QA, the DevOps, etc. So they understand what drives the customer behaviour. They can contribute from the perspective of a customer; point out opportunities derived from  technology capabilities.  Often times identify low hanging fruit.

“The strict 2-weekly time pressure will affect the  quality of work delivered.”

What’s wrong with this?
When looking at (perceived) time pressure there are multiple facets to be considered. The resistance in terms of synchronicity on the one hand and the time pressure within a sprint on the other hand.
Let’s start taking a look at the latter:
Also with a set sprint (e.g. two weeks) to deliver a working increment, teams need to find the most efficient solution. This has numerous benefits — the customer gets to working software quickly, and this can be built on in later releases. Good teams will also manage expectations effectively. Sometimes a feature will take longer than expected, and it’s up to the team to communicate this early.
The risk with this strict timing, however, is that often the simplest solution wins. This is all good until that simplest solution is not the best quality solution. When time pressure begins to affect the quality of work produced, the product owner is forced to choose whether to “accept” the feature or delay other work that would come next. Left unchecked, this can lead to stakeholders and users feeling short-changed. Now returning to the initial point in regard to synchronicity restrictions. While this is considered an emotional barrier, in practice it rarely really represents a bottleneck. What is more important?
Massively reducing the complexity of release coordination (by means of frequent but fixed release dates)? Also properly managing dependency management between (feature) teams.
Or having the team spend days in coordination dependencies and associated release coordination activities?
As long as the release frequency follows the same rhythm of your sprints, it is all about perceived limitations. Sprints of 2 weeks and a common cadence (= identical sprint timings: start & stop and the sprint rituals) are often perceived as barriers. Why should I delay my go-live and wait for the next release moment? (Why does my micro-kingdom needs to wait for the lagging majority?)
It also prevents me from going back to the team and demanding that they switch to this newest and smartest idea I have had, when I woke up this morning. What is the alternative?
The key to dealing with the time pressure of delivering solutions within a sprint is to simply not over-fill your sprints!
It might be tempting when you are running a little behind, or you have stakeholders adding pressure to see results quickly, but squeezing more and more into a sprint is just going to put you further and further behind, and corners are going to be cut.
Be realistic, expect to run into issues, and always keep the bigger picture in mind. Ask yourself — Is this the best solution for the customer? Or is it just the quickest? Which is more important in the big picture?

Synchronicity it is all about sharing a common business vision between all (feature [1] and component [2]) teams on a quarterly basis. Ensuring that during this product increment meeting [3], dependency management is a common practice! Not even a good practice as it is a base requirement.

[1] Feature: A feature is a service provided by the system that fulfills stakeholder needs and can be delivered by a single stable team. Each feature includes a statement of benefits and acceptance criteria, and is sized to fit within a program/product increment. Each feature team supports a certain number of functional domain. A functional domain could be considered as a (mini-) product.

[2] Component: Teams build systems out of components to provide scalability, flexibility, common fonctions re-use and maintainability. The creation of a specific component can be driven by a number of motivations:
Protective isolation for purposes of consistency, Re-use of logic, To support an anticipated high rate of changing requirements, Implementation/isolation of specific technology (php, java,…)

[3] Product Increment meeting: It is a Scaled Agile Framework term, that refers to a quarterly planning & alignment meeting. Program Increment (PI) Objectives are a summary of the business and technical goals that an Agile Team(s) intends to achieve in the upcoming Program Increment (PI). A product or program increment spans the period of 1 quarter.

An agile way of working  will increase the complexity

Another frequently voiced concern in the resistance movement towards adopting agility, is the statement that the company and by extension the the teams are not ready yet for this level of complexity. There’s too much methods, structure and practices that will kill the all flexibility. Usually followed by the statement, that it all sounds very sensible. That in the future when the organization is more mature, we can consider adopting it too.
An additional claim is that feature complexity is rapidly spiraling due to a stream of increments, whereby customer value is gradually an impediment. What’s wrong with this?
Agile is worthless unless it serves as a catalyst for continuous improvement. Scrum, Kanban, SAFe and other agile methodologies are worthless unless they serve as a catalyst for continuous improvement and therefore responding to both concerns at the same time.
An important part of successful agile implementations, is allowing some organic growth/evolutions in a safe environment.
In a series of articles we talk about agile craftsmanship requiring those organic aspects in order to be able to ancher it within the organization. The concerns of complexity are true when one looks at an agile transition as a textbook implementation with a series of fixed recipes. While we strongly advocate to allow a series of iterations (fast or slow) in a safe environment that allows absorbing methods. Circling back to the 2^nd point referring to growing feature complexity and lowering customer value. Why is this?
Because the factors that are slowing you down, are only partially due to whether you are sprinting, writing user stories, and doing biweekly demos. I’d argue those things are relatively minor (once you wrap your head around the idea of incrementally lowering risk). The majority of the benefit from a feature comes when it is first implemented, or in it’s first few iterations. But naturally, potential improvements arise and stakeholders compete for more functionality. Using Agile, iterations come thick and fast. As layers of complexity are added, and more hours are invested in the feature, the incremental increases in benefit become smaller. Without being aware of this, you can end up putting in a huge amount of effort just to gain minimal benefit to the end-user.

CONCLUSIONS

Agile processes require a certain context to be effective. They require us to form teams, build backlogs, measure work, and control work in a certain way.
It’s more than just the roles, ceremonies, and artifacts of Scrum. It’s the ecosystem agile methodologies operate in, that really matters. The problem is that this ecosystem doesn’t exist in most of the companies that are actually trying to adopt Agile—at any kind of scale.
Sure, many companies can adopt Agile on a small, self-contained project, but when it comes to changing how money is spent, how projects are approved, how return on investment is realized…we fall short. We struggle with forming the right kinds of teams, building the right kinds of backlogs, and measuring the right kinds of progress.

It seems everything in the organization is working against us making the kinds of changes necessary to benefit from a more Agile way of working.

The trick isn’t to just teach people Agile. We have to find a way to systematically overcome the structural, procedural, and cultural barriers that are continuously getting in their way. That problem can either be solved top-down, bottom-up, or someway in between. In our experience we’ve found that removing the impediments will require organic change to allow the new way of working to embed itself into the organisation, and hence also requires time. You’ll need engagement from the people doing the ground work first (=organic change) and further on from the senior leadership, middle management.

In times of crisis (very much as we are experiencing right now in covid-19 times) a sudden tendency to rush back to old micro-management habits is observed and to forget all notions of customer value. It is in times of crisis that one requires to be laser-focussed on customer value and business agility. Is agile indeed dead?

Short answer: “NO”.

On the on the one hand it all relates back to the above maturity of the ecosystem we described above. Furthermore, the idea of Agile is good but it has some serious issues is a statement we’ve heard before?
If the problems appear so often, is the methodology itself to blame?
A simple message dominated until recently: if you cannot benefit from Agile — you’re doing it wrong. It’s definitely oversimplified and it doesn’t work anymore as an adequate explanation.

Do not ask an Agile coach, an author of Agile books because they will encourage you to reflect on your own individual experiences and learn your own lessons. These are truly Agile things to do (also read Agile Craftsmanship article series)

No two companies, two business problems nor technological solutions are the same. If it works, it works well and let’s enjoy it. Keep on doing it and improving it. If it has become a corporate smokescreen for a lack of prudent decision-making, poor concept, questionable business value, and inefficient work — it’s a call for action!

Budgets and time frames of digital transformation projects are being exceeded by hundreds of percent. We feel there have to be better ways to deliver business value effectively and there are better ways, indeed.
Go try working with a partner who produces digital transformation projects and services for a living.
They can help you take a look from the outside; often the darkest place is under the candle and another pair of eyes can make a big difference. Every organization is unique, and the path forward will naturally vary. However, we’ve observed some general patterns that tend to be common across many organizations. With respect to the problem of sustainable pace, it’s often the case that organizations are operating chaotically in an attempt to deal with rapidly-changing customer demand and market conditions. Using structures and processes designed for an era when things moved at a more deliberate pace, and when the direction of the market was more predictable than it is today.
They may have attempted an “agile transformation” of one kind or another, but lacked the necessary organizational foundations to make it work well or last long.

Previous publications

Upcoming publication: [07.07.2020]
“Define business value in agile”