Welcome to RemoteThatWorks, a weekly newsletter hand-typed by the Valentina Thörner, the Empress of Remote herself. Proudly non-AI, and proudly all-opinions-my-own. To work with me, visit valentinathoerner.com
A while ago I wrote about adapting Scrum for your remote team - focussing on the structure that agile methodologies can lend to your approach to work. I chose a monthly cadence for the thought experiment thinking about the reality of marketing teams.
Obviously, those with experience in scrum were quick to point out that sprints are usually time boxed to one or two weeks. So why did I chose four weeks instead? And why does it matter?
First things first: there is no such thing as a Scrum police ready to fine you for adapting the framework to your reality. It’s a framework, not a religion.
The Scrum Guide does say this:
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done,” useable, and potentially releasable Product Increment is created.
The crux of the question though is the “useable and potentially releaseble product increment” - not the exact time frame. For software development, that translates into short sprints. But does the same apply to your marketing campaigns? Or to your leadership development?
It’s not about the time in the frame, it’s about there being a time frame
As a product manager, I have led one-week and two-week sprints, as well as six-week Shape-up cycles (with two weeks of cooldown phases in between). I’ve also led quarter-long quality implementation programs and two day long website redesign sprints.
It’s not about the timeframe in itself, it’s about the timeframe matching the expected result.
Remember, the result is: “a Done, useable, and potentially releaseable Product Increment”.
So what IS your product?
A short detour into the arbitrary reality of time
Before deciding what the “perfect” time for your sprint should be, remember this: two weeks do not equal two weeks. Ever.
Sometimes two weeks allow for twenty hours of focus work.
Sometimes two weeks allow for f* nothing because something was on fire, fund raising got in the way, and one of the crucial people broke her leg on a ski trip.
And that is especially true if you are managing people, not code.
So here’s the thing: your perfect sprint lengths depends on the type of team, the type of releasable Product Increment you are looking at, and reality.
With product team, I’ve learned that weekly or two-week sprints end up being one stressed experience after the other. Humans tend to underestimate the time they need for a taks, AND even the most experienced Scrum master tends to overallocate tasks into each sprint - and, see? Already I am looking at tasks, not the result.
If your sprint is too short, you end up working in tasks so small that you end up forgetting the forrest for that one tree you are focussing on.
Time is meaningless. Time is the basic ingredient.
For me, the magic lies in finding a length that
allows for meaningful results that are easily translatable into the overall strategy,
covers enough time so that you can create something meaningful where every individual understands how this relates to the bigger goals,
acknowledges that short and intense sprints are not a sustainable way to go long distances unless you love hussle culture.
That means, you need to be crystal clear on the potentially releasable product increment.
So, again, what is your product? What is your team’s product?
As the CEO, the company culture is your product.
As the Sales team, your pipeline may be your product.
As the Product team, the Product/Service of the company is the Product.
As the CX team, the way you solve customer queries may be your product.
Those a different types of product, and not all of them lend themselves to really short and intense sprints. All of them can be time-boxed though.
Sprints create accountability through goal setting
Sprints work, because they require the team to set clear goals to be achieved by the end of the sprint (or that’s the original idea. It’s not just about moving tickets from “backlog” to “current sprint”). You are basically defining a result and giving it at time frame.
This time frame allows for accountability, for reporting back, for asking deeper questions.
And, most importantly, time frames kickstart activity and accelerate delivery (towards the end). That’s why a 25min pomodoro works as I am writing this newsletter. And that’s why the two-months vertical focus for your Sales team works.
In practice, in your company, that means you end up with department-based sprints/projects/timelines (to each their own vocabulary).
Sales focus on a new vertical every two months.
Support streamlines a new operational problem every month.
Engineering continues with their weekly sprints.
Product and design pair it down into 6-8 weeks for researching pain points.
None of these is “more right” or “more wrong” than all the other time frames. The important part is the time frame, any time frame.
That said, the product leader needs to know about all those different cadences so they can bring them all together in an overall narrative that everyone can connect to.
And THAT is why, in my opinion, product leadership requires exceptional communicaton skills. Not just for stakeholders, investors, prospects. They are the conductor that makes sure the orchestra plays the same symphony :)
PS: You won’t get it right on the first try. Experiments are your friend.