When it comes to choosing a software development life cycle, there’s no one-size-fits-all approach.
There are a handful of factors to consider when evaluating methodologies like Agile, Scrum and Kanban, such as the needs of the business and its stakeholders, the size and structure of the engineering team and the size and complexity of the software. Xactly Corp Vice President of Engineering Kandarp Desai said his team follows the Agile principles since “customer focus” is one of their core principles.
“With Agile, Xactly is able to deliver high-quality customer valued products in a rapid and efficient manner,” Desai said.
But just because an Agile methodology is in place does not make it permanent. For many companies, trial and error is standard as projects and team sizes grow.
Principal Technical Project Manager Allison Utter said engineers at Mersive are constantly evaluating their software development process to ensure it allows them to move quickly, but efficiently.
“I imagine that our structure will look different a year from now as we continue to evolve,” Utter added.
We talked to 20 engineers who gave us insight into the methods they use for software development life cycles. Whether it’s Agile, Scrum or Agile Scrum, here’s why they chose certain structures, and the benefits they’ve seen as a result.
Quantcast
Quantcast’s Durban Frazer said that one of the biggest benefits of the team’s current software development life cycle is ongoing experimentation. According to the head of Seattle engineering, the current planning process makes it easy for anyone to suggest improvements, and regular retrospectives allow developers to review what’s working and test new ideas.
Give us some insight into your team’s software development life cycle.
We use a mixture of Scrum and Waterfall approaches depending on the size of the project. Each sprint is usually a combination of tasks that stand on their own and tasks that ladder up to a larger project. For example, spending two days implementing a new feature that makes development easier may be a smaller task. Larger projects, like switching a certain reporting system from a batch process to a real-time process, are typically scoped out at the beginning of the quarter. Once engineering teams and PMs determine what they can release over the quarter, the engineers will plan out the more specific tasks needed to support this new feature on a sprint-by-sprint basis.
For large projects (6-12 months) such as making sure the entire company supports GDPR, we create a small team made up of a product manager, project manager and technical lead. They coordinate technical design and project work across different teams.
"Each sprint is usually a combination of tasks that stand on their own and tasks that ladder up to a larger project.’’
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
As we continue to experiment on this process, the most substantial change came about three years ago. We had gotten too big to use the ad-hoc, informal planning processes we had. Employees weren’t sure how to ask another team for help or who was in charge of building what.
Our current approach has several advantages. Engineers are always involved in setting the roadmap. It could be as small as choosing minor tasks for the next sprint or as large as setting the technical roadmap for many months. Because we are constantly involved in planning, we can easily make changes as new information or challenges come up.
It provides an easy way of communicating procedure to others. Daily standups, sprint planning and reviews help inform everyone of the work being done, which results in discussions about alternative approaches and advice on how to better tackle the problem. Sprint boards and cross-team sprint meetings help communicate team progress to other dependent teams.
Ookla
According to VP of Software Development Marc von Holzen, having a flexible team structure allows Ookla engineers to strike a balance between focused collaboration and individual interests. His team relies on a few specific Agile principles for maximum efficiency, as outlined below.
Give us some insight into your team’s software development life cycle.
The software engineering teams at Ookla use Scrum. However, more importantly, we focus on well-defined roles and the following key Agile principles:
Key Agile Principles
- Product owns the business case, writing and prioritizing small and testable user stories, written as functional slices of a complete solution
- Software engineering owns architecting this solution, sizing user stories and delivering working software
- Scrum masters own running and evolving the process
- Engineering operations owns keeping the lights green, allowing software engineers to focus on development
The composition of Scrum teams can change over time to ensure coverage of all products and to rally around delivery of specific initiatives. Ookla as a whole uses objective and key results (OKRs) to ensure that everyone is pulling in the same direction.
"We are not afraid to experiment with processes.’’
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
The most recent change was driven by a significant increase in our team’s size, as a result of strong company growth three years ago. We are not afraid to experiment with processes, as long as the changes are supported by data and sound engineering principles.
Building small slices allows us to release early and often, which in turn allows us to incorporate learnings and course-correct as needed. The healthy tensions between developing and operating drives us to build observability into our components from the start.
LevelTen Energy
Between tasks like simplifying the power sales process and offering real-time portfolio performance monitoring, LevelTen Energy employees stay busy. CTO Eric Snyder said that in the last few years, the engineering process has evolved in a few key ways as the team has grown. One significant change? They now have multiple scrum teams that they refer to as “squads.”
Give us some insight into your team’s software development life cycle.
We’re an Agile development shop. When we had just a couple of engineers, we followed more of a Kanban flow with minimal structure, releasing as soon as we had something new or interesting to share. As we grew to include remote employees, designers and product managers, we began to follow a more formal Scrum process. It includes backlog planning, two-week sprints and a detailed task board with tickets linked to our source control system.
"Following a scrum process allows us to develop more thoughtful requirements.’’
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
We recently expanded again. We now have multiple scrum teams that we refer to as “squads.” Each squad consists of a mix of engineers, energy analysts, UI/UX designers and a product manager who focuses on a specific area of our platform. Our platform is a two-sided marketplace centered around detailed energy and financial analysis, so there is no shortage of complex problems to solve.
Following a scrum process allows us to develop more thoughtful requirements while giving us flexibility to more easily adjust our plan to meet the needs of our business.
EquityZen
Leadership at EquityZen champions process iteration. Senior Director of Engineering Shanon Levenherz said that his team explicitly calls out any implementation unknowns before moving forward with a pull request. As a result, developers can work smarter and at a consistently steady pace.
Give us some insight into your team’s software development life cycle.
EquityZen engineering leverages a custom development workflow that facilitates predictable delivery of high-quality software. All of our features and fixes start with a problem statement, which is similar to a user story template. It’s comprised of use cases, expected versus actual behaviors and success metrics or KPIs.
Our process is nine steps. It includes a triage and stakeholder consultation, business and technical design (with optional proof of concept), scheduling and implementation via two-week sprints, quality assurance, user acceptance testing and post-deploy measurement.
Our stakeholder consultation ensures that all parties are on the same page. Our business and technical specs strive to uncover all unknowns before any code is written. QA and UAT ensure high-quality output, and post-deploy measurement compares our predicted KPIs against actual business impact.
"Just as we iterate on software development, we also champion process iteration.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
We standardized this process in early 2019 and have made small tweaks over the past year. Just as we iterate on software development, we also champion process iteration. We commonly try new things, often based on team feedback gleaned from bi-weekly retrospectives.
While there have been many benefits, increased engineering throughput has had the biggest impact on the organization. By leveraging consistent, use-case driven specifications, team members don’t spend unnecessary cycles understanding business requirements. Our technical design and proof-of-concept phases provide the time needed to understand and ideate on complex technical challenges and scope definition.
In turn, the resulting implementation tasks are well defined and straightforward. By the time team members start coding, surprises are minimized and engineers can focus on what we do best: writing clear, idiomatic and performant code.
Kustomer
Kustomer’s engineering team works in two-week sprints. Engineering Manager Oren Bukspan said they aren’t picky about where great ideas come from and that necessary preparation is a result of cross-departmental teamwork. Developers have made a recent shift from function-specific roles to expertise-based need fulfillment.
Give us some insight into your team’s software development life cycle.
On Kustomer’s engineering team, we optimize for frequent releases to create value for our customers continuously. We emphasize flexibility and continuous improvement, empowering every teammate to take ownership. We embrace collaboration and automation to limit toil and wasted work.
A new idea at Kustomer can come from anywhere: customers, prospects or our own team. Software engineers, product managers and designers work together to prioritize projects, understand requirements, scope and architect work. They break large projects down into smaller, independently releasable chunks.
Engineers work in two-week sprints to develop features, automated tests and documentation. Every pull request automatically triggers tests in continuous integration, where engineers solicit a review from teammates. Once code is merged to the master branch, we automatically deploy that code to our staging environment. When needed, QA engineers help run additional tests. Engineers finally release their own code to production using our custom Slack bot, often multiple times a day.
"We always strive to maintain flexibility while encouraging ownership.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
The core themes and values of our SDLC stem from our earliest days as a company. We always strive to maintain flexibility while encouraging ownership. To help us scale with these values, we changed from function-specific teams (front end and back end) to Spotify-inspired cross-functional squads (or “skuads”) in mid-2019.
These skuads are organized by product area. They are empowered to act as mini startups with dedicated product managers, designers, engineering managers, front-end engineers, back-end engineers, site reliability engineers and test engineers, who all sit together.
Skuads become experts in their product areas and own related bug fixes and tech debt. This enables everyone, regardless of role, to make informed decisions and have substantial impact and influence in their domain.
Cockroach Labs
As an engineer, there will always be new problems to solve. Cockroach Labs’ Associate Product Manager Emily Horing makes sure her team stays flexible and can quickly respond to any new information throughout the SDLC.
Give us some insight into your team’s software development life cycle.
At Cockroach Labs, we release a section of our database software every six months. To do this, we map out our major initiatives and big features based on our company objectives and feedback collected from our users. Then we do a mini-release every month of the cycle to test new changes and get customer input. New problems to solve crop up all the time, so we always maintain a healthy degree of flexibility. That way we can respond quickly to new information throughout a cycle.
"We do a mini-release every month of the cycle to test new changes and get customer input.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
Though six months may seem like a long time, in the database world, this is a rapid pace of change for mission-critical software. We decided to run our releases at this cadence so that we can provide value to our customers faster but avoid making it difficult for them to keep up to date with the latest version.
When it comes to choosing a software development life cycle, there’s no one-size-fits-all approach.
There are a handful of factors to consider when evaluating methodologies like Agile and Scrum, such as the needs of the business and its stakeholders, the size and structure of the engineering team and the size and complexity of its software. And the use of the same methodology can vary from company to company.
“While we follow the typical Scrum technique, we also put our own spin on it. For example, we don’t have a scrum master,” said Dave Inc. Director of Engineering Dick Fickling. “Instead, we focus on quality assurance and data to guide our work and prioritization throughout the organization.”
Fickling said the focus on quality at the consumer-facing banking app pushes his team to release software updates weekly. StackCommerce Lead Software Engineer Enrique Canals said his team also works under the Scrum framework. However, they mix in Kanban, which Canals said gives the engineering team a greater ability to plan and test.
“Planning and prototyping have always been at the core of our software development process,” Canals said. “The predictability and reliability this process provides allows us to focus more on writing and shipping great software and less on processes and procedures.”
The StackCommerce team even created a game to help them objectively gauge the effort required to work through upcoming backlogs following sprints. Developers at the two companies have taken popular practices and made them their own based on their specific needs and workflows.
Dave Inc.
Dick Fickling
DIRECTOR OF ENGINEERING
Dave Inc.’s Director of Engineering Dick Fickling said adhering to a software development life cycle that allows his team to release updates weekly benefits both customers and engineers. The leader said frequent updates improve the user experience while giving new developers the opportunity to drive tangible impact on the platform early in their careers.
What steps are involved in your team’s software development life cycle?
Our software development life cycle starts with the structure of our team. We have several squads who cover different parts of our product. Each squad has a product manager, quality assurance engineer, designer and between two and six engineers.
The executive team works with product managers to set quarterly goals for the organization. The PMs then break down those goals into quarterly initiatives, working with others on the team to make sure they’re achievable and scoped appropriately. Then, the PM prioritizes the work that makes it into each two-week sprint using the Scrum methodology.
While we follow the typical Scrum technique, we also put our own spin on it. For example, we don’t have a scrum master. Instead, we focus on quality assurance and data to guide our work and prioritization throughout the organization.
Our focus on QA has allowed the development team to have an Agile-focused approach. We release weekly in the app stores, which is rare among software companies. We’re able to do that because we hired our first QA manager when we were a team of around five and throughout the company’s history, we’ve prioritized QA. Quality assurance goes through a full regression and test process every week.
"New members of the team can immediately contribute and see their work go live within a couple of days.”
How did you decide on this particular structure?
We decided on this structure very early on and have continuously evolved it to be in line with the needs of the business. As a fintech app solving pressing financial challenges for our users, our approach needs to be very nimble and allow for rapid iteration and innovation.
Shipping mobile updates every week allows us to not only test and iterate quickly to better serve our users, but it also keeps the team energized. In addition to improving our users’ experience with frequent updates, this weekly approach means that new members of the team can immediately contribute and see their work go live within a couple of days, which is very motivating.
Dave Inc. is Hiring | View 19 Jobs
StackCommerce
Enrique Canals
LEAD SOFTWARE ENGINEER
StackCommerce Lead Software Engineer Enrique Canals said development teams at the company have used an evolved version of the Agile-based methodology since the company’s founding in 2011. Canals said changing their life cycle for enhanced reliability is a crucial component of the dev team’s process, as the platform reaches over 1 billion users per month.
What steps are involved in your team’s software development life cycle?
We practice a form of Agile software development that utilizes aspects of both Scrum and Kanban. We work in sprints, typically two weeks in length, where pre-planned engineering requirements are worked on and completed, releasing incremental progress toward a specific goal. Before the end of a sprint, teams meet to discuss the backlog of upcoming tasks and play a game known as “planning poker.” This game allows the team to reduce bias while unanimously assigning a score of estimated effort to a specific task, also known as “story points.”
When a sprint cycle ends, teams perform a sprint-retrospective to determine what went well, what didn’t and what can be improved. The result of this exercise is a list of action items for the team to take into consideration during the next sprint cycle.
"When a sprint cycle ends, teams perform a sprint-retrospective to determine what went well.”
How did you decide on this particular structure?
We have experimented with various organizational structures focused on different parts of the business and customer experience. However, planning and prototyping have always been at the core of our software development process. The predictability and reliability this process provides allows us to focus more on writing and shipping great software and less on processes and procedures. Our commitment to this Agile workflow has created a stable and reliable infrastructure that has benefited our business and customers for almost a decade.
TrainingPeaks
TrainingPeaks provides athletes with endurance training solutions. To provide a framework for meeting their engineering goals, Chief Engineer Todd Palmer and his team rely on Lean software development methodology. They landed on Lean after grassroots efforts, trial and error and direct experience with customers and the market.
Give us some insight into your team’s software development life cycle.
We use a Lean software development process throughout our organization. Our goal is to deliver value from idea to customer using market-focused, mission-driven teams. Continuous integration, delivery and improvement are core concepts to not only deliver value to our customers, but also for us to improve and grow as an organization. Everyone is capable of shipping their work to production and is responsible for working in small batches, building in quality, getting feedback and taking engineering seriously.
"Our goal is to deliver value from idea to customer using market-focused, mission-driven teams.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
Our path to Lean was started by grassroots engineering efforts, trial and error, learning from our failures, customers and the market. Our efforts were embraced across the organization in large part by the amazing work in the State of DevOps report and the book “Accelerate.” While still a work in progress, the benefit to our teams has been huge. We’re shipping faster with more confidence and are better enabled to meet the needs of our customers.
Pie Insurance
Andy Batta, engineering team lead, explained why his team at Pie Insurance uses Agile Scrum Practice to manage and plan work. Over the last two years, they’ve made refinements to their system, but Batta says Agile Scrum, along with GitHub, allow his team to rapidly grow their organization.
Give us some insight into your team's software development life cycle.
At Pie, we use Agile Scrum with two-week sprints to manage and plan our work. Code changes undergo reviews in GitHub, which requires all unit tests to pass in addition to peer approval before changes are accepted and merged. Once merged, the change undergoes a suite of automated acceptance tests before eventual promotion to production. Each engineering team, which includes an embedded software development engineer in test (SDET), is responsible for quality, so changes to automated acceptance tests are also the responsibility of the engineering team.
"At Pie, we use Agile Scrum with two-week sprints to manage and plan our work.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
We started this approach very early on at Pie and have made refinements over the last two years. The decision to use Agile Scrum and GitHub allowed us to rapidly grow the engineering organization. Most engineers joining our team have experience with GitHub, Agile Scrum, or both, which enables new engineers to quickly make valuable contributions to the team. The focus on quality throughout engineering reduces the time from initial development to production deployment by catching issues earlier in our development life cycle.
Xactly Corp.
Vice President of Engineering Kandarp Desai told us how and why they follow the Agile principles at Xactly Corp. Not only does Agile remove ambiguity, but his team can also operate at a higher speed. After each demo and retrospective, they evaluate their results so they can improve.
Give us some insight into your team's software development life cycle.
Xactly’s engineering team practices Agile software development. Customer focus is an integral part of Xactly’s core principles. By following the 12 Agile principles and the Agile manifesto, Xactly is able to deliver high-quality customer valued products in a rapid and efficient manner. The self-organizing scrum team follows practices such as paired programming, API first development, automated testing, continuous integration and automated deployment. The practice of these concepts enforces a ‘win as a team, lose as a team’ philosophy, which builds a high level of trust among team members. We do regular backlog grooming, sprint planning and standups.
"At the end of each sprint, the scrum team does a demo and retrospective.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
It has helped us remove ambiguity early in the cycle and has allowed us to operate at a higher speed. Continuous integration, automated deployment and automated testing reduce time-to-market for any features. The Agile process has also enabled us to practice a DevOps philosophy, which has improved our operational efficiency.
At the end of each sprint, the scrum team does a demo and retrospective. As Peter Drucker said, “If you can’t measure it, you can’t improve it.” The sprint retrospective aligns very well with this ideology. The retrospective operates on three basic questions: “What went wrong? What went right? How will you improve?” At the end of every two-week sprint, each member of the scrum team must answer those questions. The action items are logged and reviewed by the team during the following sprints. In this way, the retrospective helps to measure and improve every two weeks.
Vertafore
Kyle Lundon, director of development operations, told us why Vertafore began implementing SAFe in 2017. As the business grows, SAFe allows the engineering team to lay out their work in quarterly sets so they can easily forecast deliverables and identify dependencies.
Give us some insight into your team's software development life cycle.
Vertafore began implementing SAFe (Scaled Agile Framework) in 2017 and concluded the rollout across the development organization at the end of 2018. SAFe is a way of developing software within large organizations with a set of workflows that help us to scale lean and utilize Agile practices.
With our SAFe implementation, we lay out our work in quarterly sets of six two-week sprints to help forecast deliverables and identify dependencies. Teams are given time for planning and innovation at the end of each quarter often resulting in unique projects, many of which make their way into the roadmap.
We strive to have the right balance of planned vs. unplanned work, maintenance, tech debt and feature work. The development teams have input into which features they get to work on, how they are broken down and how they are sequenced. Most of our feature teams practice Scrum, while many of our DevOps, performance, and architecture teams follow Kanban.
All of these ways of working allow us to work quickly and pivot confidently as needed. Teams have the support and opportunity to constantly tweak and improve their process while also identifying product and company level improvements to be made.
"Since moving to SAFe, we’ve seen benefits across the board.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
We chose to implement SAFe in 2017 and to simultaneously align our toolset, mainly to help integrate our products better, reduce and remove wasted effort, deliver complex multi-team projects, and to create consistency across the development organization.
Since moving to SAFe, we’ve seen benefits across the board. Namely, we have better dependency identification and coordination, a faster reaction to incorporate multi-team changes, the ability to complete complex cross-product projects, elimination of wasted or duplicated effort, and increased transparency to teams and leadership. In addition to all of these benefits, we’ve seen an increase in both features and releases delivered to customers, and we continue to improve with each passing day.
As we look forward, we see continued improvements gained from transferring process ownership to teams. Using Agile aligns with our mission and goals from the team to the company level, delivers increased value to our customers and shortens the time it takes to deliver a feature from ideation through release.
ShapeShift
To work on cryptocurrency platform ShapeShift, Principal Engineer Adam Samere and his team rely on Kanban. Now, his team can track work and provide insight regarding when engineering bandwidth will be available to tackle planned future work.
Give us some insight into your team's software development life cycle.
At ShapeShift, we utilize the Kanban methodology. When new features are prioritized by the business, engineering defines ‘right-sized’ epics as the top-level container for the proposed changes. Epics are kicked off with company stakeholders and engineering to fully flesh out expectations and allow engineers to ask questions and begin to formulate a solution.
Engineering and product then collaborate on breaking the epic down into stories, which are small tasks that can be completed in one or two days. Stories are then prioritized by product and engineering management to account for any interdependencies before any engineering work starts. Our full-stack engineers pull the top story from the queue and see it through to code review, and the changes are merged. At that point, CI/CD takes the changes to a staging environment for final testing before deploying to production.
"Keeping epics small allows us to keep marching forward delivering value.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
We transitioned to utilizing Kanban methodology at the beginning of 2019. It has been an evolutionary change, which we are continually adapting to best suit our needs. This change has proven beneficial to the organization at large, as we can track work in flight at the epic level, giving valuable real-time insight and allowing us to forecast when engineering bandwidth will be available to tackle planned future work.
Keeping epics small allows us to keep marching forward delivering value, and largely eliminates scope creep by moving new requirements that arise to subsequent epics. Through this transition, we’ve realized significant gains in efficiency and estimations, as well as improved quality and engineering transparency.
Artifact Uprising
Senior Software Engineer Nick Graziano said his team at Artifact Uprising implements Scrum methodology. After they release new functions to customers, Graziano said it’s important to measure their impact to ensure they have delivered the expected results from their testing.
Give us some insight into your team's software development life cycle.
For our software development methodology, we have implemented Scrum. We do not have a dedicated scrum master so we discuss our process and any changes that we would like to make during our retrospectives. Our team working agreement helps to deal with issues that may arise on the team.
We have recently switched over to Trunk-Based Development at AU. The typical life cycle for a story is as follows: Branch off of master, commit work into new branch, pull request new branch into master (this kicks off a build in Jenkins where we do testing and build images for deployment), deploy to testing environment, code review and then QA engineers verify the work against the story's acceptance criteria. If the code is approved and the story is completed, merge the new branch into master and deploy to production.
We use GitHub Enterprise for all of our repositories. For our continuous integration, we use Jenkins for testing code from pull requests and building deployment-ready images when applicable. Deployments for Spring Boot services, Magento and Go services use a Bash tool we created that updates a Kubernetes cluster. All other deployments are done using a Bash script or a Yarn script.
After we have released new functionality to our customers, we measure the impact to see if we have delivered the expected results.
"Since switching, we are more confident in pushing out smaller sets of code more often.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
We have been running Scrum for a number of years. The switch over to Trunk-Based Development happened in the last three months, some repos making the change before others. We are still in the process of migrating everything to this structure.
Since switching, we are more confident in pushing out smaller sets of code more often. This makes it easier to figure out the source of a bug if we release one into production and it makes our deployments less vulnerable since the affected area is much smaller.
Using the Trunk-Based Development approach helps us keep branches short-lived in order to keep the commits smaller and to help change isolation, ease testing and make reviews easier to execute.
NetApp
Software Engineering Manager Amanda Brown explained why they used SAFe at NetApp. Since implementing SAFe two years ago, improvements include, according to Brown, “an increased focus on priorities, more communication across the organization and improved predictability.”
Give us some insight into your team's software development life cycle.
At NetApp Boulder, we use the Scaled Agile Framework (SAFe) for our development lifecycle. This involves planning at the beginning of each program increment and then planning for each iteration. Our iterations (or sprints) are generally two weeks long and have traditional agile ceremonies such as sprint planning, backlog grooming, and daily standups.
"At NetApp Boulder, we use the Scaled Agile Framework (SAFe) for our development lifecycle.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
We moved to SAFe across our engineering organization about two years ago. We’ve had some ups and downs learning how to use this new development framework, but we’ve seen improvements such as an increased focus on priorities, more communication across the organization and improved predictability.
FrontSteps
Jim Maggio, director of development at Frontsteps, uses Agile Scrum methodology. Even though they have been utilizing it for awhile, they are still making refinements to the process. Maggio and his team strive to focus on the right initiatives and deliver on commitments in sprints.
Give us some insight into your team's software development life cycle.
Like many SaaS companies, we have adopted an Agile Scrum methodology. Within this methodology, we perform the standard key agile events such as our product team feeding the development backlog with user stories, product and development backlog refinement, sprint planning, product releases and retrospectives. A key component to our successful delivery of features on time is embracing our capacity and how we have performed in previous sprints. This key metric is viewed by the entire development team as well as our product team and CEO. This plays a critical part in our commitments as we look at the business value of all features and determine what will be delivered next.
"We have been using Agile for a long time now, but we are forever refining the process and tools.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
We have been using Agile for a long time now, but we are forever refining the process and tools. We are striving for two key things within the process. The first is to make sure we are working on the right initiatives, the ones that drive the most value for our customers and for the business.
The second is to deliver on our commitments. Commitment in our sprints is critical to our sales, support and implementation teams because it allows them to be trained and prepared to sell, support or implement as soon as features are available and in production. Within our Agile framework, every sprint gives us the opportunity to add key features and value to our products, allowing us to grow strategically.
Mersive
Principal Technical Project Manager Allison Utter and her team rely on the Agile process due to the unique scope of Mersive’s work. To operate with constant flexibility, her team focuses on keeping on task and staying informed.
Give us some insight into your team's software development life cycle.
Agile is at the heart of our process. Because much of our work is unique in scope, timeline, complexity and location of resources, we have found that a one-size-fits-all model isn’t practical. Instead, as teams are formed, we talk about the best way to approach the work including which ceremonies, tools and documentation are needed. We stay flexible to adapt as the work changes to make sure we are all staying on task and informed.
"We are constantly evaluating to make sure our process is allowing us to move quickly, but efficiently.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
Our company is growing rapidly so things are decided upon in an organic manner. We are constantly evaluating to make sure our process is allowing us to move quickly, but efficiently. I imagine that our structure will look different a year from now as we continue to evolve.
When it comes to choosing a software development life cycle, there’s no one-size-fits-all approach.
There are a number of factors to consider when evaluating the best practices that lead to effective software delivery, including the needs of the business and its stakeholders, the size and structure of the engineering team and the complexity of its software. But even with variations among dev teams, one thing that unites all developers is a need for speed and a healthy dose of teamwork.
For CCC’s Telematics Engineering Associate Director of Development Senthil Sadasivam, working at a quick pace means encouraging collaboration to bypass the red tape that can stifle innovation at larger companies. The company’s product and dev team work closely with one another to plan quarterly roadmap sessions, and then see their blueprints come to life.
“Collaboration gives us the leeway to invent new ways of building products without all the necessary paperwork that an established organization might demand,” Sadasivam said.
Engineers at Aceable and Volusion also look for agility and flexibility in their software development processes, which is why they turn to Agile. Volusion CTO Brett McLaughlin said his team puts a spin on the methodology, adopting an “Agile-light” dev process that incorporates sprint retrospectives and measures the velocity of output.
“The bottom line is that we want to move fast, but know how and why we’re moving fast; Agile is the best thing we’ve found to ensure that happens,” said McLaughlin.
Though the following three engineering teams all have a laser focus on continuous delivery, they’ve found ways to modify their SDLCs to fit the unique needs of their businesses.
Volusion
Brett McLaughlin
CTO
Volusion’s CTO Brett McLaughlin said when he joined the e-commerce solutions provider, he saw areas in the current SDLC that were ripe for improvement. Eventually, the dev team began utilizing a streamlined version of Agile that allowed engineers to balance efficiency with intention. Today, McLaughlin said his team is still working to improve their “Agile-light” process, but he’s already seeing a faster release cycle and a greater sense of pride in what’s accomplished in each sprint.
What steps are involved in your team’s software development life cycle?
We use the Agile development process for everything we can; not just engineering, but also in how we manage content, IT, our website and a number of other departments. We’re more of an “Agile-light” shop and push to embody a startup mentality. We keep our sprint planning light and our time in Jira minimal.
For example, we value the Agile sprint retrospective because it forces us to take a step away from the keyboard and actually talk to each other and think about what’s working and what’s not. We value measuring velocity because we want to know if we’re being efficient, and also if we’re working past the point of effectiveness (particularly high velocities are not always a good thing, in my opinion). The bottom line is that we want to move fast, but know how and why we’re moving fast. We always want to be talking to each other about how things are going; Agile is the best thing we’ve found to ensure that happens.
"We keep our sprint planning light and our time in Jira minimal.”
How did you decide on this particular structure?
When I joined Volusion in late 2019, the teams were running a Kanban process in name, but not really in function. As is typical of high-pressure engineering organizations, most of the Agile ceremonies, like regular planning meetings and demos, were abandoned because they “took too much time.” I found that teams that say this are really feeling overworked and over-managed. However, canceling those meetings drops sensible planning, consistent direction and often creates stress because no one is sure if they’re actually making progress.
We put in the light-touch Agile process and I’ll be honest: we’re still getting that in place to the degree that we all want. Estimates are shaky because that’s a skill that takes time, and it’s still tricky to build in the willingness to change focus from one sprint to another. We’re also moving out of an older model of specialization to a team-based approach where anyone can do anything (with help from more experienced team members). The result? We’re starting to see more adaptation, a faster release cycle and a greater sense of pride in what’s accomplished in each sprint.
Aceable
Kevin Nuut
SENIOR ENGINEERING MANAGER
Senior Engineering Manager Kevin Nuut said that as Aceable scaled, his team needed improved methods to track their progress. So they adopted Scrum and Kanban, which, along with self-organized teams, has helped engineers retain their agency and work efficiently. At the heart of this collaborative environment, Nuut said, is a “no ego” mentality that enables developers to fix bugs and deliver new features, together.
What steps are involved in your team’s software development life cycle?
Teams follow a guiding principle from our Agile coach while taking ownership of their own project deliveries within their respective sprints. As they work, engineers are asked to be transparent and caring about their work and how it might impact their team, users and stakeholders. We thrive in a collaborative environment, solving problems together without ego getting in the way of fixing bugs and delivering new features.
While we’re not 100 percent there yet, our dev teams strive to deliver features as continuously as possible. With that in mind, we put a lot of effort into unit testing, end-to-end testing and process tools to guarantee we have an automated pipeline of code-quality testing all the way through release. Our automation and manual quality assurance testing teams are integral parts of our Agile development pods, and we’ve focused a lot of time to bring them into the full process.
"Our automation and manual quality assurance testing teams are integral parts of our Agile development pods.”
How did you decide on this particular structure?
When Aceable was founded, there wasn’t much of an engineering process. Like most startups, it was all about moving fast and getting things off the ground as quickly as possible. As we’ve grown and gotten more complex in the last year, we needed to introduce more processes to make it easier to keep track of everything that’s going on. We introduced Scrum and Kanban and currently have teams on each methodology.
We continue to seek improvement through regular retrospectives that help us refine our processes and value self-organized teams that are given autonomy to solve problems in the best way possible. These practices give us the ability to keep logistical overhead to a minimum, reduce dependencies across teams and allow us to focus on producing value rather than just producing lots of code.
CCC
Senthil Sadasivam
TELEMATICS ENGINEERING ASSOCIATE DIRECTOR OF DEVELOPMENT
Senthil Sadasivam said working across departmental lines is a key part of the development lifecycle at CCC. The engineering leader said the product management and development teams work closely together to plan work for the next few months, which culminates in two-week engineering sprints. Ultimately, Sadasivam said collaboration gives their developers the freedom to invent new ways of building products without all the necessary paperwork that established organizations might demand.
What steps are involved in your team’s software development life cycle?
Our team is organized around two core areas: platform and product. Our platform team takes care of our core abilities and the infrastructure needed to enable stream-processing of live data. Our product team focuses more directly on telematics use-cases for our end customers who are primarily insurance carriers and original equipment manufacturers (OEMs). Both of our teams are a mix of software engineers, architects, quality engineers and product owners.
In our business group, we start our development process with quarterly roadmap sessions. These sessions set the vision and mission for the next three months. Participants include our product management team and key contributors from our dev team. Once the high-level asks are weeded out, our team tries to break them down into manageable chunks of work. After further negotiations between product and development, we refine the requirements further and provide release milestones for the product or feature asks. Then, product owners collaborate with the team to create necessary items in our Jira backlog. Engineers then work in two-week sprint iterations to deliver toward the necessary monthly release milestones.
"We are in start-up mode and speed-to-market and agility are very important.”
How did you decide on this particular structure?
Our current structure is primarily a byproduct of market forces. While CCC as a broader organization has products known to our customers, telematics is an evolving space. We are in start-up mode and speed-to-market and agility are very important in our domain. We are a conduit between OEMs and insurers, so the ability to pivot on short notice is critical for our product success.
We also need to make frugal decisions about our design and infrastructure while still delivering quality to our customers. All of these factors require us to work closely with other teams. Collaboration gives us the leeway to invent new ways of building products without all the necessary paperwork that an established organization might demand.
