Imagine for a moment that your mom wanted you and your friends to make a cake. The most obvious way to do this would be to carefully listen to the instructions, and then go off by yourselves to make the cake. After you’ve finished, you return to your mom and show the results.

Sure, that is a method that could work. But due to its non-communicative nature, things might go wrong. What if you present the final cake, but your mom realizes that she wanted brown sugar instead of chocolate flakes as the third layer of the cake? It would be very costly to make those changes.

A better way – an agile way to carry out this mission would be to break the making of the cake into smaller steps. Bite-sized pieces that you can frequently show to your mom. For example, in hour one you build up the first layer of the cake. Then you show this to your mom and see what she thinks. If she likes it, then she will tell you to proceed. If not, she can suggest changes. Due to your mom seeing all the progress as the cake is being made, changes are much easier to implement. If you do need to make changes, you can simply update one component instead of the entire cake.

This is the general idea behind agile development, but it’s a very, very shallow introduction.

The main idea here is that those developing the project adhere to short-term goals. These are usually called stories. Engineers are assigned specific tasks for them to complete. After assignment, they go and enter what is known as a “sprint”. This means that they will try and implement the specific story, and report back once it’s complete. These sprints usually last anywhere from two weeks to a month. On top of all of this, a daily meeting, called a scrum, is held very quickly in order to assess progress. These scrums can help identify problems that may be holding the implementation back. At the very end of a sprint, the engineers gather and create new stories that need to be completed in a following sprint. This process continues until the final product is created.

During the initial phase of fleshing out stories, engineers have to fully understand the purpose of their application. This involved creating various user profiles that will represent potential categories of real users. A power user is going to have much more intricate knowledge of your product than a regular person. This means the engineers have to create two user profiles, one for each. There are many potential user profiles, and the engineering team should try to cover as much as possible.

Once user profiles are set up, the team can begin throwing out stories for each type of user. For example, as a power user, I want to have an advanced configurations setting so that I can customize the application further. These types of stories have to be written out for each feature of the app. Once the stories behind each feature are written, the engineers will understand their application a whole lot more.

Once stories are fleshed out, the sprinting begins. Teams meet each day in the morning for a quick meeting, or a “scrum”. These scrum sessions begin with each engineer stating the accomplishments of the day before, and then reporting their tasks for that day. Engineers will also report any blockers that they have encountered while implementing a story. Any potential confusions, bugs, or other problems that may arise during development. The meetings try to move as quick as possible, and usually never go over fifteen minutes.

Once the scrum session is over, the engineers return to their tasks of implementing the story for that sprint.

These sprint sessions usually last a short period of time. At the very end of a sprint, the team will assess the development process of the application, and decide on new stories. They will then product more sprints to try and implement those stories.

The cycle goes on until the final product is produced. It is easy to tell that such a process has many advantages over the traditional method of “assign and forget”. Agile is not a methodology, but simply a different way of approaching a problem. Break down large problems, provide constant feedback for each chunk of feature, and organize in a way that optimizes production time and efficiency. Of course, it does have its flaws. Their are countless companies that incorrectly implement scrum, or abuse it with their employees. On the other hand, agile becomes a valuable asset to any team willing to stay true to the process, and provides a tactical way of tackling an impossible task.


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 )

Google photo

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

Twitter picture

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

Facebook photo

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

Connecting to %s