Agile for the Age of AI | Eficode (original) (raw)

Principle #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This principle can be seen as a reminder from a world where Waterfall projects could take years to complete and only after the completion were the outcomes released to the customer. We argue that the phrase “_satisfy the customer_” is problematic because it leaves much to interpretation. It is not beneficial to an organization to always respond to every customer request, especially not continuously, except in cases where the effort is a one-off, tailored delivery. This is particularly true when the organization delivers products or platform services to a wide audience of customers. Responding to every need of the customer would be financially detrimental to the organization, especially if the requested outcomes would not be aligned with the strategic goals of the organization.

The other aspect that requires further consideration in modern software development is the concept of early and continuous delivery. This depends on the organization's domain and its intended customers. Some organizations are definitely able to deliver their outcomes as quickly as possible, even several times a day. For some organizations, this is not feasible. Consider a global organization delivering a complex solution involving mechanics, software, and hardware, implemented in a globally distributed fashion, with a need to comply with strict safety standards. These organizations have a different meaning for what is early and continuous due to the fact that their releasable outcomes are large and will take a lot of time to complete. Further, the product's business logic may dictate that frequent releases are not feasible. For these organizations, an annual release cycle, for example, can be the optimal release cadence. Therefore, early and continuous delivery should focus more on an appropriate, optimal delivery cadence.

The term 'customers' nowadays does not refer only to external customers but also to internal ones. In many cases, teams deliver outcomes that benefit their organization. Here again, the size of a deliverable and the value of the outcome are the factors defining what is considered early and continuous delivery.

Given this, we conclude that this principle does not apply as such in the current product development landscape. In the context of a modern software development environment, we would rephrase this principle.

Revised principle: Our highest priority is to deliver meaningful value for our external and/or internal customers at an appropriate delivery cadence to sustain our business, and grow it aligned to our strategic objectives

Principle #2: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

This principle can be seen stemming from the rigid contractual structure and general approach of the Waterfall model. These efforts could spend considerable time identifying and elaborating on requirements, which were then frozen and contractually agreed upon. Conducting any changes in the latter phases of the effort was extremely difficult and costly. Therefore, the emphasis on embracing change, as Kent Beck put it in (2004) is understandable. The need to change is a result of learning, which is indeed the core of agile ways of working and of agility itself, but the concept of “change” needs closer examination.

The first determining factor whether a change can be made late in the development is the size and impact of the change. Small, inexpensive changes with minimal impact on the overall product can be implemented late in the project due to their low risk and low impact. Major changes with significant impacts, e.g., on schedules and fixed deadlines, should be carefully considered due to their risky and potentially very expensive nature. Therefore, whether the required change will be implemented depends on the nature of the change, the expected benefits to the customer, costs, as well as other factors, such as contractual aspects, brand, and public image-related issues, imposed on the organization.

Also, the concept “late in the development” requires scrutiny. For some organizations and application domains, even major changes are feasible very late in the effort. Consider a small start-up implementing a Minimum Viable Product for an emerging market. In this case, the organization does not necessarily have a customer base, it is not bound to deadlines, and may not have competition. This context gives it freedom and flexibility to operate as it pleases and harness it to incorporate learnings with very low risk. On the other hand, larger established organizations operating in regulated environments, facing strict deadlines and stiff competition, need to approach what “late in the development” means from a different perspective. With these organizations, changes can be costly, as mentioned above, but the time horizon for change relative to the project’s completion is considerably shorter due to the less flexible environment in which they operate. Furthermore, these companies often deliver complex solutions where decisions need to be made and locked in earlier in the project.

Therefore, it can be concluded that this principle is valid for some organizations under certain circumstances, but not all.

Lean Software Development (Poppendieck & Poppendieck, 2003) suggests the concept of Last Responsible Moment for decision-making. This concept is about setting a deadline for locking in a decision. All relevant information related to the topic is collected to reduce uncertainty as much as possible by the date of the decision at the latest. The decision is not postponed after the decided date. Larger organizations operating in this context should use this approach when dealing with change. Given our discussion on this principle and the concept of Last Responsible Moment, we revise this principle as follows:

Revised principle: We recognize that change emerges from learning, which will be beneficial for our customers and for ourselves. We welcome major changes in the effort until we agree on our Last Responsible Moment, which we communicate clearly to our stakeholders, customers, and our people.

Principle #3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

This principle is derived from the desire to deliver value to customers as quickly as possible and, therefore, enables rapid feedback and learning. As we discussed, the appropriate delivery cadence depends on the product and the industry's general expectations. From this perspective, it can be concluded that principle #1 is very closely connected with this principle. If we observe the original principle #1, focusing on early and continuous value delivery with this principle of frequent short time scale delivery, we can see that this principle, in fact, enables the first one.

It should be noted that, especially in large organizations, there are often internal customers and stakeholders who need to validate both releases and interim results. Therefore, to ensure outcomes are as intended and learning is as fast as possible, there is often both an external and an internal delivery cadence within the organization. These internal deliveries and outcomes should be validated as frequently as feasible. From this perspective, this principle is valid, but not from the viewpoint of external customers, as we discussed earlier.

Given the above-mentioned, we claim that principle #1 can, in fact, be supplemented with the key elements of principle #3. Here, we reformulate revised principle #1 with the key elements of principle #3:

Revised principle #1: “Our highest priority is to deliver meaningful value for our external and/or internal customers at an appropriate delivery cadence to enable learning, sustain our business, and grow it aligned to our strategic objectives.”

Principle #4: Business people and developers must work together daily throughout the project.

This principle highlights the importance of active collaboration between people involved in the development effort. This collaboration is required to facilitate prompt and appropriate responses to any needs that may arise. Further, it promotes transparency, which is essential for any effective decision-making. This principle can be seen stemming from the Waterfall project environment, where active interaction among the different parties involved was generally sporadic and most active at the beginning and the latter phases of the project. In addition, the original context of agile ways of working shines through here - a multidisciplinary team with end-to-end capabilities focusing on a single effort, and addressing uncertainty with close collaboration with people representing the business understanding of the project.

The definition of “business people” requires elaboration. In this original description, there is a clear division between the developers and everyone else. This might be sufficient with a single multidisciplinary team with full end-to-end capabilities operating in a small organization. However, in larger organizations, several teams operate in a complex context and collaborate with various stakeholders, including technical roles such as architects. In these cases, this simple division is not sufficient to identify the key people across the board that need to work actively together on a certain cadence.

Further, this principle states that there must be daily communication. In our experience, this is definitely justified in certain situations, such as in cases where solving e.g., challenges, or tackling significant uncertainties requires active collaboration. Extreme Programming (2004) went to extremes with this collaboration. One of its practices suggests an On-site Customer, which proposes that a customer, either external or internal, should be constantly available for the team by sharing the same workspace with them. While this approach is ideal rather than practical, close collaboration with the customer has its benefits. Research has shown that as communication and collaboration between the customer and the team decrease, misunderstandings about the supposed functionalities increase accordingly, resulting in more rework (Korkala & Maurer, 2006). While the study was conducted in the context of analysing collaboration between a customer and a team, the same logic between collaboration and the quality of outcomes applies to all collaborations.

While active collaboration has its benefits, it can also have detrimental effects. Consider a large effort involving several stakeholders from across the organization. There would be a need for some of them to work more actively with each other, but involving all of them on a daily basis, if the situation does not call for it, would be simply a waste. What needs to be agreed upon in this context is what constitutes a manageable and sufficient amount of communication and collaboration among the different stakeholders involved.

In addition, communication is a process that needs to be actively analysed and improved, which is perfectly aligned with the agile ethos of learning. Organisations need to focus on understanding how their communication and collaboration processes work, and how they could be improved.

Therefore, this principle, which illustrates active collaboration and communication among the involved parties and roles, is valid today but requires elaboration. Therefore, we rephrase it as:

People involved in an effort will communicate with each other in ways that enable them to work together effectively. Further, we actively analyse how we communicate and collaborate, and continuously strive to improve

Principle #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The small beginnings of agile show also in this principle. This principle implies that in the beginning, agile ways of working were more an experimental approach instead of a systematic approach to tackle the challenges of software development efforts, and people could be more or less hand-picked to work on such projects. Nowadays, software projects have grown immensely and require contributions from a significant number of people. Simply handpicking the most motivated people to put forth great effort can be impractical and even impossible. This principle also illustrates the empowerment of people to make the best of the project on their own by enabling them to do so. This is still essential today.

Regarding this principle, it can be said that it is still valid as such as it is today. Motivation is an important factor for success. One cannot necessarily handpick people for a project, but organizations should ensure that their employees' intrinsic motivations are met as much as possible. Some guidelines for approaching intrinsic motivation can be found, e.g., from Appelo (2016).

Principle #6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This principle illustrates the importance of fast and interactive communication between the team and the rest of the organization. The emphasis is on direct interpersonal communication rather than on sharing information through documentation, which was an established practice in Waterfall projects. Considering that agility is about timely responses to emerging situations, this principle should stand its ground. However, from a scientific perspective, this assumption does not hold. Face-to-face communication is the most effective and efficient communication medium only in certain situations. This is described through elaborating on the concepts of two prominent communication theories

Media Richness Theory (MRT) is a theory of communication suggesting that a media’s information conveyance abilities should be aligned with the needs of the task for the best possible performance. Further, this implies that certain media are better suited to conveying ambiguous or uncertain information (Daft & Lengel 1986, Daft et al. 1987). In cases where there is uncertainty (i.e. lack of information), obtaining more information about the subject is necessary, while in cases of ambiguity, there can be multiple possibly conflicting viewpoints. If information is ambiguous, the exchange of subjective views, further problem definition, and the resolution of disagreements are needed to achieve a mutual understanding of the phenomenon being communicated.

According to Media Richness Theory, ambiguous topics should be communicated through channels that promote rich communication, whereas less rich channels are more suitable for conveying standard data and well-understood messages. The richness of different communication media is characterized by four variables in MRT:

Through these parameters, face-to-face communication enables instant feedback, can convey multiple cues, offers a wide range of language, and emphasizes personal focus, thereby making it an effective medium for communicating ambiguous matters.

Media Synchronicity Theory (MST) (Dennis et al. 2008) is an extension of MRT and approaches communication through two essential processes: conveyance and convergence. Conveyance is the process of transmitting sufficient new information to enable the receiver to form and revise an understanding of the content of the information. This can be very time-consuming, and in cases where it is defective, a wrong conclusion will be reached. Convergence is aimed at shared understanding and agreement on the meaning of information and typically involves addressing small amounts of information rapidly, such as agreeing on details of a particular matter. Whereas conveyance demands large amounts of individual information processing, this burden is lower with convergence.

To engage with conveyance and convergence processes, two separate processes must occur. Information transmission involves preparing information for transmission, transmitting it through a medium, and receiving it from a medium. The second process is information processing, which involves understanding the meaning of information and integrating it into a mental model. In short, information needs to be compiled and transmitted, and then interpreted and integrated into a context. Synchronicity on its behalf is defined as “_the ability to support individuals working together at the same time following a shared pattern of coordinated behaviour_” (Dennis et al. 2008, p.576).

According to MST, using media with lower synchronicity should improve performance in conveyance processes, whereas convergence processes benefit from media with higher synchronicity (Dennis et al. 2008). Table 6 below illustrates the capabilities of different media to support synchronicity, as described by Dennis et al. (2008).

Communication media Ability to support synchronicity
Face to face high
Video conference tools high
Teleconference medium
Synchronous instant messaging medium
Email and asynchronous electronic communication low
Voice mail low
Fax low
Documents low

According to this, we should reconsider the high emphasis agile places on face-to-face communication as the single most efficient and effective form of communication. Given the high synchronicity of face-to-face communication and its intended purpose of converging on information, this is not the case. Effective convergence requires that the discussed information be concise and well understood to reduce participants' cognitive load and, ultimately, avoid misunderstandings. Therefore, face-to-face communication is effective when people are elaborating on, e.g., details related to a requirement. In cases where the amount of information is large and may not have been well understood previously, it would be beneficial to first communicate it through less rich media with limited support for synchronicity. This would enable people to understand the information, and it would then be elaborated through richer media capable of high synchronicity. Simply put, it would be more effective to send a document first and then discuss the details to fill it in. This aligns with MST's suggestion that there is no single best medium for communication. Instead, different communication media should be used simultaneously or in succession to gain the best possible outcome. (Dennis et al. 2008, Robert and Dennis 2005)

Therefore, it can be concluded that this principle, while aiming for fast feedback and resolution, is misguided from a scientific perspective and requires reformulation.

While it is beneficial for organizations to use different communication media for different purposes, it is very challenging to create rules or guidelines that apply to all organizations. This is due to differences in product size, domain, product complexity, and the knowledge and competence levels of the people. In addition, communication needs will change over time. This can be addressed through agile philosophy itself, as we discussed in the context of the original principle: daily communication between business and development.

Constant learning and adjustment are at the core of agile organizations. Organizations learn to address specific challenges and other aspects they deem relevant, including communication. Therefore, the ways of communication within and outside the organization should also be under active scrutiny.

This principle is essentially a key component of our new principle #3 and is already inherent in it, since the use of different communication media and the need to analyse their use are addressed, albeit not explicitly. This leads us to further revise the new principle #3 as follows:

Revised principle #3: People involved in an effort will communicate with each other in ways that enable them to work together effectively. Further, we actively analyze how we communicate, and continuously strive to improve.

In conclusion, the original principle #6 can be removed altogether.

Principle #7: Working software is the primary measure of progress.

This principle is the antithesis of the Waterfall development projects’ mechanism for measuring progress, mainly through intermittent deliverables that were often different documents completed by the end of each phase. We interpret the concept of “working software” in the context of this original principle as a released software increment that is usable by users. Further, this principle suggests that progress is measured by customer releases that create value for customers. This principle is indeed valid in the context of small, pure software efforts that can be released piecemeal. Progress without steering the course will lead organizations astray, so we also argue that the actual underlying goal of these small releases is to learn from them and use that information to improve.

The situation is, however, different when we are talking about large solutions with interfaces to other software and/or hardware components. With products of this magnitude, the release cycle is often long, and the released content can be significantly larger than for smaller, simpler products. Quite often, incremental customer releases are not even possible. While the principle of a working product as the primary measure of progress is important in these cases as well, the underlying need for learning and validation must be met in other ways. In practice, this is done incrementally in internal fashion.

What needs to be highlighted here is that these internal learning increments are only indicative measures of the product's usefulness. The real litmus test for value is the customer release. This release starts another learning cycle, using actual data to inform adjustments to outcomes and better meet customer expectations.

Based on the above, we noticed that this original principle is both valid and impractical in the context of modern product development, depending on the product's scope and context. What, however, is common with both cases is the importance of the underlying need for learning. This led us to refine this principle to incorporate it explicitly. We recognize the still-valid notion of measuring progress through actual deliveries, but wish to emphasize that delivering on it may take a long time, depending on the context. In these cases, the partial incremental, internally validated implementations of the product play a key role in determining the validity of these outcomes - this is the all-important learning aspect of the work.

Hence, we propose our revised principle recognizing both of these aspects - progress and learning.

Revised principle #5: Working product is the primary measure of progress; implemented increment is the primary measure of learning.

Principle #8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This principle puts people and their well-being at the forefront. This principle was made more concrete by Kent Beck (2004), who defined “40-hour week” as one of the key practices of Extreme Programming. It is well recognized that constant overtime work is detrimental to people’s health and well-being and ultimately productivity. Therefore, this principle is a prime example of agile being a people-centric development and work philosophy.

Following this principle requires that the organization focus on three aspects of agile: value, limiting the amount of work in progress, and the concept of slack (or reserve time). A clear understanding of value (what needs to be implemented) will ensure that the effort is focused on achieving the essential goals. This is essentially effective prioritization. Further, this focus will, in itself, limit the amount of work in progress, since it provides clear guidance on what must be completed within a limited capacity. Limiting the number of concurrent tasks further focuses on completing tasks rather than starting them. This focus on completing what is most important will reduce the overall workload over any given period. Slack, in this case, is not synonymous with slacking; instead, it is a concept of reserving a certain portion of work time (e.g., 10-30%) for unallocated work-time. This reserve is for addressing any emerging situations that may arise without jeopardizing the anticipated outcomes.

Unfortunately, utilizing these concepts is uncommon in most of the organizations we have worked with. Organizations tend to systematically overload their development teams and plan for 100% utilization rates to ensure productivity. This is in fact counter-productive. Consider a situation where a team works at 100% allocated capacity, with no room to maneuver, on 20 features and completes none, compared to a team that follows this principle, focusing on completing effectively prioritized tasks with adequate room to respond to related aspects. The latter team completes 5 out of 10 features. While this is not likely to be a stellar performance, which team was actually more productive? The first one certainly progressed further, with a larger number of tasks, and can be seen as more productive from this perspective. However, they did not complete anything of value, since it cannot be realized until it is verified. Hence, it can also be claimed that their productivity was zero from a value perspective as well. The second team is the “winner” in this case.

Considering this principle, it is definitelyas essential a cornerstone of agile as it was over two decades ago. Organizations need to start seeing their underlying structure as essential to effective, productive operations and change their practices and mindsets accordingly, despite it being a long, laborious process.

In summary, this principle is valid as it is today.

Principle #9: Continuous attention to technical excellence and good design enhances agility.

The key concept behind this principle is that technically sound, high-quality implementation and design by highly skilled experts will create a technological foundation for a system that allows easy additions and modifications. This will enable fast, high-quality implementation of emerging needs, compared to poorly designed software riddled with “spaghetti code” and quick fixes. This principle, in itself, debunks a stubborn myth prevalent for over two decades about neglecting the appropriate initial design of the system and its architecture. This thinking stems from the misconception that agile does not require appropriate planning and scope definition, driven by its misunderstood concept of flexibility that we discussed earlier.

Further, this principle emphasizes high-quality outcomes. The fewer defects there are in the code, the less there will be time and resources will be consumed by rework, and in the end, technical debt that needs to be paid back at some point. Modern software tools enable people working with the software to validate its quality in real time from multiple perspectives, and one cannot emphasize their appropriate use enough. In addition, Internal Developer Platforms (IDPs) will significantly contribute to high-quality outcomes. IDPs are collections of technologies and tools that developers can utilize effectively, as they provide self-service capabilities for tasks such as deployment, configuration, rollbacks, and provisioning. This enables developers to focus on their essential tasks instead of dealing with the complexities of obtaining these services through the IT department, for example. This improved focus on what really matters will enhance agility by enabling faster responses to emergent issues. A selection of IDPs can be found, e.g., from here. (NOTE: we DO NOT personally endorse any single platform over another. Selecting an IDP depends on the organization and its needs).

Therefore,this principle is as valid as it is today.

Principle #10: Simplicity — the art of maximizing the amount of work not done — is essential.

This principle illustrates the importance of focusing on value from both the product side and the ways the organization creates and delivers it. From the product side, a simple example of striving for simplicity is to implement only what is clearly valuable. Featuritis is a phenomenon characterized by a constant increase in features, driven by various factors. Poor sales or perceived product quality may lead to compensating for its defectiveness by adding features that are hoped to increase adoption and sales. On the other hand, Featuritis is driven by advanced users who request additional features to meet their specific needs, and these requests are often accepted, although they address only a small portion of the user base and do not necessarily yield justified revenue. No matter the reason for this feature creep, it will increase the product's complexity, making future additions and maintenance more difficult. Understanding the value of any feature and implementing only those that should be is therefore of paramount importance for an organization. It is always a good reminder to recognize that one customer is not a market.

Simplicity is paramount, also from the process side. We have already discussed how agile ways of working need to replace existing ways of working rather than complement or expand them. Since agile emphasizes people and their ability to make sound decisions, minimal control and coordination mechanisms are important for ensuring rapid response to changes and other emergent situations.

Given this, this principle is valid as it is today.

Principle #11: The best architectures, requirements, and designs emerge from self-organizing teams.

The humble origins of agile ways of working are again illustrated by this principle. As we discussed earlier, having a hand-picked team of highly experienced professionals capable of taking full end-to-end responsibility for (relatively small) outcomes is something that modern large organizations can very rarely do. Furthermore, what self-organization in the context of agility means is that every team member should be able to work on any task the team needs to complete. This would require that team members have a profound understanding of all the fields involved in the effort. Given the nature of large modern software development efforts, this requirement would be almost impossible to meet.

To implement this principle by the book would require teams with dedicated architects, who are often responsible for managing a very large and complex collection of software that serves as the basis for all software-related work within the organization. This is especially true for established organizations that offer an extensive suite of solutions to the market. What we have witnessed in these kinds of organizations is that architects are more of a shared profession that works on both the system's existing complex architecture and support teams when required. What makes their work hard to share is the immense expertise and knowledge of the system, which is very hard to disseminate within the organization, and the sheer number of products the organization provides. Dedicating these professionals to a team (or even a few teams) would create severe problems for the organization.

Understanding requirements and defining them requires an acute understanding of the organization’s strategy, goals, business targets, customer base, and markets. Simply put, the people defining requirements must understand the business the organization is in, what it wants to achieve, and how it will achieve it. In agile literature, this responsibility falls on the Product Owner, who must also be actively involved in supporting the team in their daily work. While the person working as a Product Owner may well possess all the required competencies and capabilities for this role, the burden can quickly become too much. Therefore, organizations separate the more strategic and operative responsibilities between, e.g., Product Managers and Product Owners. In this division, the Product Owner would be responsible for more operational aspects of the work, while still working very closely with the Product Manager, who is accountable for, e.g., stakeholder management, product vision and strategy, roadmaps, and financial goals and targets. In today’s organizations, Product Managers can be accountable for a host of products, which, as in the case of architects, would make them shared professionals for a multitude of teams. Having a dedicated Product Manager per team would rarely be a feasible alternative.

Further, designing complex solutions from both technical and user experience perspectives requires very strong expertise. Modern, complex software products can include many features and several ways for users to achieve their intended goals. Designing the system that enables this effectively requires a solid understanding of both the problem the user is solving with the software and the best way for them to do so. Further, this design needs to account for the user's possible limitations and incorporate accessibility aspects into the system's design. Effective user experience design requires a deep understanding of the subject matter, which makes UX experts again a shared expertise in organizations. Having dedicated UX experts for each team would require significant investments from organizations, making this approach often unrealistic.

While self-organization, as seen from the original agile perspective, is extremely difficult to achieve, it remains an important concept for any organization to implement. We define it as follows:

The ability to decide with appropriate independence, how one is going to achieve the intended outcomes a way that is seen as most natural and best

This definition states that anyone in an organization can be a decision-maker under well-understood, agreed-upon contexts. It also emphasises the importance of collaboration between involved experts and participants to achieve outcomes in the most effective way possible, since teams often require an immense amount of expertise beyond their own to reach their goals. This definition emphasizes trusting people’s capabilities in their work and decision-making and represents a clear step away from command-and-control structures, which stifle decision-making and slow down the organization. In agile organizations, self-organization and empowerment are key ingredients in making the organization agile.

Given the above mention, principle #11 would be valid only in very marginal cases where teams have all the required expertise. Therefore, it is feasible to refine this principle to better align with the current context, where agile ways of working are used.

Revised principle: Our people are the best experts on finding the ways to achieve what they need to achieve. We empower our people with appropriate decision-making rights to enable timely responses and the resolution of emerging matters, and to accelerate development flow.

Principle #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This principle, once again, underscores agile's small-team-centric origins by explicitly stating that active learning and improvement occur at the team level. This is problematic for organizations, as it effectively leaves out the crucial learning aspect involving the entire organization. Teams should, of course, learn and adapt, but if learning occurs only at this level, the benefits would be minuscule and have little impact on the organization's overall performance. The following image highlights both where the original Agile Manifesto stressed the importance of reflection and learning, as well as the other crucial aspects to improve in the context of product development.

Agility-manifesto-focuses-on-sprints

Agility manifesto focuses on sprints

Image 1: The focus of reflection and learning in the original Agile Manifesto, and other areas of product development, requires active learning and adjustment.

While the abovementioned example is hypothetical, it illustrates that organizations need to reflect and adjust their work at multiple levels, and that modern agility should explicitly address this. As in Lean, the focus of improvement is explicitly on the whole, and this must involve agile ways of working to achieve the best possible outcomes, considering both the products and the organization itself.

Thus, it can be concluded that this principle is not valid in the modern context of agile development due to its narrow focus.

Considering the narrow focus of principle #12, it needs to be expanded to involve the whole organization. Therefore, we revise this principle as follows:

Revised principle: At appropriate intervals, the organisation reflects on how it can improve strategic as well as operative aspects of its work to sustain and improve its operations and position on the market

This involves everything from company strategy to product strategy to roadmaps and backlogs to the ways of working within individual teams. This improvement aspect also includes the organization's other functions, the mechanisms it interacts with, and how these need to be improved. Further, collaboration and ways of working with external partners are regularly studied and improved.