Agile 0.0 – Balance continuity with change

March 26, 2012 at 2:29 pm | Posted in Blogroll, Out of my mind, Practice Excellence, Scrum and agile, Software Engineering, Systems Thinking | Leave a comment

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

Advertisements

Leave a Comment »

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.
Entries and comments feeds.

%d bloggers like this: