DevOps has become a popular and commonly adopted software development model in IT industry in recent years. Its popularity is partially because it advocates it could improve software development efficiency, delivery speed and cost saving. This is especially favored by managers who become the main force to promote this type of development model in their companies. However, we must be cautious about DevOps model as well. With their advantages, they also bring challenges to development teams and they have their own requirements. If we just blindly advocate DevOps to all projects, it would bring us disastrous result in some cases.

In this post, we will not focus on what good parts DevOps would bring us, instead we will focus more on what requirements DevOps has on us.

Project characteristics

With the increasing popularity of web projects and mobile apps, it seems DevOps can be adopted in more and more areas since these projects would quickly be deployed and get feedback from users because the users may only need to refresh the browser or update the app through App Store. Also, with the advancing of deployment tools, the cost of deploying an update is cheaper and cheaper. However, there are still areas where DevOps may not be in a good fit. We think projects conforming to below characteristics are not suitable for DevOps.

1. Traditional desktop software or server software which requires installation package download and manual install
2. Mission critical project requiring sophisticated domain knowledge such as database management or system management software which require lots of investigations and designs before developing
3. Bug sensitive system. If a bug would bring the system down or bring the server down, then the development should be careful. 

Team structure

With popularity of globalization, lots of companies have their teams spread all over the world to increase the delivery speed and efficiency. The drawback of this is that it increases the challenge of communication. To the scrum teams in DevOps mode, communication is critical because delivery timeline is quite tight. no one wants to wait for one day to get the response after sending out some questions to a colleague in the other side of the planet or wants to ruin the night time to join the scrum to update daily status. The team should be located in a single place so that communication will not become a big problem and the update and deployment can happen quickly. 

In addition, there is another requirement to the team size which applies to other development model as well. In a DevOps model, small scrum teams are desired. If the team is too big, it increases the communication difficulty of task coordination and it increases process time because every team member needs to update his/her status every day and that may not be others want to know.

Member quality

DevOps promotes continuous delivery and this puts on high requirement of team members. They need to be able to quickly understand the feature requirement and find out the bugs when issue occurs. When in DevOps mode, a big task would be divided into a few small tasks so that they could be worked on by many people at the same time. The whole team should be in a fast paced mode and the team could not wait for someone who is far below average and blocks other people.

Compared to traditional software development where developers would only write code for the areas they are familiar with, developers work in DevOps mode would also involve in requirement gathering, design, coding, testing, bug fix and operation. 

Also if the team member quality is unbalanced, there would be need for clear documented process to do things so that everyone could follow it even for those not well qualified. And once process is involved, the core feature of DevOps is compromised and this would slow down the overall speed for delivery indeed.

In conclusion, be cautious when evaluating whether you want to adopt DevOps model in your projects.