Development Process – part I
“Intelligence is the ability to adapt to change'' - Stephen Hawking
Defining development processes has been tackled by many books and scientific publications, causing many polemics. It is as old as the industry itself. Naturally, a team effort requires a process or a form of organisation to achieve the goal, otherwise there would be confusion, procrastination and ambiguity in reaching any results.
Given that I have worked in the software development industry for more then 15 years I have an impression that people misunderstand the development process methodology. Generally, teams would choose an existing process and stick to it regardless of the eventual needs for modifications within the process itself. Following it blindly and strictly sticking to every part is not the aim of any published methodology.
Why? Here is my argument.
First, it is impossible to have one solution for all problems in a process – simply said, it doesn't comply with the laws of nature. Every occurrence in nature has its cause and effect, so each cause will result in a different effect. It is not different with development processes. It takes a minute detail or addition which can completely change the outcome defined at the very start of the process.
Second, unified proceses will never fit to all business scenarios because businesses nowadays are so diversified, that there is no pattern which fits all. Moreover, there are often no unified processes within the same business sector.
Third, team members come with a different knowledge base, mindset and background; furthermore, they are the most complicated machines in the whole universe (that we are aware of). Yet, they are made to follow certain unified process guidelines by the letter. I will come to them later.
Ok, so what should we do?
The path to follow is to embrace the core concepts of the latest methodology, adapt its core principles, define the key elements of your particular process and set the boundaries with the team. This should be the starting point to every project process. In essence, the secret to success is to be able to adapt rather than assimilate a process of any given methodology.
It is crucial to mention that people are the key factor of success and failure of every process. It is therefore very important to carefully select the team members (bearing in mind competencies and personalities), and have the whole team to be involved in setting starting boundaries of any process. This way, we ensure everyone's commitment, ownership and responsibility as well as their wish for the project to succeed.
Once you have the team, an increase in complexity around any idea can divide it into several streams which can result in misunderstanding of the idea's essence, resulting in confusion and rejection. So, keep it simple, but careful too much simplicity can bear the same result as overcomplicating it. Finding balance, the middle ground is essentially the key to success of every project process.
So, what's the middle ground?
As mentioned earlier, defining non-negotiables (key elements of your process) should be the starting point. A joint agreement amongst team members as to what should and should not be included in the process is the right middle ground for the team. Sometimes you may think that defining this middle ground is taking too much of your sprint time, however, it actually in the end saves the total time vested in the project.
Where is all this coming from?
You can learn about classic SDLC at universities but the topic is too complex, old and abstract. It has many unnecessary phases and it results with unsuccessful, slow and failed projects.
All other methodologies developed in the meantime are just problem solver trials.
Each of these methodologies became suitable for some project types but none for all of them (Agile, Extreme Programming, Waterfall etc.).
Software development as a relatively young and fast growing industry branch has not had the time to produce a completely successful development process. Thus, successful manufacturing processes, such as Toyota's Kanban has been adapted to the software industry. Embracing already developed processes from other industries has resulted in a popular SCRUM methodology, however, not one company will have the completely same SCRUM process as another company.
The code is our product
Development of a chair is not much different from the process perspective. Developers produce code as a chair gets assembled in a factory. That chair passes quality control as does the product in software development. At the end of the process, the chair is delivered to clients, just as the code. Observing the process from this perspective, in the nutshell it is the same, but speaking of software product development it is much more complicated than that because you build software aimed to be used for different purposes and a chair is just being used for one. Because the code is our product, it requires special individual attention and approach in process definition.
Why would we embrace defining the process?
Wouldn't it just be easier to sit down and write code, and write more code, and release the code and have a fantastically happy client. The real life is not quite that simple.
There are many stakeholders involved in any project goal, from the client, to end user and all those in the middle who work on the accomplishment of the goal.
How could we make estimates without prior experience of how long certain tracks take? How can you know where the whole team's at without the reports? How can you know of the success of the project without having a process to support it?
Among many implicitly imposed process goals, there are many of them you just do not see. It doesn't mean they do not have a purpose just because your job does not depend on them. The impact of your actions (or lack of) may not directly affect your team, but surely it affects the management or stakeholders who depend on the process in order to analyze success rate, define problem issues, forecast and much more.
For example, if we do not enter the time we spent on a task or provide an estimate then the upper management can't have proper information. This can result in sending wrong information to the client, which can lead to losing credibility and finally can result in project failure.
The same way a QA guarantees that a product release is certified, having a development process defined guarantees that a product will be delivered. And let's be honest, if you were the client, wouldn't you want to have a clearly defined process and a guarantee of a delivery?!