Dev Ops vs Special Ops: What is the difference?

Let’s be honest, the idea for this article probably came from the fact that the two terms sound similar! However, the more we thought about it, the more it turned out to be an interesting way to explore what our “Special Ops” approach is by comparing it to the more widely known, but often misquoted, concept of “Dev Ops”. Let’s dive in…

First up, Special Ops. What is this all about? For a while now we have been using the idea of “Special Ops” to promote ClearSky’s unique approach to software development. Like a Special Ops team, we work in small groups delivering high impact solutions to challenging and complex problems.  Special Ops is about how we work. it affects everything we do and informs all of our decisions, big and small. From planning and design through to the development and testing of the software, we commit small teams of highly skilled individuals who are laser focussed on the desired business outcome.

So how does this compare to Dev Ops?  Dev Ops, as suggested by the name, is about the intersection between “Dev”, the technical side of a business, and “Ops, the operations side. Broadly speaking Dev are responsible for building and delivering working software whilst Ops are responsible for putting the software in customers’ hands and keeping them happy. The challenge arises in the boundary between the two sets of responsibilities.

The boundary between Dev and Ops is necessarily blurred, in fact the cross over is essential for everyone to do their jobs effectively. Dev need to be able to empathise with the customer in order to solve their most important problems with appropriate solutions.  Ops need to have an understanding of technical constraints so that they can bridge the gap to customers and make informed decisions about cost / benefit analysis of new features.

Dev Ops is about effectively managing this blurred boundary between Dev and Ops.  The best explanation of the aim of Dev Ops that we have heard is “aligning authority with responsibility” (credit unknown). This means that someone who has the authority to make a decision should have the capability to action that decision with a minimum of friction and involvement from other people.

Let’s take a simple example.  Imagine that the operations manager is the person responsible for deciding when a new version of some software should be released to customers. Without any thought about Dev Ops practices, the process might look like this:

1. Head of development emails the head of operations to tell him that a new version of the software is ready for review in UAT.
2. Operations manager emails members of his team to ask them to review the new version of the software in UAT.
3. Members of the operations manager’s team review UAT and indicate that they have reviewed the areas that they are responsible for and are happy for the version to be released.
4. Operations manager writes an email to the head of development to inform him that they are happy for the new version to be deployed.
5. Head of development Slacks one of his team (who actually knows how to run a release!) to ask them to go ahead with the deployment of the new version.
6. Dev team member runs the pipeline and waits for it to complete.
7. Dev team member Slacks QA to tell them that the new version is live.
8. QA performs some smoke tests of the new feature.
9. QA Slacks the dev team member to tell them that the new version has passed the smoke test.
10. Dev team member Slacks the head of development to tell him the new version is live.
11. Head of development emails the operations manager to tell them that the new version is live.
12. Operations manager uses mail merge to send an email to all customers to tell them that a new version of the software is now live.

This is a lot of unnecessary communication and the decision maker (operations manager) is far removed from the people implementing the action (the dev team member and QA).  With a sprinkling of Dev Ops magic the process could look like this:

1. Operations manager and his team members get an automated email to tell them that a new version of the software is ready for review in UAT.
2. Operations manager and his team members review UAT.
3. Operations manager and his team members click a button in the email they received to say that they are happy for the new version to be released.
4. The deployment automatically runs when the operations manager and the required members of his team have clicked to indicate their approval for the new version.  When the software is deployed, automated smoke tests are run on the live environment.  On successful completion of the automated tests, an automated email is sent to customers telling them that a new version of the software is now live.

This is the power of Dev Ops.  Putting the power in the hands of people with the authority to make decisions.  So how does this compare with Special Ops?  There are a lot of similarities but also some key differences.

First the similarities.  Both Dev Ops and Special Ops are about empowering people to operate effectively and do their jobs with a minimum of unnecessary interference and “red tape”. One of the keys to success of our Special Ops teams is their small size.  Each member has a deep understanding of the business problem which they are working to solve and so they can be trusted to operate semi-autonomously to deliver appropriate solutions.  Dev Ops supports this through light weight processes which facilitate input from wider team members as and when required.

Dev Ops and Special Ops are also about putting people at the center of everything.  As we saw, Dev Ops allows an operations manager to execute the decisions which he has authority over without taking up time of other managers and staff to execute menial tasks which could be automated.  Our Special Ops approach also recognises that great people are the most important part of a high performing team.  The SAS only recruits the best people who are capable of completing the most challenging missions in the most difficult environments. Similarly, we only recruit the highest performing individuals.  A lot is expected of our developers beyond their technical abilities.  Operating in a small team, they need excellent communication skills to take on understanding and ownership of the complex business problems which they are working on.

Lastly, one key way which Special Ops differs from Dev Ops is that Special Ops is not just about Dev and Ops.  As mentioned at the start, Special Ops encompasses everything that we do at ClearSky. From our sales, client services and design teams through to our technical and QA teams we are all aligned and share the same focus on the core business challenges and problems that we are working to solve.

If your interested in hearing more about our Special Ops approach then please get in touch at contact@clearskylogic.com or head to our website and take a look at what we do- www.clearskylogic.com.