3 Things I Learned from Scrum That Can Help Start-ups
5 January 2016
I held a discovery workshop for start-ups in Bucharest recently, helping attendees determine whether Scrum was the right solution for their new venture, and if it was, how they could incorporate it into their work flow. The one good thing about talking to people (I wouldn't use the word "teaching" because it sounds too grand for what actually happened) about Scrum and Agile in general is that I usually learn as much as the person I'm speaking with. So I thought I'd share three insights from the workshop.
Damn those stakeholders
One of my major motivations for holding this workshop was my love-hate relationship with stakeholders, and the belief that getting a clear vision for the start-ups and not letting things (i.e., management) interfere with that vision would make deploying Scrum easier. There's no one to hit you on the nose with the Gantt chart, estimates, or milestones, so let the congratulatory mutual back-patting commence, right? Well, it turns out that I was wrong, which might as well be the subtitle for this article.
I realized that the negative interference some stakeholders provide is balanced by the good interference provided by others. Determining which features your product should have is pretty hard when you have no business analysts, requirements, market/business insight, or intelligence.
You could say that your users are your ultimate stakeholders, so what they want is most important. However, in a saturated market that most start-ups will face, getting insight into generating a user base requires a great product and some good marketing or word of mouth. On the other hand, developing a good product usually requires users to help you refine it. You can see why this might be a problem. Consequently, most start-ups get caught in a Catch-22, which brings me to my second point.
Product vision is not 20/20 (even in start-ups)
This was completely a mea culpa item: I didn't really focus that much on "developing your product vision" as a theme because I sort of, maybe, kind of assumed (and we all know how that works out) that once you've reached the actual starting-a-start-up phase and getting-some-people-on-board phase, you have a decent wireframe of your vision.
Although most of the people I spoke with did have a decent idea, a few features, definitely some code, and some even had a user they were building it for, getting from an idea to a product vision is where a lot of start-ups trip up. And I don't mean vision as in "I know what my product is," I mean vision as in a high-resolution snapshot of what it is, whom it's for, what problem it solves, and what value it brings. Stakeholders really help point that 99 percent perspiration in the right direction.
The problem is that most start-ups build a product for themselves or their friends, or build a tweaked version of a product that's already out there. Some are even building a product that already exists in another form. And while these products aren't necessarily bad (apart from that last one), start-up founders aren't really a good persona for your product. Getting any kind of user base without user story points is going to be nearly impossible.
Even if you're one of those start-ups that does pin down its product vision, the fun doesn't stop. Extracting features from that vision and distilling them into user stories is just as hard, if not harder, for start-ups as it is for Fortune 500 companies.
Product owners for the win
Here we have a bit of a religious difference, because most start-ups are primarily just developers, most of whom have either tried and disliked or completely eschewed "corporate <insert country here>". Telling them, even in the early stages, that they need to get someone with a bit of a business acumen on board to become a product owner is going to rock the boat.
However, I remain steadfast in my belief that the best product owner is a nontechnical one. Of all the role incompatibilities out there, I think the product owner-dev team member is the biggest one. Having someone whose only job is maximizing value and providing nontechnical feedback, without actually coding any of the features, frees up developers (or likely founders) to focus on what they like doing (which is actually building). It also ensures that the reviews are better, because a nondeveloper-product owner is not going to have an emotional attachment to that feature he coded high on passion and Red Bull®.
This workshop pretty much cemented my view that product owners are among the most, if not the most, important elements of a successful Scrum project. For start-ups this probably means a product owner who has bought into the founder's idea, someone who is just as passionate about it, who wants it to succeed, and is willing to fight tooth and nail for it, without trying to dominate or take over the product vision.
You have to be the vision's greatest champion while acknowledging that the developers in your team own it just as much as you do, because it's their idea. Being a product owner for a start-up is much more difficult than being a product owner for an established company. And if you don't think that sounds hard at all, then please send me an email, because I know a few start-ups that would really like to work with you.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.8 (6 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.