20 Tips on How to Improve Tech Team Momentum
I was recently working with a client when I overheard the following comment: “It just doesn’t make sense to go any faster because the overhead [required] isn’t worth it.”
The statement was made in reference to a team not wanting to move from one-month sprints to two-week sprints in order to execute a project. It’s a valid concern: What if the “overhead” of planning, scrums and retrospecs is too much? What if the “overhead” could be removed or ceremonies could be improved? What would be possible then?
As a technical manager, you may have the authority to influence your development team to go faster; to complete smaller projects while continuing to pivot on the bigger picture or what is most important. But experience tells us that this sort of decision without team buy-in won’t be successful.
In general, teams I’ve worked with have accelerated to complete about one sprint every three weeks—but anything faster isn’t possible without advanced tooling. It’s possible to finish sprints shorter than three weeks through manual processes, brute force and exceptional individuals. But better tools and processes are still required to move faster.
Before you begin ask yourself if the work to tool-up your organization going to be worth it, you have to realize it will take time, money and most importantly leadership. The first two blocks—time and money—are likely just a lack of the third block, leadership.
One of the most convincing reasons to perform faster is because your competitors are going faster and gaining a competitive advantage. You typically don’t need corporate espionage to know if your competitors are getting things done at a faster speed. Companies who have figured out how to go fast use their speed to their advantage; They release a product faster, they brag about it, they promote their abilities to move quickly, etc. Have you ever had to defend your team against a comment such as “The other guys are rolling out features two times as fast as us and I know their team is smaller than yours. Why can’t your team keep up with them?”
Here are some additional tips and techniques to get going faster:
It doesn’t always make sense to automate testing, but automation is required if you really want to go fast.
Follow Agile best practices. Most importantly, don’t add new tasks while in the middle of a sprint. It sounds like doing something else right now will speed things up, but optimizing a system is much different than optimizing a single task.
Adopt real Continuous Integration (CI) and Automated Releases. With the push of a single button, you should be able to promote code from one environment to the next. Don’t waste time performing releases by hand; It’s not only slow, but it is risky.
Do you have a relational database? Do the following: 1) Use DB conversions scripts; Don’t convert data by hand. 2) Version your APIs and support more than one version of DB scripts. This enables you to roll out new code without breaking old code, which will result in a smoother user transition. Easier said than done, but if you can get your conversion scripts to run really fast it’s probably worth it to skip this effort.
Utilize A/B Testing as part of your rollout strategy. This allows you to confirm that your new code is working at least as good as your old code.
Adopt partial roll outs. For example, roll out your code to 10% of your users just to confirm the code is doing what you expect it to do. This works great with A/B testing.
Accept that mistakes will be made. If your company is 100% risk-averse, then going fast isn’t going to work. Allow some failures in the name of speed.
Monitor at different levels within the system so you can quickly detect if something is wrong. For example, you could monitor the how often a credit card fails so if the rate increases after a release, you will know to investigate. I prefer percentages over absolute values because a percentage-based scale works better with dynamic loads.
Set up anomaly checks. (I can’t stress this enough.) You must have systems in place to check for situations that can’t happen.
Make sure more than one person can do a release otherwise you will end up holding up releases for a single individual's. Break releases into easy, medium and hard tasks to better manage and organize the workload.
Simplify your architecture. Complex architectures are fragile. Your arch should only be as complicated as it needs to be.
Use configuration switches in your code with features that you can activate and deactivate independently outside of a roll out. This gives you more options when deciding when to roll out or roll back.
Clean up code that you know is fragile. Tech debt can destroy confidence across the company so clean as you go. Clean up a little bit here and there in every release.
Keep your backlog groomed. You never know when somebody may finish early or blocks may require switching out tasks.
Program failsafes into the system. For example, if you accept credit cards there should be a maximum amount that can be charged. These types of protections are important because they limit the risk of making a mistake.
Make sure you have a clear and simple processes for deciding if you are ready to release.
Decouple releases from sprints. A technical manager should focus on removing dependencies; There’s no reason to wait to release. Technically-advanced companies plan a sprint and then release when the code is ready. Don’t wait until the sprint is over if the tooling is in place.
Tech improvements are great, but if people are wasting time in meetings there won’t be any time to create these new capabilities. This doesn’t mean meetings are a waste of time, but holding efficient meetings and ceremonies are key to success.
If you find yourself with extra time, use it to do automation or some other task on the above list.
Always celebrate wins. I guarantee you will suffer through failures so keep the team motivated by honoring victories.
When you get to the point where going fast with discrete sprints feels easy, start considering what it will take to switch from a discrete mode to a continuous mode of operation. Who knows, you may get to the point where you release products on-demand within a sprint. First, use these tips to adapt processes and workflow so you can get things done faster.