Does your client need a lot of attention (clients, amirite?), and communication is the core of your project? Does it require constant changes in a fast-paced environment? Did you catch a cold and can’t stop coughing? Agile Development Model is going to meet all your needs.
For sure, there is no one ideal approach that solves all the problems, but the Agile Model is currently the most popular framework used by software development teams. If you ever search for a job in the industry, you must have seen the “Working in an Agile team” requirement at least several times. We got you, don’t worry. In this tutorial, we will cover everything you need to know about the fast-boy software world.
What is Agile Methodology?
First of all, the Agile Model is a set of different procedures and principles to follow while developing. Back in the days when web development started getting popular and being done by smaller businesses and startups, people needed an alternative method to develop their software against rapid changes. “Agile Manifesto” was published in 2001 by a group of tech geniuses as their way to deliver the software. The manifesto presents 4 main ideas:
- People and interactions over processes and tools
- Software functionality over documentation
- Collaboration over negotiation
- Dynamic changes over static plans
As we can infer from the points, it is focused more on “what to deliver”, than “how to deliver”. Once the team is following the Agile mindset, “how” can change over time, and that gives us flexibility and adaptability against circumstances.
Okay, but how to work Agile?
Similar to the Spiral Model, this model is also an iterative and incremental method, so that the product is developed over the iterations, and at the end of each cycle a new, fully working application is released. Yet, it is more flexible than the Spiral approach as the release time is shorter and there is more communication with the client.
It also has two different frameworks, Scrum and Kanban. Here we will be learning about Scrum, and later we will be touching on the differences between those two types as well, pinky promise. Now, let’s take a look at some jargon for Scrum. You can use this terminology to be fancy in social meetings and get the attention of your crush (do not do that, I beg).
Scrum Terminology
Scrum Master: Title given to the Product Managers in the Scrum projects
Product backlog: After gathering the requirements from the customer, the scrum master writes all the items to be done to deliver the product point by point. This documentation is called the product backlog.
Story: A single feature/module to be implemented in the project
Epic: The collection of multiple, related stories
Story Points: The rough estimation of time to complete a new task assigned by the person who will be completing the task. The interesting thing about the story points is that they have to be a Fibonacci number (1, 2, 3, 5, 8, 13, 21, …). The reason is that it’s not wanted for the task assignee to spend too much time on the minor differences in the task to give the perfect estimation but have a cumulative difficulty. Story points may indicate an hour, day, or any timeframe set in advance of the project.
Sprint: In Agile projects, every 2 weeks, there is a new version of the product to be delivered. Those 2 weeks periods of development are called Sprint.
Sprint Planning: A meeting is conducted before each sprint to discuss what to work on in the new sprint.
Sprint Backlog: Things to accomplish during the sprint. During the sprint planning meetings, deliverables for the new sprint are “pulled” from the product backlog to the sprint backlog. If any item from the sprint backlog is not ready for release, it’s returned back to the product backlog.
Scrum Board: The features to work on during the current sprint are managed through scrum boards using an agile project management tool, such as Jira (foreshadowing, we will learn about this tool later on). It typically consists of “To do”, “Develop”, “Test” and “Done” states and the features are moved in between those states during the sprint.
Scrum Meeting: A short stand-up meeting done daily on what work was done today, and what will be done tomorrow. (There’s no slacking in Scrum)
Retrospective: You guessed it correctly! Another meeting, and this time it’s done after every sprint to take a look at what has been done in the sprint, and what can be improved in the upcoming sprint.
Bug Triage: A meeting to discuss about the bugs and their priorities during the current sprint.
Velocity: Amount of work the team can get done during a sprint on average. Calculated by Total Story Points/Number of Sprints.
Ultimately, human interaction is very high in projects with constant meetings. After every sprint, the new version of the product is given to the client and moved on to the next sprint.
Scrum vs Kanban
Kanban is an alternative for Scrum. Fancy fact, Kanban was originally created by an engineer in Toyota, Taiichi Ohno, to manage the work and inventory stage by stage. Decades later, it was adopted by the software industry. Since it’s not primarily an SDLC framework, we are free to boo Kanban and keep using Scrum. Boo!
Different from Scrum, Kanban is more about visualizing the workflow than solving complex problems. It is also not made up of sprints and is rather a continuous process. Roles and the meeting ceremonies are not as strict as Scrum, but the daily standups are still conducted. Lastly, there is no velocity in Kanban as there are no sprints, but there is another metric called “WIP (Work in Progress)”. WIP creates a strict time limit to complete the tasks in the columns in the Kanban board (similar to the Scrum board) and ensures that the items move to the next column as soon as possible.
| Attribute | Scrum | Kanban |
| Project Manager | Scrum Master | Agile Coach |
| Approach | Periodic (Sprints) | Continuous |
| Idea | Delivering innovative products | Visualizing the workflow |
| Metric | Velocity | WIP |
So, when to use Kanban over Scrum? Well, in Kanban there is not much a client and stakeholder engagement. If the work does not require much a creativity and customer engagement, and it’s done like a daily routine by a bunch of area experts, Kanban can be used. Yet, the differences between Kanban and Scrum are not as strict, and nowadays teams tend to use the beneficial aspects of each method, and there is even a hybrid approach called “Scrumban” to combine the flexibility of Kanban and the routines of Scrum.
Next, we will get a step closer to start learning about testing.
Types of SDLC < Previous – Next > STLC??
Funky QA 