The DevOcho Way

We are passionate about delivering great software. Our team has experience working with nearly every size and type of business from SMB to Fortune 500. With more than 25 years experience and hundreds of projects completed, our founder has developed a bullet-proof way to deliver great software. We call this "The DevOcho Way".

When you partner with DevOcho to extend your team and deliver projects, you are hiring a group of people that know how to get things done. This is in large part due to our "DevOcho Way" process. We feel that it truly sets us apart in the industry.

We won't give away all of the trade secrets here, but here is a sneak peak into how we deliver a successful project. This will help set your expectations of what it is like to work with us.

Modified Agile Scrum Process

We believe that Agile Scrum is a great way to organize work. We also believe it can be somewhat wasteful without guardrails that help keep it on track. We have taken the standard Agile Manifesto + Scrum.org guidelines and added a few elements that we believe give us a solid advantage when delivering complex projects.

We know there are people that love Scrum and think it is perfect. We also know there are people that absolutely hate it. And a full spectrum of people that are somewhere in-between. We have developed a slightly modified version that fits really well with building complex projects quickly. Our secret is to add two formal ceremonies to the standard Scrum process. We add a Feature Planning Ceremony and a Feature Approval Ceremony. By running these ceremonies one sprint in advance of when the user stories are needed, we keep a very tidy product backlog for the Scrum Team. This reduces Developer, DevOps, and QA time in planning meetings (which they love) and keeps them focused on building.

Image Depicting the DevOcho Way of building software

We run the two loops above in parallel. Feature Planning leads Feature Development by one sprint. During the sprint, the Scrum Master, UI/UX, and Technical Leader on your project will work with your team to plan the features that the team will build in the next sprint. This process creates a steady, just-in-time, planning approach that guarantees we are planning with the latest user feedback and the best chance for successfully designing the features that are best for the user.

This also allows Sprint Planning to remain largely focused on the technical aspects of the User Stories so the Developers, DevOps, and QA stay engaged. Which has the added benefit of making these meetings faster.

There is a lot more nuance here, for example we have very specific ways we create tickets, wireframes, mock-ups, technical documentation, etc. but these are the details that you will quickly grow to love when you hire us. We are very consistent in how we document our work.

Below are three areas that we think will be interesting to the people who are "process nerds" like our founder:

Sprint Zero

In each project, we start with one sprint dedicated to planning. The goal is for the customer to have a solid start on a Product Roadmap and for our team to understand it. We prefer to hold this as a two week planning session where we lock everyone in a room and build out a rough plan. If this project is a priority to the company this is normally possible. If this project is more of a nice to have, we will have to be more flexible with the stakeholders time.

We believe Product Roadmaps are living documents that will change as the product matures and we learn more about the needs of the users and the marketplace in general. We aren't looking for perfection at this stage, just the major building blocks.

Note: The Developers, DevOps, and QA team members are typically not part of this meeting. They use this time to setup the code base, create automated CI/CD pipelines (that will save them time later), and install and configure any specific software or tools that your project will require.

Output:

  • Initial version of the Product Roadmap
  • Base code, tools, and configuration for your Project

Feature Planning

We maintain a parallel sprint to the developer sprint. We call this the "Feature Planning Sprint". This is where the customer, Scrum Master, Development Team Leaders, and UI/UX team members plan and document User Stories for the Product Backlog. The customer will choose high priority items from the Roadmap and the team will then break those down into smaller units of work called "User Stories". This way the customer is setting the priority and the team is able to document the requirements and wireframes needed to accomplish the work before the developers fully engage.

We are able to do this because we have strong technical leaders. They join this planning session to make sure the work being requested is possible and they help guide the size of each unit of work to ensure it fits in the process.

Output:

  • User Stories
  • Task Tickets (typically DevOps related)
  • Updated Product Backlog
  • Updated Roadmap

Sprint

This is where the work happens. Developers, QA, UI/UX, and DevOps will take work from the Product Backlog and place it in the Sprint Backlog. From there they will divide and conquer. Each member of the team will be focusing on the work they committed to complete in the timeframe of the Sprint. We typically do two week sprints, but occasionally, will extend those up to 4 week sprints if it makes sense for our customer. We pull work from the top of the backlog so the customer's priorities are held.

Our goal in every sprint is to release working software. Typically we don't wait until the end of the sprint because we prefer to work in a Continuous Delivery model, but we adapt to the regulatory and compliance needs of our customer.

Output:

  • Working Software