Agile: Where We Started

As a smaller company that had to work quickly with a shoestring budget, we knew we’d have to re-think the SAP development process.

Most of us previously worked on systems that had 2 to 4 releases to production per year, which is understandable in a waterfall process. But this situation was different. We had a very limited budget and lots of experiments to test. Betting our whole company on a handful of releases was out of the question.

We needed to be agile and respond to customer feedback quickly. So we re-worked the entire development process to enable us to release multiple times per week, shipping new functionality and adapting to customer needs as we went.

This series will share twists and turns that our dev process took while we were shipping new functionality. It will illustrate key issues that arose for us and that will arise for most businesses that transition from a waterfall-ish to an agile approach. Mostly, there will be a lot of good learnings shared.

With that in mind, let’s talk about where we began, and what we had.

What We Had When We Started Our Journey

We started with three key elements in our founding dev process:

1. Isolated Development Environments
2. Github for Version Control
3. Light Automated Checks for Our Code

We’ll share a full post describing each of the above, but here is a brief rationale for each of these key elements.

1. Why Isolated Development Environments?

The short answer: We had to work fast.

Time and cash were our scarcest resources. So waiting in line to use a shared development environment was a non-starter. Further, we had 4 developers on payroll, and the cost of a developer sitting idle was enormous compared to the cost of standing up a new development environment.

We also knew that not everything that we tried would excite our end users. So we needed to quickly implement new features and throw them away if they didn’t work. This would’ve been nearly impossible in a shared development environment.

Therefore, parallel development was our only viable option. And Isolated Environments were the only viable way to develop in parallel.

Note: The full post is now available here.

2. Why Github Version Control?

With 4 developers working in parallel, our code changed quickly. Further, we frequently had two developers working in the same part of the codebase who risked changing the same objects.

We needed a version control system that would allow for a large quantity of small changes while alerting us when two people tried to change the same part of the code. Taking a page from the web developer playbook, we used the gold standard: Github.

For ABAP work, we used abapGit.

This enabled - and continues to enable - our team to work in parallel while preventing collisions between our work and often contributing multiple features per day to the codebase.

Note: The full post is now available here.

3. Why Automated Code Checks?

Arguably we could have started without automated code checks, but we’re happy today that we had them in place early on.

Essentially, these automated checks kept our code clean. They automatically enforced formatting and style rules. They ensured that our code would at least compile and run without errors. In some cases they checked that variable types made sense.

The result is a codebase that is less likely to have syntax errors and is more readable and maintainable as we continue to build.

Note: The full post is now available here.

A Solid Foundation, But Lots to Improve

This foundation set us up for success, but it was by no means the end of our agile journey. The whole point of Agile is to keep improving everything over time - the product, the development processes, the speed of iteration, and so on. And we continue to do that.

The remainder of this series will share the Nuve team’s actual learnings and adaptations over time. There will be some great insights and cases here, and we hope that you enjoy learning from our experiences.