Learning Agile Methodology | Support Advacarepharma

General Concept

Agile is an iterative approach to project management that helps teams deliver value to their customers faster and with fewer issues (compared to other methodologies like waterfall (sequential)). Instead of working and releasing everything on a big launch, an agile team delivers work in small, but consumable, functional products. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly.

Although the project manager or a product manager typically prioritizes the work to be delivered, the team takes the lead on deciding how the work will get done, self-organizing around granular tasks and assignments.

Purpose of Agile

Teams choose agile to mainly respond to changes in projects from customers quickly without derailing a year's worth of plans. "Just enough" planning and shipping in small, frequent increments lets the team gather feedback on each change and integrate it into future plans at minimal cost.

Agile Frameworks

Agile frameworks (specially for software development, like Scrum, Kanban, or Extreme Programming (XP, however not covered in this document)) form the basis for popular software development processes like DevOps and continuous integration/continuous deployment (CI/CD).

Scrum is perhaps the most popular agile framework in use today but not all agile is Scrum. Scrum is a framework for managing work designed for small, cross-functional teams of 5 to 9 people who break their work into actions that can be completed within a consistent period of time called a sprint.

Kanban

Kanban is a methodology that improves output by reducing flow through a system. Typically, the output increases when fewer items are worked on simultaneously, although the right amount of work in progress (WIP) will vary for each team and system. Kanban helps to find the right workflow and WIP limits by giving you data to influence your system design.

Main Elements of Kanban

There are six key elements in Kanban:

● Limit work in progress: Rather than working on 20 features at the same time, it is better to focus on starting, finishing, and releasing a smaller number (say five). With fewer items, spend less time producing them. Tasks can be finished quicker than when focusing on a large number of items simultaneously. The time from beginning a feature, or a task, to its completion, is reduced and customers see value sooner.

● Manage flow: Flow is the concept of moving items quickly through the system. Teams manage their flow by tracking how long an item spends in each possible status (how long it is waiting to be tested, how long before someone starts work on it, etc.). Reducing these times becomes a team goal.

● Feedback loops: Taking time to reflect on what is working and considering improvements is vital in Kanban.

● Improve/evolve: Continuous improvement is a core concept in Kanban. A culture of running experiments and trying to improve and evolve is essential.

● Visualize: The team is empowered to make effective decisions when the work is visible using a board that shows the status, bottlenecks, and system limits.

● Explicit policies: can't improve something that don't understand. Any policy that relates to status updates enables the team to effectively decide if a given task is suitable to be worked on and when the status has changed.

Using Kanban

The most important factor in Kanban's effectiveness is that all work items and their statuses are shown on a board.

Checking the status of an item by seeing which column it's in. Teams decide which columns make sense for their workflow. Therefore, a Kanban board can vary from team to team.

When the status of an item changes, a team member will move it into another column.

Note: that limits are shown in red circles above certain columns. For example, a 3 above the To- Do column indicates that only three items can be in that particular section at one time. The In Progress column is limited to two items.

For example, if it’s decided to work on an item called "New login button," then it would move its card from the "To-Do" column to the "In Progress" column.

In resume, the Kanban board is important to visualize work status and understand what work to prioritize next.

Scrum

What is Scrum?

Scrum teams consist of team members, a Scrum master, and a product owner. Typically, Scrum is implemented when a large project can be broken up into 2- to 4-week sprints. Scrum focuses on feedback loops through a ceremony called the "retrospective." The unofficial motto of Scrum could be "inspect and adapt."

Other agile frameworks, notably kanban, predate the agile manifesto. But these frameworks are considered to be agile because they promote the values outlined in the agile manifesto. There are too many agile frameworks and approaches to scaling agile to list all of them here.

Scrum Team

Scrum Master

The Scrum Master is kind of the meeting planner in this whole shindig. It’s their job to ensure that all the meeting rooms are booked on the appropriate time, all the supplies needed for the meeting are available, all the team members are present and prepped up for the meeting, and all of the devices that will be used in the meeting e.g. video conferencing devices and other connectivity modules, are ready to go when they are needed.

It is also the job of Scrum Master to manage the time properly so that there is a complete alignment on the sprint goal before the meeting is finally concluded. In general within the Agile framework, a Project Manager can become a good candidate for Scrum Master.

Product Owner

The Product owner’s responsibility is a little more specific. They have to prepare all of the files and other items that are in the backlog before the meeting commences. They have to clarify the details of each and every item present in that backlog.

They also have to be the ultimate resource to the team when questions are raised around acceptance criteria or any use case. This is a very important meeting for a PO, and they should prepare heavily for it. Similarly in the Agile framework, a Product Manager can become a good candidate for Product Owner.

Development Team

Naturally, the people that make it all happen are also going to be present in the meeting. These include developers, test engineers, designers, etc, roughly all of the people that are a part of the workforce working on the product.

All of these people have to be properly active in the meeting and they are required to ask a lot of questions so that they can leave the meeting with a crystal clear understanding of what they have to do and what is going to be their next assignment in the upcoming sprint.

When organizing a first-ever sprint meeting, just keep one thing in mind that every entity in the Agile paradigm improves over time and if the first meeting doesn’t go well then can always improve itself into performing well the next time.

Scrum Events

There is a set of prescribed events in Scrum, each serving a specific purpose. These events are designed to reduce the need for other events (Scrum does not specify that). They are all timeboxed, which means that they have a maximum length.

There are five main Scrum events:

● Sprint

● Sprint Planning

● Daily Scrum

● Sprint Review

● Sprint Retrospective

Sprint

A Sprint is the heartbeat of Scrum. It is the cadence of the team and should be respected by everyone involved with the Scrum Team.

A Sprint is usually 2 or 3 weeks (although 1-week or one calendar month Sprints are acceptable). The team will attempt to begin, finish, and release work during this time. The team should maintain the Sprint length unless it decides to experiment with a different one. Sprints should not be terminated early or extended to fit a team's needs. The constraining nature of the Sprint timebox is one of its biggest benefits.

Some characteristics of Sprints:

1. Each Sprint lasts for the same fixed duration (e.g., 2 weeks).

2. The next Sprint begins immediately after the previous one.

3. The team attempts to begin, work on, complete, and release shippable features.

4. The Scrum Team creates a Sprint Goal as the single objective for the Sprint. They then create a Sprint Backlog, which they will use to achieve the Sprint Goal.

Sprint Planning

Creating a Sprint Goal and selecting which items to work on during the Sprint is done during the Sprint Planning meeting. Sprint Planning is timeboxed to a maximum of eight hours for one calendar month Sprints.

Sprint Planning focuses on answering the following questions:

● What can we deliver in the upcoming Sprint?

● How will we achieve the necessary work to deliver these items?

The Product Owner begins the planning session by discussing the Spring objective (the Sprint Goal) and which items, if delivered, would meet the goal.

The Development Team discusses how it will deliver these backlog items. It typically does this by breaking the items into smaller tasks and estimating them. By crafting a plan for delivering these items, the team will then determine if it can confidently deliver the goal.

The Product Owner will discuss these items with the team during planning, answer questions, and often make trade-offs. For example, perhaps a feature cannot fit into the Sprint, but part of the feature could be done. The Product Owner would decide whether that is a good approach. At the end of the meeting, the team agrees and commits to achieving the Sprint Goal through delivering a Sprint Backlog plan.

Daily Scrum

The Daily Scrum is a meeting of no more than 15 minutes where the team inspects their progress towards the Sprint Goal and decides if they need to make any adjustments to their plan (i.e., the Sprint Backlog). The secondary purpose of this meeting is to listen for opportunities to help teammates while requesting help if needed.

Note: this meeting may be called “daily stand-up” as well.

It is more common to have this meeting in the morning, although some teams working across multiple time zones may schedule it for later in the day. The best time is when the team finds it useful and effective.

It is important that the meeting takes no more than 15 minutes. If it goes longer, the team should consider why they cannot keep this meeting within the timebox. One possible reason is that members are facing a barrier. The team should discuss this and how best to overcome it. If they cannot remove the impediment on their own, the Scrum Master may need to assist.

Sprint Review

At the end of a Sprint, the Scrum Team will hold a Sprint Review to show key stakeholders the completed items. Many organizations choose to have an open invitation for Sprint Reviews.

Anyone who is interested can watch the team demonstrate what they have built and discuss how the Product Backlog adapts with the Product Owner. Generally speaking, the Product Owner will know who to invite to the Sprint Review, especially initially.

Holding Sprint Review at the end of the Sprint has many advantages:

● It gives the team confidence to show their work and receive feedback from the stakeholders.

● Stakeholders will see features before they are released. This allows them to give input if they see something seriously wrong or misunderstood before it affects customers.

● Feedback can come from many sources if the many different groups in the organization are invited. For example, someone on the support team, marketing team, or similar, can deliver valuable insight to help the Scrum Team.

● When the Scrum Team knows they have an upcoming Sprint Review, it encourages members to keep value in mind while working.

Sprint Retrospective

Scrum Teams will hold a Sprint Retrospective meeting at the end of each Sprint so that all members can give input on what is working well and what is not.

The team can discuss any topic in the spirit of continuous improvement at the Sprint Retrospective. This could be how the team communicates, collaborates, solves problems, engages customers, or anything else!