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’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.
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.
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.
