Everyone talks about DevSecOps nowadays. A lot of companies implement the main concepts of it. Some of them are pretty successful while others face major (organizational) challenges. It’s great to hear the success stories of the companies that are well on their way. However, it’s also extremely valuable to recognize key indicators which might be relevant in your organization that hinder the DevSecOps movement. Once you recognize these, you can actively search for solutions “in the field” to apply them in your organization. This way, you can stand on the shoulders of others and move forward faster. Are you ready for DevSecOps? Five key indicators to think about it twice.
We all know the typical problems that need to be solved with DevSecOps. Many people think of long lead times, too many handovers, departments that work in isolation, manual provisioning of systems, etc. In this article, we’ll take a look at some other aspects which might be less obvious but still very important.
1. Too many emails – every day
Organizations that depend on emailing systems (f.e. Outlook / Office365) for their daily communications can’t work very efficiently on projects and IT products. People that read and send too many emails every day keep themselves busy while they can better work on more important issues. Especially when they do send emails with lengthy documents. Who reads them? Why do these people duplicate those documents while they might be stored centrally as well?
Too many emails and large attachments also occupy a lot of storage space. In the cloud, costs can rise very fast since you also need to consider a backup, data retention, etc. Besides, it adds an extra security threat since it’s much more likely that a document falls into the wrong hands. You lack governance around it since there is no centralized control.
One solution would be to train people to send links to documents instead of the documents themselves. Even better would be to avoid sending emails at all. Move away from email-based communications and switch to a centralized system.
2. No ticketing systems for the “line management”
It’s great if every DevOps team already uses their own ticketing system. Think of Azure boards or Jira. While this is pretty common for projects and activities on an operational level, it is not so common for people higher in the organizational hierarchy. For example business unit managers, enterprise architects, or security officers. All of these roles are positioned in the “Line Management” of the organization.
One of the main problems that prevail in the line management organization is the lack of transparency. Tactical projects and activities tend to be more “secret” compared to operational activities. This is sad, since everyone benefits if these topics are more transparent and visible to a larger group within the organization.
It would be much more beneficial for the organization to create a ticketing board for these tactical projects as well. This way, everyone can follow the flow from the organizational vision and strategy towards the business goals (on a tactical level) and use this information to align their initiatives. This might sound vague but it becomes much clearer if DevOps know the exact direction of the company. It also helps to ease out the (corporate) communication, reduce the number of centralized presentations that communicate the vision and strategy.
If companies want to implement a ticketing system for line management, the direction needs to initiate this initiative. There needs to be a complete cultural change at the highest level of the organization. Everyone needs to trust each other and work in an open and transparent way. No room for big egos and political fights. THAT might be the biggest differentiator compared to the previous situation.
3. Product Owner in name only
Some of the larger companies but also the smaller ones still employ Project Managers to run their projects. This is an old-fashioned way of working. The very same companies might have a program running to “convert” these roles to Product Owners or they want to employ Product Owners “from scratch”.
One of the most common pitfalls is that the Product Owners do not work “Product-oriented” but still run their projects as companies did in the past. A Product Owner that is not purely focused on his/her IT product hinders the DevSecOps movement. If a Product Owner does not has the right mandate to propagate changes to his/her IT product, the DevSecOps initiatives fail.
On top of that, Product Owners that do not follow the essential activities cannot fulfill their role. Organizations will be slowed down and they need to train Product Owners. It’s essential that Product Owners focus on product LifeCycle management since DevSecOps require constant iterations of IT products that are being developed. Topics they need to master are versioning control, understand the different stages of their IT product (PoCs, MVPs, growth and decommissioning, etc).
Avoid employing people that have the role “Product Owner” but are actually Project Managers, System owners, or other roles.
4. No BYOD
Developers demand freedom (within certain boundaries) to develop as fast as possible. Every developer prefers his/her own Operating System, IDE, tools, terminals, browser, etc. It’s impossible to satisfy everyone when there is only a single developer system available.
While large corporations tend to offer “quick and easy to set up developer work-spaces” to “control them” and to streamline the number of tools developers can use, they actually slow things down. Even worse they accidentally promote so-called “Shadow IT”.
Developers do want to work in their own way since everyone has their own preferences. It should not matter if a developer wants to use Atom while another developer wants to use IntelliJ. If the end-result works: a “ready to deploy” application of high quality, everyone should be happy.
Bring Your Own Device (BYOD) solutions can realize this. Once developers can use their own hardware, they have the freedom to work locally (super-fast) even when there are some connection hick-ups. Provide enough security measures such as disk encryption, malware scanning, and anti-virus programs that run in the background. Besides this, help developers to choose common software packages to limit the number of tools. Run local run-time environments using containers to test applications that are in progress in a consistent way. Train everyone that uses their own Device to work securely and in a professional way.
All of these initiatives help to remain fast and become faster in the future.
5. Too much team autonomy
DevSecOps teams are responsible for their IT product from A to Z. Building and running their application(s) is the core of their day-to-day activities. But when they are only focused on that, the company is missing out on other aspects. For example:
- No sharing of best practices
- Fixing (security) issues in isolation which also apply to other teams
- Re-invention of common cloud (native) design patterns
Senior management needs to constantly search for the right balance between team autonomy and time for other activities that have an interest in other departments/teams. It helps to reserve a fixed amount of time (as a percentage) that teams can spend on collaboration-related activities. Free up some time in the sprints to attend demos from other teams, seek help for common problems, browse the backlog of others, or explore source code repositories to find common code patterns that can be re-used.
Since “everything is source code” in a “digital-first” organization, make sure that people can actually find the source code of others they want. This means you need to have a centralized source code repository for all of your teams (in the same structure) and a way to actually find the most relevant repositories. It’s not enough to give everyone “just read-only access”, developers need to actually identify those source code repositories. They need to be able to search based on metadata such as title, description, number of authors, filter on popularity, the average number of commits per time-interval, etc. Or even better: create a dashboard that shows this kind of search results, so that individuals do not need to think about it themselves.
Conclusion
Great companies that are truly practicing DevSecOps actively ban an “e-mail based” company that is focused on sending documents around. Those companies employ Product Owners that work and act like true Product Owner and not like Project Managers. At the same time, they create a sense of transparency also on higher levels in the organizational hierarchy. They have ticketing systems on the tactical level as well as on all operational levels. Developers want to really work at those companies since they can have their own developer workstation with the tools of their choice. If one or more of these key aspects is not in place at your company, use the tips and tricks in this article to start changing your organization. This way, DevSecOps is a step closer to reality.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.