Agile Methodology hdhddh churdffg ghhhhg.ppt

Meaning of Agility
Copyright 2011 John Wiley & Sons, Inc. 12-2
 In an uncertain and turbulent world, success
belongs to companies that have the capacity to
create change, and maybe even chaos, for their
competitors.
 Creating change disrupts competitors (and the
entire market ecosystem); responding to change
guards against competitive thrusts.
 Creating change requires innovation: developing
new products, creating new sales channels,
reducing product development time, customizing
products for increasingly smaller market
segments.

Meaning of Agility…
 In addition, your company must be able to
respond quickly to both anticipated and
unanticipated changes created by your
competitors and customers.
 Agility is the ability to both create and respond to
change in order to profit in a turbulent business
environment.
 Agility is the ability to balance flexibility and
stability.

Meaning of Agility…
 Some people mistakenly assume that agility
connotes a lack of structure, but the absence of
structure, or stability, generates chaos.
Conversely, too much structure generates rigidity.
 Too much structure stifles creativity. Too little
structure breeds inefficiency.
 Agility is the balance point between chaos and
order, between flexibility and stability.

Agile Business Objectives
1. Continuous innovation— to deliver on current
customer requirements
2. Product adaptability— to deliver on future
customer requirements
3. Improved time-to-market— to meet market
windows and improve return on investment (ROI)
4. People and process adaptability— to respond
rapidly to product and business change
5. Reliable results— to support business growth
and profitability

Continuous Innovation
 Developing new products and new services in
today's complex business and technology world
requires a mindset that fosters innovation.
 Striving to deliver customer value, to create a
product that meets today’s customer
requirements, drives this continuous innovation
process.
 Innovative ideas aren't generated in structured,
authoritarian environments but in an adaptive
culture based on the principles of self-
organization and self-discipline.

Product adaptability
 No matter how prescient a person, a team, or a
company, the future will always surprise us.
 For other products, the timeframe for
incorporating changes varies from months to
years.
 With the pace of change increasing and
response time shrinking, the only way to survive
is to strive for product adaptability—a critical
design criterion for a development process.
 In fact, in an agile project, technical excellence is
measured by both capacity to deliver customer
value today and create an adaptable product for
tomorrow.

Improved Time-to-Market
 As the statistics for rapidly shrinking product
development times indicate, reducing delivery
schedules to meet market windows continues to
be a high-priority business goal for managers
and executives.
 The iterative, feature-based nature of APM
contributes to improving time-to-market in three
key ways: focus, streamlining, and skill
development.
 First, the constant attention to product features
and their prioritization in short, iterative
timeboxes forces teams (product management
and developers) to carefully consider both the

Focus,
 The constant attention to product features and
their prioritization in short, iterative timeboxes
forces teams (product management and
developers) to carefully consider both the
number of features to include in the product and
the depth of those features.
Streamlining
 APM—like its lean development counterparts—
streamlines the development process,
concentrating on value-adding activities and
eliminating overhead and compliance activities.

Skill development
 APM focuses on selecting the right skills for
project team members and molding them into
productive teams.

People and Process Adaptability
 Just as products need to adapt to marketplace
reality over time, so do people and processes.
 In fact, if we want adaptable products, we must
first build adaptable teams— teams whose
members are comfortable with change, who view
change not as an obstacle to resist but as part
and parcel of thriving in a dynamic business
environment.
 The APM principles and framework encourage
learning and adapting as an integral part of
delivering value to customers.

Reliable Results
 Production processes are designed to be
repeatable, to deliver the same result time after
time after time.
 Good production processes deliver the
anticipated result, for a standard cost, within a
given time—they are predictable.
 Exploration processes are different. Because of
the uncertainty surrounding requirements and
new technology, exploration projects can't deliver
a known, completely pre-specified result, but they
can deliver a valuable result—a releasable
product that meets customer goals and business
requirements as they become known.

Agile Leadership and Team Values
"In high-performance teams, "the leaders managed
the principles, and the principles managed the team."
Carl Larson and Frank LaFasto (1989).
 If we want to build great products, we need great
people. If we want to attract and keep great
people, we need great principles.
 Why teams exist, what we intend to build, whom
we build it for, and how we work together form the
core principles of APM.

Agile Leadership and Team Values
Values
 Delivering value over meeting constraints (Value
over Constraints)
 Leading the team over managing tasks (Team over
Tasks)
 Adapting to change over conforming to plans
(Adapting over Conforming)
 There are two primary sources for agile values:
1. The Declaration of Interdependence
2. Manifesto for Agile Software Development

The Declaration of Interdependence
 The Declaration of Interdependence was
developed with project leaders in mind.
 Whereas the Agile Manifesto was developed with
software development in mind.
 It boosts performance through group
accountability for results and shared responsibility
for team effectiveness.
 It improves effectiveness and reliability through
situationally specific strategies, processes, and
practices.

Manifesto for Agile Software Development
 "This is a kind of tool, process, documents,
contracts, or plans.
 Over the years, the manifesto statements have
been misinterpreted, primarily in confusing less
important with unimportant:
 "This should not be construed as indicating that
tools, process, documents, contracts, or plans are
unimportant.
 There is a tremendous difference between one
thing being more or less important than another
and being unimportant“.
 Tools are critical to speeding development and
reducing costs.

Manifesto for Agile Software Development
 Contracts are vital to initiating developer-customer
relationships.
 Documentation aids communication.
 Without skilled individuals, working products, close
interactions with customers, and responsiveness
to change, product delivery will be nearly
impossible.

Agile Leadership and Team Values…
Q. What traits differentiate an agile leader from a
traditional (or non-agile) leader?
 A traditional project manager focuses on following
the plan with minimal changes, whereas an agile
leader focuses on adapting successfully to
inevitable changes.
 Some team leaders who are good team managers,
but overly conforming, and others who are good at
adapting, but poor at self-organizing team
leadership. A good agile leader must be both.

“Task" management versus “Team"
management
 "Team managers" enable teams to self-manage
their own tasks to facilitate the completion of
features.
 "Task managers" focus on task completion as a
measure of how well the team is conforming to the
project plan.
 "Team managers" assist their teams (and the
broader project community) remain coordinated
and effective so that they can succeed.
 "Task managers" oversee teams to ensure that
they remain "productive," on task, and don't lag
behind the plan.

Risk Management
 The chance of adverse consequences of future
events.
 An uncertain event or condition that, if it occurs,
has a positive or negative effect on a project’s
objectives.
 Risk relates to future problem not current one.
 They involve a possible event and its effect.
Example- Developer leaves- task delayed.

Risk Types
 Market Risk
 The market risk is the project complete successfully, but
then the market conditions have changed and the product
is not accepted in the market; may be the competitors
have come up with the better product.
 Financial Risk
 Financial risk is risk of financial commitment by the
customer not being honoured.
 The customer gone bankrupt cannot pay for the project
halfway through the project and so on.

Risk Types
 Technology Risk
 The technology risk is that the project assumes some
technology and then the project proceeds based on that
technology; but it may so happen that better technology
gets developed and comes into use before the project
completes.
 Project Risk:
 Project personal leave unable to find replacement for a
specific role, the schedule gets delayed and so on.

Risk Management Approaches
 Proactive
 Anticipate the possible risks
 Take actions to manage the risk
 Reactive
 Take no action until an unfavourable events occurs.

Risk Handling Framework
 Risk identification
 What risks might be there
 Risk analysis and prioritization
 Which are the most serious risk
 Risk Planning
 What are we going to do about them?
 Risk Monitoring
 What is the current state of risk?

Risk identification
 Use of checklists
 Usually based on the experience of past projects
 Brainstorming
 Knowing risk through pool concern.
 Causal Mapping
 Identifying possible chain of cause and effect

Risk analysis and prioritization

Risk Planning
Risks can be dealt with by:
 Risk acceptance
 Risk avoidance
 Risk reduction
 Risk Transfer
 Risk mitigation

Risk reduction

What is Agile Software development
 Agile: Easily moved, light, nimble, active software
processes
 How agility achieved?
 Fitting the process to the project
 Avoidance of things that waste time

Agile Model
 Agile model was proposed in mid-1990s
 To overcome the shortcoming of the waterfall model
 Primarily designed to help project to handle change
requests
 The requirements are decomposed into many
small incremental parts that are developed
incrementally.

Ideology: Agile Manifesto
 Individuals and interactions over process and tools
 Working Software over comprehensive
documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

Agile Model
 User stories:
 Simpler than use cases
 Metaphors:
 Based on user stories, developers propose a common
vision of what is required.
 Spike:
 Simple program to explore potential solutions.
 Refactor:
 Restructure code without affecting behaviour

Agile Model…
 At a time, only one increment is planned
developed, deployed at the customer site.
 No long-term plans are made.
 An iteration may not add significant functionality.
 But still a new release is in variably made at the end of
each iteration
 Delivered to the customer for regular use.

Methodology
 Face-to-face communication favoured over written
documents.
 To facilitate face-to-face communication,
 Development team to share a single office space.
 Team size is deliberately kept small (5-9 people)
 This makes the agile model most suited to small
development projects.

Agile Model: Principles
 The primary measure of progress:
 Incremental release of working software
 Important principles behind agile model:
 Frequent delivery of versions- once every few
weeks.

Agile Methodologies

Agile Methodology hdhddh churdffg ghhhhg.ppt

Recommended

Recommended

More Related Content

Similar to Agile Methodology hdhddh churdffg ghhhhg.ppt

Similar to Agile Methodology hdhddh churdffg ghhhhg.ppt (20)

Recently uploaded

Recently uploaded (20)

Agile Methodology hdhddh churdffg ghhhhg.ppt