When it comes to software development, “agile” has been a buzzword at every company for the last couple of years. An agile methodology makes a lot of sense in theory, and tons of companies have started to implement it. Basically, agile software development is a software development methodology that relies on collaboration between cross-functional teams and the end-user or customer.
While the principles of agile are straightforward, implementing them in a way that enables your dev team(s) to rapidly build, scale, and deliver functionality to your clients or customers can be challenging.
Releasing a new or updated product often can be hard to manage, quick development can become messy and cause bugs, and getting feedback on major features of a new product without that new product being released can be hard.
So what are some things that can help alleviate some of these issues?
It comes down to creating an agile software development methodology that works for your software engineering team, your company, and your end-users. So we’ve laid out some quick tips on how to go about creating agile processes that work.
CREATE A RELIABLE RELEASE PROCESS
One of the major benefits of agile is the ability to rapidly iterate on an idea and quickly collect feedback from your users. However, if you don’t have a stable release process, you’ll quickly find yourself with a buggy system, unhappy customers, and a burnt-out development team. Yikes!
Each team will have their own set of nuances and constraints that will shape their release process, but here are 4 things we believe make up any successful agile release process:
Solid branching strategy/workflow
Automated CI/CD pipelines
Ephemeral environments
Application monitoring
BRANCHING STRATEGY/WORKFLOW
When your team is well-organized and knows how to quickly and safely release their code, the team can be a lot more productive and confident about their releases. Having a proper branching strategy is vital for a team to be sure they know what code is going out, where their code is in the pipeline, and how to properly and safely merge their code into the codebase. A workflow a lot of agile teams use and have found effective is Gitflow by Atlassian.
AUTOMATED CI/CD PIPELINES
Adding your automated tests to your pipelines will help ensure that the code that is about to be merged will not break the existing functionality. It will bring ease of mind that the changes will not have unintended consequences and is safe to merge.
At my current job, we don’t allow code to be merged until it has passed its unit tests and coverage, and then we run automated end-to-end tests later in the pipeline.
EPHEMERAL ENVIRONMENTS
Here’s how Ephemeral testing environments work: they are brand new environments that would be spun up every time a new feature is ready to be tested before merging it into the codebase. Once the feature is tested and merged into the code base, the environment would then be spun back down and no longer used.
These environments allow developers to test their specific feature in what already exists in production without affecting any other developer, being affected by messy data, or affecting any other developers that may be working on another feature.
APPLICATION MONITORING
Having monitoring in all your environments not only makes debugging easy and quick but also ensures that if something does go wrong, your developers are notified right away.
Most monitoring tools have integrations with messaging tools like Slack, that way your developers can not only get an email when something is broken but also a Slack message. We’ve found that when messages are sent through a messaging service, they’re more likely to be seen and handled faster.
Some additional monitoring tools we use at my current job are Splunk and Sentry—they’ve been invaluable!
IMPLEMENT FEATURE FLAGGING
Feature flagging is like a light switch—it allows developers to turn features off and on quickly, and it can even restrict or enable certain features for a particular subset of users. This allows features to get in front of users for testing without having to completely release the feature if the team wants to get feedback before rolling out to everyone.
Feature flagging also allows features to go out, and if they’re causing issues, they can quickly be turned off. This allows teams to push out features without worrying about breaking what’s already working and allows users to provide quick feedback.
Consider LaunchDarkly, which is our preferred product for feature flagging, but there are many other products that do this, too.
USE IFRAMES AND/OR PACKAGES
You may see this and think I’m crazy, but hear me out! If you’re replacing an old application with a new one, you might want to consider using iframes or packages. Here’s why.
By breaking out your new application into major features and iframing the new features or making your features into a package that can be brought into the old application, you can start getting pieces of the new application in front of users. The biggest benefit to this approach is that it allows the team to get feedback on features as they’re building (rather than at the end). That’s a huge efficiency!
Iframing also allows users to get used to the new features, and it allows iterative releases rather than a full application release all at once.
I hope this helps you on your agile development journey!
Top comments (0)