Agile~overview

© 2012 Systems Plus
Agile Awareness

Agile Evolution

Why agile? Why do we need another approach (PMBOK Guide) for managing projects?
How do we solve different situations in our everyday life?
Initial Agricultural Revolution Industrial Revolution Information Revolution
Hunter
Gatherer
Wandering
Planting Crops
Herding Animals
Start living in one place
Machines
Factories
Moving to different cities
Led to management (project
Management, WBS)
Information/Collaboration
Focus is not only on manufacturing
Value is on ownership of knowledge
Industrial Worker Knowledge worker
Work is visible Work is invisible
Work is stable Work is changing
Emphasis on running things Emphasis is on changing things
More Structured with fewer decisions Less Structured with more decisions
Focus on right answers Focus on right questions
Define the task Understand the task
Command and Control Give Autonomy
Strict Standards Continuous innovations
Focus on Quantity Focus on quality
Measure performance to strict standards Continuously learn and teach
Minimize cost of worker for each task Treat worker as asset and not as cost
Agile Evolution

 Agile Term came into existence during early 2001 & represents ways of delivering the
product/software in fast, collaborative and iterative fashion.
 Agile Methodologies are contrary to Traditional methodologies (Waterfall etc.)
 Agile term represents huge set of methodologies including RAD, Spiral, XP, SCRUM, FDD,
Lean, OpenUP and Kanban.
 Agile Manifesto Published in Feb 2001 by 17 developers at Snowbird Utah.
Agile Evolution
RUP
(Rational Unified
Process)
SCRUM
Crystal
Clear
XP
(Extreme
Programming)
ASD
(Adaptive
Software
Development)
FDD
(Feature Driven
Development)
DSDM
(Dynamic
Systems
Development
Model)
1994
1995
1996
1996 1995
1995 1995
2001

Agile Project Management Framework

Kent Beck
(Creator XP and TDD Methodologies)
James Grenning
(author of Test-Driven Development for
Embedded C.)
Robert C Martin
("Uncle Bob", is an
American software consultant and author)
Mike Beedle
(founder,CEO of e-Architects Inc., company
that specializes in application development
using distributed objects and Internet
technologies. )
Jim Highsmith
(Author of books on software development
methodologies and creator of Adaptive
Software Development)
Steve Mellor
(developer of the Shlaer-Mellor method
and Executable UML )
Arie Van Bennekum
(Involved in DSDM Consortium)
Andrew Hunt
(Published the book The Pragmatic
Programmer: From Journeyman to Master.)
Ken Schwaber
(Co Creator of Scrum)
Alistair Cockburn
(Creator of Crystal Methodologies)
Ron Jeffries
(Collaborator and founder of XP)
Jeff Sutherland
(Co Creator of Scrum)
Ward Cunningham
(Collaborator of XP and creator of Wiki)
Jon Kern
(with both Jeff De Luca and Peter Coad
and had helped shape the charter on FDD.)
Dave Thomas
(Co Author of the book The Pragmatic
Programmer: From Journeyman to Master.)
Martin Fowler
(as per some people introduced the
term Continuous Integration.)
Brian Marick
( an early proponent of the Context-Driven
school of testing,)
Agile Original Contributors

“We are uncovering better ways of developing software by doing it and helping others
do it. Through this work we have come to value:
The Agile Manifesto
INDIVIDUALS &
INTERACTIONS
over process & tools
WORKING
SOFTWARE
over comprehensive document
CUSTOMER
COLLABORATION
over contract negotiation
RESPONDINGT
OCHANGE
over following a plan
That is, while there is value in the items on the right, we value the items on the left
more.”

Principle Shortened Version
Our highest priority is to satisfy customer through early and continuous delivery of
valuable software.
Satisfy customer with great software or Produce
value early
Welcome changing requirements, even late in development. Agile process harness
change for customer’s competitive advantage
Welcome Change
Deliver working software frequently, from couple of weeks to couple of months, with
preference to the shorter timescale.
Deliver Frequently or iterative delivery
Business people and developers must work together daily throughout the project Work with business or Daily business
collaboration.
Build projects around motivated individuals. Give them environment and support they
need, and trust them to get the job done.
Motivate People or Trust Motivated team
The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
Face-to-Face communication
Working software is the primary measure of the progress Measure software done or Working software
Agile process promotes sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
Maintain sustainable pace
Continuous attention to technical excellence and good design enhances agility. Maintain Design or Technical Excellence
Simplicity- the art of maximizing the amount of work not done- is essential. Keep it simple or K.I.S.S
The best architectures, requirements, and design emerge from self-organizing teams. Team creates architecture or Self Organize
At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts it behaviour accordingly.
Reflect and Adjust
12 Principles Of Agile

Agile and adaptive approaches for linking people, projects and value. DOI focuses on
project management side of agile projects. Agile Manifesto and agile methods offer whole
project guidance.
We are a community of project leaders that are highly successful at delivering results.
To achieve these results:
 We increase return on investment by making continuous flow of value our focus.
 We deliver reliable results by engaging customer in frequent interactions and shared
ownership.
 We expect uncertainty and manage for it through iterations, anticipations and adoptions.
 We unleash creativity and innovation by recognizing that individuals are the ultimate source
of value, and creating an environment where they can make difference.
 We boost performance through group accountability for results and shared responsibility for
team effectiveness.
 We improve effectiveness and reliability through situational specific strategies, processes
and practices.
DOI: Declaration Of Independence

Agile Methodologies

Scrum is not an acronym. First used to describe
hyper-productive development in 1987 by Ikujiro
Nonaka and Hirotaka Takeuchi, Scrum refers to the
mechanism used in rugby for getting an out-of-play
ball back into play.
Scrum generates productivity improvements by
implementing a framework that empowers teams
and thrives on change. A set of rules and
corresponding terminology are used to reinforce
such common sense techniques as small teams,
daily status meetings, not interrupting people
who are working, and a single source of work
prioritization.
SCRUM

Scrum adopts an empirical approach—accepting that the problem
cannot be fully understood or defined, focusing instead on
maximizing the team's ability to deliver quickly and respond to
emerging requirements.
SCRUM
Three pillars that hold up every implementation of empirical process
control:
Visibility: means that those aspects of the process that
affect the outcome must be visible to those controlling the process.
Not only must these aspects be visible, but what is visible must also be
true.
Inspection: The various aspects of the process must be
inspected frequently enough that unacceptable variances in the
process can be detected.
Adaptation: If the inspector determines from the
inspection that one or more aspects of the process are outside
acceptable limits and that the resulting product will be unacceptable,
the inspector must adjust the process or the material being processed
Although the above pillars guides all
aspects of Scrum Projects, there are
also four planned opportunities for
Inspection and Adaption within
Scrum framework:
Sprint Retrospective
Daily Scrum Meeting
Sprint Review Meeting
Sprint Planning Meeting

SCRUM Cont.
The heart of Scrum lies in the iteration (Sprint). The team takes a look at the requirements,
considers the available technology, and evaluates its own skills and capabilities. It then
collectively determines how to build the functionality, modifying its approach daily as it
encounters new complexities, difficulties, and surprises. The team figures out what needs to
be done and selects the best way to do it. This creative process is the heart of the Scrum’s
productivity
Dimensions of Software Development
Complexity
P3opl3
R3quir3m3nts
T3chnology

SCRUM Roles:
The Product Owner The Team The Scrum Master
Represents everyone with stake in project
and the final product
Self Managing, self organizing and cross
functional
He is responsible for Scrum Processes
Achieves initial and on going funding Responsible for figuring out how to turn
Product Backlog into an increment of
functionality within an iteration
Teaches Scrum to everyone from
implementation to Delivery
Creates overall requirements(Product
Backlog), ROI objectives and Release plan
Responsible for developing functionality Making sure process fits into organization
culture and delivers expected benefits
Responsible for prioritizing product
backlog
Collectively responsible for each iteration and
whole product
Removes impediments to progress, assists
product owner with managing backlog,
communicating vision, goal and backlog items
to team.
SCRUM Cont.

SCRUM Flow

Sprints:
 A time boxed iteration (2-8 weeks)
 build a potentially shippable product.
 includes a sprint planning meeting, Daily Scrums,
Development work, Sprint Review Meeting, Sprint
Retrospective.
 During sprint no changes are made that effect
sprint goal.
 Scope may be clarified or renegotiated as new
information becomes clear.
 Development team cannot change
SCRUM Activities
Sprint Planning Meeting:
 Is used to define what will define a sprint
and how it will be achieved.
 time boxed for 8 hrs.( 4 hrs. explain, 4 hrs.
plan)
 Product owner explains team product
backlog , ordered by priority
 Team asks questions to clarify user stories so
that they can break it into tasks.
 PO, SM and team is involved.
 Outcome is Sprint Backlog

Daily Scrum:
 Is 15 minutes time boxed daily meeting.
 Meeting happens at same place and same time.
 Each member provides answer to three questions:
 What has been achieved since last meeting?
 What will be done before next meeting?
 What obstacles are in way?
 Daily scrum for pigs (chickens welcome to listen)
 Discussion parked until after scrum
SCRUM Activities Cont.
Sprint Review Meeting:
 Is held at the end of the sprint & last about 1hr per wk of
sprint
 Scrum team demonstrates what is accomplished during
sprint.
 Very informal ; no PowerPoint slides, lectures, diagrams.
 Participant includes PO, SM, Scrum Team, management,
customer
 Project is assessed against the sprint goals defined in sprint
planning meeting
 Ideally team completes each product backlog item brought
into sprint backlog

SCRUM Activities Cont.
Sprint Retrospective Meeting:
 Is usually the last thing of the sprint.
 time boxed for 3-4 hrs.
 Attended by SM and Scrum team and occasionally PO
different formats
 go for lunch
Outside park
 CEO to attend

Product Backlog:
 Prioritized features list, containing short descriptions of all functionality desired in the
product.
 Typically contains features, Bugs, Technical work & Knowledge acquisition.
 It is
 Visible to all
 Single source and copy of truth
 Dynamic
 It helps guide roadmap planning.
SCRUM Artifacts

SCRUM Artifacts
Sprint Backlog:
 Task identified by Scrum Team during Sprint
Planning
 User Stories in Product Backlog are broken into
Tasks.
 Team estimates how many hours each task will
take.
 Burn Down Chart: is a publicly displayed chart
showing remaining work in the sprint backlog.
Updated every day, it gives a simple view of the
sprint progress. It also provides quick
visualizations for reference. Variation of Sprint
burn down is Release burn down chart.

 The main goal of XP is to lower the cost of change in software requirements. With traditional
system development methodologies, like the Waterfall Methodology, the requirements for
the system are determined and often "frozen" at the beginning of the development project.
This means that the cost of changing the requirements at a later stage in the project —
something that is very common in the real-world — can be very high.
 Extreme Programming (or XP) is software development centric agile methodologies. While
scrum focuses on project management level with focus on prioritizing work and getting
feedback, XP focuses on software development good practices.
Extreme Programming (XP) Flow

 Extreme Programming (or XP) is software development centric agile methodologies. While
scrum focuses on project management level with focus on prioritizing work and getting
feedback, XP focuses on software development good practices.
 Core values of XP methodologies are:
Simplicity: focuses on reducing complexity, extra features and waste. “Find the
simplest thing that could work” is the phrase team should keep in mind.
Communication: focuses on making sure each member knows what is expected out of
them and what other members are working on. Daily Stand Up meeting is key component of
communication
Feedback: team should get impression of suitability early. Failing fast can be useful.
Courage: It takes courage to allow our work to be entirely visible to others. In Pair
programming, team members share codes, often makes bold simplifications and changes the
code. Automated build and tests makes sure developers have confidence to make important
changes.
Respect: is essential on XP projects where team work together as a team and
everyone is accountable for success or failure.
Extreme Programming (XP)

Extreme Programming (XP) Flow

XP Practices
 XP Is Based on several simple but powerful core practices.

 XP expects participation from Whole Team, Whole team refers to all contributors to XP
sitting in same physical location as members of same team including Customers.
 XP emphasis on the notion of generalising specialist as opposed to role specialist.
Onsite Customers Product Manager /Owners Domain Experts
Technical Specialists Interaction Designers Programmers
Designer and Architects Testers Coaches- The programmer coach
Project Manager Project Community, stakeholder and
executive sponsor
XP Roles

Planning Games: XP has two primary planning activities or planning games – Release
Planning and Iteration Planning.
 Release Planning is push for new functionality all the way to production. A Project typically
has one or more releases with no more than two releases happening in a year. During
release planning customer outlines the functionality required and developers estimates how
difficult it is to estimate. Based on estimates and priorities customer defines a project plan.
Initial estimates will be bit imprecise, so process is revisited frequently and improved as
estimates and priorities evolves.
 Iterations are small development cycles within a release( as Scrum calls it “Sprint”) ideally of
two weeks. Iteration planning is done at the start of iteration. Customer describes the
functionality required in next two weeks and then developer breaks the functionality into
tasks and estimates the work. Based on these estimates and amount of work achieved in
prior iteration, team commits the amount of work they can do in next iteration.
XP Planning

XP Test Driven Development Cycle
• Red
Write a little test that doesn‘t work (and perhaps doesn‘t even compile at first)
• Green
Make the test work quickly (committing whatever sins necessary)
• Refactor
Eliminate all of the duplication created in merely getting the test to work, improve the
design

Lean Software Development

Eliminate Waste: To maximize value we must eliminate waste. In software systems,
waste can be in form of partially done work, unnecessary features etc. Therefore to
increase value we must develop ways to identify and then remove waste.
Empower Team: Rather than taking micromanagement approach we should respect
team’s superior knowledge of the technical steps required for project and let them make
decision to be productive and successful.’
Deliver Fast: Maximize ROI by quickly delivering valuable software.
Optimize the whole: Aim to see the system as more than the sum of its parts. We go
beyond the pieces of project and look how it aligns with organization. As part of
optimizing the whole we also focus on forming better intergroup relations.
Build Quality In: Lean development does not try to “test-in” quality at the end. It builds
quality into the product and continually assures quality throughout the development
process using techniques like refactoring, continuous integrations, and unit testing.
Defer Decisions: Balance early planning with making decisions and committing to
things as late as possible.
Amplify Learning: Concept involves facilitating communication early and often getting
feedback as soon as possible and building on what we learn.
Lean gives us techniques and concepts such as Value stream Mapping, seven forms of
waste, WIP etc.

 Lean software development is a translation of lean manufacturing and lean IT principles and
practices to the software development domain. Adapted from the Toyota Production System, a
pro-lean subculture is emerging from within the Agile community. Lean software development
practices, or what is commonly called "tools" are expressed slight differently from their equivalents
in agile software development, but there are parallels. Examples of such practices include:
 Eliminate Waste
 Provide market and technical leadership - Your company can be successful by producing
innovative and technologically advanced products but you must understand what your
customers value and you know what technology you are using can deliver
 Create nothing but value - You have to be careful with all the processes you follow, i.e., be sure
that all of them are required and they are focused on creating value
 Write less code - The more code you have the more tests you need thus it requires more
work and if you're writing tests for features that are not needed you are simply wasting time

 Create Knowledge
 Create design-build teams - Leader of the development team has to listen to his/her
members and ask smart questions encouraging them to look for the answers and to get
back with encountered problems or invented solutions as soon as possible
 Maintain a culture of constant improvement - Create environment in which people will be
constantly improving what they are working on - they should know that they are not and should
not be perfect - they always have a field to improve and they should do it
 Teach problem-solving methods - Development team should behave like small research
institute, they should establish hypotheses and conduct many rapid experiments in order to
verify them
 Build Quality In
 Synchronize - In order to achieve high quality in your software you should start worrying about
it before you write single line of working code - don't wait with synchronization because it will
hurt
 Automate - Automate testing, building, installations, anything that is routine, but do it
smartly, do it in a way people can improve the process and change anything they want
without worrying that after the change is done the software will stop working
 Refactor - Eliminate code duplication to ZERO - every time it shows up refactor the code, the
tests, and the documentation to minimize the complexity.

 Defer Commitment
 Schedule irreversible decisions at the last responsible moment - You should know where you
want to go but you don't know the road very well, you will be discovering it day after day - the
most important thing is to keep the right direction
 Break dependencies - Components should be coupled as loosely as possible to enable
implementation in any order
 Maintain options - Develop multiple solutions for all critical decisions and see which one works
best
 Optimize the Whole
 Focus on the entire value stream - Focus on winning the whole race which is the software -
don't optimize local inefficiencies, see the whole and optimize the whole organization
 Deliver a complete product - Teams need to have great leaders as well as great engineers,
sales, marketing specialists, secretaries, etc. - they together can deliver great final products
to their customers

 Deliver Fast
 Work in small batches - Reduce projects size, shorten release cycles, stabilize work
environment (listen to what your velocity tells you), repeat what's good and eradicate
practices that creates obstacles
 Limit work to capacity - Limit tasks queue to minimum (one or two iterations ahead is
enough), don't be afraid of removing items from the queue - reject any work until you have
an empty slot in your queue
 Focus on cycle time, not utilization - Put in your queue small tasks that cannot clog the
process for a long time - reduce cycle time and have fewer things to process in your queue
 Respect People
 Train team leaders/supervisors - Give team leaders the training, the guidance and
some free space to implement lean thinking in their environment
 Move responsibility and decision making to the lowest possible level - Let your people
think and decide on their own - they know better how to implement difficult
 algorithms and apply state-of-the-art software frameworks
 Foster pride in workmanship - Encourage passionate involvement of your team
members to what and how they do

 Task Kanban Board named after Just-In-Timeproduction method in Toyota Production System
(TPS).
 A Kanban is a ticket describing a task to do. In TPS, it is used to realize Just-In-Time"pull"
production control. In Figure 1, the Kanban Board shows the current status of all the tasks to
be done within this iteration. The tasks are represented by cards (Post-It Notes). Status is
presented by areas on the board separated and named To Do, Doing, and Done. This
Kanban Board helps team understand how they are doing, as well as what to do next. This
helps make the team self-directing.
KANBAN TPS Board

 Limiting the amount of work that is in progress will contribute to faster completion, better
quality, and greater focus on only the highest-priority work. A WIP limit is a policy, an agreed-
upon decision about how the work will be processed. Policies can similarly specify how the
organization handles types of work items.
 A WIP limit defines a stage in the Kanban system. A stage in the Kanban system may span
across several workflow states. A limit on WIP constrains how many work items can be in each
stage of the workflow at a given time. When a work item is pulled to the next stage of the
process, a slot opens and a new work item can be pulled into that stage. A number of workflow
states may be grouped together under a single WIP limit.
 A significant consequence of a WIP limit is that blocked work “holds up the line.” A blocked
work item still counts against the limit, so a situation may arise as more items become blocked, in
which no new work can progress until the block is resolved. This drives collaboration, as the team
(and any affected external stakeholders) are highly motivated to clear the blockage.
KANBAN TPS Board

KANBAN TPS Board
Three Principles of Kanban
1. Start with what you know
2. Agree to pursue incremental, evolutionary change
3. Initially, respect current roles, responsibilities and job titles
Kanban five core practices
1. Visualize
2. Limiting work in progress
3. Manage flow
4. Make management policies
5. Improve collaboratively using “safe to fail” experiments

 In Agile project management, planning is an iterative component of the
project lifecycle.
 In the above figure, see the repeated sets of green shading as planning
occurs throughout the project lifecycle.
Agile Project Management Framework

 ENVISION
Determine the product vision and project scope, the project
community, and how the team will work together
 SPECULATE
Develop a feature-based release, milestone, and iteration plan to
deliver on the vision
 EXPLORE
Deliver tested features in a short timeframe, constantly seeking to
reduce the risk and uncertainty of the project
 ADAPT
Review the delivered results, the current situation, and the team's
performance, and adapt as necessary
 CLOSE
Conclude the project, pass along key learnings, and celebrate

Agile~overview

More Related Content

What's hot

Similar to Agile~overview

Recently uploaded

Agile~overview

Editor's Notes