Most Common Project Terms at Revelry: Part 2

I love documenting the things we do and learn while driving innovation at Revelry. Documenting, teaching, and making what you know reusable is really useful for the whole team and any partners we work with. This is one of the reasons that I wrote a blog post defining the project terms we use at Revelry: Project Terminology: The 15 Most Common Revelry Terms.

But why stop at 15? I’m ready to share Part 2 with you, because there can never be too much knowledge sharing. In fact, this reminds me that recently, Revelry team members got together and collaborated on a Culture Guide. We put together some “rules” which help us remind ourselves how to work together. One of these “rules” addresses the language we use:

Adjust your language and communication based on your audience.

We assume there is no common terminology.

Use slangs and acronyms minimally; leave no ambiguity.

It’s easy to fall into the use of slang and acronyms when you work with a bias toward action. For those times that our language might become unclear, I want to elaborate on more terms that I’ve learned along the way. I know these will be helpful for someone else, whether they’re joining the Revelry team or working with us as a product owner. I’ve chosen this specific list as part of an effort to foster a shared understanding of commonly used terms. This “glossary” doesn’t exist in a vacuum – it can (and should) continue to be challenged and evolve over time as our understanding changes.

Revelry Project Terms: The Process

The Process™

Otherwise known as our Lean Agile Process, this is our lifeblood. It’s how we operate day-to-day at Revelry. It’s important to learn the process because only then, can you break the process. So if you’ve just joined the Revelry team, welcome! Now learn and figure out how to break the process.

We rely on the process to do a lot of our heavy lifting. When times get confusing, weird, busy, or stressful, it’s almost always best to work the process. The process includes checks and balances to cover each other as well as allows us to get down to deep work by taking much of the burden of remembering the little details.

Producers are responsible for the success of the process. A team functions best when someone champions the process and encourages and reminds everyone to use it. But it’s a living thing, and it can be changed. And once in awhile, we need to play some jazz notes around the process in order to achieve short-term success.

Pairing

This is what we say when two teammates, usually engineers, pair to solve a problem, and usually it’s pairing to code. One engineer “drives” another watches “over their shoulder” to give input. (This is often done remotely, such as over Zoom instead of side-by-side.)

Typically, the teammate who is learning something will “drive” while the more senior engineer gives guidance. At the cost of about a 15% increase in development time, pairing produces code with fewer errors, and even makes us happier at work. 

Labels

We use GitHub labels to quickly identify tickets on the kanban board. (See GitHub repository, below.) This allows us to quickly scan the board and visually see the current status of tickets. Labels can also be used on Pull Requests to know the status. Some common labels are:

• Draft
• Blocked
• Points 1-13

Almost every ticket has a label to help the team quickly understand the current status of the ticket. A freshly opened ticket is labeled “draft” while the Acceptance Criteria (AC) are written and agreed upon. The Product Manager assigns the Product Owner to review and approve the AC by removing the “draft” label and adding the “approve” label. When the Product Owner approves the AC, they replace the “approve” label with a “SCORE” label. This lets the producer know that the ticket is ready to be scored during the next planning poker session.

“Blocked” is a frequently used label. If someone has a question or can’t move forward, they will leave a ticket comment clearly stating the question or need, add the “block” label, and assign the ticket to the person they need an answer from.

Bugs

Bugs are a natural part of software development. A bug is something that doesn’t work as expected. A bug can be something that wasn’t already predefined and is not an enhancement.

Some edge cases are bugs that we didn’t account for in the initial implementation. Many projects use Rollbar, a service that automatically logs a bug ticket when there is an error in the code. This helps the team stay on top of bugs that could manifest in the front end. When a bug is logged by either someone on the team or Rollbar, a PM or engineer will triage the bug to decide on its level of criticality.

We can commit to bug tickets just like feature tickets in a sprint, but a non-critical bug that pops up mid-sprint typically gets worked directly after the commitment tickets have moved to “in review” or QA.  

Regressions

When something worked once but an unexpected event occurs, it regresses back to a state of not working. Regressions are caused by bugs in the software due to new code being deployed into the existing code. While Revelry does a solid job of documenting, commenting, reviewing, and coding clean in general, regressions are also a natural part of software development.

When this happens, we treat the issue like a bug with high priority. The steps to reproduce are logged and we bring it to the top of the icebox to prioritize and work via the process. So if there was AC previously written and worked for the issue you are seeing, it is a regression.

Refactor

Refactoring can sound like a negative thing to clients, particularly when the term is used while problem-solving a bug. Refactoring code does not necessarily mean changing code that was written poorly before. Instead, think of it as optimizing old code to better fit within new code and infrastructure as the project goes on.

Refactoring is a never-ending job that should be done whenever work is performed on a codebase. Our team actively refactors code while working on new, similar feature work. But sometimes, an engineer will pause and call out a specific component that has grown so much through the course of the project that it needs some extra love to get it into the healthiest place possible.

As a PM, I encourage my teams to refactor often and allow them the space to do so when they recognize opportunities. This means the team cares about the code quality and is invested in your product’s long-term health.

Revelry Project Terms: The Tools

Slack

Slack is the platform we use for open, transparent communication. It can be abused for distraction, though, so it’s important to establish Slack Etiquette. We talk about different ways to make the most of Slack a lot internally, but here’s one place where we lay out how we use Slack to communicate with our clients and partners.

API

API stands for Application Programming Interface. It’s a set of subroutine definitions, communication protocols, and tools for building software. We “call” endpoints or data of a particular category to populate a site. As the API is updated, the data and features available to us are updated.

We use the Twilio API when we want to send text messages. We use SendGrid’s API to send emails on behalf of clients. We also build our own APIs for interacting with smartphone applications that we’ve built, as we did with 20Echo.  

SSL/TLS

Commonly known as SSL (Secure Socket Layer), today it’s called Transport Layer Security (TLS). This is an upgraded version of SSL, and both of these things are options for a Security certificate for websites. Steps we take to secure websites include redirecting http to https. We also deploy security layers when sites utilize payment processing or other sensitive information. But at this point in web development, Google’s algorithms pretty much want every site to be a secure site, even if no sensitive information is being transferred. So, if we’re building a site for you, you’ll get familiar with security terms.

GitHub repository

We store project information and code in GitHub, and each project has its own codebase structure. That structure is called a repository. The driver behind the Git framework is version control: the ability to save and separate work so that nothing committed can be lost or overwritten.

Our engineers deploy their codebase to each project’s repository. And, the whole project team writes tickets using GitHub Issues in order to prioritize work. We also use a kanban tool in order to move these tickets through each sprint. 

Continuous Integration

Continuous Integration, or CI, refers to the continuous work of pushing new features into the main codebase. We use Travis CI to manage the integration of new code. This allows teams to detect problems early. We use pull requests to constantly update applications while sharing code across teams easily. Before CI, engineers may not have shared code for a week or two. With CI, developers can pull down code changes from other team members while they’re working on their own code.

Test suite finds mistakes before the code gets into someone’s local environment. Coveralls is part of our CI system to determine how much of your application code is covered by tests.

Agile teams typically configure CI to include automated compilation, unit test execution, and source control integration.

Blockchain

Blockchain technology is used in certain circumstances when added transparency, verification, and trust are needed. Blockchain is a distributed ledger among every entity in the network. Although Blockchain may be a buzzword right now, we believe in finding the proper use for implementing it.

Sometimes, using a database might be a good enough option if you don’t need the extra layers of security that a blockchain provides.

We built our own open-source contribution incentive system, tracked on the blockchain and using the cryptocurrency Stellar. Check it out at incentivize.io.

---

Product Development Product Management Project Management