Agile

• Introduction
• Agile was First used in 2001.
• An agile approach has
• Shared values 
• Common principles
• The four values are heart of agile.
• Individuals and interactions over Process and Tools.
• Working software over comprehensive documentation.
• Customer collaboration over Contract negotiation.
• Responding to change over following a plan.
• The 12 principles which describe guidelines on thinking.
• Following are12 principles
• Our highest priority is to satisfy customer through early and continuous delivery.
• Welcome changing requirements even late in the development. Agile processes harness change for customer competitive advantage.
• Deliver working software frequently (weekly or monthly) with focus on shorter time scale.
• Business people and developers should work together daily.
• Build projects around motivated individual. Provide them the environment and support they need and trust them to get the Job done.
• The most efficient way to convey information to your development team is face to face conversation.
• Working software is a primary measure of success.
• Agile process promotes sustainable development. Sponsors, developers and users should maintain a constant pace.
• Continuous attention to technical excellence and good design boosts agility.
• Simplicity the art of maximizing the amount of work not done but is essential.
• The best requirements, architecture, and design emerge from self organizing teams.
• At regular intervals, Team reflects on how to become more effective and tweak behavior accordingly.
• The first three principles focus on how to delight customers. 
• Next three Focus on team and how they can do their work
• Next Two focus on progress through agile lens.
• Next Three describe How we are Building the right thing the right way. 
• Final principal Is about continuous improvement. 
• Agile principles and lean thinking are more or less similar.
• Many practices used by agile teams and organizations.
• Website is http://agilemanifesto.org.
• Agile is thanking about a way of how we do work.
• One example of agile practice is sprint retrospective.
• A regularly scheduled event where team inspects and adapts their system of work.
• Scrum is a product development approach
• A scrum is a collection of several agile practices that work well together.
• A Sprint retrospective is a practice from scrum.
• A collection of practices that work well together in a particular context is called as a framework.
• Scrum is a framework that works particularly well in context of building some thing new like a new product, feature in an existing product or a new service offering.
• Extreme programming (XP) is an agile framework that works particularly well in context of software engineering.
• Kanban works well when what can’t be planned like providing support and other on-demand services.
• We can Blend practices from multiple frameworks together. For example teams that develop software products blend practices from (XP) and (Scrum). Teams that build new features in Existing products as well as providing on-demand support for that product to customers combine practices from scrum and Kanban.
• User Stories is a way of communications in Agile.
• Jira or any other Project Management tool can be used to pull out all records for a user.
• Resources are fixed for a timeline.
• Planning Poker is an estimation technique where team works in a group to estimate the user stories in product backlog.
• There is release planning which includes discussions like how much time is needed, people are needed.
• There are 2 types of releases
• Fixed Scope releases.
• Fixed Date releases.
• Then there is sprint planning which is applicable more to the sprint.
• Identifying Sprint tasks from User Stories
• Create Product Backlog
• Requirement list created by Product Owner.
• Ranked By Importance
• Product owner can change items b/w sprints
• Create Sprint Backlog from Product Backlog.
• Team selects requirements starting from top.
• Team breaks down requirements into tasks.
• No items are added until next sprint.
• Creating and Updating Sprint Burn Down
• A sprint is a development cycle which lasts not more than 28 days inclusive of planning.
• Short term plans are made in agile which are easily explainable to end user.
• Change is embraced
• End User can change the stories as per priorities.
• End Goal is unknown
• Faster high quality delivery
• Strong team interaction
• There should be 15 mins atleast standup(as per rule book)
• Customers are heard
• Continuous Improvement
• Scrum can also be applied to distributed environment using advanced methodologies.
• In such cases Scrum should be scalable i.e. we should  be able to create a Scrum of Scrums or Scrum applicable across multiple teams.
• By common Scrum we mean Teams should have a shared goal,shared understanding and shared commitment.
• Some of the agile engineering practices include
• Refactoring
• Test driven development
• Continuous Integration
• Pair Programming
• Xtreme Programming
• Kanaban Methodology of Agile is popular in Manufacturing Industries.
• Software is developed in incremental Cycles
• After each cycle we get a build
• Each build is incremental in terms of new features to be added.
• The final build holds all the features required by the customer.
• Business in the Past
• Application earlier were standalone i.e. were independent of each other and served limited purpose.
• For example we could withdraw money from particular bank ATM only of which we had account.
• Architecture and Design of such systems is much more simpler comparatively.
• Time to market was more for the product.
• There were only 1 or 2 releases per year
• Customer used to give adequate time for requirements.
• There was more stability in requirements there was not much changes.
• Requirements used to derive complete situation
• Waterfall method was best suited in such a scenario.
• Requirement Gathering and Analysis
• Design
• High Level Architecture
• Low Level Architecture
• Development
• Testing
• Deliver Software
• The approach was more of a Big Bang approach.
• For example once we gather requirements all of them must be gathered in one shot.
• Each level of waterfall model is done in a time frame we cannot move to next level once one level is completed.
• Whole approach is in sequential phases.
• Customer can only see software in end and give feedback.
• Changing Business Scenario
• Requirements change overtime mobile phones which were only used to call are now used to smartly control things.
• User is looking for devices with multiple capabilities.
• Banking services are provided online via telebanking or netbanking.
• One need not go to bank for money transfer etc.
• Thus products need to be agile to cope up with changing demands.
• The Enterprise must aspire to respond in real time and must have the ability to be agile when needed.
• Agile Business Drivers
• Faster time to Market/deployment for new software products and services.
• Incremental working software developed frequently and early to meet the customer needs.
• Agility to adapt to a fast changing environment.
• Individual and interactions over process and tools.
• Working software over comprehensive documentation.
• Customer collaboration over  contract negotiation
• Responding to change over following a plan
• Agile Methods in Wide Spread Use
• Scrum
• Co-located and Distributed Team i.e. same billed team sits in separate ODC be it from testing or development.
• Extreme Programming(XP)
• Co-located team
• Feature Driven Development(FDD)
• Co-located and Distributed Team
• Dynamic System Data Management(DSDM)
• Lean Development
• Crystal
• Co-located team
• Adaptive Software Development
• Agile Unified Process(AUP)
• Rational Unified Process(RUP)
• Agile Approach
• Agile is based on incremental and iterative software development.
• We take a feature of product and implement it and then we take next feature of product and develop it.
• Teams focus on one feature at a time
• Team Designs a feature
• Team Develops a feature
• Team tests a feature.
• Team reworks on feature
• Team shows something of the feature to the customer after each iteration which may be of 2 weeks.If any discrepancy is there team reworks on feature in next iteration.
• At the end of each iteration customer provides certain guidelines related to product which needs to be taken care of in next iteration.
• For example Customer may tell to standardize UI for future iterations which is a guideline.
• Each iteration refines the feature once the customer gives go ahead to feature then team thinks about the new feature.
• The end point of a feature is when it is potentially shippable i.e. when customer wants team should be able to release it.
• The feature should be working in all aspects.
• After the end of one feature the customer gives next priority feature.
• An agile team is a cross functional team i.e. all the members viz developers,testers,UI guys should work cooperatively towards a goal.
• The features are developed based on the business priorities of the customer.
• Agile provides following advantages over previous approach
• Mitigation of Risks at an early stage.
• Visibility is very early to the customer i.e. customer knows sort of what he will get at an early stage.
• Atleast a non/partial functional UI is available to the customer at an early stage.
• Customer can give early feedback based on early visibility the teams adapt themselves to the feedback early.
• Complexity is low as we split the bigger issues into smaller features and work on it individually.
• Agile Values
• Individuals and Interaction over process and Tools.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face to face conversation.
• The best architecture requirements and design emerge from self organizing teams.
• Working Software over Comprehensive documentation.
• Our highest priority is to satisfy the customer, through an early and continuous delivery of valuable software.
• Deliver working software frequently from a couple of weeks to a couple of months with a preference to the shorter time scale.
• Working software is the primary measure of progress.
• Continuous attention to technical excellence and good design enhances agility. 
• Customer Collaboration over Contact Negotiation.
• Agile process promote sustainable development. The sponsors developers and users should be able to maintain a constant pace indefinitely.
• Simplicity the art of maximizing the amount of work not done is essential.
• At regular intervals the team reflects on how to become more effective, then tunes and adjusts behavior accordingly. 
• Responding to change over Following a Plan.
• Welcome changing requirements even late in development. 
• Product Backlog
• Product Backlog contains pending requirements as stated by the consumer.
• These items are moved to Sprint Backlog before moving to Sprint.
• Sprints
• A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work.
• Sprints are at the very heart of scrum and agile methodologies. Agile is a set of principles and scrum is a framework for getting things done.
• Sprints help teams follow the agile principle of "delivering working software frequently," as well as live the agile value of "responding to change over following a plan."
• The scrum values of transparency, inspection, and adaptation are complementary to agile and central to the concept of sprints.
• Sprint planning is a collaborative event where the team answers two basic questions: What work can get done in this sprint and how will the chosen work get done?
• Choosing the right work items for a sprint is a collaborative effort between the product owner, scrum master, and development team.
• The product owner discusses the objective that the sprint should achieve and the product backlog items that, upon completion, would achieve the sprint goal.
• The team then creates a plan for how they will build the backlog items and get them “Done” before the end of the sprint.
• https://www.atlassian.com/agile/scrum/sprints is good reference for learning about Sprints.
• Sprint Backlog
• Sprint Backlog contains the pending requirements to be transferred in a Sprint.
• SCRUM Overview
• SCRUM was created from a paper published by Hirotaka Takeuchi and Ikujiro Nonaka. The paper was called as "The New New Project Development Game".
• SCRUM was formalized in 1995 by Ken Schwaber and Jeh Sutherland.
• It is also called as "Holistic Approach" or "Rugby Approach".
• Universities use SCRUM to deliver valued projects to clients.
• Millilitres have relied on SCRUM to prepare ships for deployment.
• In the automotive world, Team wiki speed is using SCRUM to build a fast,affordable,ultra-efficient, safe commuter car.
• Agile Documents
• Unit Testing Document
• Project Overview Document
• Technical Documents
• Risk Metrics
• PB Sheet
• Used to Manage Bugs
• Resource Utilization
• Defect Metrics
• Users of SCRUM
• Product Owner
• Customer Representative
• Takes requirements from the end users,customer etc
• Creates an ordered list of Requirements based on Business Value 
• This is called as product backlog.
• This list is prioritized based on business value.
• This list may contain functional as well as non functional requirements.
• The Scrum Team
• Average size should be 5-7 people
• Project Manager has command and control over team.
• In case project requires more than 9 people then project may need 2 SCRUM teams needed to execute that project.
• All these teams are cross functional in nature.
• SCRUM is the most famous architecture in Agile software development.
• Requirements are divided into User Stories.
• These stories are then packaged into Sprints.
• Sprints in a Scrum
• The deliverable's in Scrum which have a start date and an end date are called as sprints.
• Each Sprint should not be more than 4 weeks.
• Each sprint should show something valuable to the customer.
• Sprint duration never gets extended.
• Every Sprint goes through the Following Agile Stages
• Pre-Sprint Initialization
• Pre-requisite : Agile pre-assessment
• Define Roles and Responsibilities
• Source the team member(hire/organize within organization)
• Infrastructure setup: Install JIRA/Other tool
• Setup the architecture vision
• Create user stories in JIRA
• Create product backlog of all requirements
• Sprint Planning
• Pre-requisite: Scrum Master,User Stories in Product Backlog
• Determine Sprint length,velocity and capacity
• Conduct Sprint Planning Meeting
• Select User stories from the product backlog in order of priority(High to Low)
• Analyse the user stories planned in the release plan.
• Seek clarification in user stories either through impediments log/tool like JIRA
• Estimate user stories using planning Poker.
• Select user stories in order of priority till the time the total estimate equals the available capacity.
• Update Sprint plan.
• Break user stories into technical tasks.
• Sprint Execution
• Pre-requisite: Sprint Backlog,Tasks from user stories are assigned to members.
• Create design(database/schema/GUI/Query logic/Wireframes etc.) for the user stories.
• Write test case/script for user stories.
• Develop Code.
• Conduct code peer review.
• Execute Unit test.
• Debug Code(fix defects)
• Integrate Code into parent branch
• Execute functional QA/Acceptance test cases.
• Debug Code(fix defects)
• Sprint Tracking
• Conduct daily stand-up meetings or Scrum meetings
• Agenda:What was done yesterday/Plan for today/Risks faced
• Not more than 15 mins long
• The Scrum Master ensures that risks/impediments are logged in an Impediment log and tracked
• Geographically split teams should attend using tools like VC/Zoom etc. at agreed upon times.
• Re-plan/Re-Assign/Split user stories and Groom the product backlog
• Add,drop or split user stories depending on the progress(and status update in the stand-up meetings)
• Update Sprint backlog and Release plan accordingly
• Use Kanban for workflow visualization to optimize the flow of work.
• Track sprint progress (and release progress) based on Epic/Sprint burn down charts from JIRA
• Implement corrective actions (if possible and necessary) based on
• Sprint feedback/inputs in stand-up meetings
• Burn down charts-Re-calibrate the user story alignment to sprints accordingly.
• Sprint Review
• Pre-requisite : Spirit work is ready, Spirit Timebox is expired.
• Walk through the Done Product backlog items of the last sprint and provide a demo to the stakeholders.
• Discuss what has been done and what has not been done
• Gather feedback from the stakeholders for future improvements.
• Discuss future spirit(s) and new areas.
• Sprint Retrospective
• The Scrum teams inspects their process
• What went well during the sprint?
• What didn't do well during the sprint?
• What improvement/changes could be made in the next sprint?
• Use the mentioned technique for running your retrospective.
• Timeline Retrospective Exercise
• Some SCRUM Certifications
• PMI certified Agile certified Practitioner
• Scrum Professional from Scrum Alliance
• Scrum Master Certification
• Scrum Applicability
• When requirements and technology are predictable then Waterfall is best.
• When process becomes chaotic i.e. requirements are marginally known or unknown here empirical approach i.e. accept and adopt becomes best.
• SCRUM is an empirical framework it suites this zone. 
• SCRUM Values
• Focus
• We are able to deliver valuable items sooner as we focus on one thing at a time.
• Courage enhances as team works together.
• Openness is "how we are doing" and "what is in our way".
• Commitment
• Respect
• SCRUM Framework
• SCRUM teams work in a time box approach i.e. there is a definite start of their tasks and definite end of their tasks.
• At the end of time box a goal is set to be accomplished.
• The results are then inspected by the customer who gives feedback's.
• Based on the feedback the team adapts its-self
• During all this process there is no change to the duration and goal.
• SCRUM Ceremonies
• Sprint Planning
• Attendees: Development team, scrum master, product owner
• When: At the beginning of a sprint.
• Duration: Usually up to two hours per week of iteration. e.g. a two-week sprint kicks off with a four-hour planning meeting.
• Agile Framework: Scrum. (Kanban teams also plan, of course, but they are not on a fixed iteration schedule with formal sprint planning)
• Purpose: Sprint planning sets up the entire team for success throughout the sprint. Coming into the meeting, the product owner will have a prioritized product backlog. They discuss each item with the development team, and the group collectively estimates the effort involved. The development team will then make a sprint forecast outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog.
• Daily stand-up
• Attendees: Development team, scrum master, product owner
• When: Once per day, typically in the morning.
• Duration: No more than 15 minutes. Don't book a conference room and conduct the stand-up sitting down. Standing up helps keep the meeting short!
• Agile framework: Scrum and kanban.
• Purpose: Stand-up is designed to quickly inform everyone of what's going on across the team. It's not a detailed status meeting. The tone should be light and fun, but informative. Have each team member answers the following questions:
• What did I complete yesterday?
• What will I work on today?
• Am I blocked by anything?
• There's implicit accountability in reporting what work you completed yesterday in front of your peers. No one wants to be the team member who is constantly doing the same thing and not making progress.
• Iteration review
• Attendees:
• Required: Development team, scrum master, product owner
• Optional: Project stakeholders
• When: At the end of a sprint or milestone.
• Duration: Typically 60 minutes per week of iteration-e.g. a two-hour review following a two-week sprint.
• Agile framework: Scrum and kanban. Like planning, review for kanban teams should be aligned with team milestones rather than on a fixed cadence.
• Purpose: Iteration review is a time to showcase the work of the team. They can be in a casual format like "demo Fridays", or in a more formal meeting structure. This is the time for the team to celebrate their accomplishments, demonstrate work finished within the iteration, and get immediate feedback from project stakeholders. Remember, work should be fully demonstrable and meet the team's quality bar to be considered complete and ready to showcase in the review.
• Retrospective
• Attendees: Development team, scrum master, product owner
• When: At the end of an iteration.
• Duration: Typically 45 minutes per week of iteration-e.g. a 90-minute retrospective after a two-week sprint.
• Agile framework: Scrum and kanban. Scrum teams do sprint retrospectives based on a fixed cadence. Kanban teams can benefit from occasional retrospectives, too.
• Purpose: Agile is about getting rapid feedback to make the product and development culture better. Retrospectives help the team understand what worked well–and what didn't.
• Retrospectives aren't just a time for complaints without action. Use retrospectives to find out what's working so the team can continue to focus on those areas. Also, find out what's not working and use the time to find creative solutions and develop an action plan. Continuous improvement is what sustains and drives development within an agile team, and retrospectives are a key part of that. 
• Estimation

• Poker Estimation
• Each developer gives estimation from Fibonacci numbers. Story is put up to all and the developer with minimum and maximum estimation or estimation with greater variance is given a chance to speakup.
• For example if developers give 3,5,7,15 story points for issue then the developer who gave 15 will be asked for reasons. 
• The Engineering aspects involve
• Planning
• Sprint Planning
• Initiation and Planning
• Tools
• Rally
• Requirement and Design
• Sprint Execution
• Sprint Planning
• Sprint Tracking 
• Coding and Testing
• Sprint Execution
• Sprint Planning
• Sprint Tracking
• Tools
• Git
• Jenkins
• Team Foundation Server
• JUnit
• Crucible
• Integrate and Demo
• Sprint Review
• Sprint Review & Retrospective
• Tools
• HipChat
• Bamboo
• Confluence
• Slack
• Jive

• Kanban
• A Kanban is a lean scheduling system Developed in Japan by the Toyota motor corporation. A Kanban system utilizes visual cues that tell you what to produce, how much to produce.
• When adapted to software development Kanban System usually stores with oh board and visual cards that represent items in your product backlog.
• We arrange cards on the board based on workflow from new to complete.
• So we can easily Check the status of items at particular time.
• Kanban imposes limits on items that can live in a step in workflow at a given time. This helps to complete items at a steady pace.
• These limits are called as work in progress or (WIP) limits.
• If we run into a problem then we can’t add more items to the workflow as we have a bottleneck. As a result whole team first Works on the Problem which also achieves collaborative principal of agile.
• There is also less task switching when we assign these limits which also saves time.
• Kanban works really well in Collaboration with scrum framework.
• Scrum provides structure for organizing feedback, short-term planning, stack ranking, inspect and adapt mindset.
• Kanban provides a steady flow of tasks that reach Hundred percent completion by helping your team manage day today development with a minimum of overhead and blocking issues.
• Rally uses Kanban and scrum for product development.
• Agile versus waterfall
• Initially The definition off project success Was limited to The triple constraints that is schedule, cost and scope. A Challenged project would have Met two out of three constraints. A failed project missed on two or more of the constraints.
• Considering the change in requirements with time the scope part is Tweaked to include Customer satisfaction, value delivered, and alignment to strategic goals.
• Since in agile we divide a project into small deliverables it’s success rate is more as compared to waterfall model.
• These small deliverables can be better Managed in terms of schedule and risk to. Each deliverable carries a value which is called as MVP or Minimum viable product.
• Waterfall is a lifecycle while agile is an approach

Brush Up

1. All Scrum Roles , e.g. Product Owner,Scrum Master & Sprint Team are defined and performed.
2. "Product Backlog" is groomed i.e. user stories are re-prioritized regularly.
3. "Definition of Done" and "Definition of Ready" is defined for each user story
4. Sprint team is involved during estimation.
5. Length of Sprints is not more than 4 weeks.
6. All scrum rituals such as Daily stand up Meeting,Sprint Planning,Sprint Review,Sprint Retrospection are performed.
7. Scrum Master track the team impediments in an impediment log.
8. Scrum Master and Team track the sprint progress using the Epic/Sprint burn-down metrics.
9. Sufficient lessons learnt and good practices are identified in the Retrospective meetings.