1.
Agile Software Development
Tathagat Varma
http://managewell.net
Pic: http://www.seas.harvard.edu/news/2014/08/self-organizing-thousand-robot-swarm

2.
The changing nature of work…
http://www.jarche.com/wp-content/uploads/2013/01/changing-nature-of-work.png

3.
The Work Spectrum
http://performancexdesign.wordpress.com/2011/05/04/mapping-informal-and-formal-learning-strategies-to-real-work/

4.
Not all Knowledge Work is same!
http://www.mckinsey.com/insights/organization/rethinking_knowledge_work_a_strategic_approach

5.
Types of Problems

6.
http://www.emilianosoldipmp.info/wp-content/uploads/2012/08/Stacey.png
That’s the
problem we need
to solve!
And these are
the methods we
are using!!!

7.
Predictive vs. Adaptive

8.
Predictive vs. Adaptive
• Development methods exist on a continuum from adaptive to predictive.[15]
• Agile methods lie on the adaptive side of this continuum. One key of adaptive
development methods is a "Rolling Wave" approach to schedule planning, which
identifies milestones but leaves flexibility in the path to reach them, and also allows for
the milestones themselves to change.[16] Adaptive methods focus on adapting quickly
to changing realities. When the needs of a project change, an adaptive team changes as
well. An adaptive team will have difficulty describing exactly what will happen in the
future. The further away a date is, the more vague an adaptive method will be about
what will happen on that date. An adaptive team cannot report exactly what tasks they
will do next week, but only which features they plan for next month. When asked
about a release six months from now, an adaptive team might be able to report only
the mission statement for the release, or a statement of expected value vs. cost.
• Predictive methods, in contrast, focus on analysing and planning the future in detail and
cater for known risks. In the extremes, a predictive team can report exactly what
features and tasks are planned for the entire length of the development process.
Predictive methods rely on effective early phase analysis and if this goes very wrong,
the project may have difficulty changing direction. Predictive teams will often institute
a Change Control Board to ensure that only the most valuable changes are considered.
https://en.wikipedia.org/wiki/Agile_software_development

9.
What is the most important part in
these two machines?
“The Brakes!!!”
They let you go faster…

10.
Agility vs. Discipline?
http://www.ibm.com/developerworks/rational/library/edge/08/feb08/lines_barnes_holmes_ambler/

11.
Process Spectrum…
http://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf

12.
Waterfall Software Development
Limitations and Assumptions
1. Wrong analogy: Software development ≠ Production
2. Customers know EVERYTHING upfront and that requirement won’t change
3. Legacy from the past: implicitly assumes CPU time is costly, so focuses on doing everything
upfront to minimize ‘machine time’ for trial and error
4. “Wicked Problem”: Designers and developers know how exactly how to build
5. Very long feedback cycles not suitable for today’s pace of innovation
Picture from http://damonpoole.blogspot.in/2009/07/traditional-development-game-of.html

13.
Waterfall challenges: Poor Visibility
http://www.agilenutshell.com/agile_vs_waterfall

14.
Waterfall challenges: Poor Risk
Management
http://www.agilenutshell.com/agile_vs_waterfall

15.
Waterfall challenges: Poor Quality
http://www.agilenutshell.com/agile_vs_waterfall

16.
Waterfall challenges: Poor Change
Management
http://www.agilenutshell.com/agile_vs_waterfall

17.
“V” Model
http://www.testingexcellence.com/v-model/

18.
“W” Model of Testing
http://gerrardconsulting.com/?q=node/531

19.
Spiral
http://en.wikipedia.org/wiki/File:Spiral_model_%28Boehm,_1988%29.svg

20.
Incremental Development
• Incremental development
– is a scheduling and staging strategy
– in which the various parts of the system are developed at different
times or rates,
– and integrated as they are completed.
– It does not imply, require nor preclude iterative development or
waterfall development - both of those are rework strategies.
• The alternative to incremental development is to
develop the entire system with a "big bang"
integration

21.
Iterative Development
• Iterative development
– is a rework scheduling strategy
– in which time is set aside to revise and improve parts of the
system.
– It does not presuppose incremental development, but works
very well with it. A typical difference is that the output from
an increment is not necessarily subject to further refinement,
and its' testing or user feedback is not used as input for
revising the plans or specifications of the successive
increments. On the contrary, the output from an iteration is
examined for modification, and especially for revising the
targets of the successive iterations.

22.
Incremental vs. Iterative
http://www.planetgeek.ch/wp-content/uploads/2011/01/Slide7.png

23.
Incremental vs. Iterative
http://www.infoq.com/resource/news/2008/01/iterating-and-incrementing/en/resources/
Patton_Incremental_Iterative_MnaLisa.jpg

24.
Incremental and Iterative
http://itsadeliverything.com/wordpress/images//iterative-incremental-mona-lisa.png

25.
12 Agile Principles
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.

26.
Waterfall vs. Agile
http://www.isixsigma.com/new-to-six-sigma/design-for-six-sigma-dfss/doing-some-software-six-sigma-and-agile-%E2%90%98mythbusting
%E2%90%99/

27.
Waterfall vs. Agile
http://www.agilenutshell.com/agile_vs_waterfall
By doing them continuously:
• Quality improves because
testing starts from day one.
• Visibility improves because
you are 1/2 way through
the project when you have
built 1/2 the features.
• Risk is reduced because you
are getting feedback early,
and
• Customers are happy
because they can make
changes without paying
exorbitant costs.

28.
http://www.targetprocess.com/blog/wp-content/uploads/2009/06/agile_waterfall-792810.png

29.
Waterfall vs. Agile
https://en.wikipedia.org/wiki/File:Agile-vs-iterative-flow.jpg

30.
Waterfall vs. Agile: Constraints

31.
Waterfall Vs. Agile: Managing Changes
http://www.agileenterprises.com/agile-development/advantages-of-agile-development

32.
Waterfall vs. Agile: Risk vs. Value
Delivered
http://www.testingthefuture.net/wp-content/uploads/2011/12/waterfall_versus_agile_development.png

33.
Agile ROI
http://www.agileload.com/agileload//blog/2012/10/22/agile-performance-testing-process---whitepaper

34.
agile lifecycle – big picture

35.
Agile lifecycle – small picture
http://blogs.salesforce.com/company/2012/06/agile-approach-to-talent-management.html

36.
So, what happens in each increment?
Increment
≠
Mini-waterfall

37.
feedback loop in agile lifecycles

38.
test-code-refactor loop

39.
http://blog.grazitti.com/testing-in-the-agile-world/
QA in Agile

40.
from daily builds to project

41.
Feedback Loops in Traditional Techniques
vs. Agile Techniques

42.
XP Feedback Loops
http://www.ssa-outsourcing.com/services/project-management/

43.
Schneider Culture Model
http://www.infoq.com/articles/organizational-culture-and-agile

44.
Agile Culture
http://collectiveedgecoaching.com/wp-content/uploads/2010/07/Agile-Culture-Quad-diagram-results2.png

45.
Role of Management
http://www.thoughtworks-studios.com/sites/default/files/assets/agile_leadership.png

46.
What is Scrum?
• "Scrum is a team of eight individuals in Rugby. Everyone in the
pack acts together with everyone else to move the ball down the
field in small incremental steps. Teams work as tight, integrated
units with whole team focusing on a single goal.“
• "The relay race approach to product development may conflict
with the goals of maximum speed and flexibility. Instead, a
holistic or ‘rugby’ approach – where a team tries to go the distance
as a unit, passing the ball back and forth – may better serve
today’s competitive requirements.”-The New New Product
Development Game” by Hirotaka Takeuchi and Ikujiro
Nonaka.

47.
What is Scrum?
• Scrum is an iterative, incremental process for developing any product or managing any work.
• It produces a potentially shippable set of functionality at the end of every iteration.
• It's attributes are:
– Scrum is an agile process to manage and control development work.
– Scrum is a wrapper for existing engineering practices.
– Scrum is a team-based approach to iteratively, incrementally develop systems and products when
requirements are rapidly changing
– Scrum is a process that controls the chaos of conflicting interests and needs.
– Scrum is a way to improve communications and maximize co-operation.
– Scrum is a way to detect and cause the removal of anything that gets in the way of developing
and delivering products.
– Scrum is a way to maximize productivity.
– Scrum is scalable from single projects to entire organizations. Scrum has controlled and organized
development and implementation for multiple interrelated products and projects with over a
thousand developers and implementers.
– Scrum is a way for everyone to feel good about their job, their contributions, and that they have
done the very best they possibly could.

48.
Scrum

49.
http://www.flickr.com/photos/magia3e/6233729753/

50.
Roles, Ceremonies and Artifacts
Scrum Team is small (5-9),
cross-functional team
members from Dev, UX, QA
(excluding Product Owner)
to ship complete feature(s)
end to end
Scrum Master is the servant
leader responsible for
supporting team
Product Owner owns
Product Backlog and sets
appropriate priority for team
to act upon
Roles
Product
Owner
Scrum Master
Scrum Team
Ceremonies
Sprint Planning
Meeting
Daily Stand-ups
Backlog
Grooming
Product Demo
Sprint
Retrospective
Artifacts
Product
Backlog
Sprint Backlog
Increment
Release Burn-down
Chart
Sprint Burn-down
Chart

51.
Scrum Roles

52.
References
• http://agilemanifesto.org
• http://agilealliance.org
• http://scrumalliance.org
• http://scrum.org
• http://www.extremeprogramming.org/
• http://www.dsdm.org/dig-deeper/book/dsdm-atern-
handbook