The 6 things that help us the most in developing software

Nowadays words like “agile”, “lean”, “scrum” or “kanban” have been abused so many times that some of its initial values or ideas have been lost. Many people think (and say) they are agile because they do stand-ups; some others are trying to come up with new “smart” acronyms (SAFe, LeSS…) for unknown reasons (because the old buzzwords don’t sell anymore?)

This post will not try to patronise you explain what it actually means to be agile or lean. This post will simply explain the 6 things that had most impact to deliver more value in our company.

The following is not meant to be a comprehensive list of everything we do or everything that helps us to deliver a better product. Instead, it’s what we’ve recognised has had more impact along with the objectives we accomplish by doing it well.

HOW DO WE WORK

Before we start highlighting the most useful actions we do, it’s probably useful to know a bit about how we work. When we are about to develop a new feature we usually do something like this:

• Somebody has a good idea, yay!
• Product team refines and prioritises the idea by working out what delivers the most value for the business now.
• Product team writes a bit of a general spec in the form of user story and some acceptance criteria.
• If there is UX involved in it, some wireframes or designs (or even prototypes) may be worked on at this point.
• Developers discuss the story with product and among themselves to fully understand it and highlight any possible problems we may face.
• Somebody does the story and raises the pull request.
• CI triggers and marks the PR as green in github once all tests (unit, integration, end-to-end, load) pass.
• A different developer (sometimes two) reviews the code and also tests the functionality.
• Pull request is merged, and CI deploys it to our development environment.
• Product reviews the functionality and moves the story to done.

At that point, this story is considered internally released and will be deployed to the rest of our environments depending solely on business needs.

WHAT IS KEY IN THIS PROCESS?

1. CONTINUOUS DEPLOYMENT

As seen previously, we don’t do continuous deployment to production because our clients prefer to have a release schedule every so often that has X features. That hasn’t prevented us to deploy continuously internally as if we were deploying to live, meaning we still get most of the benefits of a continuous deployment approach.

Thanks to our infrastructure, anybody is able to:

• Get feedback as soon as possible as if the work is done or not. That implies our CI has to check several things: compilation, lints, tests…
• Deploy any version of the software to any environment easily. We use Mesos and created a small Slack bot that helps us deploy anything easily.
• Know what version is running in a specific environment and what this version contains. Release notes.

2. GOOD TEST COVERAGE

We run a set of tests every time we do a release. These tests are comprised of unit, integration and end to end tests. We also like to run load tests to know the impact on performance of our last change and data integrity tests that validate our data ingestion processes.

We don’t enforce a certain percentage of coverage (although we have >80%) but we focus on the quality and maintainability of our tests. At Intent HQ, writing and having tests is treated like fastening your seatbelt or putting your helmet on: a basic measure of safety that allows us to work fast.

3. RESPONSIBLE PULL REQUESTS (AND QA)

For us, pull requests are useful in different ways.

The obvious one is ensuring that the code written follows our coding standards and has proper tests that cover the functionality added. Reviewing code quality helps us develop a sense of collective code ownership as well.

Even more importantly though, we agreed as a team that we would make sure that anything that is merged into master works. By this, we mean it not only passes automated tests, but it has also been manually tested by somebody else in the team (ad-hoc UAT if you will).

That extra level of testing has added a bit of overhead to our process but this overhead has been paid in full by the benefits we are getting from it:

• Finding bugs before our users.
• Making sure we collectively know how everything works.
• Making sure we value our customers and their time by ensuring the quality of of every single thing we ship.
• Testing things that we cannot easily automate, or that are helped by human intuition.

4. FEATURE TOGGLES

We have a system allowing us to set feature toggles empowering us to enable/disable/show/hide a feature. We can do this for all users in the system, for just a restricted set of them, or even for a specific user.

Anybody can easily toggle these flags at any point in time, giving us a lot of flexibility to “canary” release a feature, easily rollback new features, or do A/B tests.

These toggles are allowing us to make decisions about whether to ship a feature as late in the process as possible while still delivering as fast as possible. A side-benefit is that we also don’t have any more feature branches lingering forever and causing rebase/merge headaches.

5. PRODUCT INVOLVEMENT COMMITMENT

At Intent HQ, Product is not only involved in several parts of the process, but they are also committed to it. We need UAT and product signoff to be as fast as possible, otherwise the delivery flow breaks and our throughput is affected. We make sure we can achieve this by making the most of our standups and Slack channels – we believe communicating often and frequently is the key to enabling us to move fast and stay together.

6. INVESTING IN TRUST

A couple of years ago, Alistair Cockburn came to Barcelona and the Scala BCN meetup had the pleasure to have some beers with him. When speaking with us, he made a clear statement that he believed companies with remote teams “should invest in trust”.

At Intent HQ we’ve always tried to make sure we don’t have two development teams (one in Barcelona and another one in London), but just one. It’s not an easy thing to do, but we are doing it pretty well.

In order to have this trust, we are using several tools: a video conferencing system for meetings, ScreenHero for pair programming and Slack for almost everything (from chats, to direct messages or quick 1:1 calls).

Along with all these, our regular visits to meet each other face to face are the best investment of all.

SUMMARY

As a company we always try to keep in mind the lean and agile principles and more importantly, we always try not to be too tied to any process or way of doing things, we always try to evolve and adapt to what’s best for us at any point, learning from our mistakes and our successes.

That also means our process will probably be different next time we write a blog post, but that’s what life is about, isn’t it?

“Fent Pinya picture” from jqmj released under CC BY-SA 2.0.