CPIE captures what a customer values most. It stands for Certainty / Productivity / Innovation / Elegance. The concept can also be extended to internal customers.
When agile manifesto was announced in Feb 2001, twelve supporting agile principles were also identified. Even after 13 years very few people know about these principles; even those who are using agile practices in their work.
These 12 principles can be broadly divided in 3 categories.
Customer: Satisfy Customer | Working Software | Deliver Frequently | Sustainable Development
People: Motivated Individuals | Work together | Self-organization | Face to face
Process: Welcome Change / Technical excellence / Inspect & Adapt / Simplicity
It would be interesting to see how these agile principles can help and guide us to achieve CPIE.
Certainty is a perception that customers form based on their interactions with us over a period of time. It is partly subjective and partly objective. To provide certainty, we must have the desire and will to keep our commitments. If we don’t have that, the customers will see it through our actions. But however well we plan, everything is not under our control. Things change, new situations emerge. “Welcome change” mindset helps us to see the new reality because we are not stuck to our existing assumptions and beliefs, and through “Inspect & Adapt” can quickly adjust to the new situation. “Deliver frequently” provides instant feedback about the changes in customer expectations. All this helps to make mid-course corrections to meet the current situations and customer expectations by the promised date.
Productivity is all about output upon input. Output is the value delivered to the customer. Input is the efforts we put in. “Simplicity” – the art of maximizing the amount of work not done – helps us to get more done with less. “Satisfy customer” helps us to be always focused on the customer value. Similarly focus on “Working software” helps to avoid unnecessary activities that are not adding any value.
Innovation is required in two areas; technical and practices. Continuous attention to “Technical excellence” and good design fosters the culture of Innovation. “Motivated individuals” can quickly identify opportunities for practice innovation and when they “Work together” it leads to useable results.
Elegance is an elusive concept which can only be experienced. It has been variously described as neatness, precision, simplicity, tasteful design, dignified gracefulness, and restrained beauty. It requires continuous attention to quality which is possible only with “Sustained development”. To experience the elegance requires full use of multiple senses, which is enhanced with “Face to face” interactions. It is difficult to achieve elegance with command & control culture. It requires “Self-organization” to bring out the best from each team member.
Though we have looked at each element of CPIE separately for better understanding, they need to be approached holistically. Together they produce the kind of synergy that is impossible if attention is divided.
To summarize, understanding the agile principles and related practices is important to achieve CPIE. But even more important is an agile mind to understand and use the right principles / practices as may be required for a given situation.
Enrollment is a powerful tool to influence other people towards our point of view. Like any tool, it is a double-edged sword. It can be used to win over another person or it can be used to manipulate him or her.
Recently I came across a good coverage of this aspect in an article by Daryl Conner at http://changethinking.net/the-ethical-ploy/the-five-elements-of-%E2%80%9Cvirtuous-trickery%E2%80%9D Here are a few quotes from the article which highlight what ethical enrollment is all about.
Ethical enrollment doesn’t overtly force or covertly manipulate anyone into thinking or doing anything. It is a way of opening doors, not pushing people through them.
Ethical enrollment is an approach to influencing others that requires being less than fully transparent, yet it is principled. It requires that we believe the new perspective we are promoting represents a positive opportunity for the other person. Even though there may be advantages for us if he or she accepts the new viewpoint, our motives are not primarily self-serving. We are honestly offering something that we believe is in this person’s best interest. It requires respecting the person’s right (despite our efforts) to being unready or unwilling to accept our point of view. Just because we show people doors doesn’t mean they are ready to go through them.
When we meet other people’s needs and respect the sovereignty of their viewpoint, we increase the likelihood that we can meet our own agenda of changing their minds. Once people feel their needs are being met, we can be more direct about our intentions without offending or appearing to be pushing our perspective. The key when using ethical enrollment is to keep in mind that, in spite of how passionately we believe in our own frame of reference, others will not come to accept our views unless and until they are ready to do so.
This is a much more mature and balanced approach than manipulating people to get acceptance of our views under the cover of enrollment and has a higher chance of success.
In the light of the above, let me give some examples of what I consider to be an unethical enrollment. I have heard three terms, patriotism discipline and loyalty, often used to brainwash a person into accepting a viewpoint out of fear of looking bad.
Though patriotism is commonly used in the context of a nation, the underlying belief is that interests of a larger system like a nation are always more important than those of the smaller systems like a family or an organization. But this is not always true. Sometimes, an individual is needed more by a smaller system than a larger one.
The way discipline is used for enrollment often means that whatever a group has decided must be accepted by every member. Some decisions do need universal acceptance by every member. However, there are situations where the group is not adversely affected even if a few members who are not convinced of the decision decide to act otherwise.
Loyalty comes from the expectation “I have done this for you in the past; now it is your duty to do what I want you to do for me”. This is often seen in parent-child or employer-employee relationships. It typically one sided because what was done in the past was on the assumption “I know what is good for you and there is no need to ask or even check”.
When faced with such situations an individual is in a dilemma how to respond. If he succumbs he suffers; if he does not he falls in the eyes of others. Systems thinking can provide clarity by removing the cobwebs. Every living entity, which has a lifecycle of its own, is a complete system in itself. In that sense every individual, every family, every organization and every nation is a system. Such systems interact with each other on an equal no system is part of another system and has a right and responsibility to look after its interests.
Though each system is independent, it is not isolated. It is closely connected with other systems. Hence, in the short run it can get away with looking after its own interests at the cost of others. In the long run, it has got to consider and care for other systems’ interests.
When viewed from system’s perspective the dilemma dissolves. The power to influence and unethically enroll others, hiding behind high sounding terms, is lost and the individual feels free to take right decision without any guilt. So it pays to stick to ethical enrollment for effective and sustained results.
Recently I read an article “The government is not above the rule of law” by Gurucharan Das in The Times of India. Mr. Das was CEO of Procter & Gamble India and later Managing Director, Procter & Gamble Worldwide (Strategic Planning). Now he is a full time writer.
A few sentences from the article attracted my attention. I realized that if a few terms are replaced as applicable in the context of an organization instead of the country, it provides an interesting perspective about the organizational policies. Here is how,
Original from the article: Citizens look to the state to reduce uncertainty in their lives. The state does this through a robust set of laws. The rule of law is based on a moral consensus, expressed daily in the ‘habits of the heart’. People obey the law not only because they fear the punishment but because they think it is fair and it becomes a habit and a form of self-restraint.
After replacement: Employees look to the management to reduce uncertainty in their lives. The management does this through a robust set of policies. These policies are based on a moral consensus, expressed daily in the ‘habits of the heart’. Employees adhere to the policies not only because they fear the punishment but because they think it is fair and it becomes a habit and a form of self-restraint.
See if it makes sense.
All of us send and receive e-mails, virtually all day. Many a times the flow becomes a deluge and we feel happy just to get it over with and attend to other things. In this rush after we send an e-mail, we miss to ask a very powerful question, “What next?” May be we need to keep track of it because the recipient needs to act on it and might forget to do so. May be we need to combine the information from the mail with other information available elsewhere so that it is readily accessible when we need it. May be we need to start next action as the current action is over, but because we did not do so it sort of falls through the cracks and comes back to haunt us when it is already too late. If nothing else, we might like to just delete it if we no longer are likely to need. There are many such possibilities, but the bottom line is that we did not ask this simple question which could have saved us avoidable heart burns in future.
This is just one example related to mails. However, the problems mentioned and importance of asking the question “What next?” has implications in all walks of our life. Individually or collectively in groups & teams, we have many goals to achieve. Each goal requires one or more tasks to be completed; and each task requires many actions to be taken, generally involving more than one person. Any delay in initiating the next action would in any case delay completion of the task, other related tasks and ultimately the goal. But this might be true for physical systems where linear relationships exist. But when humans enter the picture, things start getting complicated and delays can be order of magnitudes higher.
Let us consider a case where we could have taken the next action while we were at a place where we were required for taking the action. For example, the next action would involve meeting a person in another city or even another country. If we remembered to do so while we were there, it would involve only fixing the meeting. After we have come back we can only blame ourselves and wait for our next visit. Take another case, if we had started the next action while a person knowledgeable about the work and sympathetic to us was around; it would have taken probably minutes to complete. When we delay it, now some other person is to do it and this might result in delay of the work by days – even weeks. Even if we ourselves have to take next action, we may have had the time or the right tool or right information then but not so later.
To cut the long story short, there can be a million reasons why extra delays can take place, but only one simple solution. Let’s not forget to ask ourselves the simple question – what next – and promptly act on the answer. If you have had similar experiences, please share for everybody’s benefit.
Introduction: It is understandable but unfortunate that the very mention of the term software engineering evokes such a strong reaction in the agile community. It is understandable because of the burden of the past when good intentions turned into bad practices and unfortunate because in the process we tend to throw the baby out with the bath water.
Agility: The essence of agility is transparency inspection and adaptation. If we look at the Agile Manifesto, we see that the earlier focus on terms like “processes and tools, comprehensive documentation, contract negotiation and following a plan” had frozen the continuity. This I like to call as Agile -1.
Change over continuity: The terms on the left of the value statements in the Manifesto like “Individuals and interactions, working software, customer collaboration and responding to change” emphasized the importance of a human observer who would inspect the content with the context and adapt the approach to align them. The intention was very good but the potential energy of the earlier imbalance was released and swung the pendulum on the other side. This was a phase of Agile 1.
Agile is now mature: By the end of the first decade, agile has become a mainstream methodology and matured enough to be able to give equal importance to both the sides of the equation and provide a way for the practitioners to adapt their practices to the changing context. It has thawed the frozen continuity and can help us to consider logically the benefits of managing continuity well while also responding to change. So we are entering a phase of Agile 0. At first sight, 0 appears empty and hence meaningless. But being empty also frees it from the burden of the past, and opens up limitless possibilities.
Continuity with change: Let us look more closely at continuity and change. When we start developing a new software system, it is all about change. As it grows, elements of software maintenance start entering the picture. Over a period of time, the proportion changes and ultimately we reach a stage when the bulk of the work is to maintain the existing system with little new functionality added from time to time. Managing continuity becomes more important than managing the change. So at different stages, the mix of continuity and change differs and our practices also need to change accordingly.
Systems perspective: It would help to look at this from the systems perspective. The internal state of the system is represented by the state of its content. Similarly, the external state of the system is represented by the current state of its context. Whenever there is a misalignment between the internal state and the external state of the system, it results in creative tension. This tension can be reduced by suitably changing the content or the context or both. But before this happens we need to inspect the current states of the system, which in turn needs access to the right information in time; in other words transparency.
Real life example: Let us understand this with an example. A person brought up in a traditional joint family marries and starts a nuclear family in a big city. He still carries with him the values of a joint family but has to deal with the expectations of living in a big city. He needs to objectively see this and change either his values or manage expectations of others. How he decides to adapt is up to him but unless he is aware of the misalignment, he may end up bring an emotional wreck.
System states: The internal state of a system is the assumptions beliefs and the values it holds along with the current set of practices being used repeatedly. The external state is the interface projected to others and expectations of others from the system, along with the repetitive interactions. In the above example, the tension is generated by the misalignment between what he is and how he wants to appear to outsiders.
System stability: Apart from the system states, it is important to understand system stability. A stable system has minimum hindrance to the free flow of system energy, or synergy for short. Internal stability comes from well-coordinated actions, while external stability is about well-coordinated interactions with other systems. An internally stable system may or may not be externally stable, and vice versa.
From the software system perspective when we start making any changes to it, the internal system becomes unstable till it goes to the next stable state. The iterative development brought in small jumps from one stable state to another as compared to waterfall. This is also expressed as “potentially shippable product” in Scrum. The external stability is governed by the interface exposed and the changing expectations of others from the system. So during iteration as long as the earlier stable version exposed outside remains in sync with the expectations, there is external stability.
Adaptation options: The concept of internal & external stability is important for deciding between continuity and change while adapting to the new reality, as it becomes visible after inspection. During inspection we observe the internal and external states of the system. If they are misaligned, it may call for change. However, the change may be required to the internal state or external state or both.
If the system is internally unstable, we need changes to make it stable. But we have a choice to either take it back to the earlier stable state or forward to a new stable state. This in turn depends on how it would impact external stability.
If the system is internally stable but externally unstable, we have to decide whether to make external changes or internal ones and accordingly plan our actions. It is not always prudent to start changing the software as soon as new requirements come, without considering the resultant states. Sometimes it may be necessary to delay or deny the requested changes in the overall interest.
So far we have seen responses which were reactive. What if the system is currently stable both internally and externally? Should we let it be or proactively anticipate changes in future? We may decide to either continue the status-quo or to go for change, but we will reach the next level of stability much faster.
Inspection: With this background, let us examine what is involved in inspection. Traditionally, inspection means an action planned to know the current state and more often than not involves measurement, which requires collecting data and analyzing it. There is another part of inspection which is normally neglected. It is about observing the instances of exceptional behavior, capturing them and understanding the hidden cause or causes. Such exceptions have a tremendous potential to give us a glimpse into the emerging reality before it starts showing up through measurement.
Transparency: Reliable inspection depends on transparency. Transparency is the ability to see the reality without any obstruction or distortion. Normally, the persons who see it may not be persons who need to act on it. In case of inspection using measurement, it means that the persons who have access to the raw data do not hide it and those who analyze do not distort it. In case of observation, since the exceptions are not controlled by us, they need to be shared by those observing it to those who can analyze and ultimately to those who can act on it. Since this can’t be defined as a process, it needs to become part of the culture as an informal communication, almost bordering on gossip.
What’s in it for me? How does all this help us? Once we become aware of our attachment to one way of thinking and the knee jerk reaction against the other, we can start exploring the fundamentals at the human systems level and apply them to software development to see them in this new light. It will provide us pointers to examine our current practices and suitably modify them as we see them working. We can also benefit in other areas of our life beyond software.
Explore and share with others: Paraphrasing from the Agile Manifesto Let us together “Uncover better ways of managing our practices, by doing it and helping others do it”. When we are able to do it across the software community and get it into the collective consciousness, we would reach the stage of a perfect balance or in other words Agile 0.0
As per the news item posted by Semat http://www.semat.org on 28th Feb 2012, OMG had put out an RFP for a proposed standard “Foundation for the Agile Creation and Enactment of Software Engineering Methods (FACESEM) RFP (OMG Document ad/2011-06-26)”. Semat working group has submitted a proposal entitled “Essence – Kernel and Language for Software Engineering” on 20th Feb 2012. This is an interesting development and I would like to share my thoughts on those aspects which I believe would be of interest to the software practitioners, including those who are familiar with agile ways of doing things.
It is interesting to note that the RFP asks for an “AGILE” foundation for creation and enactment of software engineering methods. This is in sharp contrast to the current practice of methods being created once by process experts to be used repeatedly thereafter by the practitioners. The term “process”, which is so widely used currently, is also conspicuous by its absence from the defined terms in the proposal. Instead it works with practice which is defined as “repeatable approach to doing something with a specific purpose in mind” and method which is “composition of practices forming a description of how an endeavor is performed”.
The direction software engineering is likely to take in future is indicated by the key differentiators mentioned in the proposal,
- Finding the essence of software engineering so that it can be applied to and reused across different application domains and software systems of differing complexity
- Working with methods in an agile way that are as close to practitioners’ practice as possible, so that they can evolve the methods and adapt them to their particular context
- Focusing on what helps the least experienced developers over what helps the more experienced developers
- Supporting practitioners over process engineers
- Emphasizing intuitive and concrete graphical syntax over formal semantics
- Focusing on method use over method definition
In short, the proposals by Semat and others leading to a standard can be expected to benefit the practitioners, giving them a greater say in deciding how they go about developing software, or to use the term from the proposal, their “Way of working”. The universal kernel and a common language would also support the concept “think globally act locally” and provide a common foundation to tackle variety of contexts and situations in a consistent way.
When I was discussing this topic with my colleagues, I was surprised to see how quickly they concluded that it is only related to agile software development whereas it is applicable to all kinds of software development, agile or otherwise. It is actually more about how we decide to develop software rather than how we develop software.
This reminded me of Mike Cohn’s Blog “Succeeding with Agile” http://blog.mountaingoatsoftware.com/reflections-on-the-10-years-since-the-agile-manifesto which I had read some time back. As he says, we stopped talking about objects a while ago and similarly we will stop talking about agile. Rather than “agile software development” it is just “software development.” Rather than “agile project management” it is just “project management”— Of course it’s agile.
But for this to happen, I feel we will need a greater understanding of the opposing forces at play before we can optimally balance them to suit specific situations. Few examples of such universal opposing forces applicable to all human systems are,
- Defined versus empirical
- Transparency verses privacy
- Inspection verses automation
- Planning versus preparing
- Compulsion verses discretion
- Early verses late binding (of decisions to actions)
- (Internal) cohesion versus (external) coupling
Does the above thought process make sense? What are your views on this?
Agile manifesto values individuals & interactions, customer collaboration and responding to change. Fulfilling these value statements requires a much higher level of freedom to the individuals and teams as compared to the traditional project management. But this need for freedom must be balanced with the other value statement of working software (of high quality). So it is not absolute freedom but a structured freedom that we need to protect the interests of all stakeholders including teams & individuals.
Let me explain it with an example related to road traffic which all of us are familiar with. There are road dividers to separate traffic in opposite directions, lanes to help cars going at different speeds and signals to avoid getting in each other’s way for the cross traffic. Such structures though appear to restrict our individual freedom; actually help us in our collective freedom. This is fine as long as these structures are well designed keeping in mind the interests of the majority and also assuming that all respect the rules. When this does not happen, our freedom is seriously compromised and we have all sorts of problems. As we can see from this example, we are not really looking for an absolute freedom but rather the right freedom supported by good structures that protect and help us.
As we saw in my recent blog on structured freedom at https://prkarve.wordpress.com/2012/02/23/structured-freedom-with-rules-and-strategies/, the structures form by repeatedly making certain choices over other possible options. This preferential treatment to certain options over others may either be due to compulsion as in case of rules or it could be voluntary when we choose them as a matter of strategy. In either case, the structures provide momentum which greatly facilitates those actions which are aligned with the structures. However, when we try to choose other options, the structures exhibit a strong inertia, which makes change from the status quo quite difficult.
Unfortunately we can’t directly change the structures when we need a course correction. The degree to which the change is resisted depends on whether these structures are hard or soft, rigid or flexible. So the solution available is to change the rules & strategies which led to these structures in the first place, and keep repeating new way of doing things patiently till the existing structures are modified or new ones formed.
Details of these concepts, along with examples, can be found in the blog mentioned above. They are very generic; systems level concepts which can be used in all walks of our lives, including agile software development as I had covered in my talk at the recent Agile India 2012 conference https://prkarve.wordpress.com/2012/02/27/last-weekend-at-the-agile-india-2012/ which has a link to my presentation at the conference. For the benefit of those who were not there during the talk, I am sharing below the salient points.
During the talk I showed how the concept of structured freedom can be quite useful to meet the challenges faced by leadership of software organizations in the current decade. The leadership includes both at the team as well as the organization level.
The four success factors for agile movement identified during the 10 year retrospective of agile manifesto provide a good starting point. These success factors are,
- Demand Technical Excellence
- Promote Individual Change and Lead Organizational Change
- Organize Knowledge and Promote Education
- Maximize Value Creation across the Entire Process
In the context of leadership challenges, these can be interpreted in a variety of ways. However, I took three most prominent ones to illustration application of structured freedom. These were,
Enhanced quality (“Done” within short iterations)
Scrum functions as a container for other techniques, methodologies, and practices. Probably in the enthusiasm of trying something new, the focus was more on the events and practices of Scrum and somewhere the role of Scrum as a container was lost. Added to this is the short duration of iterations or sprints which doesn’t give much time for anything else. A good definition of “Done” can win half the battle. We need to look more closely at the other half of achieving “Done” in short iterations.
Specific roles & responsibilities (Considerably different from traditional product development)
Scrum roles are highly non-intuitive. For ages, we are used to a top-down hierarchical structure of management. In Scrum there are just three roles and nobody reports to each other as such. This is unsettling and leads to risks if not handled well. For the leadership, there is always a fear of losing control. Another aspect which is unusual from traditional project management is the three roles have very specific and clear-cut non-overlapping responsibilities as well as authority.
Self-organizing culture (Supported by self-disciplined teams)
Self-organization which is an essential component of agile success is more a cultural issue than merely a matter of declaring a team to be self-organized. A very common argument I have heard is that we can’t allow self-organization because our teams are not yet mature enough. The obvious conclusion is that we need to continue planning, tracking and managing them as before till they become mature enough. But this is a catch-22 situation. If a team is self-disciplined, then it is easier to help them mature with self-organization.
Then I looked at how rules and strategies can be suitably modified to bring about desired changes to the structures.
Enhanced quality (“Done” within short iterations):
Scrum as a container for best practices
As we saw earlier, Scrum is only a container for other good practices, especially those which are important for quality. A container protects the contents, so should Scrum. This is a good reason to setup suitable org rules in areas like code quality and reviews, continuous integration, test automation, and appropriate documentation. Such rules can vary from organization to organization or even from client to client in case of offshore vendors. However, for a given project, these must be seen as rules with consequences for not following them.
This is probably applicable more to the distributed teams, especially involving multiple organizations, where product backlog grooming is given a go-by or done occasionally. In such situations, even the product owner’s availability to the development team when they need it becomes an issue. Out of site; out of mind. Here again, my experience is that agreeing on it as a rule by both the organizations greatly helps.
Change in code – test sequence
We earlier saw that strong beliefs sometimes tend to be treated as rules. Start of testing after completion of coding is one such unwritten rule which exists in many projects coming from non-agile environment. This rule is even more rigorously followed if developers and testers belong to their own hierarchies, sometimes going up to the director level. Here is a good case to convert a rule into strategies. Once this option is open, there are many possibilities. Testing can happen before, during and after the coding in short cycles. Lot more communication between respective developers & testers can take place. Another interesting possibility is to redefine the roles of developers and testers. Testers who are good at thinking of different ways to fail can define a rich set of test cases. The developers can carry out such tests immediately after they complete the module level code or integration as the case may be. This can drastically cut down the completion of a user story from start to finish till “Done”.
Roles & responsibilities (Clear-cut responsibilities and authority):
Scrum defines the responsibilities and the authority of three roles very clearly and explicitly as we can see in the Scrum guide.
As rules for incumbents
Though the rules are defined quite clearly, it is often that they are either not followed as intended or completely forgotten if inconvenient. It is for the leadership to understand them along with reasons why they are important and to see that they are being followed.
Roles support each other
Apart from the leaders playing their part, it really helps that the three roles help and support each other.
Need strategies for all others
Those who are outside scrum teams may not understand them or may not find convenient to use them. It is here that the leaders need to step in and use the strategy as appropriate to the situation.
Self-organizing Culture (Needs self-disciplined Teams):
The biggest bottleneck to self-organization is the belief that only mature teams can be self-organizing. As seen earlier, such beliefs tend to become rules for those involved.
“Can do” belief
It is necessary to change this rule to the belief that it is possible to create self-organizing teams with not yet mature individuals.
The way to do it is to approach it step by step. First take care of bringing disciple through rules. Repeated use can help create self-discipline. Once it is in place, slowly more and more work is transferred and letting them make small failures.
Collaborate, learn and share
In this learning process from small successes and failures, the team as a whole working together in all the important Scrum events greatly helps. So this should be implemented as a rule. However, each person has his own way of learning. Such strategies should be shared within and outside the teams.
From the above we can summarize possible actions for the leadership.
At the level of Scrum teams:
The executive leaders need to Work closely with Scrum masters in making suitable changes and ensuring that these are repeated till they become second nature.
Help the teams in achieving self-organization by progressively transferring control as the team members gain greater confidence.
Take care of managing other stakeholders by using strategies appropriate to the situation
At the organizational level:
It is important to observe the existing structures and watch of any signs if they are becoming bottlenecks to smooth and efficient functioning. If so, the rules & strategies currently in use need to be carefully modified and repeated till they lead to the new desired structures
The traditional approach of defining processes is by so called process experts. Another, more agile, approach is to try out various combinations of rules and strategies and see what works in majority of cases of similar nature; then document those as processes and support them till they become accepted way of working.
From the systems thinking perspective, everything we do individually or in groups, boils down to just four types of basic activities. These are to execute, decide, facilitate and ensure. Execution is the simplest and most fundamental of them because nothing gets done till some tasks or actions are executed. Actions are generally taken individually while the tasks may be executed individually or collectively. The other three activities are more in the nature of being supportive to the primary activity of execution.
Decision involves making a choice from multiple options. This is where the concept of “Rules & Strategies” comes into play. There are a number of definitions of the terms “rule” and “strategy” used in different contexts. Hence it would be helpful to specify the meaning in which I am using these terms. For me, rules make the choices for us while strategies are the choices we make. Let me take a few examples to illustrate this. When I was child, there was a rule at home that the small children must be back home before the sunset. The choice for us was already made for us by the elders in the family. However, till sunset we were free to make our choices of what to play, when and with whom. Similarly, when I grew up and started driving motorized vehicles, I had the option of choosing a particular path to reach my destination. But when to move and when to stop was decided by the traffic signals. Society and the government also make lots of rules for us. For example, society lays down the rules for one of the most important decisions in our life which is, whom we can marry and whom we can’t. Similarly, because smoking is a health hazard the government has made a rule that any public display of smoking has to be discouraged. The film-makers however come up with an innovative strategy of superimposing the warning sign quite attractively while Katrina Kaif danced to an item number.
So it is safe to say that we encounter rules & strategies in all walks of our life, though we don’t often realize it. Here are some common differences between rules and strategies. Generally rules are defined by few to be followed by many, whereas the strategies are formulated by us for ourselves. Rules typically have consequences; whether legal, social or emotional. Strategies don’t have consequences as such; though we may be have good or bad outcomes depending on how well the strategy worked. Rules try to cover a large number of situations whereas we need specific strategies for each type of situation.
In terms of execution and decision, in case of rules, the time gap between decision and execution can be quite large. For example in religious, social and cultural rules this gap could be in generations or even centuries. Strategies on the other hand normally have a short time gap. For example, a cricket team may decide the strategy for a game before it starts but mid-way they will have to come up with a revised strategy depending on how the game is going. The captain would decide the strategy even for each over, sometimes changing the field placement half-way through the over.
An important category of rules is about those which we make for ourselves. When we strongly believe in something, it severely limits our choices. We may fool others with ingenious strategies, but we can’t fool ourselves. Only way to loosen the stranglehold of our beliefs is to get beyond them and critically examine them from outside. This requires an open mind to learn from failures and new exposures.
Why is understanding of rules & strategies so important for all of us; partially because they shape our decisions and actions? We can’t facilitate others’ working unless we understand the rules and strategies at play in their context and in their specific situations. A good grasp of the framework of rules & strategies gives us a great handle to influence others and shape their behavior.
Ability to ensure the desired outcome is the essence of leadership and it is imperative for the leaders to understand and use the right rules & strategies for a given set of persons for a given situation.
When there are restrictions placed on us we want to be free from them. Tighter the restrictions, more we crave for the freedom. But do we really look for absolute freedom? Not necessarily, because we also like the protection that the rules provide us. For example when driving on a road, we are happy that the traffic signals are stopping the cross traffic from coming in our way. The social, cultural and legal rules provide a great safety net for the disadvantaged when they are thoughtfully formulated and sincerely enforced.
By nature human being are lazy. We live in the comfort of the belief that whatever is working today will continue to work forever. So we keep making similar choices and keep repeating certain actions over other alternatives. This is strongly habit forming and kind of gets into our muscle memory. After some time, almost without any conscious thought we go through same motions again and again. It is great for productivity and speed of execution, but we must remember that this also gives rise to certain structures. With repeated use, these structures tend to get stronger and stronger. When our decisions and actions are aligned with the structures, we experience great momentum. However, the moment there is need for change of direction or a course correction, the same structures exhibit tremendous inertia. So the reality of our lives is not absolute freedom but a kind of “Structured Freedom”. It is therefore in our interest to be aware of the structures and the strong influence they have on our freedom and be able to recognize the structures that exist in our minds as well as around us.
All of us are responsible to ensure the desired outcomes. The scale expands as our responsibilities increase. Unfortunately, it is very difficult to directly change the structures. More the force we apply, more is the resistance. If they are rigid they will brake; if they are flexible, they will spring back. Only way to effectively change the structures is to understand how changing rules & strategies and patiently repeating the new ones often enough leads to modifying the existing or creating the new structures. This is the only permanent solution.
We have only scratched the surface of this immensely important concept which has tremendous possibilities in all walks of our life and work. Let’s together explore it further in future, peeling each layer as we go. If my thoughts find a resonance with you, please share your experiences and thoughts. If you have a different perspective, I would love to understand it, even being challenged. So you may like to join me on this exciting journey.
Whenever we talk of freedom, the common assumption is that it is about situations when we are not allowed to choose what we do or don’t do, where we go or don’t go, with whom we will talk or won’t talk and similar such choices. In short we wish to have more control on our actions and decisions. When we don’t have enough freedom, we crave for more. As it is true for individuals, it is equally true for groups of people as well as for whole societies. So there must be something common about what restricts our freedom. A better understanding about these underlying causes would help us to deal with such cases more effectively.
In my opinion one of the most importance reasons is what are others’ expectations from us as well as how safe or risky they feel about letting us do what we wish to do. Their expectations from us are directly determined by what are their needs goals and objectives and how they perceive our actions will help in fulfilling them. How safe / risky they feel depends on how they view our capabilities and by their past experience when dealing with us in similar situations. If they feel safe they will give us more freedom, if not they would restrictions on us if they have the power to do so else they will try to create hurdles for us.
How we use this information about likely reasons depends a lot on situations and context in which we work as well as what choices we have in those situations. However, it helps to be aware of the common causes and keep them in mind while dealing with specific cases.
There is an entertaining soap currently running on Sony TV titled “Bade Achhe Lagte Hain” starring Ram Kapoor and Saakshi Tanwar. I distinctly remember one scene from a recent episode where Priya (Saakshi) a middle class girl is married to the business tycoon (Ram Kapoor). On her first morning in the new home, Ram’s butler Bansi kaka asks her choice by beverage from coffee, tea and many varieties of juices. When she prefers coffee, he rattles off names of ten different varieties. She is not accustomed to so many options and overwhelmed she asks him to bring whatever he wants. We have all come across many more choices than we care to have. For example, when we are planning for a vacation, if we have to take all the decisions, from where we should go and mode of travel, stay arrangements, places to see and so on, we would rather leave majority of that decision overload to the expert like a travel agency. We may give some broad preferences and leave the nitty-gritty to them. Time & attention are the scarcest resources we have and we would always like to conserve them for things that matter to us most.
In short, we do look for freedom OF choice where we don’t have it and we also seek freedom FROM choices where we don’t want to be bothered. Policies & processes are both empowering as well as restricting depending on how well they are aligned with our needs. Hence, it is very important for those who frame the policies and design the processes to understand the needs of those who would be using them and sensitive to their preferences. Sometimes, it may be even better to give up the idea of a new policy / process, or to modify / get rid of an existing one if it has become outdated and is not serving the original intention any more.
The thoughts shared above are applicable in all walks of our life; In short they seem to be applicable to all human systems. Have you also experienced similar situations? If yes, you may like to share.
Closer home, they have a significance for software development as well, especially agile software development which encourages the teams to be self-organized. Such teams expect lot more freedom than what traditional teams are used to. It is normally assumed that teams want more & more freedom OF choice. However, I have come across situations where the team members like to be spared too much freedom and want the protection provided by rules, both defined by Scrum as well as by the organization. The leaders have a responsibility to design such rules carefully so that they provide freedom of as well as from choices as appropriate.