Why you should consider adopting one week sprints

Nine months ago, upon the early days of the COVID-19 pandemic, our R&D team at Hysolate has shifted its focus towards building our next-gen product, bringing a new concept into the endpoint security world: Isolated Workspace as a Service (IWaaS). While the concept of endpoint security through virtualization wasn’t new to us, we planned on building a new, innovative product on very aggressive timelines.

Most of you are probably familiar with Scrum – a common agile methodology for delivering great products. While Scrum does not dictate a specific sprint length, the vast majority of teams are aiming to implement a standard two-week sprint.

In this blog post, I’ll go over several reasons why I believe any startup should seriously consider implementing one week sprints. But first, let’s start by going over the main concerns that you may have in mind when considering such an option.

The common concerns

Let’s admit it – most companies are struggling to implement an effective two-week Scrum successfully. If you’ll suggest squeezing this mess into one single week – you better expect to see some raised eyebrows, and perhaps some rubber ducks and flip flops flying in your direction.

Some of the common arguments against one week sprints are:

• Wasting too much time on ceremonies and preparation overhead
• Not enough time to stabilize the product on every iteration
• Not being able to fit large features into one week
• No buffer for errors

At Hysolate, we develop both a cloud service as well as a rather advanced endpoint product. Some of the capabilities of our endpoint product rely heavily on the user environment that it runs on. Functionality may depend on many factors, such as hardware capabilities, OS versions, OS configurations, or other 3rd party applications that may run side-by-side on the same OS. This nature of our product makes it even more challenging to test and stabilize it frequently, and yet – we still managed to develop and deliver a stable, enterprise-grade product, to production – week after week (and we’ve done so successfully for almost a year now). So while all of the concerns above are completely valid, there are several ways they can be mitigated.

But should we even bother to deal with them in the first place? First, let’s discuss why a one-week cadence is especially important if you’re a growing startup (as opposed to a mature organization).

Why is a faster pace crucial for growing startups?

While Scrum can be implemented in different kinds of organizations and industries, it’s much easier to implement in a relatively mature and stable business. For that same reason – many startups only “state” they are working in Scrum, while failing to implement it in practice.

So what’s so special about growing startups? Let’s take a look at some of the major differences:

• Less certainty. By definition, startups are always in search of a great product/market fit. Short sprints allow us to re-calibrate more often by delivering to customers earlier, and creating a more frequent feedback loop. Product priorities can be very flexible, and we can learn something new about our customers that may completely change our focus (they need feature X and not feature Y), or we can focus our efforts when trying to win a key customer over. 
• Lower product maturity. An early stage startup usually means an early stage product, with less features and more gaps than what customers are willing to pay for. When there is not much feature content yet, early delivery really counts. 
• Less resources. Startups usually act on more limited resources – from Product to R&D teams, the startup must improve fast and be efficient. The amount of resources that can be invested in anything that doesn’t produce immediate value to your users, like heavy investments in automated tests and infrastructure – is very limited.

Having two-week sprints together with a period of stabilization in a staging environment, usually means that the minimal cycle from receiving a customer request up until implementation – becomes at least four weeks long. In practice, this would usually take even more – as features need to be defined by the product team before they are actually executed. This is an eternity in terms of a growing startup company, when your customers are expecting you to deliver quickly.

Some additional benefits are:

• Short sprints force us to plan carefully and be very effective.
• Short sprints force us to strip-down new features into the real MVP that can be delivered to customers – providing us with a shorter feedback loop.
• Harder to negotiate unready product requirements into the sprint – resulting in less scope changes to ongoing sprints and less production hotfixes.

So why not stick with Continuous Deployment instead?

As smaller startup companies have limited resources to spend on building automated testing infrastructures, many startups rule out the option of going with a Continuous Deployment strategy. Instead, they choose to implement Continuous Delivery, together with some form of “Staging” environment that is used to stabilize the product for at least another sprint before it reaches production customers.

Adjusting your process

Implementing one week sprints isn’t just about frequency – it should be approached as a different methodology. Having the standard Scrum Planning, Review, and Retrospect meetings on a weekly basis, along with daily stand-ups, may end up consuming a large portion of your team’s capacity before the sprint has even started. Having many meetings also has a large overhead in terms of scheduling, context-switching and adding dependencies to your workflow. Instead, adopt the concepts but adjust your process.

Here are a few examples to how we adjusted the process at Hysolate:

• Daily Scrum: should be short and concise, usually around 15 minutes. We try to avoid discussions that are only relevant to a few members of the team, and whenever possible – defer these topics to be concluded in a follow-up discussion in a smaller forum.
• Planning: one weekly meeting, which usually takes around 60 minutes. There is significant planning work that is performed individually by every team member prior to the formal planning meeting. Each team member plans and estimates their work in the upcoming sprints – while the planning meeting is designated to sync and review the general plan. In many cases we actually finished the planning in even 30 minutes or less.
• Review: instead of a weekly review meeting, we use video-capturing to demo all features asynchronously, and send the recordings on a dedicated Slack channel, for any feedback and follow-up requests. The same recordings turn out to be very useful – and may also serve as a valuable documentation and training resource.
• Retrospective: once a month. We maintain a shared online document which team members can add discussion points to, throughout the month. Then, in the next retrospective meeting, we use it as a basis to keep the discussion effective.
• Process automation: we automate things like weekly update emails that share the content that is planned for the current sprint or the announcement to internal stakeholders about the delivered content. When ceremonies happen on a weekly basis, it becomes important to reduce such manual overhead. 
• Hyper-breakdown: to successfully implement one-week sprints, you are going to need to perform an aggressive breakdown of each and every task in your backlog. New features will typically be broken down to multiple “internal” tasks and a few, small customer-facing features.
• Avoid unplanned work: take full advantage of your very short sprints – next sprint is always just around the corner, so negotiating unplanned work into the sprint should almost never happen.

The Downside of One Week Sprints

While one-week sprints can be a highly effective approach, it’s not only sunshine and rainbows. There are still significant challenges that you will have to overcome. For example:

• Larger investment in planning. Hyper-breakdown of every task and feature is a must, but performing such a breakdown often requires more time and effort.
• Less time to stabilize the product. One week means significantly less time for product dogfooding, and to perform iterations on regression bugs. Usually, making a larger investment in automated tests may address this concern, but in practice, early-stage startups cannot afford major investments in testing infrastructure over additional product content. We compensate for this shorter stabilization time by being able to very quickly deliver hotfixes, mostly in our staging environment, but also in production – when necessary.
• Planned/Unplanned changes have a larger impact on the sprint. Any unplanned change becomes two times larger, and a single vacation day becomes 20% of the sprint.

When should we switch to longer sprints?

When we had just begun developing our new product, the product backlog was practically non-existent. As our new product gained some mileage, more and more customer requirements came in and were prioritized in an ever-growing product backlog.

Some signs that it might be a good time to consider switching to longer sprints:

• The product quality doesn’t meet the target quality bar.
• You are considering implementing continuous deployment.
• The general product roadmap is more stable and clear.
• The product backlog for the next 4 weeks or so – is well-defined and ready for execution.

In Conclusion

If your initial hunch was that squeezing Scrum sprints into one single week is impossible – then you are probably right. However, Scrum is just a tool, and not a “one-size-fits-all”. Use it wisely, rather than forcing your team into the pattern. By adjusting the process to fit a single week schedule – it is certainly possible to achieve effective, hyper-agile processes, where customers get exactly what they need – at an incredible pace.

Having said that, even after adjusting the process, you will still need to establish clear development processes, and high discipline will still be an inevitable prerequisite in order to implement this approach successfully – especially when some (or all) of your team members are working remotely.

Having a team of strongly independent, multi-disciplinary engineers – that can communicate, arrange, plan, and breakdown their work effectively – is crucial to succeed in such a challenging method. Luckily, I am lucky enough to have such a great bunch of people around me – and together we calibrate the process and learn every day.

The post Why you should consider adopting one week sprints appeared first on Hysolate.

*** This is a Security Bloggers Network syndicated blog from Blog – Hysolate authored by Alon Kollmann. Read the original post at: https://www.hysolate.com/blog/why-you-should-consider-adopting-one-week-sprints/