What is wrong with Agile?

 Alongside numerous works that popularize the agile way of working, occasionally we come across articles or presentations created by experienced professionals who express exasperation with Agile.

Why is this happening?

Recently, a friend sent me the link to this article, suggestively titled “The Age of Agile must end” [See B1-Age of Agile]. I could easily see myself spending an hour discussing the points I might disagree with in this article, and perhaps even another two hours exploring areas of potential agreement. It strikes me as an excellent example of these perspectives, where software professionals or other professionals express their dissatisfaction with Agile. In short, I can say that I resonated with certain problems described. Here are some aspects of how Agile is used that, from my perspective, could profoundly affect our work:

Agile Simplified as Scrum: A good part of the "Agile world" is centered around Scrum, or similar prescriptive methods, serving as the sole reference point.

Challenges with New Products: Developing a new product often demands a distinct life cycle compared to established products. The Scrum-Agile cycle is more suited to the latter. Therefore, a variety of development life cycles should be available for selection.

Adapting Lean Techniques: When integrating Lean into an Agile-lean approach, customization according to the situation and the current stage in the product's life cycle becomes crucial.

Unaddressed Technical Debt: The issue of quality, technical debt, and a deficiency in technical excellence remains a significant concern within the practical Agile landscape.

Technical Debt in New Products: Indeed, technical debt can swiftly accumulate and impede even the development of a freshly conceived product.

Compromising for Expediency: The tendency to cut corners often gives rise to the accumulation of technical debt.

Limited Focus on Short-Term Goals: Concentrating solely on short-term objectives and hoping for medium and long-term goals to somehow resolve themselves is a common practice.

To me, these are symptoms of "Incomplete Agile". Let's talk about them.

 

 

Agile simplified as Scrum

 

Reducing Agile to Scrum (and other prescriptive methods), along with the Agile manifesto, doesn't provide a robust foundation for developing Agile processes that can adapt to various situations. A significant portion of the "Agile world" relies heavily on these limited references. Many people criticize Agile for not aligning well with their specific contexts and the outcomes they want to achieve. In reality, this often points to this "Incomplete Agile" approach.

Definitely, Agile, as well as your process, has more than 10 practices.

 

New Products Problems

The essential tools required in this scenario cannot be found within the realm of Scrum. While the Scrum lifecycle could indeed prove valuable for a mature product, an alternative lifecycle better aligned with this situation exists: the Exploratory Lean Startup, one of the several Agile-Lean lifecycle options detailed in the DA Toolkit (see [B2 – DA Toolkit]). Instead of adhering to regular deliveries, the focus shifts towards conducting numerous small experiments to identify market needs and showcase the proposed solution approach.

A more detail discussion about the type of development life-cycle could be used in the different stage of the product life cycle can be found in one of my previous posts (See [B4 Delivery vs Product ]).

When you begin a new product, you are in an exploratory stage and should adapt your approach. 

 

Adapting Lean Technique  

Some distinct approaches are necessary for various stages of the product development lifecycle. For well-established teams and existing products, pinpointing delays (a significant result of diverse sources of waste) holds paramount importance. Conversely, for emerging products, it becomes even more critical to detect trends in the primary waste sources before substantial delays accumulate. Developing a new product requires drawing from the experience of waste prevention.

Also, we're not precisely employing the Lean manufacturing approach; rather, we're utilizing a distinct approach that is better tailored for knowledge work.

You should eliminate delays from your workflow, and even better, strive to avoid them.

 

Unaddressed Technical Debt

Scrum deliberately does not tackle this challenge explicitly, possibly because its creators known XP approach and aimed only to introduce additional elements. As a result, teams and products that intentionally embrace an exclusively Scrum-based approach, without addressing the "technical excellence" aspect emphasized in the Agile Manifesto, face the potential of encountering significant risks.

A key phrase in the mentioned article [See B1 Agile Age] is “Invest in foundational efforts like design systems and a clean tech stack so future efforts can be more efficient.”

The XP approach for this aspect might remain vague or challenging to duplicate. The team that embodies the XP style had a high level of skill. They didn't create a "mess" and used refactoring to align their evolving system design with new requirements

Contrastingly, a typical Agile team faces more risk in generating "mess" and accumulating technical debt. It's advisable to invest intentional effort into overall design and technology stack options decisions. Establishing a foundational base is necessary, followed by the opportunity to refine it as experience grows and new system requirements emerge. This approach indeed pursues a goal that extends beyond the immediate delivery.

 Software ages akin to milk, not maturing like fine wine.

 

Technical Debt in New Products

 

We have several competing goals concerning the economics of the first delivery and the feasibility of continuing the business post the initial delivery. These include swiftly determining if our product demanded by the market is viable and if our technical solution is feasible, preferably without incurring substantial expenses.

Establishing a robust internal design is essential, enabling modifications to the product without compromising its integrity or significantly increasing costs through the accumulation of technical debt.

Moreover, it's important to recognize that a product consistently has facets necessitating exploration and expertise. Therefore, opting for the appropriate life cycle to accommodate these needs is crucial.

Beware: you can create hard-to-change software from the start.

 

Compromising for Expediency

 

What is our objective? Is it solely the current delivery? Is it both the current delivery and future deliveries? Do we want to ensure the continuity of our business? Technical debt accumulates over time, leading to progressively worsening delays and escalating quality issues. There could be several possible reasons for not effectively addressing these issues: perhaps we don't fully comprehend them, or perhaps we do understand them but take a reckless approach.

Behind many technical disasters lies inadequate or reckless behavior.

Limited Focus on Short-Term Goals

 

We need a deliberate effort and dedicated actions to address also our medium- and long-term objectives. Here are some examples. We need to ensure that the internal design quality remains manageable and aligned with both current functional and non-functional requirements. This practice aids us in delivering high-quality products within designated timeframes and at minimized costs across short, medium, and long-term periods. To achieve this, as well as other equally valuable objectives, we should continuously enhance the knowledge and skills of our personnel. Additionally, it's crucial to monitor sources of waste to avert the repercussions stemming from their accumulation.

Long and medium-term goals encompass more than simply the aggregation of short-term goals.

 

How to address these problems

We needed to effectively address both our short-term and medium- to long-term objectives. This necessitates a deliberate and ongoing commitment to improvement. To achieve this, we should draw upon the collective industry experience, rather than relying solely on specific Agile methods. Our development cycle and practices should be chosen based on our unique circumstances, requiring a thorough understanding of available options. While tools like ChatGPT are trendy, their suggestions should complement our decision-making rather than dictate it. But are these insights structured and validated by industry experience? Success might be a matter of luck. If we seek access to industry-proven expertise concerning these options and guidelines on their contextual application, the Disciplined Agile Toolkit (see [B2 – DA Toolkit]) serves this purpose. If our aim is to overcome the challenges posed by an incomplete or ill-suited Agile approach, it's prudent to customize it ourselves within our specific context, leveraging the wealth of industry experience already available to us.

A good starting point is the online DA Browser knowledge base (See [B3 – DA Browser])

Do not try to solve any problem you have with the same set of 10 practices.Adapt Agile practices to the specific context of the product, the team, and the organization.

Utilizing multiple references for Agile & Lean is recommended, and you can leverage the organized structure of these references available in the DA Toolkit.

 

REFERENCES

[B1 Age Of Agile]  The age of Agile must end, by Michael Burnett, Feb 12 2023

https://uxdesign.cc/the-age-of-agile-must-end-bc89c0f084b7

[B2 – DA Toolkit] Disciplined Agile Toolkit

https://www.pmi.org/disciplined-agile/

[B3 – DA Browser] – Disciplined Agile Browser

https://www.pmi.org/disciplined-agile/da-browser

[B4 Delivery vs Product ] Delivery life-cycles versus product lifecycle

https://agileand.blogspot.com/2020/01/life-cycle-evolution-example.html