Aglie: - Multi iterative Lifecycle

Scale friendly Vs Innovation friendly:

Scale: plan, procedure, spend so much money, build a big complicated product
Innovation: Observe buyers, are there things what are their problem? -> Give a
model/prototype to the customer, is it is solving the problem -> build products in
small chunks.
What makes Agile hard?

User driven -> But many users dont know what they want Micromanagement
You drive based on you knowledge -> you do your thing, I will do my thing,
we will patch at end. -> wrong, we need collaboration.

Narrative Collaboration:
o Keep the user in mind , whats value to the user, what will create a
valuable outcome and narrate the goals to the team keeping user in
mind
Do in small batches
o Will help to correct mistakes
o People in team should be allowed to come up with blue button
questions/alternatives and that should be taken based to
infrastructure team, analyzed and if need changes should be
brought it. It will help in creating not just an output for the client but
a valuable outcome for the client.

Blue button Moment: (Example)

Manager should narrate the issue with real-time examples.

Team member should be allowed to ask questions understand the
problem, should not be micromanaged, dont give overly prescribed
solution
Go with few fixes and put in production
Do observation of the fixes

Manifesto of Agile:

No requirement analysis document -> narrative collaboration

Give room to the team to think how the outcome can be achieved. Dont
over specify the requirements.
LEARNING THE right thinking at the right time.

Venture design framework:

Personas - humanized view of who our customers are

We built software

Only 20% of it is used

Agile : autonomy, ownership and creativity for team, management ->
higher quality of code and product

Agile: Mitigate risk by building a product, by regularly interacting with the client
and building what they want

Build products in iterative fashion, incremental building of product.

Sprint: short development cycle
CA agile vision to document and manage requirements in product
backlog
o Product backlog
Outlines project backlog and priorities
Managing project groomed
o User sotires
o Scrum master
Facilittes the meeting
Removes obstacles
SDaily standup meeting
o What did u do yesterday
o What will u do today
o What obstacles are impending your progress
Daily updation of sprint burndown graph

Product backlog:

Based on vision , whatever has to go into the product, those are entered
into product backlog

Sprint backlog:

A small manageable chuck from the product backlog is taken and put into
sprint backlog

Product owner

Get the requirements , list of features prioritized by the business

stakeholders and come up with the product backlog

Scrum Master

Pulls the sprint backlog from the product backlog

Team

Build the product from sprint

IN a scrum team there will be no manager

The team comprises of all the cross functional resources , they take care of
the entire team
Team will be small ( around 7 people )
Team is self-organized and self-managed, they commit how much they can
product, they commit what they have done yesterday and what will they
do today
Sprint

Daily scrum/daily meeting: update on project, any road blocks, a short meeting
for 15 mins
Scrum master: notes down all the blocks. Resolve the issues. So that the team
can work fast.
Product owner also participates in the meeting.
Senior master:

are allowed to be in the meeting but are not allowed to talk

New role, not project manager
Not allocate the jobs,
He is a servant leader, and protect the team from external disturbance,
and product owner, from adding new requirement in between sprint.
Teaches the team of the agile, sprint, principles and processes of agile.

Burndown chart: to successfully self manage, gives the status of where and how
are we progressing for the goal.

Product review:

Meeting with the client of the actual working software based on the
functionalities in the sprint log.
Product review
Users gives feedback and product owner incorporates those in the product
catalog

Retrospective meeting:

Only for team members

Process review re- evaluate and review what went right and what went
wrong

Reference:

Lecture by Rajamanickam:
https://www.youtube.com/watch?v=gLd4NZLVrFw

1. Scrum
a. Each iteration -> sprint
b. More visibility to the customers
c. Business requirements are written as User stories
d. Contents of User Stories
i. Role that is going to be executed by the user stories
ii. Features addressed by user stories
iii. Benefits derived from user stories
e. User Stories are kept in backlog
i. Types
1. Product backlog
a. All user stories not just sprint user stories
2. Release/sprint backlog
a. Collection of many sprints
i. A release can contain two or more sprints
ii. A sprint may be very tiny, so we can work
and release multiple sprints together.
b. User stories should be prioritised and assigned
to sprint

c. Customer clearly knows which user story will

come under which sprint.
ii. Prioritisation
1. Level of importance to each user stories
2. Based on relevance and importance of each user
stories
3. If there is a risk of complexity, take the complex one
first
4. Check the bandwidth for each sprint, add the user
stories to the spring until there is no room to add more.
5. Prioritisation techniques
a. MOSCW Rule
i. Must, out to have, should have, could
have, would have
b. Ranking