When a software developer hears about the latest “new JavaScript framework” or “new IDE,” they don’t have to ask for more information. However, if they hear about a “new agile framework,” they might pretend to understand, but in reality, they will be wondering, “What does ‘agile framework’ even mean?”
The terms “agile,” “scrum,” and “kanban” are often misused in the current software engineering landscape. In this piece, I’ll clarify their meanings and provide an overview of each one.
AGILE
When you are discussing the work process, try to use the word “agile” alternately to show how clever you are. It is an excellent adjective or adverb that covers a lot of ground, so you don’t need to be an expert on the subject. But, what does “agile” actually mean?
The Agile Manifesto, along with the 12 agile principles, outline the guidelines for the “Agile software development” approach. These principles provide the foundation for the agile methodology.
People and their connections, instead of methods and equipment.
Comprehensive instructions accompanying reliable software
Participation of Customers in Agreements Negotiation
Navigating shifting circumstances versus maintaining a steady strategy
You can say that you operate in an agile setting if you abide by the standards and ideas of agile software development, which involves frequent software delivery that functions properly, strong team communication, and an openness to changing requirements. In essence, this process is a combination of various methodologies, frameworks, and strategies that follow the same concepts—not one particular strategy.
Agile is a mindset and the basis for decision-making.
A method of reasoning and decision-making is known as agile.
Why is it important for us to follow these standards in our work?
After many years of trial and error, in 2001 seventeen software developers convened and found common ground in their approaches to addressing the challenges of software development. This resulted in the creation of a Manifesto, which outlines the core principles that guide the various frameworks and methodologies (like scrum and extreme programming) developed from the 1970s to the 1990s.
The Agile Manifesto is a compilation of ideas and practices that have arisen in response to various issues.
SCRUM
If you don’t know what “agile” methods are, you may unknowingly make yourself look silly by using terms like “Scrum and other agile methodologies” in conversation with someone familiar with the concept.
Scrum is commonly mistaken as a methodology, but it’s not. It doesn’t provide step-by-step instructions, nor does it answer all questions. Moreover, many implementations of scrum are misguided and do not bring any value. Consequently, some even claim that scrum is ineffective, which is an untrue statement.
What is the definition of scrum, as per the Scrum Guides? Scrum is defined in the Scrum Guides as:
An approach that facilitates people in managing complex adaptive problems and producing valuable products through productivity and ingenuity.
Scrum is a structure, but if it is going to be effective, the whole team needs to understand and value agile values as well as stick to the principles of scrum. Misuse of the scrum system is common.
In Scrum, the Product Owner, Scrum Master, and Development Team are the main roles.
These Scrum events—the Planning Meeting, Daily Scrum, Sprint Review, and Sprint Retrospective—are additional components of Scrum.
Furthermore, there are three items that can be produced: a product advancement, a sprint to-do list, and a product to-do list.
In Scrum, work is typically broken up into two-week intervals, which are referred to as “sprints.”
The product owner establishes the goals of the project and adds new tasks and features to the product backlog. At the sprint planning meeting, the development team selects which tasks to work on and how to execute them. During the development phase, the team keeps track of their progress, meeting daily to discuss any changes needed. At the conclusion of the sprint, the product owner reviews the product increment and the backlog may be amended if necessary. Lastly, the team convenes for a postmortem to review the process and consider any enhancements.
Scrum is not difficult to understand, but can be difficult to implement since it usually requires adjustments to both the development process and work ethic. It works best for projects requiring multiple experts and with a long duration.
Scrum is so popular because it offers more value to products and their customers when compared to the conventional waterfall model. Unsuccessfully completed projects under the waterfall model can occur due to long periods of inactivity, while scrum prevents this.
In order to make the most of Scrum, the team must consistently generate something valuable in each sprint. This value must be measurable, and the team must identify and address any impediments to creating greater value in the subsequent sprint.
Crafting software is often less rigid than constructing a building; it’s no longer seen as a cardinal sin to adjust the product’s requirements while it is still in production. Scrum is a tool that was designed to accommodate these shifts and help create predictable outcomes while reducing potential hazards.
Agile practices such as Planning Poker, Pair Programming, Test-driven Development (TDD) and Behaviour-driven Development (BDD) are often used alongside Scrum but do not make up part of the framework itself. Kanban is another popular method used with Scrum, although there is often confusion concerning the relationship between the two.
KANBAN
The audience often wonders which is better, scrum or kanban? This query is difficult to answer as it is like asking which is preferable, apples or oranges. Both scrum and kanban are great, so there is no definitive answer.
Kanban is an uncomplicated approach that focuses on providing items on time without burdening personnel. This method is more malleable than scrum, yet both enjoy the objective of delivering the greatest value.
Kanban, an assembly of ideas and actions, was not created by a group of software engineers. Instead, it is derived from Toyota’s production policies and is extensively utilised in other industries. There are no hard-and-fast regulations needed for its usage or execution; however, one of the more common kanban applications in software development includes a kanban board with separate divisions for activities and phases of the job.
The development process is typically represented by columns, with the most basic example being “To Do,” “In Progress,” and “Done.” Items begin in the “To Do” column, are moved to “In Progress” when work begins, and are placed in “Done” after completion. However, some scenarios may require a more complex approach.
Backlog > Establishing Requirements > Ready for Coding > Programming > Code Evaluation > Quality Assurance > Implemented > (Nobody Utilises It > Totally Eliminated)
The team can customise the workflow by creating columns and stages based on the project’s needs. If necessary, individual specialists can have their own columns. The “pull” concept suggests that only when there is a pressing requirement should tasks be added to the process.
This board’s purpose is to show the progress of tasks; one of the main components of Kanban. You don’t need a board to utilise the Kanban system, it can be as easy as a Google sheet of jobs and their statuses represented by various colours, or more complex diagrams, tables, or Gantt charts. To gain a better understanding, form a visual of the workflow to make it more visible.
Limit multitasking by reducing the amount of work you do concurrently. For example, if there are three designers on the team, the number of projects in the “Designing” column could be limited to three.
Kanban and Scrum are both heavily focused on the team, but unlike Scrum, it does not demand certain roles to be filled. Furthermore, it suggests continuous improvement instead of the Scrum’s one-time Sprint Retrospective.
What should I use?
Although Kanban and Scrum are not directly comparable and there is no conflict between the two, they still have some similarities. They both follow the same values and empower the team, with the aim of eliminating inefficiencies and hindrances. Nevertheless, the way they are achieved differs: Kanban does not assign a timeline for activities, whereas Scrum does. It encourages maintaining the existing workflow in comparison to Scrum, which pushes for changes.
When deciding on a method of project management, it is important to consider the context of the project, including the team and the specifics of the task at hand. Kanban is simpler to adopt than Scrum since it is less process-heavy and requires less changes to team culture. Nevertheless, Scrum might be more effective in the long run due to its detailed guidance, as long as everyone is in agreement with its use.
Neither scrum nor kanban are strict regulations; you can use whichever aspects of each you feel are beneficial for your team, such as a daily standup or retrospective. Additionally, it is possible to combine the two approaches if desired.
Scrum has proven to be successful when everyone is on board, but I’ve encountered cases where that can be difficult. Introducing a process and cultural change, especially with someone hoping to create a product as big as Google, can be a challenge. In those cases, Kanban is a better option since it’s more flexible and doesn’t require those types of adjustments. Authors believe that it can lead to agility and can make the transition to Scrum smoother. Others say that using Scrum ultimately leads to Kanban.
No single strategy can be applied to all jobs as they are all distinctive. It is the responsibility of the project manager to find the most efficient way to manage their team.
Stay informed by checking the Works blog and following our social media pages for the latest news!
