Why Agile?

Not many years ago, waterfall methodology was the most common process when talking about developing software. This methodology is based on producing with correlation, that is, one stage after the other; one ends and then another one begins, and so on.

The process is pretty similar to the one at the assembly line; the procedure is linear and nothing moves forward to the next phase until the actual is not completely finished.

Over time, companies started realizing they were investing too much time and money on extensive documents for systems which, they never ended up using or implementing, or if they did, they were not precisely what the users wanted or needed. This basically happened because there was no stage to validate the idea.

When developing a digital product (an app, a game, an internal management system, etc) it is necessary to constantly validate the ideas. It is very common to have new ideas during the process, or even to realize you are working on something that actually does not add that much value to the product.

This is why the “relatively new” good practices in software encourage the participation of all the team members throughout the whole process, in short periods of time, in order to grow the product on a robust basis and pivot when necessary — if it is detected that something does not work as it should, or users behave differently than expected, or they do not like or notice it)

In 2001, “The agile Manifest” was published and it established the foundations to develop successfull software. The manifest is based on different values and principles that refer to the following ideas:

• Functional software in a short period of time (2 weeks to 2 months)
• Encourage change over sticking to the plan
• Active client collaboration
• Teams and interactions over process

Even the biggest and most bureaucratic companies are working on agile methodologies, as waterfall was not generating the expected results. It was being too bureaucratic, slow and expensive.

Within agile, there are different frameworks. Among the most common ones, we can find Extreme programming, Scrum, Lean, Kanban.

They are all really good. Which to use will depend on the project’s goal, on how much the client is involved, on the project status and the team’s preferences.

I will focus on Scrum which, on my opinion, is a good balance between fast deliveries and agility, with order and organized teams.

Projects have different phases: planning (documentation), design, coding and testing. Watterfall considers each of this phases as individual and separate, and assumes that after the first stage of planning, you already know all that has to be designed, coded and tested. This means it assumes you know, with certainty, the totality of a project that can last, for example, 1 year. This seems a bit arrogant, doesn’t it? Scrum, meanwhile, seeks to involve all 4 stages in a short period of time called sprint (1 to 4 weeks).

Scrum methodology has artifacts, ceremonies and roles. I won’t get deep into each of these, but I’ll do a short introduction, just to put you into context:

Roles:

• Development team: they are the ones in charge of developing the product — designers, developers and testers.
• Scrum Master: in charge of organizing the team, making sure the communication is fluid and removing possible impediments throughout the process.
• Product Owner: responsible for defining and prioritizing the product backlog. This does not mean he does it on his own — he involves the rest of the team to do this — but it’s his main responsibility.

Artifacts:

• Product backlog: functionalities expected to be developed in the future.
• Sprint backlog: functionalities expected to be developed in a specific sprint. (1 to 4 weeks)
• Increment: what was completed at the end of a sprint. This is a key concept — the team’s mindset should not be to just make progress after each sprint, but to have certain functionalities ready. (It’s better to have 1 finished functionality, than 3 progressed)

Ceremonies:

• Sprint Planning: scrum team meeting with the product owner where the functionalities to be developed on the current sprint are defined.
• Daily Sprint: 15 minute meeting where the development team discusses what has been done, possible issues, and the next things to work on. The Product Owner can join the meeting to clear possible doubts.
• Sprint Review: meeting with the Product Owner where the increment is shown.
• Sprint Retrospective: scrum team meeting to discuss and analyze a past sprint, in order to identify positive points and things to improve.

Scrum helps organize the team and provides shared responsibilities. It allows constant iteration in order to identify what adds value to the product and what does not, to be able to change when needed. Moreover, it generates a lot of synergy between those involved in the project and the client, building a space where many creative ideas can arise.

Understanding Scrum is not that complicated, but putting it into practice can be hard. There are several challenges that may cause teams to discard it the first time they feel threatened or uncomfortable.

Scrum does not provide you with all the rules and guidelines of how to do everything. This is good, and “bad” at the same time. ¿Why? There are some people that feel comfortable with clear guidelines and rules. It is good because, being an agile framework, one of its premises is that every team works differently, and therefore, it gives them the freedom and flexibility allowing them, through the different ceremonies, to redefine the interactions, discover improvement opportunities and implement them.

If you are interested in working with Agile, not necessarily with Scrum, I recommend you looking at this report that shows how the projects that are carried out using agile are more successful than with waterfall.

If you have any comments or suggestions, feel free to contact me! gonzalo@amalgama.co