---
title: "[old] 9 agile techniques that will change your life"
date: "2016-09-07"
tags:
- "agile"
- "english"
- "productivity"
- "programming"
- "tech"
---
> **disclaimer:** this post is really old, from when i first started writing technical articles. it's from 2016.
#### Learn about TDD, OKRs, CI, CD and more!
You’ve probably heard of Agile development somewhere. It’s one of the most popular ways of making software these days. With Agile development, you can pump out functioning software within a few weeks and make both your developers and your clients happy.
Here are nine Agile techniques that have helped us here at [devAcademy](https://medium.com/u/e90784f3811e), and that can help you, too.
* * *
### 1\. Test Driven Development
TDD is one of the most popular development processes today, encouraging a sense of confidence in one’s code and helping you provide simpler answers to problems. With the [wide variety of testing frameworks available for every programming language out there](https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks), there’s no excuse not to implement TDD in your project.
TDD is a way to define requirements needed to be met through detailed and specific test cases. Afterwards, software is improved to only pass the new tests. Simply put:
- Find out what you want to add.
- Write tests for what you want.
- Write enough code to make your tests pass.
- ???
- Profit!
You see that right there? That’s TDD in action.
Obviously, your tests should include some sort of system of verification that the desired result is achieved correctly. Your test code should also have the same upkeep and maintenance as your production code — it’s important! Your tests shouldn’t depend on states of the machine you’re testing on, and tests shouldn’t depend on each other. They should be fast to execute and easy to integrate on any machine.
On our Ruby projects, we use a combination of [RSpec](http://rspec.info/) and [Shoulda](https://github.com/thoughtbot/shoulda) to write awesome, transparent tests for our code. Find a testing framework that’s right for you and go wild with it.
### 2\. Continuous Integration
When we make things, we normally make a branch for each feature that we’re making, then merge it back into the master branch after we’re done modifying our own code. This makes sure that everyone always has the most updated version of our code.
Go with the [flow](https://guides.github.com/introduction/flow/)~
Keep your branch updated and make sure your code is available to everyone when you’re done with it. We use platforms like Travis CI to make sure that our code is fully functioning with tests and code quality checks when we merge something to master so that our modifications to the master branch don’t affect everyone else negatively.
### 3\. Continuous Deployment
When I make something new, I always get antsy. I want my new code to be out there as fast as possible, and here at dev we feel like it’s a crucial part of development — new issues get found faster and more efficiently, and features are pushed out rapidly.
There are a few drawbacks to Continuous Deployment, just like there are in Continuous Integration, but the benefits vastly outweigh the consequences. Your users can experience your latest features within moments of you pushing your code to your repos and can give you feedback in real time. There are no wait times to let your users get that fresh code smell; they get the latest code, all the time.
\[embed\]https://stories.devacademy.la/this-is-what-youre-missing-out-on-with-continuous-deployment-afa6b49c4c8c\[/embed\]
### 4\. Daily stand-ups
The best teams make sure that they’re all on the same page. You can’t work on a project together unless you know what everyone is doing. Daily stand-ups help teams work in synergy, letting others know what’s on your plate and your daily progress.
A normal stand-up consists of three questions presented to all team members:
- **What did you do yesterday?**
This question lets your team members know what progress you made on the things you were going to do yesterday, and if you completed them or not. It also makes sure that your other teammates are informed on activities that happened yesterday so they don’t repeat objectives in their work today.
- **What did you do today?**
This questions lets your team members know what you’re going to do today. It also informs your teammates on things that they should try to work on with you and collaborate with so you can achieve your objectives faster.
- **Is anything hindering your progress?**
This is probably the most important question in a stand-up. Being open and honest about our faults helps us grow as people in general. If something was blocking your progress, it doesn’t make you a worse person, it just means you need to improve in that area. That’s the whole point of being agile — identifying obstacles quickly and resolving them quicker.
### 5\. Pair programming
The best ideas and the best projects have been made by working together. In our personal experience, we’ve found that tacking two people onto one objective helps a lot — you have someone else to bounce ideas off of and it distributes some of the load that comes with each objective.
Another person can also help remind you of what goals you need to reach together. With someone else on your team, you can reach objectives faster since there’s someone to corroborate your work.
### 6\. Retrospectives
Here at [devAcademy](https://medium.com/u/e90784f3811e), we have a weekly meeting to review what we did last week, how we did it, how/if we failed at doing something, and how we contributed to our Objectives and Key Results this week.
> Coding isn’t just a way to make computers do things — it’s a personal journey of finding a digital solution to a problem.
Coding isn’t just a way to make computers do things — it’s a personal journey of finding a digital solution to a problem. Retrospectives let us help others provide input on everyone’s progress so we don’t feel alone on our programming expedition.
[What a retrospective looks like at devHouse](https://www.facebook.com/devacademyla/photos/a.356158231151265.1073741827.316005858499836/838163579617392/)
In Agile development, one of the most essential parts is communication. This helps us achieve just that. We have a meeting every Friday morning to socialize and check on our progress as a team. You should, too.
### 7\. Planning
This is really a no-brainer. You should always make sure that your activities are planned out with some tool that fits in with Agile methods. We use Basecamp, but you can use tools like Trello, Asana, or even plain old Google Calendar for planning out things with your team.
Making sure you have a set timeline makes sure that you can verify that you’re getting work done efficiently. If you can meet your goals before the allotted time frame, you’re probably doing way better than you planned, which is great! Having something to refer to in terms of your progress helps you easily and transparently analyze what you need to improve on, and how to pace yourself.
### 8\. Code reviews
Your code isn’t always going to be the best. Sometimes you think your code is awesome, but you haven’t seen the glaring security error or possible cases that could creep up on you in production. That’s why we review each other’s code here at [devAcademy](https://medium.com/u/e90784f3811e). By implementing pair programming, this should be really easy. Your partner and/or supervisors should be able to check your code easily and transparently.
> In Agile development, transparency and communication is essential.
We use GitHub for our code, so we normally comment on our pull requests so we can scrutinize the code we’re working on! That way our entire team is on the same page and we can see why we did/didn’t merge something to the master branch. In Agile development, transparency and communication is essential, and this helps us achieve just that.
### 9\. Objectives and Key Results
Have you ever had a big project that you really want to finish, but don’t know where to start? OKRs can help you out with that. This technique of planning out progress and key points in your project came to be in 1999 at Google, and since then they’ve dominated the market by using this technique. Maybe they’re onto something, eh?
A good objective encompasses a big goal, answering what your final ambition is. It can be something like “Adopt Agile development techniques”. The point is to have something to work up to.
Good key results show you the details of the journey you’re about to take. They’re small steps towards your goal, and they don’t always have to be linear! Things like “Educate team members about Agile techniques”, “Improve productivity using Pair Programming” and “Use OKRs to plan out our next project” are all awesome Key Results because they talk about steps to reach your objective.
Once you have some OKRs planned out, you’ll start to notice that you’re going to be more organized and get more stuff done as a team. You’ll also feel awesome when you cross one of those Objectives off! It’s a great experience.