Blog

4 Typical Transitions Teams Go Through When They First Start Adopting Scrum

  • Post author:
  • Reading time:4 mins read
You are currently viewing 4 Typical Transitions Teams Go Through When They First Start Adopting Scrum

Over many consulting engagements, I’ve come to see 4 stages that organizations and teams go through as they try to learn and implement Scrum on their own. Typically, these engagements start when an organization reaches out asking for help as they are not seeing the benefits they expected after adopting Scrum. I usually find the organization at 1 of the first 3 stages.

Stage 1 – The Handoffs.
They say they are doing 2 weeks Sprints, but after observing their teams, I notice that they have broken down their work into a Requirements Sprint followed by a Design Sprint, followed by a Coding Sprint, followed by a Testing Sprint and so on… I explain that this might be a lot better than what they used to do, but in Scrum we want to avoid handoffs and have a cross functional team focused on a deliverable of working software and all these activities need to happen within a single Sprint.

ScrumFall

They agree and decide to go with an 8 weeks Sprint (4*2). I explain that we can do better and in Scrum a Sprint is 30 days or less as we want to have more frequent feedback, reduce our risks, and continuously deliver value. So they settle on a 4 week Sprint as described in Stage 2 below.

Stage 2 – The Long Sprint
Here we have 1 long Sprint where the first 3 days or so are spent on requirements, the next 3 days on design, and the next 13 days on coding and the last day on testing. Of course, this does not end well. The testing folks are not happy and complain that we can’t just dump everything on them on the last day of the Sprint and expect them to finish up testing in such a short time frame.

Still ScrumFall

Stage 3 – The Parallel Sprint
By this time, the team is getting more mature and realizes that in Scrum, requirements and design emerge over time and are progressively elaborated on in an ongoing activity that happens throughout the Sprints known as product backlog refinement. Now their focus is on coding and testing and because most testing is manual and time consuming, they settle on a having a coding Sprint and a testing Sprint happening in parallel, with the testing sprint going over the items that were completed in the previous sprint.

ScrumBut

This might be better than what they were doing before but it’s not were we want to be. Feedback cycles are still too long, and we are back to hand-offs between coding and testing.

Stage 4 -The Aha Sprint
Where we want to be is at a point where we can properly size our product backlog items or stories to be small enough so that they can get completed within half a day to 2 days (assuming a 2 week Sprint). And by completed, we mean coded, tested and deployed to an environment. This way, stories are getting completed throughout the Sprint and all team members are engaged and working on the same Sprint goal.

These stages are primarily due to an initial misunderstanding of what Scrum is as well as a lack of good technical practices, especially around automated testing.

Scrum – Completing PBIs throughout the Sprint

There is actually one more scenario that is very popular: Thinking that Agile or Scrum only applies to development. I talk about that next in the most common misunderstanding of Agile.

Also check out the complete Agile Testing series: