Many teams struggle to deliver a Product Increment at the end of every Sprint. Here are the top 5 reasons why teams can’t do that consistently:
Lack of understanding of what a Product Increment is
There is a general lack of understanding as to what a Product Increment is and how we build things iteratively and incrementally. Many teams adopt Scrum but still approach development the same old way. Build widget A in Sprint 1, build B in Sprint 2, and build C in Sprint 3, and in Sprint 4, we put A+B+C together. In Scrum, a Product Increment is whatever you previously built, plus anything new you built in this last Sprint (the increment). So, we build widget A in Sprint 1, we build B and connect it to widget A in Sprint 2, and we build C and connect it to A+B+C in Sprint 3. When we build things iteratively and incrementally, we always have a working version of our product running all the time. We always improve on what we already have and then add to it. If you are doing something only once, you are not iterating. If you are not adding to what you already have, you are not incrementing.
Lack of skills on how to build things iteratively and incrementally
There is a lack of skills and knowledge in terms of how to actually build things iteratively and incrementally. Developers don’t learn this stuff in school, yet we expect them to know how to do it without training. This leads us to the Developer Training Dilemma.
Siloed roles
Siloed roles or teams are another problem. This means we are doing Scrum, but the team is not cross-functional, does not have the necessary skills to take an idea from conception to production, and cannot deliver value without hand-offs to another team. Knowledge is siloed and organizationally we are still structured with tons of dependencies between teams and between team members. A user story gets handed off from one team member to the next, or from one component team to the next before it gets completed. This creates bottlenecks and sub-optimizations as we end up ordering our work based on who is available instead of what is most valuable.
Quality is an afterthought
Testing and quality are still an afterthought. We are still in this mindset of build first then check for quality later. We still approach things in a phased approach. We need to transition to building quality in and shifting testing to the left. There should be no phases. From the beginning we want to build a quality product. Quality considerations happen as we are building the product, not once we are done with it.
Lack of automation
There is zero to no test automation, no build automation, and no deployment automation leading to long and painful testing cycles and fragile deployments.
Let’s take a look at the Agile Engineering practices that are essential to succeeding with Scrum and overcoming these struggles that teams face with trying to deliver a Product Increment at the end of each and every Sprint.