Agile

Introduction

Agile software development methodology is an process for developing software (like other software development methodologies – Waterfall model, V-Model, Iterative model etc.) 

Agile means ‘ability to move quickly and easily’ and responding swiftly to change

Traditional Methodology

Let’s assume a case that we are developing an huge application, that target the release after 10 months. This 10 months will be utilized as below,

• 1 month for Requirement Phase
• 1 month for design 
• 3 months for coding
• 2 months for validation/testing
• 1 month for internal bug fixes
• 1 month for system/integration test
• 1 month for UAT

After 10th month, when the software is set to release their might be a possibility to face issue. If the issue itself a wrong understanding of requirement, then it will cost much

Agile Methodology

In Agile methodology, the 10 month span will be split into 10 iterations. Each iteration will be lasted from minimal of 2 weeks to maximum of 2 months. Assume the task have been split into 10 iteration. Each iteration will hold all the states as explained starting from requirement gathering till UAT compliance.

When first iteration is over, the minimum viable product will  be delivered. Then if any issue have been identified by customer, then same will be carried out for fixing in upcoming iteration. So at the end of 10 months, most of the bugs will be fixed.

How Agile differs from traditional models?

In traditional approach each job function does its job and hands over to the next job function. The previous job functions have to signoff before it is handed over the next job function authenticating that the job is full and complete in all aspects.

For example, Requirement gathering is completed and handed over to design phase and it is subsequently handed over to development and later to testing and rework. Each job function is a phase by itself.

In Agile way of working, each feature is completed in terms of design, development, code, testing and rework, before the feature is called done. There are no separate phases and all the work is done in single phase only.

Modern Agile Tools

Lets see about some modern Agile tools, i) Scrum ii) Kanban

Scrum Methodology

1. Scrum Teams work in a series of sprints
2. Scrum Master needs to manage the team developer and product owner
3. Each sprint shall start with sprint meeting, which should include in planning of important tasks lead by Scrum Master
4. The Development team should work on identified Sprint Backlog
5. Handle daily scrum meeting
6. Review the points completed at end of sprint
7. Take incomplete points to next sprint
8. Release as minimum viable product at end of each sprint

Kanban Methodology

• Kanban is continuous process
• Here Agile Coach will manage the product owner and developer
• Here no sprint log maintained and items are pulled directly from Product Backlog
• Items will be moved to next flow only when its completed and better in short duration
• Follow daily stand-up meeting at the short of 15 mins

Roles in Agile

Product Owner

• Responsible to write or create user stories (task) in backlog
• Here tasks (user stories) are collective and Product owner will not split user stories as release. He will maintain all information’s in backlog
• Assign user stories to a product (Product backlog query)
• Prioritize the product backlog (Sort by Relative Priority)

Scrum Master

• Scrum master ensures “sprint” is available
• Focus to ensure team holds the tasks always
• Responsible to create Release related to Product
• Responsible to create Sprint
• Responsible to create Team (group), the sprint could be assigned to Team
• Assign User stories from Product Backlog to Release Backlog along with Product Owner (Product Backlog and All Releases queries)
• Assign user stories from Release Backlog to Sprint (All Release)
• Monitor any blockage in implementing (All Impediments)
• Use Burn-down chars to Track Progress (need to look at daily scrum)
• Manage backlogs based on “ideal burndown” (Agile Dashboard)

Team

• Team is member who does actual design, implementation and testing and responsible for delivering the product
• Team members will create Task based on Sprint Backlog (User Stories) ie., creating creating Task from CR or PR
• Team member should also be responsible in updating the task assigned to them, like adding the effort hours and updating the status
• Team member is responsible for creating Impediment in case of any blockage encounter in progress. This will be reviewed in next Scrum Meeting

Development Team Size

• Optimal Development Team size helps to handle the work efficiently and helps to achieve the sprint. The optimal team size should be 7 and it shall vary with + or – 2. So in simple it ranges between 5 to 9 members.
• When team size is too small, this will decrease the interaction, less skills to handle all phases and results in delay in delivering incremental release
• When team size is more, then too much coordination is needed. Managing the team will become too complex
• The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog

Domains

Product

A Product is a long-lived application or collection of source code whose capabilities are built, maintained and expanded by a series of Releases

Product Backlog

Product backlog is the collection of all User Stories planned for Product. The Scrum Product Owner is the only person allowed to own the contents of the Scrum Product Backlog.

Release

A Release is the deliverable and collection of activities that make up an Agile software project.  Typically, a Release will span multiple iterations (Sprints), and clearly defines the target commitment for the project.

Once the Release is created, the User Stories are populated from the Product Backlogs. In general, the User Stories that are not mapped into any of Release in product backlog should be added This will be completely managed by Product Owner

Release Backlog

It is the collection of all User Stories planned for this Release. Though users stories are directly created from Product, its always recommended to create release and add User Stories to it

Epic

• An Epic is used to manage long run User Stories
• Here the scope of outcome is very high and they are divided into more number of sub stories
• The story size of Epic is decided by calculative value of story size of sub stories
• Its not advised to relate Task under Epic and in this case, it needs to be related with user stories

User Story

• List of the requirements that are needed for product. Could say customer requirements to be implemented for product
• User Story could be a Problem Report or Change Request
• User Story shall be created by Product Owner
• User stories holds the Task and also they shall be created from impediments
• The initial state of user story is “draft”, during this state priority and rough estimation are planned
• Once planed they are set to be in defined state, and then will stay in Product or Release backlog until added to sprints. Once added to sprint, then they are termed to be In progress state
• User Story is set to Complete only when Product Owner found the implementation met their need, if not it will be at In Progress state or simply will be Cancelled

Task

• The Task shall be created in order to complete the User Story
• Tasks are created by Team Members, and used to update the status or report any impediments to the team
• When Task is in Draft state, its not fully defined and estimated
• When its agreed upon with defined effort, it will be at defined state
• When work initiated they will be at In Progress or other state Product Owner will not evaluate functionality of the software at Task level, they will be looking at User Story level

Sprint

• Sprint is created by Scrum Master
• Normally will be in duration of 2 to 6 weeks. The sprint holds the collection of User Stories from Release Backlog to be implemented by Sprint Team in each sprint (priority base).
• Release might be split into “N” sprint and User Stories are distributed in each sprint
• At the end of each sprint, all user stories need to be completed. If not it has to be reviewed and taken to future Sprint or to Release Backlog again
• Ideally each sprint will produce build-able (and potentially ship-able) version of product
• Team members working on a Sprint meet daily (for no more than 15 minutes) to discuss what was accomplished in the previous day, what the goals are for the current day, and any Impediments which may be blocking their progress
• Initially, Sprints are in a state of Scheduled.  This indicates there is a plan and date (time-boxed) to perform the work.  If that plan changes and it is believed the Sprint is no longer required, it can be transitioned to Cancelled.  Once the Sprint starts and its User Stories are being actively worked upon, the state is set to In Progress.  From this state there are two self-explanatory outcomes – Complete and Cancelled
• Sprints can be created independently, but it is recommended to create the related Sprint from a Release

Impediment

• Anything that prevents a team member from performing work as efficiently as possible is called as Impediment
• The Impediment are discussed at Daily Meeting and its Scrum Master responsibility to clear all those Impediment
• Impediment shall be closed by Scrum Master, when it has been resolved

Scrum Events

Grooming or Backlog Refinement Meeting

This meeting is mainly focus on prioritization for Product Backlogs and mainly to prepare for Sprint Planning Meeting

Sprint Planning Meeting

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it
within the time-box

Sprint Planning answers the following:

• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?
• Sprint Goal is set, which acts as Objective in implementing the product backlog

Daily Scrum Meeting

Daily Stand Up meeting supports in tracking whether work moves as per plan. Here three major factors like, what team did yesterday, what going to do today and was there any impediment

Rules

• It helps to keep the meeting focused, efficient and effective because the alternative is standing for more than 15 minutes.
• The additional blood flow to the body also helps with a more energetic standup
• Use the 3 question paradigm for more efficiency (Yesterday-Today-Obstacles)
• Only 1 person speaks at a time
• Focus on Items / Issues […] via walking the board. (Story-focused stand-up)
• Always focus on high priority items first in the same column –

Conditions

• Keep it short and focused. Don’t take more than 15 minutes
• You are allowed to question everyone about everything as long as answers are short
• Treat blocking items or obstacles with a little more depth (regarding ways of resolution)

Take it Offline

• You are allowed to question everyone about everything as long as answers are short. Else take the discussion outside the scrum
• Problem-solving should take place afterwards but not during the meeting
• Raise your hand if you think the topic should be moved to an offline meeting
• The Scrum Master needs to know when to halt a team member turning their discussion into an in depth update
• Use a “Parking Lot” on a whiteboard to jot down discussions that require members to stay behind after the daily scrum to discuss further

Team Norms

• Give team members who are not needed for further discussion the ability to decide to leave if they prefer as that gives them a sense of value to their time
• Everyone leaves together
• Team members need to respect each other’s conversation, they shouldn’t start playing with their phone or leave the daily scrum once they have given their update

Sprint Review Meeting

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.

This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendees understand its purpose. The Scrum Master teaches everyone involved to keep it within the timebox

The Sprint Review includes the following elements,

• Attendees include the Scrum Team and key stakeholders invited by the Product Owner
• The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”
• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved
• The Development Team demonstrates the work that it has “Done” and answers questions about the Not Done
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose.

The purpose of the Sprint Retrospective is to,

• Inspect how the last Sprint went with regards to people, relationships, process, and tools;
• Identify and order the major items that went well and potential improvements; and,
• Create a plan for implementing improvements to the way the Scrum Team does its work.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. This mainly focus on inspection and adaptation.

Agile in one Flow

Below picture represents the whole agile process in one flow,

Views: 32