Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts

Tuesday, July 26, 2016

Intro to SCRUM under 5 minutes

7:14:00 PM
Hello everybody, by the end of this video, you will understand what is Scrum and the Scrum Framework



Scrum is one of the development methodologies which provides a framework for Agile mode of development. Scrum defines the roles, responsibilities and the process to follow

Scrum Roles

In Scrum, there are just three roles. the Product Owner, a Scrum Master and The Team

The Product Owners responsibility is to identify requirements, prioritise them such that the highest priority ones are at the top of list and the least priority ones are at the bottom of the list. PO is the sole person responsible for the ROI

The Teams responsibility is to develop the features that they committed to and meet the quality requirements. Teams are usually 5 to 9 members and they are cross functional i.e. the team comprises of programmer, validator, UI expert or whoever is necessary for successful completion of the Sprints. The team is also self organising with a high degree of autonomy

The Scrum Masters responsibility is to ensure the process of scrum is followed religiously. He/she protects the team from outside interference, helps removing impediments and guides the Team and PO on the Scrum Process

Scrum Framework

Now that we understand the roles, let us look at the Scrum Framework

To start with, the Product Owner starts creating the Product Backlog. Product Backlog is an ordered list of items that needs to be developed to complete the product. These could be product features or technical requirements. The Product Backlog Items at the top of the list are more granular, while the bottom ones would be coarser. The coarser ones will be eventually made granular, when the team finishes off with the higher priority ones. The  PO is the owner of the Product Backlog Items

The Sprint, which is a time-boxed iteration, starts with the Sprint Planning Meeting of 2 to 4 hours. This is where the PO and the team comes to an agreement on what they would develop in this Sprint. The meeting is split into two parts. In Part 1, the PO explains the requirements that he would like the team to work on and also answer the teams queries. In Part 2, the team does a bottom up estimation and decides how many of the PBIs, they think can be implemented. At the end of the Sprint planning meeting, the team is ready with their Sprint Backlog which is the set of activities to develop & validate the selected PBIs

The Sprints are usually 2 to 4 weeks and ends on the specified duration, no matter how many PBIs are pending implementation. The idea is to ensure a potentially shippable product is released frequently

During the Sprint, the team does a daily scrum meeting where everyone in the team meets everyday at the same location at the same time. In this meeting, each of the team members appraise the rest of them on “What they did yesterday”, “What they did today” and whether they are facing any issues. The intention is to appraise everyone on whats happening and bring in accountability. Typically the stand-up meeting should not exceed 15 minutes

At the end of each day, the team enters the remaining hours required for them to complete their remaining tasks. This is plotted along the timeline and this chart is called the Sprint burndown chart. It provides a visual view on how much work is pending and is useful for the team as well as the external stakeholders in assessing the risk

During the Sprint, the team members also spend around 5 to 10% of their current Sprint time in refining the PBIs for the upcoming Sprints. This helps the team in familiarising with the next set of requirements as well as giving inputs to the PO

Towards the end of the Sprint, the team does a Sprint Review, where they demonstrate the developed features to the PO and stakeholders. This helps the PO and stakeholders to see the working product and give feedback. Basically this is the inspect & adapt time for the product. The feedback is added as items in the Product Backlog and prioritised

Further to the Sprint Review, the team does a Sprint Retrospective among the team members. In the Sprint Retrospective the team looks back at the process and ask themselves on what practices need to be continued, started and stopped. This is the inspect & adapt time for the process. The actions from this meeting is incorporated in their next Sprint

Intro to Agile under 5 minutes

7:07:00 PM
Hello Everybody! In this video, I’ll give you basic understanding of what is Agile and why Agile in software development



Waterfall

One wouldn’t be able to appreciate Agile methodologies unless we go back a decade or so when most of the software world used to follow the Waterfall model of development. In waterfall model, projects  are split into distinct phases with no overlap whatsoever. The phases were requirements, design, coding, unit testing, integration testing and system testing. So one phase had to get over i.e. frozen, to start another and typically the project duration used to take many months to years. The biggest problem in this approach was by the time the project was delivered to the Customer, either the requirements would have changed or the requirements may have been wrongly interpreted by the development team. Because of the rigid boundaries waterfall it had the following shortcomings

a. Any change was expensive, as it meant it has to start from requirements and corrected along the other phases
b. Communication silos, as each person restricted themselves to that phase
c. The responsibility was fragmented. No one took E2E responsibility, everyone focussed on only their phase
d. Low levels of motivation, as exposure and learning was limited

The data from the Standish group shows that only 14% of the projects using waterfall was considered successful i.e. within budget and on-time delivery, compared to this Agile methodology had a whopping 49% success rate

Over the course of the last two decades, the software industry has moved from various variations of waterfall based developments and nowadays most organisations have adopted to one or the other forms of agile development

Agile

So, Agile is a time-boxed iterative approach that builds & delivers software incrementally instead of trying to deliver it all at once at the end of the project

It works by breaking projects down into little bits of user functionality, prioritising them and continuously delivering them in shorter cycles

Agile Principles


In Feb 2001, about 17 s/w developers met to discuss on arriving at a light-weight s/w development methodology. Although they couldn’t agree on many things, they all agreed on the following 12 principles

1. The highest priority is to satisfy customer through early and continuous delivery
2. Welcome changing requirements even if it is late in the development
3. Deliver working software frequently, from a from a few weeks to months, with preference to shorter timescale
4. Business people and developers should work together
5. Build projects among motivated individuals. Give them the support and environment and trust them to do their job
6. The most efficient way to convey information to and within development team is face to face communication
7. Working software is the primary measure of progress
8. Promote sustainable development. Team should be able to maintain a constant pace than burn out after a release
9. Continuous attention to technical excellence and good design enhances agility
10. Simplicity - the art of maximising the amount of work not done, is essential
11. The best products emerge from self organising teams
12. At regular intervals, teams should reflect on how to become more effective

These principles are core to any of the Agile methodologies

Agile Manifesto

Based on these 12 principles, the Agile Manifesto was made, according to which, one has come to value

Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over following a Plan

While there is value in the items on the right, the items on the left are valued more

Agile Methodologies

There are various Agile Methodologies starting from Scrum, eXtreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), etc. We will dwell into some of these in future videos
Powered by Blogger.

Featured Post

Know all about GST in India under 8 minutes

In this video blog, you will understand all about What is Goods & Services Tax (GST) in India How are the indirect taxes affecti...

Recent

recentposts

Random

randomposts