At disruptiveOps, our engineer approach utilizes the 3 Cs; Culture, Cloud, and Commonsense.
Influenced By Agile & Lean Thinking
disruptiveOps’ culture is influenced by Agile, eXtreme Programming (XP), and Lean Thinking and that is especially evident in how we operate within our SDLC. This approach unifies us in our mission to provide best-of-class solutions and services to our customers and sense of purpose and pride for everyone within disruptiveOps.
Our engineering teams leverage ScrumBan with 7-day Sprints to accommodate timing challenges with our international teammates and partners. We re-plan nearly every day to ensure we are working on the right-thing at the right-time and allow our teams the freedom to swarm for additional re-planning when needed. Our teams test, review, and demo nearly every day for fast feedback and learning. We encourage our teams to swarm whenever there is chance to improve a process and have formal retrospectives every 2 weeks.
Within disruptiveOps, we have no physical servers or purchased software. Instead, we leverage cloud-based solutions to help us manage every aspect of our Software Delivery Life Cycle (SDLC). This approach provides an incredibly low Initial Cost of Ownership (ICO) and Recurring Cost of Ownership (RCO). This approach is also ideal as it allows us to more quickly integrate customers and partners into our SDLC.
User Experience, UI Requirements / Enhancements, UI Defect Management
Repositories, Continuous Integration, Continual Delivery
Product Lifecycle Management, Program Management, Enterprise Management
Static Code Analysis
OneNote, Word, Excel, PowerPoint
We have gravitated toward the XP framework because of how well it aligns with our overarching Agile & Lean approach, most notably how it stresses customer satisfaction, empowerment, and responding to change. Because XP emphasizes teamwork above all else, everyone is considered an equal partner in a collaborative team (leadership, management, stakeholders, customers., developers, etc.).
disruptiveOps has the experience to know that context matters and that we need to utilize just-in-time commonsense approaches to solving challenges.
Any Device – Any Platform – Any Time
We build products that can be used on any modern device and web browser because you need products that easily integrate into how you are working today. For organizations that want tighter integration with our products, we even offer the opportunity to use the same microservices we use for retrieving, saving, and analyzing data. Because our products are on the cloud you have 24x7x365 access to them via the Internet.
Security Is Paramount
We build security into our entire SDLC so you can rest assured your data, devices, and organization are safe.
Prior to development, our Product Owner works with the UX and development teams to understand not just the functional requirements but how we may need to limit exposure of data that some may consider sensitive.
During development, combine the engineering standards and practices of Microsoft SonarSource and that of SonarSource. Our developers perform Static Code Analysis (SCA) with SonarLint throughout their day to reduce the opportunity of checking-in code with security weaknesses. Our CI process uses SonarCloud to perform SCA during the check in process to prevent code with major, critical, or blockers findings from being put into our repositories.
We continually build-in time for pentesting to more quickly identify and resolve findings within all layers of our products. This extra layer of protection helps resolve issues so you do not have to deal with them.
While we use the highly secure Azure Government Cloud, we continually review its security posture with the Azure security tools. To ensure real-time awareness of findings we utilize notifications process to our entire enginereing staff and Chief Executive Officer.
UX As A First Class Citizen
We do not start engineer anything until the UX team verifies and validates a user journey. Verifying the relevancy of a requirement promotes our concept of only do what is required and nothing more. Validating the user journey reduces the time to deliver value because we are able to test it more quickly and inexpensively with wireframes and conversations.
disruptiveOps’ UX approach is one of the leading reasons why we have an extremely low defect rate. By the time, the engineer teams are ready to work on the requirement they are already familiar with it, have supportive wireframes, and “walk through” the entire user journey.
disruptiveOps is able to frequently deliver value with reduced cost, waste, and risk because we fully embrace what DevSecOps is supposed to be all about.
Our cloud-based delivery pipelines leverage best-of-class tools that interoperate seamlessly. This approach provides disruptiveOps with continuous upgrading, maintenance, and monitoring at a dramatically lower ICO and RCO. Our development teams love this approach because they can spend more time what they love to do vice having to maintain tools, perform manual delivery and deployments tasks, etc.
We practice core concepts like Continuous Integration (CI), Continuous Delivery/Deployment (CD), Continuous Automated Testing , and Continuous Monitoring to establish testing consistency and increase stability with functional and Non-Functional Requirements (NFR) within our microservices and products. Exploiting these concepts reduces our RCO and provides us a greater sense of comfort to release on a daily basis.
- Continuous Integration prevents bad code and scripts from being pushed to our repositories
- Continuous Delivery eliminates the manual activities of moving code, scripts, and data to other environments and while increasing quality because of the built-in automated tests
- Continuous Automated Testing increases quality of functional requirements and NFRs and eliminates low-quality code and scripts from being pushed to higher environments
- Continuous Monitoring provide real-time notifications of failed builds, tests, and impairments so the team can swarm and overcome the challenge
Relevant Technical Stacks
To ensure our technical stacks are relevant and secure the engineer teams review them every other Sprint to look for updates and establish a plan to quickly upgrade them. We have discovered that this high frequency of updates has actually been less disruptive and problematic since the updates are always incremental in nature.
Learn more about our technical stacks here
Within disruptiveOps we utilize a lightweight architecture approach that includes the minimal documentation and imagery so its memorable, impactful, and easily explainable to customers and partners. Our Enterprise Architect collaborates with the engineer teams at least monthly to review it for relevancy and readability.
We built disruptiveOps suite of products as the there was no like-solutions in the market and we needed them to help our clients with the Agile Transformations. We continually improve these products to meet our needs and those who we serve.