The document discusses Agile software development, emphasizing its iterative and incremental nature that fosters collaboration among self-organizing teams. Key principles include responsiveness to change, delivery of working software, and continuous customer involvement, contrasting Agile with the Waterfall model, which is more rigid and documentation-heavy. Various Agile methodologies and practices, such as Scrum and Extreme Programming (XP), are outlined, alongside tools and resources to support Agile processes.

1. Nov 21, 2013
Agile Software
Development
Monitor
Progress
Project Progress
By: Pradeep Patel

2. Agile Software Development is
a group of software
development methods 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.
An information
radiator displaying the up-to-
date summary of status, is
placed prominently in an office
Agile methods break tasks into
small increments with minimal
planning and do not directly
involve long-term planning.
Iterations are short time
frames (timeboxes) that
typically last from one to four
week
A common characteristic of
agile development are daily
status meetings or "stand-
ups". In a brief session, team
members report to each other
what they did the previous day,
what they intend to do today,
and what their roadblocks are.
At the end of the iteration a
working product is
demonstrated to stakeholders
What is AGILE?

3. Waterfall Model
It is a sequential design process, in which progress
is seen as flowing steadily downwards through the
phases of Conception, Initiation, Analysis, Design,
Construction, Testing, Production/Implementation,
and Maintenance.
It places emphasis on documentation (such as
requirements documents and design documents)
as well as source code.
Why it fails?
If clients change their requirements after the design is finalized, the design must be
modified to accommodate the new requirements. This effectively means invalidating a
good deal of working hours, which means increased cost, especially if a large amount of
the project's resources has already been invested in.
There are few other models that had been used in the past, however most of them are
based on Water Fall model and will not be discussed here
Pre-Agile Methodologies
Initiation
Planning
Execution
Monitoring
and Control
Closure

4. AGILE-Iterative and Incremental development
Image Source: Wikipedia
Inception:
Identifies project scope,
requirements (functional and
non-functional) and risks at a
high level but in enough detail
that work can be estimated.
Elaboration
Delivers a working architecture
that mitigates the top risks and
fulfills the non-functional
requirements.
Construction:
Incrementally fills-in the architecture
with production-ready code
produced from analysis, design,
implementation, and testing of the
functional requirements.
Transition:
Delivers the system into the
production operating
environment.
PHASES

5. AGILE-Manifesto
• over processes and toolsIndividuals and
interactions
• over comprehensive
documentationWorking software
• over contract negotiationCustomer
collaboration
• over following a planResponding to
change
Individuals and interactions : Self-organization and motivation are important, as are interactions
like co-location and pair programming.
Working software : Working software will be more useful and welcome than just
presenting documents to clients .
Customer collaboration : Requirements cannot be fully collected at the beginning of the
software development cycle, therefore continuous customer or stakeholder involvement is very
important.
Responding to change : Agile development is focused on quick responses to change and continuous
development

6. Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with
a preference to the shorter timescale.
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.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
AGILE
Principles

7. AGILE- Methods(Putting Agile to Practice)
Extreme Programming (XP)
Scrum
Kanban
Scrum-ban
Test-driven development (TDD)
Lean software development
Continuous integration (CI)
Feature Driven Development (FDD)
Dynamic Systems Development Method (DSDM)
Agile Unified Process (AUP)
Agile Modeling
Crystal Clear
Graphical System Design (GSD)
Story-driven modeling
Velocity tracking
Crystal Methods
Acceptance Test Driven Development (ATDD)
Software Development Rhythms

8. AGILE-SCRUM
A Scrum process is distinguished from other agile processes by specific concepts
and practices, divided into the three categories
Roles
Artifacts
Time Boxes..

9. AGILE – Effective User Story Contents
A user story should contain the following main items
Title: <a name for the user story>
As a <user or persona>
I want to <take this action>
So that <I get this benefit>
The story should also include validation steps — steps to take to validate that the working requirement for the user
story is correct
When I <take this action>, this happens <description of action>
Optional Information that a story can contain
An ID: A Unique identifier for the story.
The value and effort estimate: Value is how beneficial a user story is to the organization creating that product.
Effort is the ease or difficulty in creating that user story.
The person who created the user story: Anyone on the project team can create a user story.
For user stories that are too large to be completed in a single iteration or sprint, some teams use Epics.
Epics are basically a higher-level story that’s fulfilled by a group of related user stories.

10. AGILE –Extreme Programming(XP)-Values
Simplicity: We will do what is needed and asked for, but no more. This will maximize the value
created for the investment made to date. We will take small simple steps to our goal and
mitigate failures as they happen. We will create something we are proud of and maintain it
long term for reasonable costs.
Communication: Everyone is part of the team and we communicate face to face daily. We will work together
on everything from requirements to code. We will create the best solution to our problem that we can
together
Feedback: We will take every iteration commitment seriously by delivering working software. We
demonstrate our software early and often then listen carefully and make any changes needed. We will talk
about the project and adapt our process to it, not the other way around.
Respect: Everyone gives and feels the respect they deserve as a valued team member. Everyone
contributes value even if it's simply enthusiasm. Developers respect the expertise of the customers and vice
versa. Management respects our right to accept responsibility and receive authority over our own work.
Courage: We will tell the truth about progress and estimates. We don't document excuses for failure
because we plan to succeed. We don't fear anything because no one ever works alone. We will adapt to
changes when ever they happen.

11. AGILE –Extreme Programming(XP)-Rules
Planning
User stories are written.
Release planning creates the release schedule.
Make frequent small releases.
The project is divided into iterations.
Iteration planning starts each iteration
Managing
Give the team a dedicated open work
space.
Set a sustainable pace.
A stand up meeting starts each day.
The Project Velocity is measured.
Move people around.
Fix XP when it breaks.
Designing
Choose a system metaphor.
Use CRC cards for design sessions.
Create spike solutions to reduce risk.
No functionality is added early.
Refactor whenever and wherever possible
Simplicity
Coding
The customer is always available.
Code must be written to agreed standards.
Code the unit test first.
All production code is pair programmed.
Only one pair integrates code at a time.
Integrate often.
Set up a dedicated integration computer.
Use collective ownership.
Testing
All code must have unit tests.
All code must pass all unit tests before it can
be released.
When a bug is found tests are created.
Acceptance tests are run often and the score
is published.

12. AGILE- XP Practices
Coding standard: Team members should follow established and adopted coding guidelines and standards.
Collective ownership: Team members may view and edit other team members’ code or any other project artifact. Collective
ownership encourages transparency and accountability for work quality.
Continuous integration: Team members should check in changes to their code frequently, integrating the system to ensure
that their changes work, so the rest of the team is always working with the latest version of the system.
Automated CI should be considered using tools like
Test-Driven Development (TDD): In TDD the first step is to quickly code a new test basically just enough code for the test to
fail. This test could either be high-level acceptance or a more detailed developer test. Functional code is then updated to
make it pass the new test
Customer tests: Detailed requirements are captured just-in-time (JIT) in the form of acceptance tests (also called story tests).
Refactoring: Refactoring is a small change to something, such as source code, database schema, or user interface, to
improve its design and make it easier to understand and modify.
Pair programming: Two programmers work together on the same artifact at the same time. One programmer types the code
while the other programmer looks at the bigger picture and provides real-time code review.
Planning game: This includes high-level release planning to think through and monitor the big issues throughout the project
as well as detailed JIT iteration/sprint planning.
Simple design: Programmers should seek the simplest way to write their code while still implementing the appropriate
functionality.
Small releases: Frequent deployment of valuable, working software into production is encouraged.
Sustainable pace: The team should be able to sustain an energized approach to work at a constant and gradually improving
velocity.
Whole team: Team members should collectively have all the skills required to deliver the solution. Stakeholders or their
representatives should be available to answer questions and make decisions in a timely manner.

13. AGILE -Kanban
Stop starting and start finishing!
Four basic principles (how you need to think)
Five for properties (what you need to do).
Basic Principles
Start with what you do now
Agree to pursue incremental, evolutionary change
Respect the current process, roles, responsibilities & titles
Encourage acts of leadership at all levels
Core Properties
Visualize the workflow
Limit WIP(Work in Progress)
Manage flow
Make Process Policies Explicit
Improve Collaboratively
(using models & the scientific method)
• The Theory of Constraints (the study of bottlenecks)
• The System of Profound Knowledge (a study of variation and
how it affects processes)
• Lean Economic Model (based on the concepts of “waste” )
http://www.everydaykanban.com/what-is-kanban/

14. AGILE –Agile Modeling(AM)
Agile Modeling (AM) is a practice-
based methodology for effective
modeling and documentation of
software-based systems.
At a high level AM is a collection
of best practices, depicted in the
pattern language map .
At a more detailed level AM is a
collection of values, principles,
and practices for modeling software
that can be applied on a software
development project in an effective
and light-weight manner
With an Agile Model Driven Development (AMDD) approach, typically just enough high-level modeling at the beginning of a project is done to understand the
scope and potential architecture of the system.
During construction iterations modeling is done as part of your iteration planning activities and then take a JIT model storming approach where modeling is
done for several minutes as a precursor to several hours of coding.
AMDD recommends that practitioners take a test-driven approach.
Active stakeholder participation: Stakeholders (or their representatives) provide info, make decisions, and are actively involved in the development process.
Architecture envisioning: This practice involves high-level architectural modeling to identify a viable technical strategy for your solution.
Document continuously: Write documentation for your deliverables throughout the life cycle in parallel to the creation of the rest of the solution.
Document late: Write deliverable documentation as late as possible to avoid speculative ideas likely to change in favor of stable information.
Executable specifications: Specify detailed requirements in the form of executable customer tests and your detailed design as executable developer tests.
Iteration modeling: Iteration modeling helps identify what needs to be built and how.
Just barely good enough artifacts: A model needs to be sufficient for the situation at hand and no more.
Look-ahead modeling: Invest time modeling requirements you intend to implement in upcoming iterations.
Model storming: Do JIT modeling to explore the details behind a requirement or to think through a design issue.
Multiple models: An effective developer has a range of models in his toolkit, enabling him to apply the right model for the situation at hand.
Prioritized requirements: Implement requirements in priority order, as defined by your stakeholders.
Requirements envisioning: Invest time at the start of project to identify the scope of the project and create the initial prioritized stack of requirements.
Single-source information: Capture info in one place only.
TDD: Quickly code a new test and update your functional code to make it pass the new test.
Agile Modeling practices

15. AGILE-AMDD continued……

16. AGILE -Tools
JIRA and it add-ins like GreenHopper, Confluence(Collaboration), Bamboo(Continuous Integration) and
Crucible(Code Review)
VersionOne
Rally and its add-in like AccuBridge
Mingle
VSTS with Scrum Templates and its add-ins and templates like UrbanTurtle, Conchango etc.
Excel and template from Jeff Sutherland
PivotalTracker
Scrumworks
Hudson(Continuous Integration)
Scrumpad
TargetProcess
Agilo
BrightGreen
Outsystems
Redmine
ScrumDesk
Tinypm
Trac
Zen
CruseControl (Continuous Integration)
GoogleDocs spreadsheet template (and also collaboration)
SharePoint (Collaboration)
SVN- Subversion (Version Control)

17. AGILE –Tools..Continued….
Agile Bench
Agilefant
Agile Tracking Tool
Arpoh
Assembla
Express
IceScrum
LiquidPlanner
Mendix
PangoScrum
Planigle
Polarion
Scrumboard
Scrum’d
ScrumNinja
Serena Agile On Demand
Silver Catalyst
Sprintometer
Virtual SCRUM Board
WRAP
Bugzilla (Bug Tracking)
Cucumber (TDD)
CVS – Concurrent Versions System
Elluminate (Web Conferencing)
Rspec (TDD)
Selenium (Automated Testing)
StickySorter (Collaboration)
Team City (Continuous Integration)
Twiki (Collaboration)
WebEx (Web Conferencing)
http://setandbma.wordpress.com/2010/02/17/agile-tool-expert-recommendation/

18. AGILE –Additional Resources
Agile for Dummies-IBM
Scrum Reference Card
Agile Data

19. Thank You
Pradeep Patel
MCTS, MCPD, PMP
blogs.pdotsolutions.com
techconnect. pdotsolutions.com