Revelry

Your partner in product development

Revelry's Process

A Proven, Lean Agile Approach to Product Development

Let's Talk Process. Connect With Us.

Table of Contents

A Systematized, Optimized Process for Digital Innovation

You’re about to get a behind-the-scenes look at Revelry’s unique and proven Lean Agile product development process, along with the tools and tricks we’ve used to deliver scalable software solutions to hundreds of companies worldwide since 2012.

Our New Orleans-based team relies on this approach to design and build mobile, web, platform, blockchain, and AI/ML applications that help companies across industries get to market and scale faster than their competitors.

product management our process

A Note From Our Founder and CEO

Building software is hard. At Revelry, we’ve optimized our product delivery workflows into a process we call Lean Agile; we apply it to just about every part of our business. We’ve also developed an arsenal of tools that de-risk various delivery tasks; collectively they’re referred to as our Innovation Stack.

The combination of our process and stack eliminates as many meetings as possible and enables productive and time-saving async communication, so product design and engineering teams have the headspace to do their best work and scale in a remote-first world. We’re sharing it here with you, because we’ve learned so much from our industry peers and believe in open collaboration.

No company is the same, but we hope you’ll find ideas and information here to help make your processes more efficient. If you’d like us to chat more, let’s connect and talk about what we can build together.

– Gerard

About Lean Agile

What Is Agile?

Agile is an iterative approach to software development that gained traction on the fringes of developer culture in the early 2000s and has now become a mainstream method.

Agile Alternatives

Older development methodologies imagine the whole castle upfront and plan every brick in advance. They work backward from their ideal end product, create a detailed spec doc, and go heads-down for a few months to develop the product. Unfortunately, by the time they resurface, business needs have often changed – or the budget diminishes while the product is still a pile of features that are 80% done. 80% done is worth zero to a user.

Ship Gold Every Week, One Brick at a Time

We guard against these expensive mistakes with a launch-and-iterate approach that’s extra transparent for our clients. Each week, we place one solid brick down before deciding which brick to add next. And on and on until the castle’s built.

We work in sprints, quickly shipping tangible and high-quality units of software one at a time. First, we imagine the whole system just long enough to lay out a few architecture rules to keep the system flexible. This first sprint focuses on the product’s first grain of core functionality; developing, testing, and launching a unit of 100% solid software.

Then we check in with our partners, identify the next set of crucial features, and start the second sprint. We never create one be-all-end-all spec doc at the start of a project like traditional software consultants might, even though we do just as much planning. It’s spread out through the entire development project.

We Don’t Predict, We Adapt

Our frequent recalibration ensures that for each one week increment, the team only works on features that support the partner’s current business goals and the most urgent needs of their users. This system also lets us rapid-launch products — we can get a working prototype or MVP out in the world in as few as 4 sprints. Many of our engagements last 3-6 months, while some partners work with us for years to continue iterating.

Our Six-Step Lean Agile Process

Step 1: Project Inception

We begin Project Inception with Project Discovery. It includes the formation of a Product Delivery Team (at least one Product Manager, Front-End Design Engineer, Back-End Engineer, and Client/Product Owner) and various exercises to clarify business objectives, project goals, and user needs.

The Project Brief lists the details of who we are building for, what problem we are trying to solve, and why that problem matters. We establish what the smallest valuable Core Loop through the product looks like. That’s where we’ll start. The project might be an MVP web product, new mobile app, a digital marketing campaign, or a complete end-to-end digital transformation of existing business practices.

After setting up the Project Brief, we run our Starter Stories from a Slackbot script. This mostly automated sequence ensures each project is set up in the same way and that no part of the process is left to chance. The first 20 or 30 tasks involved in the setup of a new project used to take hours, or even a day, to complete. At Revelry, the Slackbot script performs these tasks in about 10 seconds:

  • Create the project in GitHub
  • Add the Project Brief template
  • Connect the Agile tools
  • Set up permissions
  • Generate the first batch of stories

Next, we invite clients to a Slack channel. We set up a shared Slack channel for each project, so that the whole team sees all conversations and product development as it unfolds. This complete transparency is another area where Revelry differs from typical software and innovation companies.

Step 2: Writing User Stories

Next up, we write our first Issues in user story format. Issues are the lifeblood of our projects. They contain the ingredients for how our product works. Think of them like bricks that build a good house. Some issues need to be worked (or laid) before the others. Sometimes we need to research the best way to build a feature before we write the issues for building the feature, and sometimes we need to have a designer design a feature before we implement it into an app. We should write issues for everything we are working on, as soon as we can, even if those things are rather intangible, like research or a bug that is hard to reproduce.

Writing our issues in a “user story” format enables our team to design and implement from the perspective of the user that the functionality will affect.

We tell our partners that one of their most important jobs is to help us write user stories that capture their product vision for their users. It’s a collaborative process. Multiple people on the team will provide input and the partner’s product owner signs off on the final story. For instance, we might ask a UX designer to review a user story before final approval. Here’s how we write our stories.

Write a quickly digestible title

If you’re an Agile fan, you’ll notice our User Stories titles differ slightly. Typically, an Agile story headline would look like this: “As a [user type], I want to [perform some action] so that [I can receive some benefit].”
But, we’ve adopted an alternative headline format:

“[User Type] – [Feature/Epic] – [Action or Result]”

We want our User Story headlines to be easier to scan across our project management tools. They should be consistent from story to story. And, we want our project tickets to increasingly rely on communicating the business value within the body of the story, where it belongs.

These stories become issues in GitHub with a unique identification number. We manage progress by using a Github board that automatically visualizes the status of your GitHub issues.

Examples of Lean Agile headlines

  • Typical Agile Headline: As a user, I want to sign in with my email address and password
  • Lean Agile Headline: Registered User – Log In – Log In Via Email, Password
  • Typical Agile Headline: As a developer, I need to setup my local environment
  • Lean Agile Headline: Developer – Project Setup – Local Environment
  • Typical Agile Headline: As a bot, I need to deploy the staging branch to Heroku through Codeship
  • Lean Agile Headline: Bot – Continuous Deployment – Deploy Staging Branch
  • Typical Agile Headline: As an admin, I would like to filter users by most recent sign in
  • Lean Agile Headline: Admin – Reporting & Analytics – Filter Users by Recent Sign In

Step 3: Scoring User Stories

Once stories are written and approved, we need to figure out how difficult and complex they are so we can prioritize our resources for the next sprint. This happens during the story scoring process, which estimates the amount of effort we’ll put into each story relative to other stories.

Team members cast their personal votes and then we calculate the average score for each story. A democratic process like this can take awhile, and it wasn’t uncommon to spend 2 hours on a scoring meeting at Revelry, which ate a lot of developer hours.

We automated the scoring process and our meeting time dropped to 45 minutes or less.

We built a Slack bot, /poker, that prompts each team member for their vote on a story, calculates the average, and moves on to the next story. The bot hides story scores until everyone has cast their estimate, so we don’t influence one another’s answers, then uncovers them with a /poker reveal.

It’s essentially a virtual, automated polling system that cuts out over an hour of inefficiency. This really adds up when you use it every week for a team of 3-6 people. Plus, we’re all in the meeting at the same time, but we can be on opposite coasts or in different countries and have an equal hand in the quick meeting.

Then, we queue up the new user stories. To do this, we write them, define AC, score them, and put them into GitHub, in preparation for the first sprint. If Revelry joins up with a client’s team while a project is already in motion, then that team needs to have the stories written and scored before the first sprint with Revelry.

Download Revelry’s Lean Agile Guide

Complete this simple form for immediate access to Revelry’s comprehensive guide to Lean Agile, including details on our 6-step product development process, optimization tools, The Revelry Way, and more.

  • This field is for validation purposes and should be left unchanged.

Step 4: Sprint Kickoff

Each sprint begins with a kickoff meeting.

First, we assign the team. We look at the needs of the project and assign Revelry teammates needed for that sprint: this could include software engineers, designers, or product managers. We sometimes create developer/developer and developer/designer pairs and place them into existing teams.

One thing that’s unique about working with Revelry is that you have access to teammates who have deep industry specialties. You can bring on a finance tech expert who used to work at Capital One, or someone from IBM, or even load up on designers if your project is design-heavy. We build you a team that’s the best in the business for that sprint.

Another important teammate is the Product Owner: usually a point person on the client’s team who serves as the ultimate decision maker on everything related to the product. On most projects, the Product Owner co-writes the user stories with Revelry and is–as much as possible–involved in the day-to-day of the sprint. If the client can’t play the role of Product Owner, we provide that as a service, bringing fully written stories to the client for approval and user testing.

Next, we re-visit stories. During kickoff, we revisit the stories we wrote and scored in the previous sprint, prioritize them, and make individual commitments to get them done. We also make sure to:

  • List dependencies and potential blockers in the story’s GitHub ticket as check boxes.
  • Link up any stories that must be completed prior to work on an individual story using GitHub #issuenumber, which also calls out dependencies.
  • Assign issues to teammates that we need answers or feedback from.

Step 5: Working the Sprint

During a given sprint week, the assigned team works the user stories. Here’s how we do it.

Working stories in Github

GitHub provides distributed version control and story tracking. Here is how we use github boards to visualize that progress.

  • Every week, we meet with our product owners to identify the next up priorities for the team
  • These stories should be written, approved, and scored before the beginning of the following week, so they are ready for the team in the Implement column.
  • At Sprint Kickoff, we review our accomplishments from the previous week, talk about what we are working on next, and work through any blockers to those priorities.
  • When an engineer starts working a story, they assign themselves.
  • As they complete the Acceptance Criteria, they mark the check boxes.
  • Once all AC is complete, the code is scanned by Lintron, an automatic style checker we built
  • When an engineer has addressed Lintron’s notes, they move the story to In-Review (a.k.a. Code Review) and assign their pull request (PR) to a different engineer on the team (or in the company).
  • Once the code is reviewed in-depth by a second Reveler, we move the issue to the Quality Assurance (QA) column. We use Codeship for automatic deployment and continuous integration, so any code that passes review is available for QA within minutes.
  • When in QA, another team member should be able to pick up the ticket and test it. If they find that the ticket does not meet the pre-approved AC, they uncheck the box and send the issue back to the engineer in the Implement column. If an edge case arises in QA that isn’t represented by any AC, we log a separate issue. Sometimes we play jazz, and kick the ticket back for a very small fix that was not covered in the AC.
  • Once QA is complete, we move it to user acceptance testing (UAT). One of our partners’ most important jobs is to do UAT and use their product every day. If there are issues with meeting the AC, they send it back down the chain to Implement. If there are other issues, we hash it out in comments and discussions, write tickets, and prioritize accordingly. Issues that don’t meet the AC coming back from either QA or UAT automatically become the highest priority in comparison to other work in progress or unworked prioritized tickets.
  • When the issue has passed UAT, we mark the issue as done. If there is a production (live, user facing) environment, we then deploy the feature to production as soon as the next release is slated, or in some cases immediately through automated deployment.

Daily standups

Our daily standup meetings happen in Slack, and are complete in 10 minutes or less. We’ve seen many benefits: Slack is quicker than getting everyone on the phone, and managers can quickly skim through the notes on multiple projects to get their pulse.

We use the built-in Slack /reminder command to run our scrum meetings for us automatically. (Here’s a closer look at how we do it). It sends a reminder to the team to round everyone up and reinforce our scrum philosophy.

In a Standup, each person on the team answers the following questions:

  • What did you do yesterday? include issue number
  • What are you planning today? include issue number
  • How are you blocked? ask for help & set reminders
    • We note blockers and take them offline to be addressed. Do not solve problems on standups.
    • If we need to hash anything out face-to-face, we quickly jump on a zoom.us call.
      • All updates need to reference a specific issue number, and by the end of the meeting, we’ve updated all the stories to reflect their current status.

Step 6: Lean Agile Sprint Wrap-up

During the week, we have also been writing new stories for the next sprint. Often we will run a session of planning poker at the end of the week to prepare for the next sprint kickoff.

Every other week, the team has a retrospective conversation. We discuss what felt bad, what was awesome, and specific tactics to improve the next sprint’s communication or velocity.

Start Sprint 2

  • Kickoff
  • Build
  • QA & UAT
  • Write and score stories for Sprint 3

Rinse and repeat. That’s how we do it.

Avoiding Disasters

Let’s talk about how and when to escalate things to management. When you’re moving as fast as we do, there are 4 common issues that can derail progress. Here’s how we deal with them without ringing all the alarm bells and slowing people down.

(This problem-solving is the domain of the project’s Product Manager on the Revelry team, who is responsible for removing blockers, getting questions answered, and facilitating proper channels to solve problems during a sprint.)

Here’s what we tell our teammates when they come up against these common issues:

1. Stories that are more difficult than originally anticipated

If you’re an engineer or designer

  • Immediately ask questions you need answered in the implementation Slack channel, without at-mention pinging anyone, the moment you encounter something you have questions about.
  • Assume it won’t be answered and do your own research for 30-60 minutes.
  • If you have made no actionable progress in that time, at-mention ping someone to get attention on it.

If you’re a Product Manager

  • Watch out for hang-ups. Your projects should develop a cadence and you’ll be able to see how scored stories move through the workflow as projects progress.
  • When things aren’t moving at the normal pace, there may be a problem. e.g. a story has been in progress for too long, or if it’s stuck in QA. We share the issue in #firedrill channel in Slack without tagging anyone directly.

2. Issues that you won’t finish by the end of the sprint

  • Sometimes, working an issue rolls over to the next sprint.
  • It happens, it’s ok. Don’t panic. Stories rolling over are top priority for the following sprint and no other stories should begin until those are complete.

3. When a client asks for a new feature or change in AC mid sprint

  • This happens, but if you stick to the main standup process, this is easier to avoid. Features and AC changes can quickly derail a sprint and must be addressed immediately outside of a standup.
  • If it’s a simple update or addition of a single AC, the Product Manager will often update the existing story, as long as it doesn’t affect the difficulty score.
  • If the change is big enough, the PM will write a new story. The original story is now a dependency of the new story to be created — link them as such with #issuenumber.
  • If the request is for a new feature, 9 out of 10 times, we’ll create the story but put it at the top of the backlog for prioritizing into the next sprint.
  • For that 1 out of 10 times that we really really need to get the new story added to the sprint, we’ll do lots of handwaving to point out it risks bumping an existing story off the sprint commitment.

4. Communication with clients

  • We open our Slack channels to our clients for full transparency, and that’s where we communicate with clients so that everyone gets context and an awareness of the conversations that are happening.
  • 1-1 direct communication with clients should be reserved for sensitive or confidential issues that require privacy, and this should be rare to keep things running smoothly and transparently.

The Tools We Use

These are just a few of tools we use to automate our software development process. Reach out to learn more about any or all of them..

  • Automated Slack Standups
  • Codeship
  • Dependabot
  • Generate starter stories
  • Github Actions
  • Github Boards – Automatically-updated visualization of Issues
  • GitHub – User Stories and Story tracking
  • Issue Bot — Slack bot for creating GitHub issues
  • Issue-Lookup
  • Lintron – automatic style checker
  • /Poker – Slack bot for efficient story scoring
  • Reusable Stories
  • Rollbar
  • Slack
  • Start a project command
  • Travis CI/CD – Automatic code deployment and continuous integration

What is Lintron?

Lintron is a pull request robot that we update every time we create a new code standard, and it very consistently catches style and logic issues, freeing up human code reviewers to provide substantive feedback. The results have been great.

lintron

The Revelry Way

Turning Ideas Into Businesses

Our process isn’t set in stone and we improve it every day, but it has served us well: 100+ projects and growth fueled through amazing relationships, happy customers, and straight up hustle.

Core Principles

Stay true to the core principles of this Lean Agile process and you can’t go wrong.

  • Ship gold every week, 1 brick at a time
  • Guarantee clients full transparency
  • Automate with lean tools
  • Individual ownership gets things done

Let us know if you try our process and tools. We’d love to hear from you. You can reach us via email at hello@revelry.co or get in touch to partner with us.

Let’s Build Something Amazing

_