Early-stage startups are difficult beasts to wrangle, for a number of different reasons. First and foremost, a startup undergoes significant change and/or evolution every 6-months or so (give or take a few months) and, as a consequence, everyone must relearn what they thought was true so that they may execute effectively.
But, for some, this type of environment is life-giving and they quite literally live for those types of challenges! This is why it’s so important to make sure that the folks that you hire early-stage are made fully-aware of what it’s really like to work in a startup.
Changing Our Technical Workflow
Recently, I shared internally with the team that we’d be moving from a more traditional
SCRUM-like technical workflow to one that follows more closely with the
Now, the differences between the two could take quite a bit of time to explain, but, these two charts below are good for a high-level:
Here are my notes that I shared in our team’s Slack Channel:
As you all know, I’ve been working hard to try to reduce my technical overhead as I scale myself with our growing business. And, something that I’ve been reconsidering for some time is changing the fundamental technical workflow to better accommodate the quickly-changing requirements.
Based on the last major retrospective, it’s pretty clear that we need a much more dynamic and fluid process than a more rigid one that we’ve been locked into through traditional Scrum.
Consequently, I’m opting to move towards a more Kanban (light) approach instead of Scrum as we’ve been using.
The higher-level concerns using our existing Scrum is that we’re locked into a 2-week sprint cycle and it’s pretty clear that things change every single week, let alone every two weeks.
When we had a much more clear pathing and feature-set (before feedback and before real, live users) the sprint cycle was fine and felt like we had enough work and had enough clarity around the project (sprints, epics, point clarity and displacement) and the usual ceremonies scaled fine.
But now, the epics (e.g. features) are massive and require 2 if not 3 engineers per epic (including me). Since each task are clearing the 2-week mark consistently, it means that our existing SLDC is broken as we cannot simple build, test, bug-fix, and deploy within a 2-week timetable.
This is in addition to the fact that we deploy only new functionality to the beta when we’ve successfully tested (and successful tests now require at least a full week in and of themselves)!
Closing a sprint as an arbitrary ceremony is a useless ceremony and, as @peter will tell you, Agile exists to serve the development team, not the other way around.
If we move to Kanban then we can have an unchanged workflow and also start new milestone(s) with well-defined core goals / features and allow the closing of those milestones when they are successfully implemented (build / test / deploy).
Estimates and priorities can be adjusted in near-real-time and gaps can be easily covered by shifting roles as they will no longer be pre-defined.
My brother and cofounder, Peter, had these additional comments in the Slack-thread:
Kanban is a work in progress // work in flow // theory of constraints monster. Within the right hands it can be a powerful framework to operate from.
I always say: “If you can’t do scrum right, you won’t do kanban right.”
Kanban requires more discipline than scrum to do well.
At this early stage, when we change a workflow internally we must also change the way we see the entire business. At scale, workflows can be changed without fundamentally changing the entire business but that just can’t happen in the context of a smaller team.
At the end of the day, it doesn’t really matter what strategy or plan or workflow or process that you end up choosing and then using – as long as it allows you to move quickly from ideas and concepts into a working product.
And the more quickly you can get the
cycles down and into a tighter, iterative (feedback) loop, the better! Definitely not a one-size-fits-all when it comes to building great software.