It's time we admit that the feature release process isn't agile.

Most organizations as a whole aren’t agile. Let’s stop pretending like we are.

About 15 years ago, I was helping my father unload a trailer in our garage. After we were done, it was time to unhitch the trailer. I started doing it a certain way, different than what he’d taught me in the past, but from what I could tell, it was a more efficient, less strenuous way. He stopped me and said, “What are you doing? That’s not how I taught you to do it.” I replied, “Yeah, but this works better for me.”
My stubborn father said, “I’ve been doing it this way for 30 years.” My stubborn ass responded, “Well, maybe you’ve been doing it wrong for 30 years.”

It was like I hit him with a rolled up newspaper. He could only mutter, “Well, that’s not how you make friends,” and let me be.

This exchange is burned into my memory, not because it was some pivotal moment in my life, but because I started to notice that mentality throughout every job and process I’ve encountered.

Most tech lead teams like to think they’re agile and collaborative. That may be true within teams, but cross team collaboration during feature development is anything but. The process is tough, creates friction, and has very few tools to help. Ephemeral environments are the key to bridging the gap between tech teams and tech-adjacent teams.

Regardless of the size of your team, we’ve found that most teams follow a similar structure when it comes to releasing features:

• The Ideation Stage: This is where we vet the potential feature, hash things out and truly collaborate
• The Pen to Paper Stage: The feature moves on to UI/UX and starts to have some life breathed into it. The designs or prototype get passed between departments where everyone can share thoughts, concerns, or even praise
• The Building Stage: As developers, we take this new idea to life.

The Building Stage

I want to focus on this stage a little bit more.

The idea is now presented with clear goals to the development team. As developers, we have no shortage of amazing tools to collaborate with our peers – KanBan board smorgasbord, Github, Cloud-based IDE’s, Slack… you name it, we have it.

As we build this feature, we iterate several times using the tools above. Once we’re done, we create a pull request and open up the request for review to the whole team... right?

Of course not!

The dev team needs to review first. After the new feature is reviewed by us and meets our standards, we’ll package it up in a release cycle to then be presented to the other departments.

In theory, that makes sense, but this process does not account for one critical possibility: mistakes.

The whole point of collaboration is to vet a solution, identify pitfalls, create solutions, and release something amazing into the world. What we see, however, is that while departments collaborate well internally, interdepartmental collaboration and agility is non-existent once a feature hits the development stage.

As soon as other departments start testing, a flood of spreadsheets, Slack messages and email chains gets unleashed. Tech-adjacent reviewers scramble to give feedback. Devs scramble to compile it. Tickets get opened, closed and reopened. Features that worked a minute ago break in the middle of a demo. It’s a mess.

The worst part is, there may be several layers to this review process. Developers review, UI/UX, Marketers, QA, Internal and External Stakeholders may all get involved at some point.

We get it, it sucks. But it's just how things work

Thinking back to my story from earlier, you can start to see why I dont like this phrase very much. It implies that we shouldn’t attempt to improve upon anything. With this phrase, there would be no innovation!

Our processes aren’t some unbendable, priceless antiquities that shouldn’t be questioned. In fact, they should be questioned relentlessly. The reason we don’t is because of complacency and ego.
As someone who has worn a lot of hats in product teams, I can tell you that there is a lot of friction between developers and tech-adjacent roles. For some background, I started my career in Account management, moved to Project Management, and then went back and became a dev.

As a dev, I had a lot of gripes when it came to being interrupted, when a request took me away from writing code, or when a tech-adjacent (like an account manager) asked me to fix a bug on a demo site when it wasn’t happening locally or when i just checked five minutes ago.

But as a PM, it was incredibly frustrating to have to deal with developers who gave me very little access to the things I needed. I wanted to easily check on the progress of a feature, but I couldn't do it without technical help; I was at their mercy. And nothing was more frustrating than when I had a meeting with a client and I had to utter the horrifying words, “This just worked a second ago.”

In fact, my own team got so tired of dealing with these issues that we built a solution for ourselves… and quickly realized it could work for other teams, too.

A better way to review features - aka our shameless plug

Like many other solutions, our solution isn’t new. We’re just doing it really well. Voyage started as an internal tool and process because we couldn’t find one that actually solved the problems without adding unnecessary burdens to our dev team. We found a lot of tools that would deploy the front end, but that’s just half the battle for fullstack apps.

As we began talking more and more about what we were doing internally, customers and peers started to ask if they could get in on the goods….and with that, Voyage was born.

Our product, Voyage, creates ephemeral environments which have reduced friction between departments, created better collaboration, and have caused us to iterate more quickly through our release cycles.

Voyage creates a short-lived environment of the entire web application. Unlike other products, we knew we needed to get the entire team involved, which also meant getting the entire application involved. With each pull request, Voyage automagically deploys the entire application, along with any services the app may have.

• A pull request is opened
• A temporary environment is automatically created
• A unique URL is generated and shared with the whole team

And in as little as 3 steps, our entire team is reviewing the same feature at the same time. No additional accounts, no “let’s schedule a zoom call to review.” Just a simple “here’s the link.”

No more spreadsheets

One of the mantras we have within our organization is that if we can get rid of a single spreadsheet, we’ve done our job.

That’s why with every deployment, Voyage has built in feedback tools. Anyone who has the link can quickly review the feature and application and share issues and screenshots. No more spreadsheets, Slack messages, or email chains to figure out what’s going on. These comments integrate directly into the git provider and can also create a Jira ticket if the project has been configured to do so.

Other favorite features within Voyage are: 1. One click configuration pre-set: if you’re just spinning up a simple application, Voyage has several pre-sets that allow you to go “config file free” and start deploying quickly. 2. Password protected deployments: Privacy is obviously a huge concern, so we allow you to set a password in front of your application. 3. Multi-repo support: monolithic applications are taking a back seat to multi-repo applications. Voyage handles both with ease.

Voyage is incredibly easy to set up! If you are using docker, then you’re nearly already set up. A quick config file with ~20 lines of code gets full-stack apps up and running.

All Aboard

I don't believe in Voyage solely because it’s a great product; I believe in it because it has transformed our process and made us a better, faster team with more efficient communication. I challenge you to break out of the mindset of “things are working, lets not mess with it” and instead consider how much better things could be if you adopted a new solution and process.

If you’re interested, sign up HERE and start shipping features faster.