Revelry Process : Design and Development for Growth

Revelry Labs is a digital product design and development company.
3 years in business, 40 happy customers, 22 employees,
187 invoices sent, 184 invoices paid, 98% success rate,
$2MM+ in revenue.

This is how we roll; the Revelry Process.

Budgets

Before we end any intake meeting, we talk budget.

We don’t need an exact number, but we need something. It could be the top line number, a range within reason, an hourly or day rate, monthly or yearly allocation of funds. Whatever the case, a financial transaction will take place.

The only way we can get our heads wrapped around the best way to solve a problem is knowing the constraints of a budget we have to work within.

Mike Monterio tells a great story about budgets.

We’ll still talk to you if you don’t have a budget, but everyone’s time is valuable. Let’s not waste it.

Ok, now that we’ve got the budget out of the way, let’s dig in.

Define. Create. Release. Repeat.

We work with our customers and partners to define project goals and objectives from a high level. Then we design and build. Then we release a thing and we start over. There is no point in detailing specifics on how we achieve our collective goals and objectives at the beginning of a project.

“Ideas are cheap and abundant; what is of value is the effective placement of those ideas into situations that develop into action.”
~ Peter Drucker

Similar to ideas, spec documents are almost worthless in digital product development. They can serve as a guideline and can be a good exercise to go through before starting to build something, but how many times have you seen a web or mobile project completed to an original spec? In 15 years, I’ve never seen this happen. Almost everything you write specs for that will take longer than 2–4 weeks to complete a design and build cycle will most likely be outdated by the time anyone gets around to building something against a spec.

I’m not saying we don’t need spec in software development. We need specs, but those specs should be laid out in very small and detailed stories and setup for quick execution and delivery.

A full stack team we deploy on a project consists of a product owner, scrum master, developers, designers, and quality assurance. We also place developer/designer or developer/developer pairs into existing teams.

Product Owners are like bosses. They are the decision makers on all things related to the product and own the user stories.
And all stories should be user stories. Even if the user is system level or a robot. Now, let’s get Agile.

Define.

Once we’ve clearly defined the project objectives and goals from a high level, we dig in and get our hands dirty. We get Agile.

The Product Owner works with our team to break down the high level objectives and goals into Epics. Epics can be thought of as features of digital products. User stories are created within the Epics. And within those user stories, we create acceptance criteria.

Here’s an example of a simple Epic, “messaging” with some user stories.

Epics are created at the beginning of a project. Stories are created one sprint in advance of kickoff.

We review and discuss all stories and acceptance criteria in a sprint kickoff meeting with the entire team working on the product. We score each story on difficulty. Then we create.

Create and Release.

We check in daily as a team. We discuss things we’ve accomplished and what we’re working on. We identify anything blocking progress or changes that need to be addressed and we move on quickly. These daily meetings are typically 10 minutes or less.

We only comp up designs if it’s necessary to communicate the desired functionality of a story and get everyone on the same page.

Stories move from the backlog, to ready, to in progress, to QA, to shipped.

We do work together in pairs, but not 100% of the time.

We use GitHub for distributed version control and issue (story) tracking. Our code is split into multiple branches. The main branch is the stable branch for production. We use a develop branch to keep things in sync across the team during development. Individuals and pairs create their own branch from develop and submit pull requests when ready. All code we write goes through a review process and is continually integrated into a staging environment. Pull requests are always tied to an issue. We use codeship for continuous automated testing and deployment. Once a pull request is merged and passes all tests, that story is assigned accordingly to QA or the Product Owner, in staging, and ready for testing.

Repeat. At the end of the two week sprint we demo to all stakeholders, discuss things that went well and ways we can improve. Rapid iteration is the name of the game. We believe that projects succeed more often with continuous communication and evaluation. Then we start the process over again.

I’ve explained this process so many times. Some get it, some don’t. Our process and production workflow isn’t for everyone. We do bend a bit on a case by case basis. We also adapt to the workflow of other companies and teams when we join active projects. We’re not agile purists by any means.

The strategy is more important than the tactics: Quickly ship small, tangible victories and iterate upon them.

How, Why and Lessons Learned

How

We invoice at the beginning of a sprint and payments are due at the kickoff of the next sprint.

We stay flexible with our contracts. They generally start with a design sprint at this point, so we can clearly define user needs, business goals and the most valuable features to focus on. Some are three, six, or twelve month contracts. And in many cases, one or two sprints are all that’s needed to get an MVP or prototype out the door.

We do not fix-bid projects or propose solutions based on a locked in spec document.

We work together to continuously make the best decisions around creating a quality product within your budget.

Over the years, we’ve developed a toolkit. Our development toolkit is open source; check it out. The toolkit helps us move pretty quick in the initial stages of a project so we can get to the good stuff. It’s a baseline suite of tools that handles auth, payments, and other things out of the box allowing us to focus on core business functionality and provide value from day one.

Our growth is fueled through amazing relationships, happy customers, and straight-up hustle. Our process is not set in stone. We improve our process every day.

Why

So we can produce great digital products. Products that work for users make businesses work better.

Our process may be different, but it works. It works very, very well. We build MVPs and prototypes for startups to test their ideas, enter markets, and help them evolve into established companies. We build quality software to help companies scale and disrupt slow moving competitors.

This is our passion. Integrity is everything. We stand behind the commitments we make and deliver.

Lessons

Companies that continue to stick to traditional methodologies of building products, and using antiquated tools, are being left in the dust. Don’t become one of them. Make the culture change in your organization on your next project and document the process.

Don’t fix-bid projects. Fix the budget and how you approach projects. That doesn’t mean increase your budget. Own your budget and work with people that can execute accordingly and bring your business the most value. The point here is not to spend more money. It’s to ensure that in any given budget, no matter what happens, you come out of it with something valuable.

Rather than trying to squeeze in 10 features, determine the one that will bring the most value. Nail it.

(Chart from intercom.io’s book on product management.)

Then go on to the next and the next and the next. Focus on one thing at a time and scale laterally when demand hits and the budget is in line.

The absolute worst thing that could happen to your product is for it to reach “completion” with a giant bucket of features that are 80% on their way to usable. That’s worth precisely $0. This is why we’re so against fixed bids with frozen spec documents. Per-iteration focus emphasizes completeness and makes learning/adaptation comparatively cheap.

Keeping a process lean, clear, and simple makes it much easier for everyone to be flexible, adapt, and get creative while working within constraints.

We put our business and our reputation on the line every day. When you win, we win. We’re so confident in our team, our work ethic and our revelry process that we guarantee customer satisfaction.

Revelry customers had ideas that are now businesses. Some have a few thousand in revenue, some a few million, and some a few billion. Regardless of the volume of business, we’ve found that the short and focused cycles of our delivery process provide the most value in achieving short and long term goals.

---

Gerard Ramos Growth Lean Agile Process