I started my agile journey twenty years ago. At the time, I was a Java programmer and a UML modeler, and I lucked into working in an XP team.

Joining an experienced XP team was uncomfortable at first. The practices were very different from what I was used to. Kent Beck’s book Extreme Programming Explained was a great start to my agile journey, and it helped me to make sense of the practices of my first agile experience on an XP team.

Agile Manifesto for software development was articulated in 2001 by authors who shared 

“a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work.” – History of Agile Manifesto.

Accompanying the Agile Manifesto is a set of 12 principles.

Principles come from practice.

Before we dive into these principles, let’s consider what it means to have principles.

“[principles] can be applied again and again in similar situations to help you achieve your goals…Without principles, we would be forced to react to all the things life throws at us individually as if we experienced each of them for the first time…having a good set of principles is like having a good collection of recipes for success.” – Principles, book by Ray Dalio

In his book Life & Work Principles, Ray Dalio uses the following picture to describe how he learned his principles.

“I learned my principles over a lifetime of making a lot of mistakes and spending a lot of time reflecting on them.” – Ray Dalio.

As independent thinkers and practitioners, the authors of the Agile Manifesto represented various approaches such as Extreme Programming, Scrum, Crystal, etc. They chose to express the opening statement of the Agile Manifesto as follows:

“We are uncovering better ways of developing software by doing it and helping others to do it. Through this work we have come to value:” – The Agile Manifesto.

The emphasis is on learning by doing. We have to act our way into being. And this requires humility to acknowledge mistakes and the courage to reflect honestly. So a new attempt can be made to solve a similar problem until a principle that improves chances for success distills from practice. This is challenging work. The authors’ efforts were not just in the two days they were in Snowbird, Utah, but a distillation of decades of experience into a set of values and principles.

The Audacious goal they collectively pursued was to promote organizational models based on people and collaboration they would want to work in. This goal has inspired thousands of practitioners to take on the Agile journey.

The power of principles enables you to benefit from the experience of others who have encountered similar situations. And over the last 20+ years, practitioners have built upon the foundational 12 Agile principles to inform next-level trials (experiments) & trails.

For example, 

Craig Larman and Bas Vodde published their work in three books

• Scaling Lean & Agile Development [2008]
• Practices or Scaling Lean & Agile Development [2010]
• Large-Scale Scrum: More with LeSS [2016]

Their learnings with the application of Lean and Agile principles led to the development of  De-Scaling Principles: https://less.works/less/principles

Jez Humble and Dave Farley published their build, test, and deployment automation practices in the book Continuous Delivery [2010], laying the foundations for the DevOps movement. The movement’s learnings are captured in the principles of continuous delivery: https://continuousdelivery.com/principles/

You see how it works. Principles enable others to navigate challenging situations, creating space to challenge boundaries and pursue more audacious goals. The fruits of their successes are shared as an additional principle for the new problems that lie beyond the frontier. It is a virtuous cycle.

On the other hand, if the people involved do not operate on shared values and principles, they keep getting caught up in the same problems as before and fail to evolve.

“People who have shared values and principles get along. People who don’t will suffer through constant misunderstandings and conflicts” – Ray Dalio.

agile is an attitude

Alistair Cockburn, Agile Manifesto signatory

An individual, a team, an organization, a project, a program, or a product can position itself to “be agile.”  Agile’s strength is its values and principles that enable it to transcend boundaries. Not a technique but an attitude to respond in a characteristic way.

“In order to succeed in the new economy, to move aggressively…. companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies.” – History of Agile.

Organizational systems get stuck in set routines because people are creatures of habit. Maintaining an Agile attitude requires leaders who can exercise independent thinking and empathically challenge the status quo.

The Agile movement, in its early days, was referred to as being “mushy” or ”rose-tinted.” And to the larger community’s credit, we embraced the fact that we are about people and culture. This was not because we were naive but because it was a fight worth having.

“It has been remarked by a wise man that he who wrestles with a hog must expect to be spattered with filth, whether he is vanquished or not. This maxim I have long known and appreciated; nevertheless, there are occasions when it must be disregarded. A man may be attacked in such a way that he is compelled to flagellate his hogship, even at the risk of being contaminated by the unclean beast.” – Source

The agile movement’s weakness also stems from its values and principles-based approach. This is because people need practices to act their way into independent thinking. People with positive experiences with agile methods engage further to understand the principles. In contrast, people with negative experiences with agile practices develop a cynical disposition. There are ample Dilbert comic strips on the agile theater (in name only).

Currently, the Agile movement is at a precipice. Becoming muddy, sometimes referred to as the Agile Industrial Complex. Whether the Agile movement will vanquish the industrialized projects factory ‘hog’ remains to be seen. The most important thing to remember is that implementing or “doing” practices means nothing if the attitude is not set right.

Understanding Agile Manifesto Principles

Maintaining the Agile attitude requires a sense of balance. The Agile Manifesto frames its values as left over right and concludes that while there is value in items on the right, we value the items on the left more. Maintaining the Agile attitude requires situational awareness to pursue the audacious goal of steering away from becoming Dilbertesque bureaucratic order-taking organizations. For the rest of the article, we will refer to these organizations as Not-agile. We will better understand Agile principles in light of the problems it helps solve.

I will also share links to resources and short notes that may help your agile journey by implementing these principles. I do not intend to be comprehensive in my list. I want to share some starting points so you can reset or begin your agile journey. With mindful practice, I hope you appreciate the depth and wisdom embedded in the Agile Manifesto principles.

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

Not-agile organizations don’t satisfy their customers with software delivery. Their lack of understanding of their customer leads to implementing solutions that either don’t work or make the customer’s job harder to do. Users resist software upgrades because adopting the new is more expensive than doing the same. This could be because of the prohibitive costs of retraining staff or the fear of uncertainty with the new.

Your customers have a job to do. They’ll get’er done. The trust you get depends on whether you get in the way or make it a tad bit easier to get’em through the day. It’s that simple; nothing more to it. The longer you hold off on solving their problems, the less they look to you for help.

The shift in attitude is to accept that perfect is the enemy of good enough. It is impossible to get it right the first time. You will have to iterate. And you will learn faster about what satisfies your customers when they collaborate with you. 

Can you trust your understanding of the user’s needs and implement a solution the organization can support and maintain going forward?

Resource links:

• Speedboat/Sailboat Innovation game
• Minimum Marketable Feature (MMF)
• User story mapping technique
• Continuous Delivery : Get changes of all types into production or the hands of users safely and quickly in a sustainable way.
• Feature toggles (flags)

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Not-agile organizations want to manage change. They don’t like to welcome it. They believe that you cannot handle things that you cannot control. Therefore, changes require approval processes and committee reviews. They actively pursue stability. The change control board approves changes. 

In Not-agile organizations, builders and planners have invested too much effort in scheduling all the work to fill their capacity. Any deviations from ‘the plan’ will incur significant adjustment penalties impacting other projects. They have optimized for utilization and, as a result, have too much going on simultaneously. They are set up to give customers what they may no longer want for cheap.

Agile organizations are playing a different game. If the customer is going to change their mind, then let’s hear it sooner rather than later. This way, we can do something about it and collaboratively shape the solution together. 

Welcome! Change, not just accommodate it or tolerate it. The processes in agile organizations are set up to allow for requirement changes. They do not play the requirements as a contract game. Instead, they treat customer requirements as conversation starters to engage in a collaborative exploration of actual needs. 

The shift in attitude is towards embracing uncertainty. Instead of insulating from changes, learn to find opportunities from them. If you want to be agile, actively pursue variability, not predictability. At the very least, don’t let these change requests hang in limbo. Decide to prioritize. If you are wrong, the change will come knocking harder; this time, you may prioritize it higher or pivot. 

Resource links:

• Healthy Product backlogs
• Cost of delay & classes of service
• Harmful misconceptions about Product Owner.

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

Not-agile organizations cannot design, develop, integrate, and test a new increment every two weeks or months. Instead, they engage in big-upfront requirements gathering, big-upfront design efforts documenting their solutions in detail. These efforts yield tomes and go on for months/years. The rubber finally meets the road when they reach the development and test phase. And soon, they discover that the software does not work for its users.

Delivering software that works for your customers in less than two months is technically feasible. Many organizations do daily releases at scale. For both greenfield and brownfield efforts. Techniques & technologies to do this have been in practice for decades now. 

The shift in attitude is towards embracing a growth mindset. What capabilities do you need to deliver fully integrated, tested, working software in shorter timescales?

Let the pain guide your way. Negative feedback loops put your skin in the game, generating the impetus for change. Agile approaches (XP, Scrum, FDD, etc.) are learning systems that deliver small doses of pain early and often so you do something about it. Because if you don’t address these risks before, they accumulate into a blow-up.

Cultures built on foundations of trust engage in learning from failures, whereas cultures of fear engage in cover-ups with pretty PowerPoint presentations. Fundamentally, do you trust your ability to learn and grow:  your people, organization systems, and products?

Resource links:

• Test Driven Development : Eliminate fear in application development, learn to communicate, and encourage learning.
• Continuous integration : It is about the behavior of team members who integrate continuously (daily or hourly) and not about the tool or server you use. You can even do it on a dollar a day with a rubber chicken
• Definition of Done
• Definition of done and undone work

Business people and developers must work together daily throughout the project.

In Not-agile organizations, everyone is busy. People are knowledgeable and helpful, but getting time on their calendars is difficult. There is just too much going on. 

In Not-agile organizations, the business and IT consulting each other or collaborating on problems to solve does not occur at the work level. Instead, managers of managers, who are a few steps removed from the situation, discuss and decide. Decisions made at higher levels negatively impact both the business and IT workers.

Business managers choose to optimize their local department efficiencies and generate all requirements upfront and in isolation. The IT managers optimize locally for developer productivity and develop big-bang code release packages. During the User Acceptance Test (UAT) phase, the Business vs. IT divide finally gets revealed. This gap manifests as a long list of change requests (CRs) that get hotly debated as relationships further deteriorate between the two. Trapped in the local optimization mindset, the business looks for better ways to “write” requirements, and IT looks for better “tools” to develop releases. 

When businesses and developers work separately, they keep pushing the overloaded burden back and forth. This dynamic plays out at all scales: task, story, feature, project, and program. 

The theory of Constraints will inform you that any process will have one or more bottlenecks. And when you unblock one blockage, you will discover the next bottleneck. And so on. It is always a shifting concern. Local optimization means that people involved in that process will push their workload without regard for the downstream effect on others.  

The attitude shift is to optimize the whole value chain, from specifications to delivery. When business people and developers work together, they can build a mutual understanding of managing expectations and deliveries. The more closely the two groups work, the better the flow of value through the organization to its customers. 

Resource links & tips:

• Recognizing bottlenecks
• Ubiquitous language 
• Card, Conversation, Confirmation 
• Specifications by example or Acceptance test-driven development (A-TDD) 
• Set up Visual Management systems (Kanban boards) to develop a shared understanding of the state of work items from discovery to delivery. From sponsors to users to developers in a single self-management system. This is not a dashboard.

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

The fundamental attribution error is a logical fallacy where we underrate the influence of circumstances and how they can impact people’s behavior.

The attitude shift is to first investigate the organizational/project environment for demotivating factors, lack of adequate support, or trust in the people doing the job. Do not blame individuals or their personalities if any of these is lacking.

If a project is not going well or you want to set a project up for success, ensure that people are motivated and have support and trust from the organization.

Applying this principle requires management awareness of demotivating factors within your environment. Not trusting people to do their jobs manifests as micro-managing and blaming them for not performing according to management expectations. 

Often, individuals who are asked to multi-task on many concurrent projects are overloaded with the task load, the coordination overhead, and by stakeholders who want status updates on their requests. Lack of control in managing their day-to-day leads to demotivation. This is a Push system where workers have no control over their work day. 

This principle invites the management to reflect on human motivation factors in their organization and make changes to create conditions for trust by offering needed support to people working on projects.

Resource links & tips:

• Niko-Niko calendar
• Instead of allocating fractional resources to projects, bring projects to a fully dedicated team. Long-term stable teams with all the skills necessary to get the job done learn to hold each other accountable, can depend on each other, and work through challenging projects.
• Collaboratively develop a project charter
• If your team implements the Scrum framework, then ensure that the Scrum Master is empowered to identify and cause the removal of impediments. Through their service, they engender a motivated work environment.
• Five-Why’s technique
• Management practices “Gemba” (go see) to develop first-hand awareness of challenges. Instead of focusing on metrics and dashboards akin to watching the scoreboard, they actively learn how the game of development gets played. This gives them direct awareness of the support needed by the people doing the work.

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

Not-agile organizations trust their processes but not their people. I recall early in my career working as a programmer when I was prevented from conversing with the customer because it was someone else’s job to manage communications. Playing that telephone game took us four days to resolve a simple query that could have been addressed in a 10-minute conversation.

The attitudinal shift lies in recognizing that when we can see and converse with each other, we can convey much more information quickly. The act of development requires constant back and forth between the builders to negotiate trade-offs in planning and implementing task efforts. The quality of collaboration improves more rapidly through face-to-face conversations than via process documents and emails.

In Not-agile organizations, expectations are conveyed via emails or one-way communication channels. This project must be delivered on <date>. Or Send me your update—no chance for dialogue, just an order to comply with. Communication with the development team flows through a faceless document/committee decision or sound bites from a hallway conversation. This is demotivating.

The required management attitudinal shift is to engage in bi-directional communication with the development team. This allows the management to hear what they have to say and engage in collaboratively problem-solving.

Resource links & tips:

• In virtual development teams, video conferencing tools can enable face-to-face conversations. And if there are still communication gaps or more significant problems to solve, you’d look to bring the development together in the same physical space for a few days. 
• 15 min daily syncs: Development team members synchronize daily through face-to-face sync meetings to share project-related information. If you are implementing the Scrum framework, a Daily Scrum enables developers to review progress against their Sprint Goal.
• Just talk: Any member of any development team is able and expected to reach out to a member of another team to discuss an issue. No need to get permission. Get up and talk to people. This practice comes from LeSS and enables decentralized coordination.
• I am a strong advocate for Amazon’s documentation culture. At Amazon, meetings require written memos. The first 10-15 minutes are reserved for reading together, followed by 30-40 minutes of Q&A. A go/no-go decision is then taken or postponed.
• Pair programming
• Mob Programming : “All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer”

Working software is the primary measure of progress.

Not-agile organizations treat estimates (guesses) as commitments and then spend significant energy comparing the actuals versus the plans. They invest in complicated dashboards that measure progress with sophisticated stupidity – everyone knows it’s a myth. In trustless cultures, no one can call out that the emperor has no clothes. 

I once met a so-called agile team that a popular agile team assessment tool assessed to be 96% agile. They missed being 100% “Agile” because they had not delivered working software in over a year! 

Results matter. How you get there matters even more. Abstractions and dashboards that provide the illusion of progress are comforting, but these don’t work. And the path that leads you on the journey of comparisons & assessments does not end with the results you seek. Don’t get distracted in cargo-cult rituals that end up disappointing. 

If you want to get better at delivering working software, get better at delivering working software. Measure how frequently you ship software and whether it works for your customers. Learn from it and move on. Any secondary measures that you track and monitor have to lead you to get a better understanding of improving on your primary measure of progress: working software. 

A literal interpretation of this principle can lead you astray.

The shift in attitude this principle calls for is how thinly you can slice to deliver working software to your customers quickly. So you can validate whether you are headed in the right direction. The proof is in the pudding. And all other measures disappear when customers build trust in your ability to deliver software that works for them frequently. And trust is built upon experience.

Resource links & tips:

• A Metric leading to agility 
• INVEST in good stories 
• Elephant Carpaccio exercise 
• Walk the dog technique
• Story splitting patterns

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

This principle is a helpful test of an organization’s attitude towards uncertainty. 

Not-agile organizations Jekyll & Hyde through their existence. The terror of upsetting executives, missing deadlines, and career implications punctuates spells of tranquility and familial camaraderie. People work long hours and ‘stretch’ themselves to meet project objectives. And the cycle repeats itself. Organizations that fail to create sustainable work environments experience higher attrition rates and spend more on re-training new staff, which becomes increasingly difficult to attract.

Stressful work cultures negatively impact your health and personal relationships, which will outlast any triumph you or your manager experiences in meeting executive or market expectations. So be kind to yourself.

Every organization experiences challenges that require an immediate response. If your data center is on fire, you will need all hands on deck at whatever hour to save your assets. Sustainable does not mean that we let the barn burn to the ground. Promoting sustainable development means that we will not actively set fire to the barn and then demand heroic rescues.

In Not-agile organizations, sponsors, developers, and users rarely collaborate. They are siloed into separate functional groups, transferring risks from one silo into another. A game of hot potato until the music stops. For example, a scenario that often plays out goes as follows: 

The Sponsors make commitments and secure a budget from the company Board. The sponsors then set objectives for business users to deliver successful outcomes. The business users, mostly busy running shop, gather their requirements and send them to the developers. The developers, who are also mostly busy cutting code, make assumptions and misunderstand user needs. The business complains that IT did not deliver, the IT complains that the business doesn’t know what they want, and the sponsors look for somebody to blame.

Here is a tip! Stop calling people resources. Instead of saying, “The project resources will have to work late,” practice saying, “Tom, Arun, Sheila, and Jenny will have to work late.” 

Notice the attitudinal shift? – Discussing real people with names and faces makes us acknowledge their humanity, not just their functional use in the borg. Overcoming challenges through brute force only works for a while, and then the brute breaks. 

This Agile principle gives us the earliest detection mechanism for built-up risk. 

When people start to work harder and longer, they need to work smarter. If the developers are working harder to deliver on all ‘the scope,’ then the users need to collaborate with developers to simplify their requirements. The sponsors need to enable the two to deliver the best possible business outcomes under the circumstances. This is risk management, and the constant pace indefinitely sets a clear boundary to know when to work smarter, not harder. 

The shift towards promoting shared collaborative problem-solving involving sponsors, developers, and users leads to sustainability.

Resource links & tips:

• The Mythical Man-Month 
• Slack : Getting past burnout, Busywork, and the myth of total efficiency.
• If you use Scrum, involve your users and sponsors in your Sprint Planning and Sprint Review events. Refine your product backlog with your users.
• Set up Work in progress (WIP) limits to manage the flow of work as it progresses through various stages. When work overflows your WIP limit, you get the early signal of risk building up. WIP is one way to express ‘constant pace’ as a measure.

Continuous attention to technical excellence and good design enhances agility.

Not-agile plan-driven organizations trade-off on software quality and compromise on the quality of life of people working on the project to meet planned date, budget, and scope expectations. Inspection of quality happens in later phases as a check before delivery to users. Not-agile organizations often run out of time to build it well but spend a lot of time fixing it later. Lack of agreement in standards and poor stability of their codebase makes it challenging to adapt to changes in requirements. 

Agile organizations know that quality emerges from what you put care into, not from what you have cared to check for. 

Increases in the quality of software speed up project deliveries. Agile organizations do not consider quality a control variable that can be dialed down to meet planned expectations. Agile practitioners pride themselves in their craftsmanship and believe in shared standards to hold each other accountable. The stability of their codebase preserves the optionality for the agile organization to adapt to changes quickly.

The attitude shift is towards built-in quality instead of inspecting for quality later on. The longer it takes to find issues with the codebase, the longer it will take to fix it. Software’s malleability makes it easy to mess with. A messy codebase makes developers fearful of change. Good design, discipline in engineering practices, and pushing for improvement in shared standards increase confidence to make changes and recover from mistakes.

The degree to which you can be excel technically depends on many factors. One thing is for sure, the thinking and practices that got you into the mess will not get you out of it. 

Resource links & tips:

• Clean Code: A Handbook of Agile Software Craftsmanship
• Working Effectively with legacy code
• Refactoring: Improving the design of existing code
• Agile version control
• Agile Source code management for teams

Simplicity–the art of maximizing the amount of work not done–is essential.

Not-agile organizations believe in economies of scale when it comes to software development. They want to get the most output from their investment in software. Because of this, they package all their required and anticipated needs & wants into a large batch of specifications so they can get it all in one large contract. This often leads to over-engineered solutions that have many unnecessary features/functions. The complicatedness of their software makes it difficult to add incremental enhancements. They try to save a nickel and lose a dime.

Agile organization’s bias towards simplicity. They look to meet today’s customer needs by doing their elegant best to build the simplest thing that could work. This is challenging work. And it requires a deep understanding of the customer problem and the technological systems. 

Over time with added features/functions, all solutions tend to increase complexity. But as soon as a simplified abstraction or interface becomes apparent, they prioritize bringing product complexity down. This keeps their solutions elegant and simplifies future work. It is easier and quicker to add incremental enhancements.

The shift in attitude is to make solutions as simple as possible, not simplistic. 

Resource links & tips:

• Yagni 
• Stop starting, start finishing
• Refactoring
• System Metaphor 

The best architectures, requirements, and designs emerge from self-organizing teams.

Not-agile organizations have specialist functional silos for requirements, designs, and architecture. The overriding belief is that the result will be better when experts focus on their areas of expertise and generalists on implementation details. 

In Not-agile organizations, architects chart the technology runways with blueprints, frameworks, and technologies to use. Requirements specialists work with users to gather their needs and document user experiences and journeys. Design specialists pull it together to lay out the technical specifications for generalists (developers & testers) to implement. Once finalized, the underlying assumption is that requirements, design, and architecture will remain static.

Software is nothing like building bridges or buildings or offshore rigs. Software is malleable. And the primary concern is to architect & design for changeability, not finality. As the users use your software, they will discover what they need. As the developers build the product, they discover how to make it. Users’ needs and developers’ ability to build influence each other, and from this dynamic, the actual requirements, design, and architecture emerge.

The shift in attitude is towards the collaborative realization of the working software, not in creating specialist documentation. This means that specialists are accountable for developing shared understanding, not documentation.

Resource links & tips:

• Walking Skeleton
• Design workshops with agile modeling
• Spike
• This short video from Nordstrom innovation labs is a window into the agile team collaborative dynamic.

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

Not-agile organizations lack the courage to take corrective action. Hesitation sets in because people are unsure whether others also experience the problems they see. The proverbial elephant in the room is not openly discussed. Each person independently assesses the situation and acts to protect their interests. Shared learning does not happen because discussions are primarily superficial, and people take a defensive stance, often forming cliques along departmental boundaries and tossing blame each others way. Fear and lack of trust characterize organizations that do not show courage in learning and growing.

Agile organizations accept the current reality for what it is. The retrospective prime directive beautifully captures the essence of their stance. 

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” –Norm Kerth, Project Retrospectives: A Handbook for Team Review

Trust is given by default because agile organizations know not to fall into the trap of the fundamental attribution error. This takes a lot of courage. Sharing your thinking and actions while maintaining openness to learn about other’s perceptions of your activities is challenging. Acknowledging discrepancies in each person’s work style preferences without judgment and developing working patterns so the whole is greater than the sum of the parts takes effort. It is not easy, but the retrospective process can be fun if you are willing to learn. 

The shift in attitude is about enabling learning at all organizational levels. From the C-level group to the agile development team. From inspecting and adapting on project team-level behaviors to inspecting and adapting on organizations’ policies, structures, and mechanisms. How agile can you be? 

Resource links & tips:

• Project Retrospectives
• Agile Retrospectives
• Facilitators guide to participatory decision making
• Overall Retrospectives
• Learning together as a team
• Sharing values, a team building exercise

More audacious goals

Not-agile organizations are Talyorist industrial projects factories. Independent thinking gets stamped out of people there. The lack of agency afforded to people at all levels is disempowering and turns these organizations into bureaucratic machines. Effective at doing what it is programmed to do but unable to learn and grow. 

Not-agile organizations cannot be persuaded into agility by alerting them to existential threats from more nimble, aggressive, trust-based people organizations. Alarmist tactics only trigger defensive fear response mechanisms. In their flight to safety, they seek complicated all-encompassing frameworks because bureaucrats only know how to impress other bureaucrats. A delightful parody of this phenomenon is  L.A.F.A.B.L.E.

A craftsman, on the other hand, strives to impress their customer. In an increasingly globalized and digital marketplace, craftsmanship is required at all levels, from C-level executives to programmers. Artisans have traditionally shared their wisdom with other artisans as a rule of thumb. Principles are shared amongst skilled practitioners to push the state of the art. A rule of thumb also assists apprentices in being mindful in their practice. As they slowly develop mastery through practice, they realize the wisdom packed into the principle as a recipe for success.

The Agile Manifesto is a call to action toward creating trust-based collaborative organizations. If that is also your mission, then the Agile Manifesto values and principles are an excellent guide to your journey.

To close this article, here is a quote from Ray Dalio’s excellent book, Principles.

“Evolve or die: […] The key is to fail, learn, and improve quickly. If you’re constantly learning and improving, your evolutionary process will look like the one that’s ascending.”