I worked in different roles for different companies and in each role there was some talk about reviewing and optimizing development process as it was thought that the current process is either too laborious or too simplistic, yes too simplistic processes aren’t too good either. You might think that simple process is the way to go but not always. Let me explain.
If the team is working on a green field project, the development team is aware of the business domain, are technically capable of producing good code and detailed coding standards are defined at team or company level then simple process of [design-> develop->test->deploy] will work. But if this team has been working on this project for some time say 6 months and a new developer joins the team then this simple process will start to fail. By the time this developer joins the team there is already some code in place that is developed to certain standard and this developer doesn’t have any knowledge of the application that is being developed and so he tries to do something which, if badly designed, might break something else. So, in order to avoid such cases this development process is deemed too simplistic and review process loops are introduced between design, develop and test actions. So that someone with considerable understanding of the tool will avoid any code that has such ill side effects from being added to the solution.
Now the review process, if not overdone, also improves the quality of the code in other ways. It helps in reducing the bugs because both design and development actions are thought twice and by two different people. Review process also helps the code to at a better standard which I will not go into too much detail. So, it is always suggested to have some sort of review process in the development lifecycle.
Now you might say, hey we found a solution to the problem! But unfortunately development is never that simple. There is a group involved in any IT development whose behaviour is absolutely unpredictable. This group of people are called by different names end user/customer/business user or whatever you want to call them. Introducing these chaps changes the dynamics of development with a huge margin. The ever changing mind of this group of people is the main cause of most of the IT projects failure. Add a business analyst to this situation and it gets really cumbersome. In order to tackle this problem project managers put in various kinds of contingencies but the one we are interested in are the changes to development process.
Agile:
One of the ways to deal with this chaos is to use agile methodologies where the requirements are gathered every few weeks and are signed off and frozen until they are completely developed. This process works well in most of the cases. But the methodologies need to be customised according to the project in order to see the results. These changes are not drastic changes but minor changes like level of documentation needed who attends the scrums, length of each sprint etc.
One of the ways to deal with this chaos is to use agile methodologies where the requirements are gathered every few weeks and are signed off and frozen until they are completely developed. This process works well in most of the cases. But the methodologies need to be customised according to the project in order to see the results. These changes are not drastic changes but minor changes like level of documentation needed who attends the scrums, length of each sprint etc.
Anyway, there are certain scenarios where agile doesn’t fit the purpose. For example if the IT project is about adding new features to existing application and these feature requests come at irregular intervals and they need the changes without any delay – like can’t afford to wait until next sprint. Adding to this scenario if there is a support team who maintains the system and helps users use the system then the development process needs to be very different and also a bit involved as there are many stakeholders and multiple developments each at different stage of development cycle are carried out at the same time. And typically such applications life span is long enough to loose part of the team and add new members to the team.
All these will demand a stringent development process and checks at every stage. This is where most of the teams adopt a complex and laborious process which is complex to use and reduces the team efficiency. This makes the team think that they can improve the process, which they surely can.
Development process could be slick yet stringent. For example take a look at the following process:
Requirement -> Review -> Design -> Review ->Develop -> Review ->Test->deploy.
This isn’t too long compared to our previous process, but the main difference isn’t in the process but the way this process is implemented. At each of the non-review stages at least two people must be involved. This avoids too much dependency on single developer, reduces the bugs, improves coding standards and also improves the individual knowledge over technology and application. So, it is a win-win for both individual developer and the team.
Also it is suggested to involve the support team at the requirement or at least at design phase so that the knowledge transfer to the support team will not be laborious. It is not required for the support team to approve or make their presence felt, they just need to be added to the ‘cc’ list so that they are aware of the change before they go into the KT meeting.
Anyway that is my view about development process – different teams have different requirement and too simple process isn’t always the ideal solution and same with too laborious processes.
Comments