Agile Principles vs. Rules

 The well refined Principles Last when Time Moves on; However, a Progressive Organization or Society will love to break the Old or Hidden Rules in order to Move Forward. 

Leadership is about "why," to discover the underlining leadership or business fundamental principles. Management is about "what", to define the rules based on the set of principles. More specifically, what are the difference and correlation between principles and rules, at today’s Agile working environment or beyond?

Principles are meant to be guidelines.Well-refined principles will be still effective when time moves on, but the rules may need to continue to be updated when circumstances change. The management philosophy is first teaching the principle ("why"), then explain the rule ("how") to getting daily things done. Because principles are abstract in order to oversight and unify; to be more specific, they have to become rules. However, the problem arises when you believe that your particular rules are somehow better than other rules that stem from the same principles. It is more worried about the rule sets that don't seem to be rooted in any principles, or so-called agile frameworks that aren't rooted in agile principles. The logic 'Agile' order could be:

Agile Values (Manifesto)
+ Agile Principles
++ Agile rules, processes & practices per a particular flavor (XP, Scrum, etc)
+++ Agile implementations to support those processes & practices 

Supply the link to underlining principles when giving a rule. If you just give a rule, people will follow it blindly - because they were told by an expert. If you give them a rule and explain how it relates back to principles, they will understand the subtleties of how to make it work. This works because the principle undergirds the rule, not the other way around. Doing this has a huge benefit: once they really understand correct principles (why), they can manage themselves (rules), including adapting their rules to their special situations. Blindly applying rules can be absolutely not Agile. On the other side, Agility does not mean the abandonment of all rules. Human culture is based on setting rules. The rules start from personal space and extend in ellipses from the core. But the organization chooses to exist in a binary, black/white world can't fulfill the true colorful vision, and further skid to oblivion.

Use Agile Values and Principles as a guideline to evaluate any practice, process, tool, etc. Although rules make life easy; they mark between "right" and "wrong", which has limitation. Rules can easily be mapped to process to control behavior. At industrial age, business management has depended on a command-and-control approach, which arose from factory settings then spread throughout the business world. This works well for some endeavors, but this approach does not work well with knowledge workers who must constantly make decisions with changing information and context in the digital era, for example, building software systems are creative, not just mechanical activities. There is a huge personal change required for "leaders" to move out of C&C mindset. It seems like a giant leap of faith that work will get done without your detailed guidance and rule setting. Likewise, it is difficult for some "workers" to get used to the new independence and responsibility of being largely in charge of oneself within broader parameters

One rule works in Agile, be good at "Reflect, Tune, and Adjust". One of the key ideas of Agile is that there is no process that can ensure that all projects will always be successful - while the process is important, individuals and how they interact is the critical thing to get right. So it always involves:

*change - it is scary. It tends to introduce too many unknowns where we need to improvise a solution.
* control - Agile creates new control structures. Tied to this is the "knowledge = power" belief.
* transparency - It requires one to be accountable for his/her actions and not shifting faults to others.

Living up to principles by setting and following the rules. In other words, the reason people turn principles into rules is that they need to do that in order to live up to the principles (unless the principles are already in the form of low-level rules). Although it is true to say that there is no single "golden way" to achieve the goal, as with all high-level goals, there are a variety of ways to achieve these goals. These ways of achieving are typically prescriptive steps, so it is also true to say that you need to come up with at least one way for your project. And that way will always have steps to follow and constraints to obey rules. For example, one way to make working software the measure of progress in your project is to make sure the software, as a work-in-process, is always available to all stakeholders to examine, to have an automated process that updates the working software daily, and to regularly interact with the stakeholders.

The principles are like light, to guide one through the uncertain future: as "there are known known- there are things we know that we know. There are known unknowns; that is to say, there are things that we now know we don't know. But there are also unknown unknowns – there are things we do not know we don't know. The principles are abstract to apply to vary circumstances when heading to the future; Rules are more temporal, rules are meant to be broken – the progressive society loves breaking old or hidden rules, and build the new rules accordingly for charting the better future.

Posted in: Agile,Connecting Dots