1. Refresh Savannah
July 20, 2010
Introduction to Agile
Premise:
Waterfall is DEAD as a SDLC!
But... Can you release too early?
Marvin Heery, Social Usability
MPH Consulting
Credit to: Pradyumn Sharma of Pragati Software Pvt. Ltd. and
Kyle R. Larson of Advanced Technologies Integration, Inc

2. Waterfall review
• Old school
• Proven not responsive to todays deadline-driven
application development needs
• Rapid development – RAD attempts
– We’ve seen Band-Aids before:
• 4GL
• Interpreters
• Other approaches
• WHY AGILE NOW?
– When did Agile thoughts begin?
– Been around a while – proven – how many of you use it
now?

3. The typical sequence for the conventional
waterfall management style
1. Early success via paper designs and overly precise
artifacts,
2. Commitment to executable code late in the life cycle,
3. Integration nightmares due to unforeseen
implementation issues and interface ambiguities,
4. Heavy budget and schedule pressure to get the system
working,
5. Late shoe-horning of suboptimal fixes, with no time for
redesign, and
6. A very fragile, expensive-to-maintain product, delivered
late.
From: Improving Software Economics Whitepaper (May 2009)
Source: IBM Rational Software

4. Presenters experience
• Degree in CSC – way back – see the gray?
• Worked in utility company – COBOL – online CICS
• Supported developers – as systems programmer
• Went into vendor world for career change
• Evolved to application development tools focus
– RDBMS world
– 4GLs
• Taught Conceptual Data Modeling with Data Dictionary
technologies
• Even evangelized the early OODBMS technologies,
including development approaches & supported early
adopter level systems

5. This presentation
• Cobbled together – from others – credits on
title slide – originals available if interested
• Not all you want to know
• Hopefully enough to make you want to know
more
• Raises some thoughts for implementing UX
practices & getting value from Usability
Testing – couple slides on parallel tracks!

6. Who are you?
• Who here writes code either as part of their
job or in their spare time?
• Who writes code with other developers?
• Who follows a software development process
when coding?
• Who works with designers for the UX
process?
Bar Camp Phnom Penh Agile Project Management - Scrum 9

7. When did I first see Agile?
• Agile development started out in 1994
• 2001 / 2002 timeframe my first exposure
• After an internet startup experience
• Looking for alternative approaches to develop new
applications I was interested in at the time
• Attended Agile (XP) User Group sessions in Atlanta
• ISSI – Internet Security Systems (sold to IBM)
– Supported XP User Group
– Had embraced Agile tools & methodologies to built their new
products
• Now Agile is being adapted to address organizational
change

8. So, What is Agile?
• Agile Manifesto
• Principles – easy ones to understand
– See List below…
• Implementations in several approaches
– XP, SCRUM… see slide with various flavors…
• Project Management not DEAD but different!
– SCRUM

9. The values of the Agile Manifesto are
supported by a collection of 12 principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change
for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity— the art of maximizing the amount of work not done— is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
From: Adapting Agile Methods for Complex Environments Source: IBM Rational ( December 2009)

10. Manifesto for Agile SD
• Based on the Manifesto for Agile Software
Development
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
Bar Camp Phnom Penh Agile Project Management - Scrum 13

11. Three styles of software development
 Agile – Work is implemented in stages
(iterations), and only enough planning is
carried out to complete the next iteration
 The Waterfall - Heavy up front
planning, following a traditional engineering
approach
 Method C – Very little or even none
organized planning
Bar Camp Phnom Penh Agile Project Management - Scrum 14

12. Comparing Waterfall & Agile

13. Waterfall in Practice

14. Agile Methods
– Extreme Programming (XP) (Kent Beck, Ward
Cunningham, Ron Jeffries)
– Scrum (Jeff Sutherland, Mike Beedle, Ken
Schwaber)
– DSDM – Dynamic Systems Development
Method (Community owned)
– Crystal (Alistair Cockburn)
– ASD – Adaptive Software Development (Jim
Highsmith)
– XBreed (Mike Beedle)

15. All Agile Methods
• Maximize value by minimizing anything that
does not directly contribute to product
development and delivery of customer value
• Respond to change by inspecting and
adapting
• Stress evolutionary, incremental development
• Build on success, not hope

16. Agile Software Development
Methodologies
• Useful compromise between no process
and too much process.
• Suitable for responding to changing
customer requirements.
• Adaptive rather than being predictive.
• Work well even for predictable
requirements.
• People-oriented as against being process-
oriented.

17. Introduction to XP
• Pioneered by Kent Beck, along with Ward
Cunningham and Ron Jeffries.
• A set of useful guidelines or best practices
for handling software development
projects.
• Strong emphasis on small iterations,
simple design, and testdriven
development.

18. Five Core Values of XP
• Communication
• Simplicity
• Feedback
• Courage
• Respect
Motherhood & Apple Pie?

19. Overview of XP: Practices
• Primary practices (13) • Secondary practices (11)
– User stories – Customer involvement
– Weekly cycle (iteration – Shared code
planning) – Root-cause analysis
– Test-first programming – Code and tests
– Incremental design – Single code base
– Continuous integration – Incremental deployment
– Ten minute build – Team continuity
– Pair programming – Shrinking teams
– Energized work – Daily deployment
– Quarterly cycle – Negotiated scope contract
– Sit together – Pay-per-use
– Whole team
– Informative workplace
– Slack

20. Stories
• Story = customer-visible functionality provided by
a system.
• Build a list of stories based on discussions with
customers.
– Just note down the names initially.
• Role of stories:
– Estimation
– Scope definition for a release cycle
– Units of planning and monitoring a system
– Prioritization by customers.
– Risk assessment and estimation by developers
• Concept of epics involving grouping stories

21. Pair Programming
• Two programmers working together for
some programming task.
• Benefits:
– Knowledge sharing
– Better quality
– Coding standards
– On-going code reviews
– Ease of inducting new team members
(mentoring)
– Mutual learning
– Improved productivity

22. Incremental Design
• Avoid “complete design before implementation”.
• According to a Standish Group report:
– 7% of features and functions are always used, 12% are often
used,
– 16% are sometimes used, 19% are rarely used, 45% are never
used.
• Design what is needed now. Keep investing in the design
every day.
• Create spike solutions to tackle tough technical or design
problems.
• Design done close to when it is needed is more efficient.
• Refactor your design as you go ahead.

23. Real Customer Involvement
• Customer writes user stories, acceptance tests, and
answers queries of developers.
• Negotiates a set of stories to be included in each scheduled
release.
• Benefits:
– Priorities can be set / adjusted in real-time
– No need to have water-tight requirements
– Customer is available to help make course corrections as clarity
emerges gradually about the requirements, effort estimates and
consequences
– Customer participates in discussions and planning meetings; has
greater understanding of technical issues and status of the
progress

24. Quarterly Cycle
• At the macro level, plan work a quarter at a
time.
– Identify bottlenecks
– Identify and initiate corrective steps
– Focus on the big picture, where the project fits
within the organization.
• Take stock of the project, the team, and its
progress.

25. Other Practices
• Sit Together:
– Develop in an open space big enough for the whole
team.
• Whole Team:
– Create a cross-functional team, with all the skills and
perspectives needed for the project to succeed.
• Informative Workspace:
– Display information about the project status all over in
the workspace.
– Place user story cards or big charts for issues that
require steady progress.

26. Other Practices (cont’d)
• Incremental Deployment:
– When taking over a legacy system, gradually take over its
workload beginning very early in the project. No “cut over”
during a weekend.
• Team Continuity:
– Keep effective teams together. At the end of a project, don’t
send the programmers to the “pool”.
• Shrinking Teams: (Mythical Man-month?)
– As the team grows in capability, keep its workload constant but
gradually reduce its size. Free people to form more teams.
– If a team is too small, merge it with another very small team.
• Daily Deployment:
– Put new software into production every night.

27. Who plays role of Customers?
• This is where UX practices can be integrated effectively
with the Agile Development track
• Create parallel track for UX
• Integrate Usability Testing early & often
• Use paper prototypes first
• Refine level of Usability Testing as cycles & iterative
process generate more robust set of features
• UX Practitioner becomes Customer – use internal
company resources as Test Participants at various levels
of Testing
• Develop external Design Partners for Test Participants

28. Proposed Parallel Track Approach

29. UX Track details
• And as far as integrating design - design is a
dependency for development.
• We almost never start a sprint with
outstanding design tasks that need to be
developed in the same sprint - it almost never
works.
• Design should be 1 sprint ahead of
development, and the user stories need to be
split up that way (any user story that requires
design basically becomes an "epic" so it can
be split up over multiple sprints).

30. Introduction to SCRUM
• Another prominent agile methodology.
• Co-developed by Jeff Sutherland and Ken
Schwaber in the early 1990s.
• While XP practices are more programmer-
centric, Scrum practices are geared towards
the project managers.
• XP and Scrum complement each other very
well.

31. Chickens and Pigs
A chicken and a pig are together
when the chicken says, "Let’s
start a restaurant!.
The pig thinks it over and says,
"What would we call this
restaurant?”
The chicken says, "Ham n’ Eggs!"
The pig says, "No thanks. I’d be
committed, but you’d only be
involved!"

32. Here’s a Happy Scrum Master (aka Pig)!

33. What is Scrum?
Definition from rugby football:
a scrum is a way to restart
the game after an
interruption, where the
forwards of each side come
together in a tight formation
and struggle to gain
possession of the ball when it
is tossed in among them
Bar Camp Phnom Penh Agile Project Management - Scrum 44

34. Scrum
• Term in rugby to get an out-of-
play ball back into play
• Term used in Japan in 1987 to
describe hyper-productive
development
• Used by Ken Schwaber and
Mike Beedle to describe their
Agile methodology

35. So how do they play it?
http://www.flickr.com/photos/euan_forrester/2322625115/

37. Overview of SCRUM
• The core of Scrum is an iterative, incremental process
skeleton.
• At the start of each iteration, the team selects what it can
implement by the end of the iteration, by looking at the
requirements, technology available, its skills and capabilities.
• The team is then left alone to implement the chosen
functionality.

38. Functionality of Scrum
Bar Camp Phnom Penh Agile Project Management - Scrum 49

39. SCRUM Process

40. The Scrum Team
• Typically 5-10 people
• Cross-functional (Programmers, UI
Designers, Database experts etc.)‫‏‬
• Members should be full-time
• Team is self-organizing
• Membership can change only between
sprints
Bar Camp Phnom Penh Agile Project Management - Scrum 51

41. SCRUM Flow
• Project Vision
• Product Backlog
• Sprint
– Sprint planning meeting
– Daily Scrum meeting
– Sprint review meeting
– Sprint restrospective meeting

42. Sprint Planning Meeting
• At the start of a Sprint, there is a Sprint planning
meeting. In this meeting, Product Owner and
Team get together to collaborate about what will
be done for the next Sprint.
• Product Owner tells the team what is desired. The
Team tells the Product Owner how much it
believes it can turn into functionality over the next
Sprint.
• Time-boxed to a maximum of eight hours. Divided
into two parts. The first part is for selecting
Product Backlog, the second part is for preparing
a Sprint Backlog.

43. More on stories – SCRUM/Sprint
• Any user story that can't be accomplished
by 1 person during 1 sprint is too large and
should be turned into an epic with lots of
user stories...
• because...
• a user story = 1 discreet feature
implementable by 1 developer during 1
sprint.
• Otherwise, you're back to waterfall.

44. Sprint
• All work is done in Sprints.
• An iteration of 30 consecutive calendar days.
• The Team can seek outside help, information, support.
• No one can provide advice, instructions, etc. to the
Team during the Sprint. The Team is self-managing.
• The Team is committed to the Product Backlog selected
during the Spring Planning meeting. The Product
Backlog is frozen, and no one is allowed to change this
Product Backlog during the Sprint.
• If the Sprint proves to be unviable, the ScrumMaster
can terminate the Sprint and initiate a new Sprint
planning meeting.

45. Daily Scrum (Standup Meeting)
• Is a short (15 minutes long) meeting, which
is held every day before the Team starts
working
• Participants: Scrum Master (which is the
chairman), Scrum Team
• Every Team member should answer on 3
questions
Bar Camp Phnom Penh Agile Project Management - Scrum 56

46. Questions
• What did you do since the last Scrum?
• What are you doing until the next Scrum?
• What is stopping you getting on with the
work?
Bar Camp Phnom Penh Agile Project Management - Scrum 57

47. SCRUM Masters version
1. What did you do yesterday?
2. What are you going to do today?
3. Are you stuck or waiting on a
dependency?
a) If so, who do you need to help you fix it?
Thanks to our resident SCRUM Master, Kevin L.

48. Sprint Retrospective Meeting
• Conducted by the ScrumMaster. Attended only by the
Team, the ScrumMaster, and the Product Owner
(optional).
• Timeboxed to three hours.
• Team is encouraged to revise its development process to
make it more effective and enjoyable for the next Sprint
• ScrumMaster starts by asking all the Team members:
– what went well during the last Sprint?
– what could be improved in the next Sprint?
• Role of ScrumMaster is not to provide answers, but to
facilitate the Team's search for better ways for the Scrum
process to work for it.
• Actionable items to be added to the next Sprint are
devised as high-priority nonfunctional Product Backlog.

49. Lots more adaptations, considerations
• Marriage of UX (design) principles into Agile processes
• YES, designers & developers DO work together
• False to say that they don’t in a development team
• Key is forming the TEAM – designers being a part of the
TEAM is possible – need to be responsive to the Agile
mentality though
• Challenge in outsourced project teams – developers
need to get with a set of designers – or converse if
designers are driving project they need to “recruit” a
set of developers who can participate over life of
project & not do an over the fence approach to design
& coding

50. Getting to Agile, using Scrum…
• Research – reading
• Look at successful implementations around you
• Training
• Consulting
• Coaches
• Use the Lawver method – AOL got there, can YOU?
– Sneak it in one teams development approach for one project
– Let other teams see your success
– Management will notice
• Make it YOURS

51. Is this where you want to be?

52. Questions, Discussion
• What did you learn new tonight?
• What will you do with what you learned?
• Can Agile processes help your teams, company?
• If you did Agile tomorrow how would you start?
• Embracing Agile, building the Team
• Do you see better PM techniques with SCRUM
than you do today?

53. Can you release too early?
• Seth Godin – do you know him?
• The world we live in, as Seth sees it…
– “In the new economy of launch and learn and revise…”
• Can we release too early? Too often?
• So…
– Can Usability Testing early & often with REAL users,
watching them get lost in your new features help?
– Will that make you more comfortable that your launch or
revision release is going to keep them from getting lost?
– Learn from Usability Testing before you learn from lost
users – you might not even know they get lost without
watching them!

54. Thanks!
Marvin Heery
MPH Consulting / Social Usability
http://socialusabilty.wordpress.com
@socialusability, Facebook.com/SocialUsability
socialusability@gmail.com
Using Google Wave?