Kanban, Lean, Scrum- Agile Methodologies Tutorial Just An Hour – FREE

Last updated on 22nd Jun 2020, Blog, Tutorials

What is Agile Framework?

Agile is an umbrella term for several iterative and incremental software development approaches, with each of those variations being its own Agile framework. The most popular Agile frameworks include Scrum, Crystal, Dynamic Systems Development Method, and Feature-Driven Development.

• While each Agile methodology type has its own unique qualities, they all incorporate elements of iterative development and continuous feedback when creating an application. Any Agile development project involves continuous planning, continuous testing, continuous integration, and other forms of continuous development of both the project and the application resulting from the Agile framework.
• Each Agile framework is considered lightweight. Rules and practices are kept to a minimum, especially when compared to traditional waterfall-style development processes, and are designed to be adaptable to all kinds of circumstances. The focus, instead, falls on empowering developers of all kinds to collaborate and make decisions together as a group quickly and effectively. The grand vision behind the Agile development methodology is to create applications in small increments, with each individual increment tested before it is considered complete. This process assures quality is “built” into the product, versus inspecting for quality later.

How to Practice Agile?

There are various Agile Methodologies that are in practice in various diversified industries.

However, the most popular methodologies amongst all of them are:

• Scrum
• Kanban
• Extreme Programming

All these methodologies focus on lean software development and help in building better software effectively and efficiently.

That is all with Agile Introduction. The part is structured to help you to understand the core values and principles that shall be adopted for a team to be working in an Agile mode and mindset.

Types of Agile Methodologies

There are several agile methodologies in practice across the world. We are going to learn more in detail about four of the most popular ones.

1) Scrum

• Scrum can easily be considered to be the most popular agile framework. The term ‘scrum’ is much considered synonymously to ‘agile’ by most practitioners. But that is a misconception. Scrum is just one of the frameworks by which you can implement agile.
• The word scrum comes from sports rugby. Where the players huddle together in an interlocked position pushing against the opponents. Each player has a defined role in their position and can play both offensive and defensive as per the demand of the situation.
• Similarly, the scrum in IT believes in empowered self-managed development teams with three specific and clearly defined roles. These roles include – Product Owner (PO), Scrum Master (SM) and the development team consisting of the programmers and testers. They work together in iterative time boxed durations called sprints.
• The first step is the creation of the product backlog by the PO. It’s a to-do list of stuff to be done by the scrum team. Then the scrum team selects the top priority items and tries to finish them within the time box called a sprint.
• An easier way to remember all of this is to memorize the 3-3-5 framework. It means that a scrum project has 3 roles, 3 artifacts, and 5 events.

These are –

Roles: PO, Scrum master, and development team.

Artifacts: Product Backlog, Sprint Backlog and Product increment.

Events: Sprint, Sprint planning, Daily Scrum, Sprint review and Sprint retrospective.

We will get to know more in detail about each of these in our subsequent tutorials.

2) Kanban

• Kanban is a Japanese term which means a card. These cards contain details of the work to be done on the software. The purpose is visualization. Every team member is aware of the work to be done through these visual aids.
• Teams use these Kanban cards for continuous delivery. Just like Scrum, Kanban is also for helping the teams work effectively and promotes self-managed and collaborative teams.
• But there are differences between these two as well – like during a scrum sprint, the items being worked upon by a team are fixed and we cannot add items to the sprint whereas, in Kanban, we can add items if there is available capacity. This is particularly useful when the requirements change frequently.
• Similarly, another difference is that while the scrum has defined roles of a PO, scrum master, and development teams, there are no such pre-defined roles in Kanban.
• Another difference is that while the scrum suggests a prioritization of product backlogs, Kanban has no such requirement and it is totally optional. Thus Kanban requires less organization and avoids non-value adding activities and is suitable for the processes which require responsiveness towards changes.

3) Lean

Lean is a philosophy that focuses on waste reduction. How does it do that?

• In lean, you divide a process into value-adding activities, non-value adding activities and essential non-value adding activities. Any activity which can be classified as a non-value adding activity is a waste and we should try to remove that wastage in the process to make it leaner.
• A leaner process means faster delivery and less effort wasted in tasks which don’t help to achieve the team goals. This helps to optimize every step in the software development cycle. That is why the lean principles were adapted from lean manufacturing into software development.

Lean software development can be used in any IT project by applying the seven lean principles which are shown below:

• These are quite self-explanatory as their names suggest. Eliminating wastage is the first and most important lean principle and we saw how to do that, we just classify activities as value and non-value add.
• A non-value add activity can be any part of the code which might make it less robust, increase the effort involved and take up a lot of time while not adding justifiable business value. It can also be vague user stories or poor testing or adding features that are not required in the big picture.
• The second principle amplifying learning is again easy to understand as a team needs various skills to deliver products in a rapidly changing environment with new technologies cropping up in quick durations.
• Making late decisions can be rewarding in circumstances where it reduces rework like if there are any changes expected then better delay it so that the team does not have to redo the work as the business needs change.
• But there is always a trade-off here as the teams need to balance this with the fourth principle of delivering faster. Delaying of decisions should not impact the overall delivery and must not reduce the pace of work. One eye should always be on the complete picture.
• Having empowered teams is also very common nowadays and this is something that even agile suggests. Empowered teams are more responsible and can take decisions faster. The sense of ownership in an empowered team leads to better results. To empower a team, they should be allowed to organize themselves and take decisions on their own.
• Thus we see that lean and agile have a lot in common with one stark difference – while lean teams can help to refine a product, agile teams are the ones who actually build the product.

4) Extreme Programming (XP)

• Extreme programming is another most popular agile techniques. As per extremeprogramming.org, the first XP project was started on March 6, 1996. They also mention that XP impacts software project development in 5 different ways – communication, simplicity, feedback, respect, and courage. These are called the values of XP.
• Out of these, it all starts with communication. XP teams collaborate with business teams and fellow programmers on a regular basis and start building code from the very first day. The focus here is on face to face communication as far as possible with the help of the other visual aids.
• Extreme programmers also build a simple code and start getting feedback on it from the first day itself. The focus is on not going overboard or predicting requirements which have not been shared. This keeps the design simple and produces just the minimum product which will serve the requirements.
• Feedback helps the team to improve and produce a better quality of work. This helps them build respect for each other as they learn from each other and learn how to share their views.
• This also gives them the courage as they know that they have gathered everyone’s best ideas and produced a good product with feedback from others. Thus they are also not afraid to include changes or receive further feedback on their work.
• This is particularly useful in projects where the requirements are going to change often. Constant feedback will help the teams in including these changes with courage.
• Thus we have seen the different agile methodologies like Scrum, XP, Kanban and Lean along with their respective advantages and disadvantages.
• Now, we can easily differentiate between them and also appreciate the subtler differences amongst them. We also learned the fundamentals of each of these methodologies and saw how to apply them in our projects as and when required.

WHAT ARE THE BENEFITS OF AGILE?

Benefits to Customer:

Customers find that the vendor is more responsive to development requests. High-value features are developed and delivered more quickly with short cycles, than with the longer cycles favored by classic “waterfall” processes.

Benefits to Vendors:

Vendors reduce wastage by focusing development effort on high-value features, and reduce time-to-market relative to waterfall processes due to decreased overhead and increased efficiency. Improved customer satisfaction translates to better customer retention and more positive customer references.

Benefits to Development Teams:

Team members enjoy development work, and like to see their work used and valued. Scrum benefits Team members by reducing non-productive work (e.g., writing specifications or other artifacts that no one uses), and giving them more time to do the work they enjoy. Team members also know their work is valued, because requirements are chosen to maximize value to customers.

Benefits to Product Managers:

Product Managers, who typically fill the Product Owner role, are responsible for making customers happy by ensuring that development work is aligned with customer needs. Scrum makes this alignment easier by providing frequent opportunities to re-prioritize work, to ensure maximum delivery of value.

Benefits to Project Managers:

Project Managers (and others) who fill the ScrumMaster role find that planning and tracking are easier and more concrete, compared to waterfall processes. The focus on task-level tracking, the use of Burndown Charts to display daily progress, and the Daily Scrum meetings, all together give the Project Manager tremendous awareness about the state of the project at all times. This awareness is key to monitoring the project, and to catching and addressing issues quickly.

Benefits to PMOs and C-Level Executives

Scrum provides high visibility into the state of a development project, on a daily basis. External stakeholders, such as C-Level executives and personnel in the Project Management Office, can use this visibility to plan more effectively, and adjust their strategies based on more hard information and less speculation.

WHAT ARE THE SCRUM REQUIREMENTS?

Scrum does not define just what form requirements are to take, but simply says that they are gathered into the Product Backlog, and referred to generically as “Product Backlog Items,” or “PBIs” for short. Given the time-boxed nature of a Sprint, we can also infer that each set should require significantly less time to implement than the duration of the Sprint. Most Scrum projects borrow the “XP” (Extreme Programming) practice of describing a feature request as a “User Story,” although a minority uses the older concept of a “Use Case.” We will go with the majority view here, and describe three reasonably-standard requirements artifacts found in Product Backlogs.

User Story:

A User Story describes a desired feature (functional requirement) in narrative form. User Stories are usually written by the Product Owner, and are the Product Owner’s responsibility. The format is not standardized, but typically has a name, some descriptive text, references to external documents (such as screen shots), and information about how the implementation will be tested. For example, a Story might resemble the following:

The elements in this User Story are:

1. Name: The Name is a descriptive phrase or sentence. The example uses a basic “Role-Action-Reason” organization. Another common style, popularized by Mike Cohn, follows the template “As a <type of user>, I want <some goal> so that <some reason>.” The choice of template is less important than having a workable standard of some kind.
2. Description: This is a high-level (low-detail) description of the need to be met. For functional (user-facing) requirements, the description is put in narrative form. For non-functional requirements, the description can be worded in any form that is easy to understand. In both cases, the key is that the level of detail is modest, because the fine details are worked out during the implementation phase, in discussions between team members, product owners, and anyone else who is involved. (This is one of the core concepts of Scrum: Requirements are specified at a level that allows rough estimation of the work required to implement them, not in detail.)
3. Screens and External Documents: If the Story requires user-interface changes (especially non-trivial ones), the Story should contain or link to a prototype of the changes. Any external documents required to implement the Story should also be listed.
4. How to test: The implementation of a Story is defined to be complete if, and only if, it passes all acceptance tests developed for it. This section provides a brief description of how the story will be tested. As for the feature itself, the description of testing methods is short, with the details to be worked out during implementation, but we need at least a summary to guide the estimation process.

There are two reasons for including the information about how to test the Story. The obvious reason is to guide development of test cases (acceptance tests) for the Story. The less-obvious, but important, reason, is that the Team will need this information in order to estimate how much work is required to implement the story (since test design and execution is part of the total work).

Story:

Not all requirements for new development represent user-facing features, but do represent significant work that must be done. These requirements often, but not always, represent work that must be done to support user-facing features. We call these non-functional requirements “Technical Stories.” Technical Stories have the same elements as User Stories, but need not be cast into narrative form if there is no benefit in doing so. Technical Stories are usually written by Team members, and are added to the Product Backlog. The Product Owner must be familiar with these Stories, and understand the dependencies between these and User Stories in order to rank (sequence) all Stories for implementation.

Defect:

A Defect, or bug report, is a description of a failure of the product to behave in the expected fashion. Defects are stored in a bug-tracking system, which may or may not be physically the same system used to store the Product Backlog. If not, then someone (usually the Product Owner) must enter each Defect into the Product Backlog, for sequencing and scheduling.

WHAT ARE THE SCRUM ROLES?

The three roles defined in Scrum are the ScrumMaster, the Product Owner, and the Team (which consists of Team members). The people who fulfill these roles work together closely, on a daily basis, to ensure the smooth flow of information and the quick resolution of issues.

ScrumMaster:The ScrumMaster (sometimes written “Scrum Master,” although the official term has no space after “Scrum”) is the keeper of the process. The ScrumMaster is responsible for making the process run smoothly, for removing obstacles that impact productivity, and for organizing and facilitating the critical meetings. The ScrumMasters responsibilities include

• Teach the Product Owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum.
• Improve the lives of the development Team by facilitating creativity and empowerment.
• Improve the productivity of the development Team in any way possible.
• Improve the engineering practices and tools so that each increment of functionality is potentially shippable.
• Keep information about the Team’s progress up to date and visible to all parties.

In practical terms, the ScrumMaster needs to understand Scrum well enough to train and mentor the other roles, and educate and assist other stakeholders who are involved in the process. The ScrumMaster should maintain a constant awareness of the status of the project (its progress to date) relative to the expected progress, investigate and facilitate resolution of any roadblocks that hold back progress, and generally be flexible enough to identify and deal with any issues that arise, in any way that is required. The ScrumMaster must protect the Team from disturbance from other people by acting as the interface between the two. The ScrumMaster does not assign tasks to Team members, as task assignment is a Team responsibility. The ScrumMaster’s general approach towards the Team is to encourage and facilitate their decision-making and problem-solving capabilities, so that they can work with increasing efficiency and decreasing need for supervision. The goal is to have a team that is not only empowered to make important decisions, but does so well and routinely.

Product Owner:

The Product Owner is the keeper of the requirements. The Product Owner provides the “single source of truth” for the Team regarding requirements and their planned order of implementation. In practice, the Product Owner is the interface between the business, the customers, and their product related needs on one side, and the Team on the other. The Product Owner buffers the Team from feature and bug-fix requests that come from many sources, and is the single point of contact for all questions about product requirements. The Product Owner works closely with the team to define the user-facing and technical requirements, to document the requirements as needed, and to determine the order of their implementation. Product Owner maintains the Product Backlog (which is the repository for all of this information), keeping it up to date and at the level of detail and quality the Team requires. The Product Owner also sets the schedule for releasing completed work to customers, and makes the final call as to whether implementations have the features and quality required for release.

Team:

The Team is a self-organizing and cross-functional group of people who do the hands-on work of developing and testing the product. Since the Team is responsible for producing the product, it must also have the authority to make decisions about how to perform the work. The Team is therefore self-organizing: Team members decide how to break work into tasks, and how to allocate tasks to individuals, throughout the Sprint. The Team size should be kept in the range from five to nine people, if possible. (A larger number makes communication difficult, while a smaller number leads to low productivity and fragility.) Note: A very similar term, “Scrum Team,” refers to the Team plus the ScrumMaster and Product Owner.

Advantages of Agile Methodology

Given below are the various advantages of Agile Methodology:

• The customers continuously get a look and feel of the project progress at the end of each iteration/sprint.
• Each sprint provides the customer with a working software which meets their expectations as per the definition of done provided by them.
• The development teams are quite responsive to the changing requirements and can accommodate changes even in the advanced stages of development.
• There is constant two-way communication which keeps the customers involved, thus all stakeholders – business and technical – have clear visibility on the project’s progress.
• The design of the product is efficient and fulfills the business requirements.

Disadvantages of Agile Methodology

Though there are several advantages of Agile methodology, there are certain disadvantages involved in it too.

They are:

1) Comprehensive documentation is not preferred which can lead to agile teams incorrectly interpreting this as agile doesn’t require documentation. So the rigor gets lost on documentation. This should be avoided by continuously asking yourself if this is sufficient information to proceed or not.

2) Sometimes, at the beginning of the projects, the requirements are not crystal clear. The teams might proceed and find that the customers’ vision got realigned and in such situations, the teams need to incorporate many changes and it is difficult to gauge the end result as well.

Agile Challenges

The existing waterfall techniques at that time were too cumbersome and had no provision for feedback until the final product was ready to be delivered. It was called a waterfall model of development because the teams first finished one step completely and only after that they moved ahead to the next step.

This meant that there was no scope for course correction and the customer had no view on the progress until the whole product was ready. And that was what these experts wanted to avoid. They wanted a solution which would have scope for constant feedback in order to avoid the cost of rework at a later stage.

And that is why agile is also about being adaptive and continuous improvement, as much as it is about constant feedback and speed of delivery.

Conclusion:

 If you want to be agile, the first tenet is “Every project needs a slightly different set of policies and conventions, or methodology.” People’s attitude toward communication, user involvement, and frequent releases is more important than the specific process you use.