Skip to content

Predicting the Future with Agile Development

David Hardwick

October 12, 2015

5 minute read


Bold article title, I know, but I promise it to be true! And to make things more confusing, I am going to start off by proving the opposite.

BetterCloud believes that we cannot predict the future. If we could, we’d be able to predict:

  • Exactly what benefits a customer wants and needs
  • Exactly how to build a solution that will deliver all the benefits customers need
  • Exactly which user experience is required to interface with the solution

We would know what features are needed, how to build it, and when it would be finished. We’d also know how many customers are going to buy it. I’m not sure where the excitement would be in this field if all of that was predictable!

If we could predict the above at BetterCloud, agile development would be a total waste of time. We’d be better off just doing waterfall development.

Waterfall development is the process by which you execute the project in four distinct stages.

  • Defining the requirements
  • Design to achieve the requirements
  • Develop code according to the design
  • Test all your work before deploying it to customers

But given that we have to deal with reality, these items cannot be known ahead of time. So how then does agile development, which is an iterative development process, predict the future?

Please do not roll your eyes at me, but the prediction is obvious: things will change.

And since we know things will change, we need to prepare for it; actually, we need to embrace it!

Developing Feedback Loops

At its most basic level, this requires us to set up feedback loops to ensure we are constantly improving. These feedback loops are at every level in agile development; the faster the feedback, the faster we can improve and the cheaper it is to learn from mistakes.

If you learn about a bug in your code from a unit test before it even hits the team server, then it’s quick and cheap to fix. However, if that bug makes it all the way to production, customers lose faith in the quality of your product. To resolve the issue, the fix has to go back through all the various environments to make sure the bug wasn’t only fixed but also that no other bugs were introduced in the process. As you can see, clearly that isn’t fast and isn’t cheap. And that’s exactly why setting up fast feedback loops is so critical.

User testing on the live application is a feedback loop, but getting an application out to production through structured user testing isn’t a fast feedback loop. Neither is gathering feedback through support channels and application analytics from thousands of users.

Using Agile Principles to Setup Fast Feedback Loops

Agile development has much faster feedback loops.

BetterCloud has taken to agile principles and setup the following feedback loops:
(ordered from the slowest to fastest feedback loops)

  • Beta testing with customers on monthly basis
  • Sprint demos and retrospectives at the end of each sprint (every two weeks)
  • Testing internal releases both manually and using automation suites in integration environments several times a week
  • Testing releases in team environments daily
  • Automated regression tests run daily
  • Automated integration tests run several times a day
  • Static code analysis run many times a day
  • Unit tests run several times an hour

Side note: One of the cheapest ways to avoid changing any code while still being able to get great feedback is to run tests with customers interacting with a clickable prototype. There is still nothing like the user interacting with a live system, so don’t get upset when you get more feedback that you didn’t get with the prototype. That said, do use prototypes!

The Importance of Test-Driven Development

Okay, now that we have covered all the ways agile development creates fast feedback loops for us, what else can we do to prepare for change?

Glad you asked! Another great way to prepare for change is to bake certain practices into the culture of your development process.

Test Driven Development (TDD) is a practice that focuses on writing the tests first. TDD focuses on quality and sets up a foundation that is more accepting of change. When you have tests that are focused on validating the features and behaviors that you provide to customers, and these tests are written first–even before any code is written–then you have a great safety net to catch any problems that typically occur when you have to change the code.

At BetterCloud, we didn’t make our architecture testable when we started. We did some unit testing, but it wasn’t done well and it wasn’t comprehensive. When you live with a code base for years, you want to have a strong safety net of unit tests, integration tests, and automated acceptance tests so that developers aren’t scared to touch your code. It’s stressful when you walk a tightrope without a safety net. It’s understandable why a developer would try to push back on any enhancement requests that require a code change if they don’t have a safety net to catch any errors.

But we must react to feedback. If we don’t, the product will not evolve. The product won’t stay aligned with the ever-changing set of customer needs, and the product won’t be able to stay competitive with other solutions vying for customer attention in a competitive marketplace.

BetterCloud now has a development culture that heavily encourages TDD.

Given the old adage, “you are what you measure,” we use SonarQube to manage our code analysis tools. SonarQube let us bring together a suite of tools so that we know the code’s unit-test and integration-test code coverage, duplicate code violations, null pointer violations, security violations, and more.

All these measurements are broken down by the code modules, giving teams clear ownership over how their code compares to other teams with respect to quality metrics. We also measure quality using visualizations. We have set up “testing dashboards” that show the automation coverage we have on our functional, performance, and consumer-provider tests.

The market for product development talent is strong, so keep your developers happy by creating a culture of TDD–and a culture with comprehensive test coverage at many levels (e.g., unit, integration, GUI). If you do not, then your development team will be so bummed and stressed about managing and enhancing your codebase that they may want to go work somewhere else. They would rather work somewhere that doesn’t blame them for the bugs that come out of code changes that they were asked to make without the test coverage safety net.

Hopefully, I’ve convinced you that the future is clear: things will change! Things will change because you cannot predict the exact customer needs, the exact technical solution, and the exact user experience. Things will change because even if you do get your customers’ needs exactly right at some point, your customers’ needs themselves will change because the market is pushing them to be more innovative and more efficient.

Let us review. So how do you prepare for change?

  • Build a safety net of automate testing at the unit, integration, and functional level
  • Create a culture where your development team is proud of their code as opposed to scared to touch it — encourage ownership and measurement of code quality
  • Use agile processes to add feedback loops into all levels of your development process

With this in place, you can iterate toward your customers’ needs, evolve technical solutions, and improve the user experience; all while doing it faster and cheaper–with a happy development team!

If you want to take your career to the next level, be proud of your code, and believe that the only thing you can predict about the future is that it will change, then please look at our job postings at BetterCloud. We are building a great product, we have a great culture and we want you to be a part of it.

About BetterCloud

BetterCloud has a true microservices architecture where teams follow Jeff Bezos’s edict on communicating between microservices via internal APIs that will one day be exposed to customers. Using agile processes, teams own their code from their desktops to production. Teams can use Java, C#, or Go to write their services and use HBase, Cassandra, AppEngine Datastore or clustered MySQL for their data tier. All services are required to scale for high availability within a cluster and across zones. TDD is heavily practiced for unit, integration, and automated acceptance tests along with SonarQube rules analysis so that peer code reviews can focus on the fun stuff.

BetterCloud is a meritocracy. Those that excel and want to grow are given the opportunities to do so as quickly as possible. We consider ourselves a learning organization, with ‘lunch-n-learn’ Fridays and 3-week, hands-on ramp-up exercise using our tech stack before jumping into a team.


Sign up for our newsletter