Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

What Is Agile and Scrum

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 6

What is Agile and Scrum?

Technical Business Analyst/PM - BI/Analytics/CRM,


Agile Scrum Master
Introduction: Business in current environment is very demanding. Complexity
have increased manifold and therefore novel and innovative ways are being
devised in IT industry to cater to the ever increasing demand. The processes
that were carried out earlier are sometimes no longer feasible in current
situation and with increasing competition the privilege of having margin of error
has narrowed down.

Corporate sector can no longer afford to have failure in IT projects as they are
increasingly getting dependent on automation and digitisation. As business is
trying to keep itself ahead of its competitors, the demand for faster and more
accurate implementation has become the need of the hour. Thus Waterfall
model, spiral model etc which were widely used previously is getting replaced
with Agile manifesto.

Why Agile? Before we try to understand Agile we need to know why Agile
came into existence. A lot of project failures in the past have been partly due
to lack of clear cut clarity in business requirement and partly due to frequent
change requests among other reasons. Waterfall model is successful when
these anomalies are not present. Some may argue that Spiral model or
prototyping can fit in such circumstances. Well yes to a certain extent they do,
but then Spiral model may not lay down well defined process, definite short
duration, small manageable team and above all continuous engagement of all
stakeholders. Here is where Agile fills the gap.

What is Agile? The word Agile means ability to move quickly and easily and
as the word means so does the process.

How is Agile different than previous models? The factors that make Agile
different than previous models is the focus of Agile. Agile focuses on or we can
say it values:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The above statements make it imperative as to fact that agile is more focused
on quality delivery than following legacy protocols. However it does not mean
that things on the right side are not given due value, its just that the things of
the left side are valued more.

What is Scrum? Scrum is a framework which is associated with Agile


manifesto to deal with complex works such as new product development.
When the process is too complicated for the defined approach the empirical
approach is the appropriate choice. Scrum introduces feedback loop for
continuous improvement of process and quality.

In waterfall model process is divided into SDLC activities which are


Requirement Analysis, Design, Code, Integration, Test and Deployment. In
Scrum instead of activity driven phases we divide the product development
into fixed length iterations called Sprints each of them having some
combination of SDLC activities. The Duration of each sprint varies from 2 to 4
weeks.

Scrum team size is generally between 4 to 9 resources and based on their


roles they can be classified into following:

1. Product Manager He is responsible for Return On Investment (ROI) of


product development activity. He is final arbiter of requirements questions. He
should have the vision of the product. He is focussed more on what than how
and makes business and prioritisation decision.
2. Scrum Development Team Its a cross functional group responsible
for self organising to built a potentially shippable product increment every
Sprint. They collaborate and work as a team rather than as individuals in a
group.

3. Scrum Master He facilitates the scrum team with processes, provides


visibility and protects team from distractions and interruptions, removes
impediments which affects the team, teaches people how to use scrum,
promotes improved engineering practices and enforces time boxes. It has to
be noted that scrum master has no management authority over the team, and
does not play the project manager role. The project management activity is
being done by product owner and the team with scrum master just acting the
facilitator.

Artifacts of Scrum.

The two important artifacts of Scrum are:

1. Product Backlog It contains the list of everything we might ever do.


These broken up lists of complete requirements are known as Product Backlog
items. Each of these items has stated priorities, prioritised by Product owner.
Anybody can add to the Product Backlog list but Product Owner has to
priorities it and scrum master has to make it visible. A well formed Product
Backlog does not contain tasks but only well formed Product Backlog items.
These items can be written as User Stories or as Use case scenarios. Force
Ranked means there is only one thing in the top position of the list.

2. Sprint Backlog It contains what we have agreed to do during the


current Sprint. It has committed Product Backlog items(WHAT),an end
date(WHEN) and sprint tasks representing HOW .The status of each tasks are
evaluated in Sprints which are Not started, In progress, and Completed.

Scrum Elements - Meetings:

1. Sprint Planning Meeting First day (about 4 hours). It is held to decide


which Product Backlog items will be included in the sprint and how it will be
done. It is attended by Product owner, Scrum Development team and Scrum
Master

2. Daily Scrum - 15 minutes every day It is done by Scrum Development


Team. They report to each other and state what each of them has done
yesterday, what they intend to do today and what are the blockers.

3. Sprint Review Meeting Last day (about 2 hours). The team


demonstrates the potentially shippable product increment to product owner
and anybody else who is interested, sometimes referred as stakeholders. The
product owner decides as to which items have been done and which items did
not meet the acceptance criteria. They can measure velocity and have
feedback from Stakeholder as to how they are fairing.

4. Sprint Retrospective Meeting Last day (2 hrs). Every sprint ends


with a Sprint retrospective meeting for the team to inspect and to improve their
process. They discuss as to what went well, what could be improved, what we
learnt and what puzzled us.

Apart from the above mentioned Scrum defined meeting there is another one
which is generally done as a part of Sprint Planning meeting or sometimes on
its own.It can be named as Backlog Refinement meeting In this meeting
the team and the product owner meet and decide the Backlog items that would
be included in next couple of sprints. They check if they can further trim down
large epic or user stories which are nothing but part of Product Backlog items.
They can evaluate and modify the existing backlog items priorities.

Key Principals:

1. Empirical - The Scrum process is about running projects as a series of


Sprints. This means not planning the whole thing at once, but planning to
produce the product in phases with ever richer functionality. We can see the
sprints as a series of plan do deploy adapt activities. By producing
releasable product early we learn as we develop, always improving the
process. This is called a control feedback loop and can be very powerful in
developing an empirical approach in our company. The feedback we garner at
the end of the sprint process is from the customers, stakeholders, product
team and organisation all of which helps us improve our product and process.

2. Empowering - The whole of the agile movement is based on


empowering teams to take ownership and responsibility for projects. The
organisation moves away from a project manage led process to coaching
product teams in order to be self organising and internally motivated. Scrum
places checks and balances in the system to ensure that the team can grow
into a powerful self organising group.

3. Fast - If it is not FAST it is not Scrum. Scrum relies on sprints which


produce releasable increments of a product every 2 4 weeks.

4. Three pillars -

Transparency - All items (artifacts) in a scrum process must be visible.


All problems in a scrum process must be clearly and openly recorded.
The culture of the organisation must strive to support honest reporting of
problems. The huge advantage of this is that the efficiency (velocity) of a
team is true and the progress of a team is true and therefore the
business owners can plan launches and releases sensibly.
Inspection - Inspection develops on from transparency. In Scrum we
prioritise inspecting our code and systems hand in hand with the
development of the product. We value early feedback from the client,
stakeholders and product owners to ensure the right thing is being
built. We prioritise our work load by analysing the wish list from what will
add value to the customer. The traditional role of product manager is
replaced with product owner who is an integral part of the Scrum team.
Adaptation - Scrum is an empirical framework which is seeking to gain
feedback from customers, stakeholders and the development team early
and regularly in the process. This feedback is then used to change
priorities and behaviours to enable the team to be more effective.

Impediments in Scrum practices: Some the impediments that are faced by


scrum teams in an organisation are as follows:

1. Old Habits Hierarchy based team formation have been traditionally


being followed in organisations and Scrum is disruptive to such age old
practices. It is hard to believe that scrum master is going to facilitate the team
without management powers but that is what has to be implemented in scrum
framework. So they have to do away with hierarchy as it is an impediment.

2. Distractions Many a times the management in the middle of Scrum


project starts giving priority to other projects and that posses treat to sprints
deliverables. The team members get distracted and original focus gets lost.
Scrum master has to ensure that this should not take place.

3. Lack of mixed teams It is a common notion that Scrum team do not


include resources from diversified fields and so they are not included which is
wrong. Sprints require team from all fields including hardware, DBA etc. in
order to make the whole project successful.

4. Lack of coordination Many a times the team members act as


individuals in groups rather than as team members and do not understand the
collective responsibility and leave everything on scrum master or product
owner. Also sometimes geographical constraints also lead to lack of
coordination. Scrum master has to ensure that such impediments have to be
removed.

5. Lack of team rewards In a Scrum team Scrum Master is more visible


and so many a times he gets the most credit. Other resources like those who
are doing documentation are not given proper due and this affects team
motivation. So the organisation management has to treat the whole teams
achievement as that of a single unit and should give each of them proper
credit.
6. Partial adoption Sometimes some part of activity is done through
scrum and some part by Waterfall model. This does not serve the purpose of
adoption of Scrum.

Dismiss

Jennifer Douglas
Scrum Master
Nice but not all accurate. My response back to you comes straight from
scrum.org You speak of the empirical process control, knowing transparency is
key, terminology is very important and must stay consistent amongst all
organizations using scrum. Just a few examples of article being inaccurate:
Scrum elements-meetings, are actually called events (not elements, meetings
or ceremonies) Teams can have 6 (+ or - 3 people) so a team of 3-9 There are
actually 3 artifacts in Scrum you only mentioned 2. The 3rd you missed was
"increment". Pretty important since that is what the team is working towards for
their sprint goal. Backlog refinement is not part of the Scrum framework but
needs to take place. The PO needs to conduct/facilitate those meetings and
the SM coaches team (including PO) where needed. Definitely love the info on
Agile just need to be more accurate (up to date) with Scrum. See more See
less

LikeUnlike
Sign in to like this comment
Reply
Sign in to reply to this comment

You might also like