Agile & Scrum Methodology
Responding to change is Agile; Being Proactive is Agile; Being prepared is Agile; Being Flexible is Agile; Being Assertive and Open to say No is Agile; Agile enables you to get things done.
In the new era of product delivery, the requirements evolve fast, and working products have to be delivered faster. To make this happen an empirical process (inspect and adapt) is the way.
Agile is an empirical process which enables continuous learning and adapting to a process to unwind complex problems.
Uncovering better ways of developing software by using this method will create a lot of value for the developer.
Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Principles of Agile:
- Satisfy the customer through continuous delivery
- Welcome changing requirements even late in development
- Deliver working software frequently
- Business people and developers work together daily throughout the project
- Build projects around motivated individuals
- Working software as a primary measure of progress
- The sponsors, developers, and users should be able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity; the art of maximizing the work not done.
- At regular intervals, the team reflects on how to become more efficient and adjusts its behavior accordingly
- The best architecture, requirements and designs emerge from Self-Organizing teams
- Face to face communication with and within a team
Agile Values :
Agile Methodologies and Framework :
Scrum :
Scrum is an agile framework which emphasizes on reducing the complexity to focus on building products that meet business needs. It also enables one to address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Scrum employs an iterative, incremental approach to optimize predictability and control risk
Scrum is:
• Lightweight
• Simple to understand
• Difficult to master
Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
Scrum Principles:
- Small ‘shippable’ increments of development
- High quality working software
- Ongoing integration during development
- Cross-functional teams
- Self-managed team
- Visibility
Scrum Values:
- FOCUS
- COMMITMENT
- COURAGE
- OPENNESS
- RESPECT
The Scrum Team:
- Development team
- Product owner
- Scrum Master
Development Team (6 +/- 3)
A cross-functional team committed to delivering working units with a clear business value.
The team builds the plan; Decides who will do what; As more is known, the team continues to adjust work and assignments.
The only thing that is valuable to the team is the team’s goal.
Development teams have the following characteristics:
Self-organizing : They decide how to turn Product Backlog Items into working solutions.
Cross-functional : As a whole, they’ve got all the skills necessary to create the product.
Increment.
No titles. Everyone is a developer, no one has a unique title.
No sub-teams in the development team.
Committed to achieving the Sprint Goal and delivering a high-quality increment.
Attributes of self-organizing teams are that employees reduce their dependency on management and increase ownership of the work.
Some examples are:
The team make decisions about the work, estimate the work, have a strong willingness to cooperate and team members feel they are coming together to achieve a common purpose through sprint goals.
Product Owner:
- Has authority to make decisions
- Involved in setting the release goal.
- On hand for clarifications.
- Understand customer needs.
- Possess scrum knowledge
Scrum Master:
- Safeguards the process not the project
- Facilitates scrum process
- Facilitates creativity and empowerment
- Helps in improving the productivity of the team in any way possible
- Facilitates team self-organization
- Protects the team so they can focus on meeting their commitments with high quality
- Removes the barriers between development and the product team
- Ensures full visibility of team’s progress
Scrum Event: Sprint
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable, and potentially releasable product increment is created. Sprints have consistent duration throughout a development effort.
A new Sprint starts immediately after completing the previous Sprint.
Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
During the Sprint:
• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
Sprint Ceremonies
Sprint Planning Session:
Objective:
Product backlog → Sprint Goal (Sprint Backlog)
How is the object achieved?
• Log the capacity of each team member regarding Story points.
o This must include only the efforts; the team member is planned to accomplish the Sprint goal.
o This must not include time to be spent on planned meetings, any other time which is to be spent other than the Sprint goal.
• Pick a user story from the product backlog.
• Understand the user story
o Functional queries of the user story will be clarified by BA/Product owner present in the call.
o Technical queries of the user story will be clarified by the architect present in the call.
• On complete understanding, size the user story in terms of story points.
o To size, this plays a plan it poker game in which each team member gets a chance to size the story and explain why does he/she thinks the size is x story points.
o Repeat this until the whole team concludes the story point.
o Scrum master/product owner are the silent spectators while sizing.
• This process continues until the team accumulates stories to their capacity in the Sprint.
• The final list of Stories become the Sprint backlog and Sprint Goal.
Daily Scrum:
To plan the day, identify the risks and ways to mitigate them.
This is time boxed for < 15 minutes
Rules:
- The whole team attends
- Every weekday
- Everyone attends
Report these three things to each other
- What was an individual able to accomplish since last daily stand up?
- What will the individual try to accomplish by next daily?
- What is blocking accomplishments?
Sprint Review
To demonstrate what is ready to ship to PO and stakeholders and get feedback on what was delivered.
This is time-boxed for < 1 hour for one week Sprint.
Rules:
- Team demonstrates
- No PowerPoint
- Demo on production like environment
Sprint Retrospective
To collate feedback on how team worked in the last sprint and identify improvement actions.
This is time-boxed for < 1 hour for one week Sprint.
Adhering to this process and following it as is makes a successful delivery team
