We get to work with clients across North America every day to help deliver experiences that amaze their customers. Our engagements can vary in scope and time. For some clients, we provide embedded team members where our developers work full-time for a client. In other situations, we’re here to add depth to your in-house team with one of our experienced developers or designers.
Then there are the engagements where a client needs a full tech team to bring a new solution to market or move a legacy solution to a modern, manageable infrastructure. It’s in these engagements where our Development Operations (DevOps) team comes in to manage the product development lifecycle - from the idea to production (and around again).
Our product life cycle process is built on the widely used agile Scrum methodology. It’s a set of processes used by development teams around the world to manage simple to complex software projects. We’ll get into an example of how we do this - but at a high level, projects start with epics.
These are large stories of how an end-user will use a product. Examples of these would be “a customer needs to be able to order food and have it delivered” (SkipTheDishes) or “a user needs to be able to share photos easily with friends” (Instagram).
These epics are then broken down into smaller stories that are units of work to be designed and developed. From there, the team moves into sprint planning. Sprints vary by team and project - but the standard sprint lasts two weeks and includes design, development, and testing.
The number of sprints will vary from project to project - but each sprint and the entire project ends with a retrospective. It’s a chance for the team to review the work done, make adjustments, and start the next sprint off with a clear idea of what’s next.
The best way to understand how we work is with an example. Before we dive in, we wanted to acknowledge that our clients trust us with privacy and security. The story you are about to hear is true. Only the names have been changed to protect their privacy.
The epic story of a simple PDF
One of our insurance clients came to us with a scope of work in mind. It was a seemingly simple project and came in the form of something most of use a few times a week - a PDF form. Our client has over 25,000 advisors and they send the form to clients to complete when they’re applying for life insurance.
Taking something that’s done with paper or pencil (or a fillable PDF) and moving it to an app or the web is described as digital transformation. Our client didn’t say those words, they simply said “...we need to put this PDF online.”
The initial scope of work for the project became the epic stories we built the development plan around. As we worked through planning with the client, the project scope was refined to include all the integration points needed to put the PDF online. While the client’s customer is only supposed to see the website for applying for life insurance, we all know there’s way more going on under the hood.
The project scope increased to included their advisor network being managed through the platform. We also built-in tools for the client’s advisors to communicate with their clients. This included security-focused features like capturing signatures of legal documents and tracking of the underwriting process.
The devil is the details
Managing a project of this scope is no easy task. As our team works with a client to refine the stories, we move them into a project planning tool of choice - JIRA. (If you’re a project manager, you might enjoy this JIRA Jr. video) All of a project’s stories are kept in a backlog. During each sprint planning session, stories are assigned based on priority and timeline.
Sprint planning gives the team a chance to ask any additional questions about each task. It’s also the way our team can understand all the moving parts. Communication is key to any project. In a fast-paced development project, having a team that knows how to work as a unit means the difference between on-time deliveries and delays.
When a sprint starts, we move through the project’s JIRA board. Each development day, we use daily standups to review tasks. If there is an issue or question, the standups give us a chance to figure it out as a team.
Once a sprint has been completed, we have a sprint retrospective meeting. It’s a meeting with a purpose. It helps us create a shared understanding of what went well, what didn’t go as planned, and what can be improved for the next sprint.
Test and then test again
“I don’t care if it works on your machine! We are not shipping your machine!”— Vidiu Platon
As the developers complete their work in a sprint, we start our testing process. DevOps is built around not just continuous development, but continuous testing too. In this insurance project, we had both a QA environment and a staging environment. Code was first tested in the QA environment. This testing includes automated testing and manual testing. Once it passes there, the code is then moved to the staging environment where we run that cycle of testing over again.
Our insurance client also had access to the staging environment so we can review it with them in real-time. Once the code is accepted in testing we move that JIRA ticket over to “done”. If for some reason it doesn’t, we move it back to the “to do” column and we work on it again in the next sprint. This continues until the work is accepted by the client.
Ship it
The most exciting time for our clients (and for us) is deployment. As we near the completion of the last sprint, our team has already been working with the client to plan out the launch of the project - from a new website going live to submitting apps to the Apple App and Google Play stores.
With our insurance project, we worked with the client to create a bi-weekly deployment schedule. The launch went great. The days of submitting a PDF and manual data entry were over. Even at this stage though, the testing hadn’t stopped. Before we deploy any code to production, it gets retested before we deliver it to the client.
Earlier, we talked about our retrospective meetings after a sprint ends. When a project ends, we also have a retrospective - and the client joins us for this one. These end of project retrospectives help us get a better understanding of their experience with the project. Our development process is built around continuous improvement - for our client’s projects and BitBakery as a team.
