When digital marketers think about how developers build a website or program, they probably have images of geeks typing away at a computer screen until a very buggy version of whatever they are working on comes out. But to fully understand how digital properties work, it’s important to understand the process by which they are made. The most popular method today is Agile. To the uninitiated that might sound strange, doesn’t everyone want to be Agile? Who wants to be rigid?

 

Agile-101
Image stolen from GA Blog

 

There are two major processes for developing programs, iterative and vertical. A vertical process involves lots of developers all working on various parts of a program and then piecing those parts together at the end for a quasi-fully functioning program. A loose analogy is sort of like building a skyscraper in separate pieces. One team builds the windows, one builds the steel supports, one builds the plumbing, etc. At the end, all of the pieces get snapped together and people turn on the lights to see if the building functions the way it should.

The problem with vertical processes is that once your building is snapped together and you realize that you have a problem with your plumbing, it’s much more difficult to figure out where that problem is and then unsnap the other parts so you can fix it. Because you didn’t test how your plumbing fits in with the entire building earlier on in the process, you didn’t know that there was a problem at all.

It’s costly and time-consuming to go back through a full stack of code and try to isolate where a problem is occurring. For smaller teams, this can be especially difficult, and while a vertical process might sound better to a client, the time required to smooth out bugs and make the program work properly can be even longer than the time to develop the program itself. And we haven’t even mentioned what happens if there is a fatal incompatibility between functions that is not discovered until the end…

In order to answer these questions and to optimize how teams work, Agile was created.

Agile Methodology

The main purpose of Agile is to reduce the amount of time spend creating a program – and therefore accelerate its development – by creating a minimum viable product and then integrating the required functionalities in an iterative process. By testing the new functionality between each step the team can respond to issues more rapidly and fix them before adding more layers of complexity to the program.

It’s called agile because of how flexible a process it is. Agile gives a preference to a functioning program over an exhaustively documented solution and at the same time favors adaptation over strictly following a plan. For the development team, the idea is to rapidly and regularly deliver a working product to the client, and positively accommodate any changes that come along during the work flow, which would be nearly impossible in a vertical process.

Scrum

We’re not talking about rugby, but in a way, we could be. Scrum is the method that drives Agile. It’s the day-to-day planning of the development that needs to be done. Like rugby, it’s made up of sprints and melees. A sprint is a development cycle that is usually a few weeks or a month long where at the end a minimum viable product is delivered to the client that satisfies a user story of the program. In terms of Scrum, the faster the sprint the better, but the length of the sprint will be set in advance.

At the beginning of each work day there is a melee, which is a meeting between team members that lasts less than 30 minutes and is the key moment to share what’s happening, re-evaluate how long tasks will take, and share problems that are difficult to resolve.

Each sprint has a sprint backlog which are the tasks that remain to be executed to finish the sprint. They are tasks that support the user story and are taken from the project backlog, which is comprised of all of the user stories (functionalities) that remain to be developed.  Because of their nature, sprints can be re-evaluated as need be and tasks can be relegated to the backlog of either the sprint of the project if the sprint is at risk.

Actors

There are three main entities in Agile, the product owner, the scrum master, and the project team. The product owner is the representative of the client and decides which functionalities to be developed when, the deadlines, the priorities, and the budget. He manages the project backlog. It is a best practice for the product owner to not be one of the developers of the team in order to avoid conflicts of interest.

The scrum master is the project manager who is responsible for applying the Scrum method to the development. He is the one who heads up the daily melees and who reports to the product owner.

The last entity is the development team itself, made up of people with different skills like analysts, architects, integrators, etc. In Scrum, a team is usually between 3 and 9 members.

Burndown

As the sprint goes along, the scrum master measures the progress in terms of hours of work left for each task. It’s a graph with a downward slope that hits the x-axis when the sprint is finished. Each day the scrum master calculates where the team is: if the line is above the planned line, the sprint is behind and if it’s below, the sprint is ahead of schedule. Here’s an example from Wikipedia:

Burn_down_chart

After reading this I hope that you have a slightly better idea what people mean when they talk about Agile, there are some amazing resources on the web like this, this, and this.

Do you think this could be helpful for people you know? Share it! And as always please get in touch with any thoughts or questions. Thanks! 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.