Software Development organizations tend to "lean on" or "crank up" processes in the delivery cycle in an attempt to achieve higher predictability. For all the obvious reasons, achieving predictability becomes the key initiative for the product delivery teams as well as the key source of concern for the executive team, the board, customers and other stakeholders outside the delivery organization.
By predictability, I refer to the questions of 'when' software will be delivered, 'what' it will contain and 'how' it will perform for the end users.
Does cranking up process alone provide this predictability? I don't think so. Besides process, there are other forces also at play in a software development lifecycle that influence the delivery predictability and the ultimate outcome.
In fact, I believe that a software development lifecycle is controlled by four significant forces that simultaneously act on and influence the lifecycle in terms of time, content and quality (the "what", "when" and "how" of above) of software. These four forces are:
- Knowledge --representing the knowledge that is needed, acquired and eventually embedded in software. For more on this concept, refer to The Laws Of Software Process** by Philip Armour.
- Community -- representing the community that is engaged in the delivery cycle towards acquisition and capture of knowledge, their skills, roles and responsibilities
- Collaboration -- representing the collaboration needed to accomplish various tasks and activities towards software development and delivery
- Process -- representing the process that is used to manage and drive the development and delivery mechanics
Quite analogous to the Law of Parallelogram which allows us to measure the resulting impact in magnitude and direction of two forces acting on a body simultaneously, I am proposing the Law of Software Development, aka the Law of Four Forces (or Sanjiva's Law of Software Development :)). These four forces simultaneously act on the development cycle and the Law of Software development provides a means to measure (or predict) and influence the outcome -- a product of time, content and quality.
The rationale for treating these as forces or vectors is that each has its own influence, also in magnitude and direction, towards the overall lifecycle. An optimum delivery of software with respect to time, content and quality requires a deliberate and proportional balance between each force. Conversely, an out-of-balance scenario, unless deliberate, can potentially affect the efficiency of the overall delivery effort and significantly impact any one or all of the outputs mentioned above.
Furthermore, similar to a parallelogram, a weakness in one force can potentially put a significant burden on the others in an attempt to achieve the desirable (or any) outcome. Agile methodologies are a clear example of the increase in collaborative tactics to overcome the deficiencies in the Knowledge force. Here, the rapidly evolving business requirements and lack of sufficient knowledge ahead of the development cycle warrants added focus (or weight) on the Collaboration and Process forces by creating various iterative delivery models, directly engaging end users, trading off formal documentation, and so on.
Agile, then, is an example of a deliberate manipulation of other forces when Knowledge is known to be a weaker influence. In many real-life situations, there isn't a clear assessment or acknowledgment of the weight or impact of any of the four forces on the software development cycle and therefore the impact on the others is more accidental and uncontrolled. I have seen many situations where unplanned and unwarranted increase in collaboration results as a way to accommodate lack of Process and Knowledge forces. Here, the predictability falls off because the organization has not clearly assessed the forces at play and their individual impacts.
So the lesson here is towards gaining a deeper understanding of the Law of Four Forces as it influences predictability of software development and delivery in your organization and managing each one to improve the overall predictability and the outcome.
-Sanjiva, Bangalore, August 19, '06
**In his book "The Laws of Software Process", Philip Armour asserts that software is not a product but a knowledge medium. He formulates his Laws of Software Processes in the context of "the knowledge that is available for implementation into an executable system".
PS -- The interaction of individual particles and behavior of large-scale matter in the universe is also controlled by Four Forces (not necessarily those mentioned above) -- in this case, Gravity, Electromagnetism, Weak and Strong Nuclear force. Coincidence? I think not. It is another one of my attempts at 'Unifying theories' ;)
Comments