Get certified - Transform your world of work today

Close

Agile Principles from a Non-IT Industry Standpoint

For Agile acceptance in industries beyond technology

18 July 2017

Vivek Sinha
Capgemini


The most recent 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 nontechnology 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 need 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 team." 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 nor infrequent.
 

Summary

Here is the alignment between each principle and its core essence.
1 – ROI (return of investment)
2 – Changeable
3 – Getting real/Real time
4 – Clarity
5 – Self-organizing team
6 – (Virtually) colocated
7 – Boolean done
8 – Sustainable pace
9 – Continuous collaboration/review
10 – Simplicity
11 – Evolution
12 – Frequent inspection and adaptation

As mentioned, this post is more a compilation of common thoughts presented by many Agile coaches and gurus, and some original thoughts may have been unintentionally overridden by others. I apologize for any such cases.

My sincere thanks to Dr. Andreas Wintersteiger, whose training and session inspired me to look at Agile principles in a simpler and more generic way.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.9 (14 ratings)

Comments

Julian Bayer, CSM, 8/16/2017 6:23:05 AM
I appreciate that there's a need to generalise agile principles so as to make them better applicable to other domains. However, I have to disagree with you on multiple counts:

On principle 3, you want to ignore "working software". In my opinion, "working" is the key word in this principle. It's not just about shipping anything. "Working" implies a standard of quality that must be met. Maybe one needs to find a better adjective than "working" depending on the domain one is in, but I think ignoring that part misrepresents the principle.

On principle 4, your go-to example of business people and developers working together is the daily scrum - a meeting specifically designed to only include developers. Business people may attend, but they do not participate. That, at least, is the definition given in the Scrum Guide. I do agree that the principle is about clarity, but I think you may have chosen a bad example there.

I don't think watering down principle 6 just because it can't be done by everyone is a good idea. A face-to-face conversation IS the most efficient and effective method of conveying information. That is a fact. Of course it cannot be achieved everywhere, but organisations should strive to do the best they can with regards to this principle. The principle doesn't need to be watered down for that, IMO.

I also don't agree with your summary of princple 9. IMHO, it is not about collaboration. It is about craftsmanship. It is about expecting each and every member of the team performs their work diligently and with discipline with regards to the state of the art.
Vivek Sinha, CSP,CSD,CSM,CSPO, 9/4/2017 4:49:30 AM
Hi Julian,

Thanks for your review, and apology for delay in response [Summer vacation, you know]

On Principle 3 -
I appreciate your points - I should have emphasize on ignoring "Software" part and not the "working" part; which is essential aspect (for both tech & non-technology industry).

On principle 4 -
I think, we are in Sync; the example may be better.

On principle 6 -
Idea is to be face to face as much as possible. If team are no co-located, invest in tools and culture to create VIRTUALLY CO-LOCATED environment, so that face to face can be achieved.
If one go to a non-tech industry team (new in agile adoption) and ask them Face to Face is essential, and you have to make your team co-located; they might feel – Agile is not for them.

On Principle 9 -
I liked the terms "Craftsmanship". For non-tech industry, it will be easy to understand it using this term. However, often people consider craftsmanship as an individual contribution, while principles are essentially around teamwork and teams.

Once again I appreciate your review, it's kind of fill the voids, Thanks.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe