back issue: operate at maximum velocity
This was originally posted by me to medium on Jul 22, 2014.
Optimizing your product development methodology to achieve super-human delivery times.
Time is money. When we talk about velocity, at the end of the day we’re talking about cost. Not only cost of engineering but also opportunity cost. The faster your team can ship, test, and pivot the less chance the established brands and copycats can keep up.
If there’s one thing our company has become known for, it’s speed. This isn’t an accident. We’ve gone to great lengths to eradicate wasteful process, keep our teams light yet powerful, tighten our feedback loops, reuse code, and simplify our approach wherever possible. This has resulted in the unprecedented velocity that companies have come to count on when calling us.
Lighten Your Process Load
Every process comes at a cost. As such, you should keep a close eye on each one you introduce. Question each and every one of them like a 30 year old biker coming to pick up your teenage daughter for the prom.
Sometimes the time cost required to follow a process is larger than the problem warrants. For instance, if we spend 2 hours every week on a process to avoid Problem X, but Problem X really only costs maybe 4 hours of productivity every 6 weeks then we’re losing 8 hours of availability by following said process. Off with its head!
Don’t over specify
A great example of a place many companies could save time is in product specification. Even if you’re the greatest leader the world has ever seen, your team’s collective cognitive capacity far exceeds yours. The role of a leader isn’t to solve all your team’s problems, it’s to leverage your team’s talents to overcome them. Leaders need to communicate the vision of what needs doing, not to dictate how it gets done.
Arbitrary meetings must die
Meetings kill more time than just about any other process. Rather than holding long meetings (arbitrarily set on the calendar with large groups of people) hold short ones when urgent need arises and when it’s not urgent, collaborate asynchronously using Yammer or Slack (or whatever you use).
Keeping your team on task and in the zone is more important than getting everyone in a room to gather information that has already been shared online in other channels for the benefit of leadership.
Calculated Chaos
If this sounds like total chaos then you’re forming the wrong picture. Of course you still specify your features, you still have meetings, you’re still required to maintain some process, but at the same time you don’t have to specify every pixel and charting library.
The idea is to tailor the depth of your process to the team doing the work. Give them just enough process to get the job done right while getting out of their way enough to allow them to do it quickly.
Small Ships Move Faster
The smaller you can make a ship the faster it can move, change course, and react. Smaller teams make it easier it to communicate well, collaborate, and arrive at a consensus. All of this results in greasy-greasy speed.
Hire product minded talent with broad skill sets
This is a founding principal of Must Win. Mike and I are a great team because between the two of us you essentially have above-average coverage of just about every important MVP development skill (ux design, front end development, back end development, ops, scaling, etc.) This allowed us to take on end-to-end projects on day one with a product team of two.
Since then, everyone we’ve added has had a broad skill set. Jeanette is our back office swiss army knife, Jose is an end-to-end developer and a front end expert, Dylan is an end-to-end developer, Matt is a front end developer and a designer.
Having a team comprised of multi-talented individuals allows us to take a project’s needs and create the smallest possible team to tackle it while distributing the work enough to get it done on time. We like to use teams of three, AKA the “Triangle Offense,” usually consisting of two core contributors and a role-player. Project needs and team availability vary. Sometimes a team is only one person, two people, or even four, but they’re always as small, nimble, and powerful as possible.
Tighten Your Feedback Loops
The shrinking doesn’t end at process and team size. Reducing your sprint size allows you to take on smaller chunks of work while giving more opportunity for feedback. This allows you to change course more quickly, makes it easier to test, and opens fewer opportunities for regressions to sneak into the application. Lastly, this gives you the opportunity to offer more frequent feedback to your team, making it easier to avoid pitfalls and bad habits.
Reduce, Recycle, Reuse
Finally, it’s important to make smarter development choices. This can mean knowing when to leverage open source code and paid libraries as well as optimizing your code for future maintenance.
Stand on the Shoulders of Giants
Reinventing the wheel never made a project run quicker. Today, in the era of GitHub and Stack Overflow, there are millions of libraries and snippets one could use as a starting point for just about any job imaginable. How much time can this save? On a given MVP project we use anywhere from 30-50 open source libraries. Most of these are ones we use often (think Ruby, Node, Bootstrap, Angular, Devise, etc.), others are libraries we use for feature-specific needs (charting libraries, API integrations, etc.)
Imagine how much time you can save if you have the choice between writing 30-50 libraries or using ones written by thousands of contributors over the course of the last five years. What are the odds you can reasonably write something better than they could, more quickly? Even if their library doesn’t do everything you need it to it will most likely be better to extend it than start from the ground zero.
Simplify Execution
It’s extremely important to avoid “gold plated” features and overly complex code. The more simple you can make your work the easier it will be to maintain in the future. Saving not only cost today but going forward. Speed today at the cost of tomorrow is not what we’re after. Simple, maintainable, and reusable code is what we’re after.
“Embrace simplicity in your engineering. The best engineering usually isn’t showy or intense-looking. Given the same result, the simpler code is more valuable to your organization. This will often be unsatisfying to people’s egos, but the best engineers have nothing to prove.”
“When I actually became a real engineer, I realized the simpler I could build something and the less it needed documentation and illustration, the better off my coworkers were — the faster we could all build the thing we were hired to build.”
— Kris Gale (source)
Avoid Dogma
We like to think of ourselves as technology and process agnostic. There is no one perfect way to do something. Because of this we’re quick to slaughter sacred cows. If something isn’t working then you have to be willing to part ways with it, as quickly as possible, just as you would with a featureset that was clearly not improving your product.
Our religion isn’t Ruby on Rails, Agile Development, MVC, TDD, etc — we kneel at the altar of Velocity. If it makes it easier to make things, ship them, and maintain them then that’s what we do. At the end of the day your startup’s ability to survive might just depend on reducing development and opportunity cost.
