9 Engineering Teams Share How They Structure Their Software Development Life Cycles

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

 

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.

 

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.

 

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.

 

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. 

 

 

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.

 

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.

 

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.

 

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.  

 

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.