Beyond Scrum: Getting to Continuous Deployment

Scrum is great. Personally, I love it. I loved it as a developer and as a team leader. It brings order to the developer’s life and brings a lot of visibility to the lives of project managers all around. It becomes almost the magical solution for development group leaders everywhere. Can’t deliver on time? Use scrum. Need visibility for management? Use scrum. Quality issues? Use scrum. Communication among the team problems? Well, you got the idea.

Image Source

But scrum alone isn’t enough to develop quickly and continuously. Why not?

The Problems with Scrum

Technical Debt

Let me paint a picture. A sprint ends. Now, you’re faced with the decision of continuing to work on the content that you’ve already committed to in the last sprint or begin something else entirely. As a developer, or even as a leader, you find yourself giving up on content. Meanwhile, your technical debt gets bigger and bigger with no chance of shrinking anytime in the future. This means that, your code base turns to legacy code more quickly – unmaintainable and untestable.

Image Source

Refactoring phases are needed sooner than you want them. The cycle continues, but continuous development only gets further away.

Separate Methodologies

Today, as the RapidAPI‘s VP of R&D for the last year, I still see the good scrum brings R&D engineers. But I’ve also seen teams using the retrospective for evolution of the initial methodology set. It becomes hard to set one unified methodology across the departments since each team set its own methodology. The independent process is great, but hard to control management-wise.

Changing Our Mindset

Ultimately, continuous development is more than adopting scrum or some methodology. It’s a state of mind. Unfortunately, that nebulousness makes it even harder to implement.

There is no 0 to 100 setting for continuous development methodology. There’s no on/off switch. It comes in smaller steps. However, we did learn some best practices that help along the way.

1. Adopt technical practices and fast

Adopting technical practices is a must. Even if you don’t adopt a dynamic and time-to-market methodology, setting technical standards is incredibly important. Here are a few that we found most helpful:

Automating Separately  vs. Jointly

For us, we found that in order to have independent process for each feature, stable automation must be implemented. This was a departure from the joined automation (unit testing, code review, real-time monitoring abilities) that we used in scrum. It made a huge difference.  

Streamlining Code Reviews with Linting

It’s a known fact that most of the time code reviews are about code convention. So many commits result in comments about naming variables, functions and the indent of your code. Two or four space indentation was one of our favorite office debates.

Source Image

Once the standards were set (see section above), we added a code convention enforcement tool – linting – to put those issues to rest once and for all. This way, our developers debate on more important stuff. Best practices, data flow, smart components…or which Avenger is the best.

Since RapidAPI codes mostly in the JS stack, our natural choice was ESLint. We applied it to both our backend and frontend layer. This application made the code more readable and allowed quicker debugging and development.

2. Stop thinking on the little things – make time for the important things

Yes, I know I just talked about having debates over indentation. But another best practice towards continuous development was being actively focused on prioritizing. If you have stuff that takes unnecessary time from your crew- fix them. Identify and improve bottlenecks, reduce time of different flows in your current processes. Support tickets keep coming? Invest time in building tools for support so they can do it by themselves.

3. Make the change in steps

You can’t move all of your systems to continuous deployment in one day. You could try, but your team might kill you. Try to plan a strategy to build trust in the process. Deploy minor services first. Make pilot feature to test the flow. Move to staging environment first and not directly to production. Eventually, these smaller steps will result in building real momentum for continuous development.

Conclusion

We’re not a full-fledged, continuous deployment machine. There’s still a lot of work to do. But breaking free from traditional scrum methodologies and tweaking our mindset has us well on our way.

Has your team embraced continuous development? What are you doing to refine your development process? Two space or four spaced indentation? Leave us your thoughts in the comments below.