The Agile Process

The Agile Process at LaunchCode

Building a successful project takes work and some serious perseverance. However, many people don’t realize that their success or failure in building a project depends on more than pure grit. The most successful individuals and teams create their projects systematically. They keep things simple and only work on what is most important to the user. It may seem counterintuitive, but they focus on maximizing what they don’t build.

While it may appear that these people have an innate ability to strategize and pump out projects; they may actually be borrowing concepts from the Agile methodology.

“Agile” is a BIG buzz word in the tech community. While it can become very complicated, at it’s heart, Agile is simple. The Agile methodology is premised on building software more simply to better serve the needs of the user. That’s it.

The LaunchCode Tech Team uses the Agile methodology everyday to build projects enabling LaunchCode to provide free education and paid apprenticeships in technology across the country. We love Agile. As a team it helps us build better projects, spend our time more effectively, and enjoy our work by helping others.

It may seem counterintuitive, but they focus on maximizing what they don’t build.

The same Agile concepts embraced by the LaunchCode Tech Team (and much of the technical world) can be helpful for your project too. Let’s break it down.

What is Agile?

It all started in 2001 when a group of software developers got together and decided to change how the world should write software. They wrote a document titled the Agile Manifesto. Consider it the “Declaration of Independence for Developers.” The intention was to liberate the developer’s spirit while better serving the needs of the users.

These developers wrote up 12 principles. They’re all great, but we’re going to focus on two concepts from Agile Manifesto here:

1. Work closely with the customer to deliver exactly what they need.
2. Ensure that developers can work happily and productively.

To understand Agile, you have to understand how software has been built historically. Traditionally, software was developed using the Waterfall Method. Using the Waterfall Method, you first make a grand plan of all of the features you would like in your app. You may even decide in what order the features should be completed. Next, you sequentially build each feature. When all of the features are complete, you can call the project complete and present it to the user.

Waterfall may sound enticing. It is thorough. It lets you plan ahead. It may even be the natural work pattern for many people. In any technical project though, you can run into a few snags. First and foremost, what happens when things go wrong? For example, when your features take longer than expected, will you have a working app? Will the user find value in using it? Will the features that are complete be done well and bug-free? How much will you enjoy being a developer trying to meet that deadline?

Agile Methodology forces you to think unconventionally. Instead delivering the perfect project, deliver the imperfect project initially. Ask the user what feature is most important to them. Complete that feature first. Deliver it to the user and get their feedback. Work on the second most important feature to the user. Repeat.

The phenomenon that you will discover is two-part. First, since you were consistently “delivering” your project and getting feedback, even if your project isn’t completely “done”, it will likely be functional and usable. That’s good. Second, you may find out many of the initial features of the app turned out to not be non-essential or even a distraction. Not only did you avoid spending time on unimportant features, but your project is less complicated and less messy.

Agile In Practice

Whether you are a neophyte developer on the path to a professional career or an experienced software engineer, Agile can make building more productive and fun.

Here are our Agile words of wisdom to all of you that are building a project, launching an app, and changing the world:

Simplicity — the art of maximizing the amount of work not done — is essential.

Simplicity

One of core the tenets of Agile is “Simplicity — the art of maximizing the amount of work not done — is essential.”

User Stories

Frame your features very specifically using user stories. Think about who is using the feature and why they are using it. Make them small, accomplishable actions.

For example, instead of saying this:

“Build an ecommerce website.”

Say this:

“Jane can see a picture of each product for sale.”
“Jane can search through the products by name and color.”
“Jane can purchase an item by providing her credit card information.”

User stories let you break a big project into little chunks that can be individually delivered to the user. Since stories are written from the perspective of the user, it is easier to think about the needs of just that one user and not anyone who could ever use the app.

YAGNI

(You ain’t going to need it.) Stop! Before you add that feature, please remind yourself that you most likely won’t need it. Really…you probably won’t need it. Only work on the most important features first, because even the “small” or “easy” features can end up being a lot of work or make things complicated. Keep it simple. Focus only on the essential.

Just Ship It

Most likely your project is made to help someone, so give them what they have been waiting for! Even if it’s not perfect but it works, ship it! Push it to Github. Make it live on the internet. Update it in the app store. Share it with a friend. Sign up for LaunchCode. Most often you will be surprised by the warm welcome your creation receives from the world.

Agile at LaunchCode

At LaunchCode, we have six developers and a product manager working on all of our software systems including the website, candidate management, placement application, and education software. We embrace the core concepts of Agile as well as employ Scrum to help prioritize our work amongst the team. We have approximately three to five different projects at any given time, and the product manager decides and prioritizes work (stories) based on impact.

We work in two week sprints to deliver certain features. Each feature is written out as a user story with the name of the user and why they are doing that action. We assign point values to each story based on the complexity, risk, and effort. We track how many points we complete each week, and use that data to estimate of how many points we expect to complete in the following weeks. Pivotal Tracker online software helps us prioritize our stories by order of importance. Developers choose the most important story and deliver it to the customer. Repeat.

Our team has a daily standup. It’s a great time for the team to sync up on what everyone is working on, verbalize their goals for the day, and bring up any issues that may be blocking their work. At the end of each two week sprint we have a retrospective meeting where we discuss what went well and what can be improved, so that we are learning from and constantly improving the process. This works well for our team, and we think it's good advice generally.

Happy Coding!