Author: Mirel Spahić
Given that I work in software development industry for more then 15 years I got an impression that people misunderstand the development process methodology goal by sticking to it and not allowing to change it a bit with regard to the project needs. In my opinion, following it blindly and strictly to the every piece of it, is not the aim of any published methodology.
,,Intelligence is the ability to adapt to change'' - Stephen Hawking
Why, do I have any argument?
Trying to develop unified process is unnatural because it is impossible to have one solution for all problems – simply said it doesn't comply with the laws of nature. Also, process members are people with different knowledge base, mindset and intelligence and they are the most complicated machines in the whole universe (we are aware of), yet you force them to be a part of some unified process – also unnatural. Third, unified processes will never fit to all business types and so on...
Ok, so what should we do?
In my opinion, embracing the core concepts of a popular methodology, taking a baseline out of it with boundaries as an agreement between team members and applying tweaks on the top of it is the right path we should follow. In other words, assimilating the methodology to the team is better than adopting a team to it, and finally building the team of self-organized people can result in a fantastic idea of self-organized, perfect team. I believe it is not a new idea and it happens in some companies but I would call this approach as one way of having a successful working process.
Historical note: Defining development processes has been tackled with many books and scientific publications, causing many polemics. It is old as much as software development is as a team effort. The team effort requires some sort of organization or process to achieve the goal otherwise the result might be something nobody expected to have.
Is it going to be too complicated for us?
Increase in complexity around any idea in the world can divide it to several streams which can result in misunderstanding of the idea's essence, leading to a confusion and rejection at the end. So, doubtless, it is very important to understand the essence of the process being implemented to help achieve the team goal. This is the answer to many of you stating that development team do not need a process and other roles and tools involved. At the top of that, it is very hard to give a report to the upper management because there is always someone who pays people to do the job and that person has a right to know what is going on.
Where is 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 a 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 manufacturing as a relatively young and fast growing industry branch did not have time to seek for a successful manufacturing process. Community tried to embrace already developed processes by successful manufacturers such as Toyota and make them fit into the software development (Kanban for Toyota Lean Manufacturing).
This story yielded some of them as a very popular methodology in a software development world such as SCRUM.
What is Product development?
It is very important to define the product development. Development of a chair is not much different from the process perspective. Developers are producing code and code is their product as a chair being assembled in a factory. The same chair passes quality control like product release by QA and at the end they go to clients. By looking this way, in the nutshell it is the same, but speaking of a software product development it is much more complicated than that because you build a software aimed to be used for a different purposes and a chair is just being used for sitting on it. Thus, it requires special attention and approach.
We produce the code – The code is our product
Why would we embrace the process?
Among many implicitly imposed process goals, there are many of them you just do not see. It doesn't mean they do not have the purpose because your job is not depending on them but your single action can have many undesirable effects. It does have effect on someone else in the upper management for sure.
The sample is workflow process and tooling inadequate usage – 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 the losing credibility and finally can result in project failure.
The same way for example QA guarantees that a product release is certified, having a development process defined guarantees that a product will be delivered.
There are many other benefits for the company you work with when it comes to the branding, marketing, reputation and so on.
Our actions affect others as well