No Process As Process

Software projects are infamous for failure. These failures occur for a number of reasons. Many times these failed projects fail even though a software process was implemented. We might therefore conclude that process itself does not guarantee success. At the same time it is not the process that fails or succeeds but rather the resources that execute them.

Software processes try to encapsulate years of experience and knowledge of successfully delivering software. They consist of a number of techniques and steps coordinated within a workflow. They orchestrate all the resources required to deliver software.

Software projects consist of technology, people, process and context. These elements are all related in a multitude of ways. In fact they are related in an infinite number of ways, and therefore it would be foolish to think that a single process would be valid for all the relationships that could occur.

I would say that the process should provide the coordination of the technology, people and context. Process does not do this by itself (although most processes think they do), but unfortunately requires someone - typically the software architect - to execute the process in order to coordinate the technology, people and context. Due to the dynamic and unpredictable variables such as context and people, the process must be malleable and flexible. It is the software architect’s role to ensure that he is getting the desired outcomes from the process.

Also process is considered a risk in terms of the project, but I would rather see process as a mechanism used to mitigate risks in a project.

Bruce Lee a leading martial artist once said the following “No way as way, no limitation as limitation”. Bruce Lee was referring to the large number of martial arts styles that existed, including his very own style. Bruce Lee was of the view that a true master needs to be like water and adapt to its environment. Bruce Lee attributed his success to his adaptability – by adapting to his opponents fighting style he was able to overcome him. Thus a true master is not limited by a single style but rather adaptable enough to any style.

This analogy is also true for any software development process. While there are numerous experts punting their own or a particular method, a fixation with one particular method for every kind of project is not always in the best interest of the project itself.

Process is only a means to an end and not an end in itself. Process should be the collection of the best techniques that get utilised appropriately to deliver value. Thus it is the application of techniques, rather than the techniques themselves, that overcome the specific challenges of a delivery.

So can one size fit all? No. Yet we have the process evangelist screaming “use mine; use mine”, without really trying to understand what kind of project you wish to embark on.

The following concept is so important that I must repeat it again – every project consists of many different elements. User requirements, people, technology, business driving forces, and the process itself are all important elements of a software development project. On every project these elements combine differently, and the combination of these elements is infinite.

Furthermore each of these elements by themselves is complex enough and uniquely influences each project. Trying to synergise them is an immense task only to be undertaken by skilled individuals who can choose the appropriate courses of action for the specific project challenges.

Fortunately the techniques that can be used to implement a process are well known, but the application of each technique is where the failings continue. The application of these techniques is where skill, experience and a touch of good luck is required, and cannot be acquired from any one book, seminar, training course etc. It is a craft that can only learnt as a craft through some form of mentorship and experience.

I believe that our efforts should be directed at identifying the techniques required for the application of process to any development effort. We need to define the criteria for the use or non-use of each technique. In this way we will be able to select appropriate processes for projects, thus contributing to a project’s success.

However, this is not to say that the application of any particular process as it stands now would not succeed. If applied differently, it is possible that we could succeed with a lot less process for an equivalent quality of delivery.

Over the next few months I will be addressing how we categorise these process techniques, apply them and more importantly how we share this expertise in a simple manner for the benefit of all software developers.

Remember the focus – The end of any project is the delivery of value to its sponsor and not the process used.