For those who do not have time to read the full article by Jurgen, here is a summary from AI 🙂
Agile's decline: The popularity of Agile is declining, conferences are dwindling, and agile roles are being phased out. Due to excessive ceremonies, buzzwords and dubious certifications, agile has become obsolete.
Key factors of decline: Several factors have contributed to Agile's decline, including the proliferation of certifications, rampant framwork, superficial learning, agile dogmatism, fashion fads, questionable roles (Scrum Masters, Product Owners), a focus on speed over result, chaotic management, misalignment with strategy, and major problems with the Agile Manifesto.
Paradigm shift: The original agile values are becoming obsolete in the face of new technologies and changing business requirements. The values of the Agile Manifesto no longer correspond to today's business requirements.
The need for new values and principles: The business environment demands new values and principles that balance leadership and management, prioritize the customer experience over the product, address the needs of all stakeholders, and leverage modern technology.
Agile as “undead”: The term “Agile” melts and becomes ambient, meaning that it is ever-present and influential, but is not explicitly labelled or marketed as such. The need for agility is greater than ever, but the Agile brand has lost its power. Organizations need agility more than ever, but they won't pay for anything called “Agile.”
In my article, I would like to freely follow up and look at what, in our experience, remains “undead” and what every organization that wants to succeed in today's world should at least consider.
Small development teams
The basis of modern development is small teams. A trend that has highlighted the impact of artificial intelligence on software development as such is the shrinking of development teams to the size of 2 to 4 people. These members are largely fungible, self-organizing, operate with a great degree of autonomy and responsibility, and have a large context of the business of both the firm and the customer. Together with the Product Manager, they participate in Product Discovery. With these features, they are able to prioritize, search for minimal products and make daily scope decisions, greatly streamlining end-to-end delivery of value for the customer. Alternatively, there is a collective of people and teams are formed within the most dynamically, see our recent article about Fast Agile.
Custom methodologies
The context of each business, in my opinion, is more specific than it might seem. Therefore, I perceive that the right approach for most organizations is to build their own methodologies and development processes. Of course, based on understanding the principles of specific agile methodologies and approaches and taking into account antipatterns. There are a lot of parameters that influence what is the appropriate approach for you and that you need to consider, e.g.
- The type of business in which you operate and your customer
- Corporate culture
- Preparedness of the organization for change
- Product and its structure
- Structure and size of the organization
- Experience with methodologies
First, name (given the current state of the world) what works for you now and what, on the contrary, creaks, and do a survey of possible approaches, calmly using AI. Start with the basics in Lean Software development, look again at the traditional approaches such as Scrum or Kanban, complement them with modern methodologies such as ShapeUp or Fast. An understanding of scaling frameworks and modern product management including The Lean Startup is also useful.
The result may be that you organize teams using the Fast approach, you want the collective to do pre-prioritization with WSJF from SAFe, and you limit the duration of the development of the features using the Appetite concept from ShapeUp. Complete this with Scrum retrospectives and limit the number of dynamic teams by limiting the amount of work done by people familiar with Kanban.
Advanced Product Management
It's still true that the biggest type of waste in software development is functionality that no one uses/pays for. Someone had to design it, develop it, test it, deploy it, support it, create documentation, and besides, it requires maintenance and increases code complexity. This is then negatively reflected in every other developed functionality.
Not only for this reason, the quality of product management and the correct determination of what the organization will develop and what, on the contrary, will not play a key role. For these decisions it is necessary:
- Have a well-grasped product vision and strategy
- Communicate vision and strategy regularly to the entire organization
- Correctly communicate with all relevant stakeholders using, for example, an outcome-based roadmap that communicates what value will be delivered; unlike traditional roadmaps that communicate output typically in the form of planned product characteristics.
- In close cooperation with development teams and designers to understand the real needs of the customer and propose suitable solutions (e.g. with the help of tools and techniques from Design Thinking, The Lean Startup and continuous product discovery)
- Effectively work with data and use it for decision-making
We recently wrote about how to support and build these things in the organization in Our article on product role development.
One backlog
Scalable agile frameworks such as LeSS or SAFe teach us that a company should have defined product priorities within a single list (backlog). Depending on the complexity of the organization, there may be more of them in practice, but their hierarchy must always be maintained — in other words, the backlog lower in the hierarchy is an approximation of the more general backlog and respects its priorities.
By adhering to this principle, you will ensure that teams in your organization are always working on what is a priority. Otherwise, when there are multiple independent backlogs, you run the risk of sub-optimization — for example, some teams may work on what they are most effective at, but what is not a priority at all.
In practice, you may be forced to hold a workshop with stakeholders to (in a good way) force them to agree on development priorities together. Furthermore, this approach will push you to build fungible feature teams. Although this is often perceived by teams with resentment (teams are specialized in one area/product/feature and other areas do not want to interfere - it would be a change/they would have to learn something), but it has a great benefit for the flexibility of development and thus the impact on the customer and business of the organization.
You can learn more about scaling agile development in our experiential workshop How to Scale Agile.
Agenti cambi
Change, change, change... is heard on every corner in today's organizations. Organizations need to change the way they operate and processes, roles and responsibilities, business models, the way product management works, support tools in development, introduce new technologies and many other areas. There are many approaches, processes and best practices to support change management, but it is always necessary that change is actively promoted and managed.
Given the amount of change in organizations (and their urgency given by the times) and the frequent overload of company leaders, it is therefore advisable to have a team of people who are dedicated to change management and have the necessary qualifications for the job. One of the options I personally recommend is to change the original Scrum-defined role of Scrum Masters to change agents.
A way in which this can actually work so that the business benefits of such a built role are visible, on in the article o redefine the role of Scrum Master.
Conclusion
Jurgen Appelo writes in his article: “Agile is falling apart... but we need to be more agile than ever without using the term.”
To achieve true agility, you need to stop thinking of agile methodologies as a comprehensive guide on how to solve a certain type of problem. It is necessary to break them down into individual principles, ideas and techniques and approach them as if a child creates from Lego — to build the best possible in terms of goals and context. But pay attention to the fundamental difference between building your methodology based on understanding principles and bending agile principles because “We are different!”