Modularis

You Should Run Sprints, Not Marathons

SHARE THIS

Recently, I was working on a Product Visibility Session for a new client. As we were implementing their company-wide agile process, the time came to decide on the length for each development sprint. Their team had previously used SCRUM with little to no success. They were used to running two to four-week sprints and were in a bit of a shock when we recommended the adaptation of 1-week sprints. They were concerned with not having enough time to deliver meaningful value in such a short span of time.

Additionally, the P/L business unit leader, in spite of spending a great deal of time, effort, and money implementing SCRUM, felt as if the development team “wasn’t yet agile enough”. This is a typical scenario that we help our clients solve. They are familiar with SCRUM, most have had minor to no success following it, and have fallen into a complacent rhythm. Even two weeks is a long time in the agile development world and many things often change. Part of our strategy is to help clients get into a continuous development mindset, on their way to continuous delivery.

The benefits of 1-week sprints may not always be obvious at plain sight. Nevertheless here are a few of them.

Focus on the must-haves.

Shorter sprints require the team to focus on breaking down their units of work efficiently. Since they only have one week to show value, everyone from the product owner to the software engineer has to make sure that only the must-have features are worked on. The scope of every feature is reduced to its bare necessity while still providing value.

Get to market faster.

Once your software development team gets in the groove of delivering incremental value every week, you’ll be able to provide the most wanted features to your clients in a matter of weeks and not months or years.

Reduce risk by being more predictable.

Smaller units of work are easier to estimate, which translates into better accuracy when planning your releases. Better accuracy gives you predictability which leads to risk reduction. Shorter sprints do not translate into fewer mistakes, but less costly ones.

So, get your team thinking sprints and not marathons. With a few adjustments in the way they design their activities, you can be on your way to continuously deliver innovation and stay ahead of the competition.

Head over to LinkedIn and follow us for more Software Product Development Insights

Follow On LinkedIn