I typically see teams in one of 4 stages when adopting Agile practices.
The Multi-Sprint Hand-Off
Teams here are working in Sprints. 2 week Sprints. They have a requirements Sprint, a Design Sprint, a Coding Sprint and a testing Sprint. This might be better than what they were doing before but it is still taking 8 weeks before they complete anything. Yes, they might be using the word Sprint, and they have a product owner, and a scrum master, and they use product backlogs, and user stories, and daily standups. All this does not mean they are doing Scrum or becoming Agile.
The Single Long Sprint
Teams here understand that all software development activities need to happen within a single Sprint. This includes requirements, design, coding, and testing, etc. So those just transitioning into this stage typically try to go with an 8 week Sprint before pivoting to a 4 week Sprint to be more aligned with what a Sprint is in Scrum – 30 days or less.
So now, the first couple of days are spent of requirements, the next couple of days are spent of design, most of the remaining days are spent on coding and they reserve the last day for testing. Now it’s taking 4 weeks to complete a user story, but of course the testers are not happy. They are complaining that the team can’t spend most of the Sprint coding and then just dump everything on them on the last day and expect them to quickly turn things around and have them ready to go.
The Parallel Sprints
Teams here understand that requirements and design in Scrum are progressively elaborated on and this is an ongoing activity that happens in product backlog refinement. So, what remains is coding and testing. However, due to time consuming testing activities, we setup parallel Sprints, 1 for coding and 1 for testing, with the coding sprint feeding the testing sprint, and the next coding sprint feeding the next testing sprint, and so forth. One team focuses on coding and keep coding from one Sprint to the next, while the other team is focuses on testing and is testing what was coded in the previous Sprint. Any bugs found in a testing Sprint get fixed in the next coding Sprint. Now it takes between 4 to 6 weeks to complete a story. Better, but not quite were we want to be at.
The Scrum Sprint
What we want to get to in Scrum is the ability to deliver working items throughout the Sprint, typically every couple of days, and not wait until the end of the Sprint or worse batch things up into several Sprints. This is how you start realizing the benefits of Scrum and get a faster ROI, reduce risk, welcome changing requirements, and pivot to changing market conditions. Most teams struggle to get here or start here on greenfield projects, but then it quickly becomes unsustainable as complexity sets in and coding and testing start taking longer and longer.
Let’s take a look at some of the reasons team struggle with getting to this stage or staying in. Here are the top 5 reasons team struggle with delivering a Product Increment at the end of every Sprint.