As many individuals and organizations that have lived and breathed in the agile community will tell you, there is not a “silver bullet” for adopting agile within your organization. That is to say, there is not a single “right way” that solves everything. Organizations have varying nuances between (and even within) them, from various goals, objectives and processes, to entirely different team dynamics and culture. Prescribing a process for a large organization to adopt and expecting all organizations to adhere to it is next to impossible. With that being said, against other people’s argument, I WILL say that there is a right way to agile.

Organizations lose focus on the principles behind agile, the Twelve Principles of Agile Software (Twelve Principles). When organizations lose focus (or never had focus) on their goals and principles, it becomes easy to blame the people within an organization, adoption of a new process, or say it just doesn’t work for their organization for other various reasons. I would challenge these organizations to ask themselves what are the goals and principles they are focused on while implementing agile. Is it to check a box? Is it because other organizations in their industry say it’s the best way to do things? The questions continue, but the real question is, did I implement agile and take to heart the Agile Manifesto and Twelve Principles?

The Agile Manifesto was written in 2001 at a summit of independent practitioners of various programming methodologies. Agilealliance.org says “The participants didn’t agree about much, but they found consensus around four main values.” You can read about the Agile Manifesto more here, however I would prefer to focus on The Twelve Principles of Agile Software.

You can read all Twelve Principles of Agile Software, and some of these obviously require interpretation for your specific organization, but there are a few worth focusing on that I believe are at the core and should be taken with the utmost respect.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
This should be the goal of any organization that has a technical software component. Most organizations fall into this category and it does not take much to argue that when you are able to deliver valuable software early and continuously to your customers, the result is higher customer satisfaction.

“Welcome changing requirements, even late in development. Agile processes harness change for customer’s competitive advantage.”
In the past, as a software engineer, having someone come to you and ask you to change something halfway through building it would cause abrasion between the teams. The developer thinks: “Does this business stakeholder really know what they want?” and the business stakeholder would think: “Why does it take so long for a change to even happen?” and thus opposing forces in the development process are created. Business always pushing for new features and changes and developers asking for clearer roadmaps and vision. Development teams embracing change and understanding the business value of those changes increase their investment in the overall process and desire to see a positive outcome.

“Simplicity – the art of maximizing the amount of work NOT done – is essential.”
Organizations are deathly afraid of refactoring software. There is often a large cost associated with refactoring poorly designed or overly complex systems. The goal to take to heart here is focusing on the immediate need and minimal amount of work done to meet that need. Development and Architecture teams often get caught into the dangerous practice of over-engineering systems and implementing solutions that do not immediately affect or impact the desired outcome for the organization. “Architecting for the future” is often a term that is used, however organizations will often put in place architecture or implement for the future and due to the rate of change of their business and technology needs, this is often more costly from both a time and resources perspective to correct than refactoring and building iterative solutions.

These may seem like simple principles behind Agile and they are. However, when organizations lose sight of these, they often encounter a rocky path with their adoption. Organizations that I have seen that have embraced the Twelve Principles of Agile Software have thrived through their agile adoption and flourished with the results. Aligning your organization to the Agile Manifesto and Twelve Principles of Agile Software can better align individuals and groups within your organization to common goals.

Whether your organization has been using agile in some form for years or is just now planning its adoption, let’s talk about your goals and alignment to the Twelve Principles of Agile. Ensuring the principles are embraced across your organization along with the optimization of teamwork, processes, and tools will ensure the highest efficiency and quality possible out of your development cycles.

You May Also Like These Topics