Top 10 Reasons for Slow Velocity
I work with quite a few product teams, and after a while you start to see patterns. Many organizations are frustrated because they believe that it takes far too long to move from concept to delivery. They often just blame the skills of their developers, which is rarely the root cause in my experience.
In this note I wanted to highlight what I consider the most frequent reasons for slow velocity:
1. Lack of strong product owners. The lack of a strong and capable product owner is typically the largest single reason for slow product. Without such a leader, the team is almost certainly destined to churn. And churn slows everything down, plus it takes a serious toll on team morale.
2. Lack of strong project management. The lack of strong project management is typically the second biggest reason for slow product. Each team needs a true project manager (ScrumMaster for Scrum teams). This should not be the product owner, and it should not be someone with another job. The most important function of the project manager is to remove impediments, and most impediments won’t go away quickly without someone actively chasing them down. We say “pushy but not bossy.” See http://www.svpg.com/product-management-vs-project-management/
3. Infrequent release cycles. Most teams with slow velocity have release vehicles that are too infrequent. On the order of a release vehicle no less frequently than every two weeks. Correcting this typically means getting serious about regression test automation and release automation so that a release candidate can be tested in hours and not weeks or months, and the team can release with confidence.
4. Not including lead engineers during product discovery. The lead engineers need to be key participants in product discovery from day 1. They can often contribute alternative approaches that will be significantly faster to implement, if you include them early enough in the process for the product manager and designer to adjust. If not, their critical input will come too late in the process and the result is, more churn. See http://www.svpg.com/knocking-down-walls/
5. Not utilizing user experience design in discovery and instead having them try to do their work during the sprints. User experience design should be completed before an item gets on the product backlog, and it should be defined “pixel perfect.” If not, the team will be waiting for designs and visual assets (not to mention the very real danger of “feed the beast”). See http://www.svpg.com/design-vs-implementation/ and http://www.svpg.com/feed-the-beast/
6. Lack of product vision and focus. Realize that rapidly shifting roadmap and priorities cause significant churn and substantially reduces the total throughput. This relates to having a strong product owner, but it’s essential that the team have a clear vision of the big picture and how their immediate work contributes to that. See http://www.svpg.com/product-strategy-in-an-agile-world/
7. Lack of dedicated teams. If engineers are treated like chess pieces and reassigned to different areas every project, they won’t gain the expertise, or build the team relationships, necessary for high velocity. See http://www.svpg.com/dedicated-product-teams/
8. Lack of dedicated rapid response team. If the same teams are doing sustaining and escalations work as well as the forward progress work, the interruptions can dramatically slow down the throughput of the team. The critical problems must be fixed, but they don’t necessarily have to be fixed by the same team doing the new development. See http://www.svpg.com/the-rapid-response-team/
9. Inflexible product architecture / technical debt. Often the architecture does not facilitate or enable the rapid evolution of the product. This is not something that can be fixed overnight, but it should be attacked ongoing. See http://www.svpg.com/engineering-wants-to-rewrite/
10. Missing holistic view. It can be difficult for each team to know what the other is up to and how the different parts fit together into a cohesive whole. Teams often thrash and churn because they don’t understand the holistic view and the dependencies and inter-relationships. See http://www.svpg.com/holistic-view-of-product/
There are of course several other root causes of slow product, but these are among the most common culprits. The good news is that each of these can and should be addressed.
However, as important as velocity is, even more important is making sure that the software you do release is actually good software that will make a difference for the business. In my next article I’ll summarize the top reasons for poor product.