AGILE - Methodology July 2017 Srinivas-Kothuri

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 23

AGILE - Methodology

July 2017
Srinivas-Kothuri
AGENDA
Agile What is?
Iterative & Incremental Development
Agile Manifesto (Values & Principles)
Agile Methodologies
SCRUM - What is ?
Waterfalls Intro & Pitfalls
Scrum - Comparison with waterfall
Scrum Pros & Cons
Extreme Programming (XP) intro
KANBAN Intro
DevOps What is?
AGENDA CONTINUED..

Transitioning to Agile from Waterfall


Scrum @ NINDS IRMB
Sprint Cycle at NINDS
Challenges and Lessons Learned
Agile at COE ARM & RRM
References
Agile What is?
Definition
Agile --readiness for motion, nimbleness, activity, dexterity in motion

Agility The ability to both create and respond to change in order to profit in a turbulent
business environment
Companies need to determine the amount of agility they need to be competitive

Agile Software Development


A software development methodology or system development methodology in software
engineering is a framework that is used to structure, plan, and control the process of
developing an information system

Agile software development is a software development method based on iterative and


incremental development, where requirements and solutions evolve through
collaboration between self-organizing, cross-functional teams.

It promotes adaptive planning, evolutionary development and delivery, a time-


boxed iterative approach, and encourages rapid and flexible response to change.

It is a conceptual framework that promotes foreseen interactions throughout the


development cycle.
Iterative & Incremental Development
Iterative & Incremental Development
Iterative and Incremental development is at the heart of a cyclic software development process
developed in response to the weaknesses of the waterfall model.
It starts with an initial planning and ends with deployment with the cyclic interactions in
between.

It follows a similar process to the plan-do-check-act cycle of business process improvement.

Incremental:

Iterative:
Agile Manifesto (Values & Principles)
Manifesto for Agile Software Development:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to the value:

1. Individuals and interactions over processes and tools


2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Principles:
Satisfy the Customer Promote Sustainable Pace
Welcome Change Promote Technical Excellence
Deliver Frequently Have Self Organized Teams
Collaborate Daily Support & Trust Motivated Teams
Promote Face-to-Face Maximize Through Simplicity
Conversations
Deliver Working Software Reflect & Adjust Regularly
Agile Methodologies
Various Methodologies:

SCRUM
Crystal
Feature Driven Development (FDD)
Adaptive Software Development (ADP)
Extreme Programming (XP)
Rational Unified Process (RUP)
Agile Unified Process (AUP)
Rapid Application Development (RAD)
Team Software Process (TSP)
Dynamic Systems Development method (DSDM)
Kanban
Test Driven Development (TDD)
Acceptance Test Driven Development (ATDD)
Behavior Driven Development (BDD)
Domain Driven Design (DDD)
Model Driven Design (MDD)
Iterative & Incremental Development (IDD)
Lean Software Development (LSD)
DevOPS
Scrum What is?
Definition
A framework within which people can address complex adaptive problems, while
productively and creatively delivering products of the highest possible value. Scrum is not a
process or a technique for building products; rather, it is a framework within which you can
employ various processes and techniques.

Scrum Theory
Scrum is founded on empirical process control theory, or empiricism. Empiricism
asserts that knowledge comes from experience and making decisions based on what is known.
Scrum employs an iterative, incremental approach to optimize predictability and control risk.

Scrum Roles:
Product Owner:
Defines the features of the Product & decides on release date and content
Prioritize features according to Market value & Accept or reject work results

Scrum Master
Removes Impediments * Ensures that the team is fully functional and productive
Responsible for enacting SCRUM values, Practices & Shields the team from external
interferences

Scrum Team
Cross functional, Full-time staff that is self organizing
Scrum What is? (Continued..)
Scrum Ceremonies:
Sprint Planning
Create Backlog, Determine Sprint Goal & Create Sprint Backlog
Daily Standup
15 Minutes stand-up for communication and discuss commitments and not for problem
solving
Sprint Review Meeting
Present accomplishments, waits for acceptance
Sprint Retrospective
Feedback & Lessons learnt meeting.

Scrum Artifacts:
Product Backlog
List of all desired work prioritized and is owned and managed by the Product Owner
Sprint Backlog
Subset of Product Backlog, owned by the Sprint Team and estimates are updated
Product Increment
Potentially shippable product increment aligns with development teams Definition of
Done
Monitoring (Burndown Chart for iterations, Burndown chat for releases, Burnup charts)
Depicts the total backlog hours for Sprints/Releases.
Scrum What is? (Continued)

A product owner creates a prioritized wish list called a product backlog.


During sprint planning, the team pulls a small chunk from the top of that wish list, a
sprint backlog, and decides how to implement those pieces.
The team has a certain amount of time a sprint (usually two to four weeks) to
complete its work, but it meets each day to assess its progress (daily Scrum).
Along the way, the Scrum Master keeps the team focused on its goal.
At the end of the sprint, the work should be potentially shippable: ready to hand to a
customer, put on a store shelf, or show to a stakeholder.
The sprint ends with a sprint review and retrospective.
As the next sprint begins, the team chooses another chunk of the product backlog and
begins working again.
Waterfall Intro & Pitfalls
Waterfall model is a sequential (non-iterative) design process, used in software
development process, in which progress is seen as flowing steadily downwards.

Late Delivery
Projects didnt meet deadlines
Long time to react to market demands

Final product too different from customers expectations


Only discovered at release time
Further time/money to fix the product

Requirements issues:
Customers dont have idea of what they want
Customers change requirements after design
Lack of flexibility or problems with deadlines

Implementation issues:
Technology unknown
Evolving technology needs
Unanticipated technical problems

Release issue
Market changes continuously
Company changes direction
Scrum Comparison with Waterfall

Agile & Waterfall Comparison

SCRUM Process
Scrum Comparison with Waterfall (Continued..)
Scrum Pros & Cons
Advantages
Completely developed and tested features in short iterations
Simplicity of the process
Clearly defined rules
Increasing productivity
Self-organizing
each team member carries a lot of responsibility
Improved communication
Combination with Extreme Programming

Drawbacks
Undisciplined hacking (no written documentation)
Violation of responsibility
Current mainly carried by the inventors
Fatigue for the project team for extended durations
Lessened Telecommute options
Extra coordination required for distributed teams
Main cause for scope creep
Attrition can cause changes in velocity and planning
Extreme Programming (XP) intro
Extreme Programming is a type of Agile methodology that is popular and somewhat controversial
method consisting in values, principles and practices.

It can be used together with SCRUM


Sit together (Open-Space and communication)
Whole team (People allocated full time to a project)
Informative workspace (Blackboard to draw how project proceeds)
Energized work
Work only as many hours as you can be productive
When you're sick, rest and get well
When coding, turn off phone and email notifications
Pair programming with pairs rotating every couple of hours
Ten-minute build (build and test shouldn't take more than 10 min.)
Continuous integration:
Commit many times a day
Let the build system automatically test the code and report errors through some
kind of notification (e.g., a display or email)
Incremental design:
Daily attention to design
The most effective time to design is in the light of experience
Team continuity (people work mostly with those they know and trust)
Single code base: (only one code stream: no multiple branches)
KANBAN - Intro
What is:
Kanban literally means visual card, signboard, or billboard.
Using a Kanban approach in software drops time-boxed iterations in favor of focusing on
continuous flow.

Kanban Steps:
Define a work process flow.
Elaboration & Acceptance criteria
Development
Test
Deployment
Layout a Visual Kanban board.
Goals column on left, then a waiting queue, process steps and a final done to the
right
Decide on limits for items in queue and work in progress
Good limit is the factor of the number of people in a role that can work on an item
in a given process step
Place prioritized goals on the left column of the board.
Visible goals promotes focus
Helps prioritize
Helps manage feature scope & requirements
Start the board by placing stories or features in queue
Product owners manage the waiting queue
Date and time marked to measure cycle time
KANBAN Intro cont..
Move features through the process flow as work is completed
Mark the start and end date for the card for every process step
Use the dates on the cards to calculate cycle time
Calculate cycle time which is the end time start time
Calculate average cycle time which is the wait time
Relieve bottlenecks as quickly as possible
Display and manage cycle times
Reduce the number of Kanban slots allowed until cycle time remains unchanged
Reduce the size of development items
Work in progress is actually the number of items * the average size of items
Identify and act on bottlenecks immediately
Relieve repeated bottlenecks by changing the number and types of people in each
role and cross training.

Product & Process inspection:

Evaluate the quality of the product from a functional, engineering and UX perspective
Evaluate pace of Development
Evaluate and adjust the process
Begin looking at the process using lean thinking
Monitor cycled time of validated decisions
Dont overlook the feedback and watch for backed-up queues
DevOps What is?
Characteristics: Definitions:
Treating Infrastructure as Code is fundamental Applying agile techniques to operatio
to DevOps Getting development and operations
Automating the work of setting up and
work together
maintaining systems infrastructure
Making it defined, efficient, testable, DevOps is the last mile of Agile
auditable and standardized How to deploy software with speed a
Automated Testing is part of pipeline confidence
Automated CI / CD pipeline DevOps is about accelerating softwar
Automated application deployment deployment
Logging & Traceability of all changes

Security:
DevOps and CD allow businesses to deploy software far more frequently than in the past,
increasing consistency, predictability, and ultimately, quality.
The deltas between builds are much smaller, reducing the likelihood of catastrophic errors.
Bugs are smaller and easier to fix. While functional problems can often be detected through
regular use, security vulnerabilities are harder to spot.
Since infrastructure as code allows VMs to be provisioned and de-provisioned in minutes,
keeping track of security vulnerabilities without automation is impossible.
Transitioning to DevOps Compare with Agile

Agile Development:
Iterative development,
Sprints, Stories,
Velocity
DevOps
Continuous Integration
Continuous Deployment
IT Automation
Application management

OPS Values Agile Values


Procedure Driven Business Driven
Stability Responsive to change
Availability/Uptime Real time
Controlled/Frozen Constantly up to date environment
environment
Infrequent updates CI/CD Environment
Transitioning to Agile from Waterfall
Agile Misconceptions
Letting the programming team to whatever they need to with no project management,
no architecture, allowing a solution to emerge, the programmers will do all the testing
necessary with unit tests.

Transition: Factors for Success


Think positive
Come to terms with uncertainty
Focus on definition of Done. (Avoid earned value)
Environment of trust. (No Fear)
Shared reality
Choose the right project. (Size, Importance & Visibility)
Get buy-in of senior management
Communicate
Use experienced people
Transitioning to Agile from Waterfall continued..

Things to consider:

Transparency- It ensures that aspects of the process that affect the outcome
are visible to those managing the outcomes.
Inspection The various aspects of the process must be inspected frequently
enough that unacceptable variances in the process can be detected.
Adaption When inspection determines that one or more aspects of the
process are outside acceptable limits, an adjustment must be made as quickly
as possible to minimize further deviation.
Customer relationship:
Scrum implies a transparent relationship with the customer
It keeps everything about a project visible to anyone
The customer sees the product constantly
This way, it can provide early exposure to possible schedule slips
When accepting a project, be sure to communicate risks to the customer.
Courage is needed!
Make him make the decision
Just saying "yes" can harm everyone
Give him probabilistic answers (about the expected percentage of
success) + risk analysis
Transitioning to Agile from Waterfall continued..

Transition Warnings:
Transition to Scrum without support from the top of the company creates a resistance
that cannot be overcome from below.
To reduce resistance, keep the change process nameless among employees
Don't start a new project until it can be fully staffed
All disciplines must be represented from the beginning
A company is never ``done'' becoming agile: there are always improvements to be made
None of the agile processes described by their originators is perfect for your
organization. It needs to be tailored and adapted
Do not reward single individuals, but only the whole team
A bonus can be a free Sprint to work on whatever they want
REFERENCES
The Scrum Guide from scrum.org

Scrumalliance.com

NINDS Scrum Presentation and Materials from Matthew White

Leading Agile

Abrahamsson P, Salo O and Ronkainen J. Agile software


development methods (Review and analysis).

Scott W Ambler. Agile model driven development.

Cohen D, Lindvall M, Costa P. Agile software development.

http://en.wikipedia.org/wiki/Agile_Modeling.

http://en.wikipedia.org/wiki/Extreme_Programming.

http://en.wikipedia.org/wiki/Agile_Unified_process.

http://en.wikipedia.org/wiki/Scrum_28development29

You might also like