Run your startup BETTER, not FASTER!

A crash course on OKRs and Agile with Wethos

At the beginning of October, I moved from the Bay Area, California to New York to join Wethos — a social impact startup connecting nonprofits to mission-driven freelancers. It’s great working with a team of people working on something that’s bigger than themselves or other dumb photo-sharing app or app startup solving a first-world problem. I’ll leave my rant for another post.

Anyways after joining this startup, I quickly figured out we were not working as effectively or efficiently as we could have. So I rolled up my sleeves to work with the team to make our work processes better!

How we were working in the past

Here were our problems:

  1. We had poor communication and spent time everyday to re-align on priorities
  2. We had lack of transparency across teams. Our design team wasn’t working close enough to engineering and our marketing team didn’t know what the hell was going on with product.
  3. We had no clear process and structure around project owners. Too many cooks in the kitchen. When it took us a while to make a copy edit, we knew things had to change.
  4. Constant reshuffling of priorities
  5. We had poor and unrealistic time estimates for development
  6. Since we were working with a Waterfall methodology, our work process was not improving. We weren’t iterating and learning from past mistakes.
Thankfully our company was open, honest and willing to learn from our mistakes, unlike this guy!
“Think about your work. How much of your time is wasted while you’re waiting for someone else to finish their work, or for information to be delivered, or because you’re trying to do too many things at once?”

Transitioning from Waterfall to Agile

Before I start this I want to explain that Agile is not a silver bullet to all your company’s problems. It will not ensure successful long-term company planning. However, it is meant to show you problems in your process early and often. It is up to you to solve them!

Here’s what Agile is:

Agile is an iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.

The agile approach can be applied not only to software, but also other areas. Think about marketing. Before spending money on a huge social media campaign, you want to test whether you will reach your target audience effectively. You can run rapid content testing before dropping big dollars to evaluate whether you’re getting the ROI you need.

Agile shows you where problems are

  1. As a leader, it will expose to you organizational issues and systemic challenges.
  2. As a team member, it will expose the impediments and realities of how well you’re delivering your software.
  3. As a project manager, it will expose the faultiness of your planning and estimates, etc. Then it’s up to you to do something about it.

Notice how with Waterfall if you have faulty requirements, you have to fix everything at the end when you realize your key assumptions for the project is wrong. With Agile you’re constantly testing that.

Shout-out to Julie Zhuo for the amazing image!
This is how most startups work. They don’t test what they don’t know, so they wander around in the dark and hope they make it to the finish line and find product-market fit!
This is how great startups and companies work. They realize they don’t know everything that will work, so they constantly test new ideas and evaluate whether it’s getting them closer to their goals.

How to Build A Great Product Roadmap

According to andrea saez to build a successful product roadmap, you need to answer 3 questions.

  1. What are we doing?
  2. Why are we doing it?
  3. How does this tie back to our OKRs?
Example Objective = Improve Project Management Process.
Key Result = Increase Project Completion Rate by 42%

Product Roadmap Tips and Tricks

  • Product Roadmaps should be so clear even your users can understand it.
  • Focus on a few key themes over a period of time with a key outcome.
  • For example, improving project management over the next two quarters.
  • Set one primary goal per theme and measure that goal by one key metric I.e. Decreasing the project abandonment rate by 23%.
  • Make goals aggressive, but achievable.

How To Scrum

  1. Create Product Backlog of user stories that need to be completed to ship product
  2. Conduct Sprint Planning to prioritize what’s most important for the sprint (usually 2 weeks)
  3. Every day or other day during sprint, have stand-up to answer: What have you done? What are you doing next? What are barriers to getting work done?
  4. After the sprint, run a retrospective to answer: What went well? What can we do better?

Do and Donts for Standup

DO:

  • Literally Stand-up. It’ll keep the meeting brief.
  • Make it collaborative
  • Keep Trello or Jira open to see what’s done and what’s not
  • Address small problems before they turn into big ones

DON’T:

  • Constantly set priorities each standup. It should have been done during sprint planning.
  • Don’t rant and rave and turn it into a long meeting
  • Move stand-up to different times everyday. Stick to the process.

Roles For Scrum Team

  1. Product Owner — Understand business and market requirements, prioritizes the work done by team
  2. Scrum Master — facilitator-in-chief, clears obstacles, establishes effective environment, ensures strong team relationships
  3. Scrum Team — team with diverse skills and roles. Drives the plan for each sprint

Example: Assign points to projects in Sprint

  • 1 point project = 1/2 day of work
  • 2 point project = 1 day of work
  • 3 point project = 2 days of work
  • 5 point project = 4 to 5 days of work

The point system is an estimate.

It’s not perfect and doesn’t measure value.

It’s not about scoring the most.

Scrum Guidelines

  • Most important stories get done first.
  • Estimates for unscheduled work are worthless.
  • Stay away from time estimates. Stick to point estimates based on effort, complexity and doubt.
  • Estimates aren’t guesses, but they’re not accurate either.

Most importantly…

If you’re not doing the work, don’t estimate it.

More work is only added in a sprint if it’s urgent. Otherwise it must be put in the backlog. No agile scope creep. The scrum team can say no.

To end it, here’s an excerpt from Jacob Young, our front-end developer teammate.

The “LEAN Startup” and “Agile Methodology” is really a misnomer and results in a lack of forward planning and execution. Instead by always delivering benefits to the customer, one often finds themselves in a position where they cannot stop, pause, and evaluate the direction of the company.

The process of working in a LEAN startup involved a lot of the following:

  • Identifying problems in the product the customer had
  • Solving and shipping that solution as quick as possible
  • Gathering feedback on that change and using it for future change
  • The above doesn’t happen on “sprints” it happens more or less in real-time.

The downside is that if there are literally hundreds of incoming changes per week, there is very little bandwidth for everyone to step back and see the bigger picture.

Maybe there is a trend in the incoming requests? Perhaps they only describe the symptom and not the root cause for a pain point.

The take away I’m trying to get at is this:

  1. Long term thinking is helpful on regular intervals
  2. LEAN is trying to avoid *very long* development cycles in order to reduce the risk of making a wrong turn 1 year ago and not being able to correct it
  3. However taking a *very short* development cycle does not allow the team/company to plan ahead.
  4. There needs to exist a balance between responding to incoming changes and making larger steps.
There is no silver bullet. However, making a process that addresses those things is helpful. If you’re going down an Agile approach, remember the central tool of Agile is actually reflection.

Reflecting means sitting down after a sprint and reviewing how things went. It also means sitting down after multiple sprints and reviewing.

TL;DR

Make a process that allows people to get important work done in short interval
Make established times to stop and re-evaluate large concepts: Ask “how well did we execute on what we said we were going to do in the last 2–3 months”?

And that’s it folks! Now I wish you all the best. Go save the world, dammit!

If you’re interested in signing up for Wethos as a freelancer to do mission-driven or as a non-profit to get affordable talent for project, please do so! Reach me at rohit@wethos.co if you have any questions

Check out my social media links at: