In my opinion, deploying new code or features every day is the ultimate measure of agility.
Deploying every two or three weeks is much better than deploying every 6 months or year.
But, a lot of times two or three weeks gets pushed to deploying the next sprint. Which then becomes a month or two. It’s a dangerous pattern.
A work item is only done when it’s actually released and used. Until then, everything else is just extra risk being built in.
A lot of value comes out of small improvements versus big changes.
Big changes are usually completely new functionality that might have been requested, but still hasn’t been used in production and needs feedback.
Small improvements are usually based directly on user feedback and can make a BIG improvement on the experience of your product. For example, adding a filter to a table isn’t risky, it’s not a big change, but it could make using your application much better.
If it’s ready today, why wait to make your users life better?
If your team can deploy something new every day, you can react to feedback and get something built based on that feedback right away — which is the ultimate feedback loop.
Here are some items you need to consider to get there.
Keep Your Work Items Small
If you want to deploy new software every day, it’s important to keep your work items small.
Honestly, one of the best ways to keep it small is to just look at it and talk out loud as a team to see if you can get it done in a day.
Here are a few other techniques I like:
- Remove all uses of the word “and” from the work item and break those down into a separate work item.
- Use the SPIDR technique to try and identify Spikes, Paths, Interfaces, Data, and Rules that can be split out.
- Identify if there are two or more things that need to be done that can be worked on at the same time by different team members.
No post about technology would be complete without mentioning a few buzzwords like micro services.
However, if you’ve built out micro services and put the appropriate contract tests into place, it should be easy and low risk to deploy small updates to small services.
Have Your Team Swarm On The Item As Much As Possible
Every day, get together as a team and decide what the goal for the day is, break the work down into tasks, determine how each team member can contribute, and assign the tasks.
This could be pairing, testing, or really anything to help the team accomplish the goal.
I doubt there will be nothing for a team member to do, but if that is the case they could focus on tomorrow’s goal and work on setting the team up for success on the next item.
Figure Out The Test Cases Early
If you are going to deploy every day, it’s imperative that you take complete ownership of quality as a team.
When breaking down the work item into tasks, talk through the test cases and how you are going to test it.
Some questions I like to think through include:
- What is the happy path?
- What happens if it works?
- What happens if it doesn’t work?
- What happens if dependencies don’t work?
- How would we know something doesn’t work?
- How might one break this?
- How might one try to hack this?
Know & Plan For Your Bureaucracy
If you know me, you know how much I love bureaucracy.
Regardless, it exists everywhere in some fashion and is likely to slow you down. It’s important to know it, understand it, and plan for it.
Does someone have to approve a release?
Does someone have to document something or attach screenshots of something?
Do you have to smile, blink three times, and high five yourself before closing a item?
Plan for this. Get the people needed involved in your daily routine so you can easily pull them in and get their approval or whatever it is you need.
Let Your Team Focus
If your team understands the goal and has all the context, then your job is to get out of the way.
No 10 minute meetings, no one second to chat, etc.
I’m not saying you can’t meet with your team, but if you’re trying to get time with them after they have their plan for the day you are going to cause context switching, lose their focus, and waste time.
There isn’t much time to waste when you start deploying every day.
Instead, you can schedule time for the next day so when they plan they can arrange their day and work accordingly.
Be Available For Questions
Did I just say leave your team alone?
What I meant was, leave them alone…until they need you.
Make sure to make yourself available for any questions or feedback needed. Be able and willing to hop on a call to share their screen and give them the info they need.
This is the kind of collaboration that seems to get skipped frequently. Too often, the product owner doesn’t see something until it’s in UAT.
If you see it and provide feedback while your team is working on it, it reduces the risk of rework and wasted time by a significant amount.
This is what it means for the product owner to be a part of the team. You are also winning and losing with the team.
Have Automation In Place At Every Step
Automation is going to save you time and reduce risk so it’s going to be a huge help deploying every day.
Do you have the appropriate unit tests to make sure your units of work aren’t breaking?
Do you have the correct integration tests to make sure your code works together nicely?
Do you have the necessary functional tests to validate the key features still work?
Are you running all of these locally, when checking in code, and in different environments?
This is going to make sure everything works as existed before so you don’t have to worry about taking down your whole application or breaking a critical feature.
Build, Test, and Deploy To Identical Environments
It worked locally. 🙈🙉🙊
Let’s get rid of that phase altogether.
When you have identical environments that you build, test, and deploy to you should eliminate issues that come up because of different versions, etc.
This is one of the biggest benefits of containerization in my opinion.
It gets a little more tricky when it comes to serverless because your local environment likely is a little different. However, it doesn’t mean you can’t have environments between local and production that match production.
It’s important to run your tests on these environments also.
Have An Easy Way To Roll Back Features
I can hear it now. But what if it breaks?
Plan for it.
Add feature toggles to enable turning features on and off.
Use blue green deployments to enable rolling back to a previous working state.
Use a branching strategy that easily allows you to roll back code changes.
Some of these items take a lot of planning.
For example, it takes some time to get an automation suite fully fleshed out. It takes some time to get your architecture to support this.
Some of this is a mindset shift.
Too frequently our team members are really all just their own silos. For example, one team member works on an item, moves it to QA for someone else to test, who then moves it to UAT for someone else to approve of.
There is no real teamwork.
You just become mini waterfalls. You still throw it over the wall.
Sure, you throw it over the wall sooner, but it’s not collaborative.
Software is a team sport, not individual. You win and lose as a team.
You should decide what is the highest priority or business value and work as a team to deliver that as fast as possible.