Agile Principles from a Non-IT Industry Standpoint

The 2017 State of Scrum Report found that "Scrum and Agile practices, once the sole domain of software developers, are making significant inroads outside of IT and finding acceptance in industries beyond technology."

The Agile mindset was recognized in 2001 at a summit of practitioners who found consensus around core values captured in 12 principles called the Agile Manifesto.

If you look at these two statements closely, you'll recognize a problem. The Agile principles were thought of and built around software development by software practitioners. Obviously, the principles include many references to software or IT-specific terminology, such as early and continuous delivery of valuable software, emergent architecture and technical design, and working software as a principle measure of progress. People from non-IT or the non-technology industry may find it difficult to relate the principles directly to their work. We need generic phrases that are applicable across industries and that simplify the principles without losing their core essence.

The fact is that many agile coaches, gurus, and practitioners have already done this. So here is a collection and compilation of simplified or rephrased agile principles that may help agile enthusiasts from both the IT and non-IT industries.

Generalizing agile principles

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

Emphasize "customer satisfaction." Someone from outside the IT industry may ignore the "delivery of valuable software" part. Instead, think of something that is relevant to you or your industry. In reality, it doesn’t matter what the deliverable is (e.g., software, a mechanical product, or a service). What matters is customer satisfaction, which comes only after return on investment. So the first principle of agile is customer ROI.

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

How can you (your team, your process, or your solution) welcome changes in requirements? By keeping your solution, process, tool, service, or design changeable. Yes, the second agile principle is changeable.

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

Again, you may ignore the "working software" part and emphasize the "delivered frequently" aspect of the principle. It’s all about getting real, or as close as possible to a real-time response to customer needs.

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

The daily stand-up is the most popular and arguably the most effective way to achieve cooperation. Your business context may not allow you to hold these meetings, however. So examine this principle again, and think about what it aims to achieve. Yes, it’s all about clarity. The fourth principle is to bring more clarity to everyone and everything. You may design your own way to achieve that.

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

This principle is already generic. A self-organizing team is the fifth principle of agile.

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

Colocation may not work well for every industry. What does work well is the investment in tools and bandwidth to create virtually colocated teams and workspaces. Invest in these tools.

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

In a non-IT business, working software is not part of your model, so what is your principal measure of success? Focus on the first and last part: "working" and "measure of success." In this context, it means Boolean done — something is either done (working) or not done. The measure of success is not work in progress or partial completion; nothing is successful if it's 40% or 80% complete.

This is really interesting and important. None of your matrices or MIS should be partially or a percentage complete. Design your matrices with a Boolean-done approach to embrace the seventh principle.

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

People are not a "resource" — they are people. If your team or staff is working overtime, they will burn out soon; if they are working too little, they will be bored. You must strike a balance; understand people’s needs and accordingly frame your working rules and process. The eighth principle is about sustainability, and it comes from treating people as humans and not as a resource. (By the way, who invented the awful term human resource?)

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

Pay attention to "continuous attention" and ignore the "technical excellence or design" part, if it is not applicable to your industry. But don’t confuse continuous attention for micromanagement or continuous follow-up. The ninth principle is about review and continuous collaboration.

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

Nobel prize-winning poet Rabindranath Tagore said, "It is very simple to be happy, but it is very difficult to be simple." The tenth principle is in the same vein — how to make things simple, be it process, rules, tools, reporting, governance or operating model, or your code and architecture (sorry that I mention some IT stuff here). Often people make things complicated by habit, by trying to make something too perfect, or by overthinking.

Agile is all about simplicity.

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

You may comfortably ignore "architecture, requirements, design," etc., and pay attention to "emerge from self-organizing teams." If you abide by the fifth principle (self-organizing team), all you need is patience and belief; things will evolve into their best shape on their own.

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

No point in guessing about this. It’s inspect and adapt, frequently. Frequency should be sustainable — neither too frequent or infrequent.

Vivek Sinha is an Agile - DevOps coach in Spain. As an agile evangelist, he supports others’ agile adoption and process improvement and also facilitates "Agile-For-Developers" training programs for budding agile professionals.