.svg)
Introduction
Time to market is critical because the speed of software development has a significant impact on the success of a product. Launching a product or feature quickly can be the difference between gaining a competitive advantage or falling behind.
A focus on velocity and ship dates
Given the above landscape, one response from an engineering leader might be:
“It’s more important than ever for my team to demonstrate velocity and output, while hitting all milestones.”
On the one hand, this makes some sense. In the current environment, teams need to focus on delivering software to meet tight deadlines. This is especially true in industries where competition is high and the market is constantly changing. Teams are focused on velocity and meeting project deadlines, in what I’d call a date-driven approach to software development.
We’ve all been in organizations where delivery teams had to hit the deadlines that were promised by the business. Even worse, we’ve been in scenarios where financial incentives were directly tied to meeting date-driven targets for software delivery.
Being too focused on velocity and ship dates can be dangerous and compromise quality. Before I suggest the right approach, let me first detail the signs that your team is too date-driven.
Overemphasizing velocity
Pay attention to what is being communicated during sprint reviews and retros. If the delivery team is reporting how much was delivered (i.e., velocity) without communicating what was delivered (i.e., value), it’s a good indicator that the team is too focused on dates.
Here is another graph that we like to include in every sprint review:
This is a real-world example from a sprint review. The scrum master reported the team’s success in delivering 150+ items in a four-week sprint.
The problem?
When we analyzed what was delivered, we found that over 50% of the 150+ items were bug fixes. This is a symptom of being too date-focused and delivery-focused. The team completes tasks quickly and meets its deadlines, but at the expense of thorough testing, code reviews, or related quality assurance measures.
Shifting deadlines and missing commitments
Above is an example of how one of the date-driven teams was building a release candidate. The team’s goal was to release after two sprints (i.e., a monthly release cadence). They just finished Sprint 43 and the “ideal release” should include items front Sprint 43 and Sprint 42 (i.e., the current and previous sprint). But, as we can see, there are 25 carryover items from the previous sprints (e.g., Sprints 40, 38 and 39)that are being included as well.
The data also shows that 20 out of 25 items are either bugs or story issues – the team had to spend time trying to fix issues and bugs that were not addressed in the previous sprints. One might say that some of these items were de-prioritized by the project owner, but the fact that the team spends most of i’s capacity working on bugs clearly shows that the team’s focus is on delivery vs. quality.
Rushed development leads to a higher number of defects, and it is one of the main symptoms of a date-focused mentality.
The downside of a date-driven focus in today’s environment
Let’s relate this back to our original observations about the focus around cost optimization.
Taking a date-driven approach to software development can compromise software quality. Lower quality, in the form of bugs and defects, then has a cascading effect of increasing costs. Your customers lose confidence, you need to spend more dev and QA resources fixing bugs and your future ship dates need to be pushed out.
Hitting a deadline is important, but organizations need to evaluate the negative effect that a date-driven focus has on long-term usability, maintainability, user satisfaction and brand reputation.
Let’s talk about a quality-driven approach instead
First, let me clarify that I’m highlighting a team’s focus here. Dates are important and dates will never go away. Our teams still need to meet our committed dates. Instead, I want to discuss the benefits of focusing on quality while managing to hit our dates.
Teams that focus on quality are more concerned with delivering software that is reliable, secure, and scalable. These teams often take a quality-driven approach to software development, focusing on testing, validation, and collaboration to ensure that the software meets the needs of stakeholders.
When the business wants to reduce time to market, it’s not easy to balance meeting deadlines with developing high-quality software. Quality-driven delivery teams take time to thoroughly test and validate their work before releasing it.
While this approach can give the perception that teams are slower, the proper set-up enables these teams to deliver better software that meets the needs of stakeholders. They also reduce the risk of technical debt and other long-term issues. Ultimately, a quality-driven approach can build a strong foundation for the success of the organization in the long-term.
Here are some signs that your teams are quality-focused.
Release coverage
Missing Coverage is a good metric to use to gauge the team’s focus (i.e., on date vs. quality).
For every release, the delivery team should work on ensuring that testable user stories/bugs have corresponding test cases associated with them. The “Missing Test Cases” metric should be as close to zero as possible. That’s a good indicator that the team is quality-focused: they’re doing proper sprint planning, with adherence to the right quality assurance processes.
Single pane of glass
Quality-related release metrics can be disjointed and require explanation. In order to create alignment between Delivery and Product/Business teams, create release-specific “Defect Removal Efficiency” (DRE) visuals.
The dashboard above shows not only the total number of issues, but also identifies potential defect leakage and process improvement opportunities. For example, delivery teams could look into Integration vs. Test environment delivery and quality processes to understand why the number of defects has doubled.
There are a number of additional graphs and charts that teams can use to visualize quality, but tracking coverage and DRE data typically allows teams to quickly pinpoint potential problem areas.
Conclusion
A large number of defects and missed deployments is usually a good indicator that teams are focused on date-driven delivery and rushed development. In the long run, this leads to a large amount of technical debt, unhappy customers and negative brand image.
Alternatively, teams that practice a quality-driven approach, allocate time to do proper design and focus on building and practicing a QA-first approach usually achieve predictability when it comes to delivery and quality.
