Agile methods

Agile Methods
A brief guide to agile software development
Duong Trong Tan
tandt@fpt.edu.vn
HCM city, 9- 2011

Objectives
Software Engineering history & agile
What is agile development?
The Agile Manifesto
The diversity of methods
Scrum
XP
RAD
TDD
Crystal
Kanban
Agile mashup
The cooperative game
A brief introduction to Agile Software Development
2

Agile Basics
“Agile projects succeed when the team gets the spirit of agility.” – Ron Jeffries
3
Image courtesy of Pollyanna Pixton

4
Continuous improvement
Hyper productive
Kaizen
Agile
Small teams
Buzzwords
Incremental
Lean
Changes
Earned Value Based
Iterative
Rapid
Adaptive

History
5
SE
Scrum
Weinberg: psychology of computer program
Declaration of Independence
deMarco: Peopleware
XP
2005
2011
2001
1970
1980
1995
1990
AgileAlliance.org
1968
Gilb: Principles of Software Engineering
Royce: managing the development of large software systems
PMI developed agile certifications
RAD
DSDM

6
So, what are software projects?

Partiesand Concerns
Users?
Customers?
BO?
Developers?
7

8
What is agile development?

The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
9
That is, while there is value in the items on the right, we value the items on the left more.
AgileAlliance.org

The Twelve Principles of Agile Software
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.
10
AgileAlliance.org

Home ground comparison
11

The diversity of methods
12

Rapid Application Development
One of the earliest method
A strategy instead of comprehensive process
Utilizing of Prototyping
“VB – Access Method”
Still useful, esp. prototyping technique
13

Prototyping
Early visibility of the prototype gives users an idea of what the final system looks like
Encourages active participation among users and producer
Increases system development speed (in RAD)
Steps:
Identify basic requirements
Develop Initial Prototype
Review
Revise and Enhance the Prototype
14

Scrum
A hyper-productive development model
15

Scrum
One of the most successful agile methods because of its hyper-productivity
It is management – oriented
Somewhat CMM Level 3 equivalence
Widely used in various types of projects
Google AdWorlds project
3M
Universities RnD projects
In VN: LogiGear, KPM, FSOFT, FAT, etc.
16

Scrum Framework
17
Scrum Team
Rules
Rules
Scrum
Transparency
Inspection
Adaption
Artifacts
Scrum Events
Rules

18
Image courtesy of ScrumAlliance

Scrum Roles
Scrum Master
Product Owner
Development Team
Other parties (all kinds of ‘chicken’)
19

Transition of roles
Project Manager
Tester
Developer
System Designer
QA
Graphic Designer
20
Cross-functional Scrum Team

Management Transformation
21
Managers tell people what to do and make sure they do it properly
Managers maintain the right to authorize decision
Managers limit the information or resources available to workers
People decide what, and how to do
Team makes decisions
Information is transparent
TO

Transition of organization
Self-directed Team
Multi-functional Team
22
Customer-driven
Multi-skilled workforce
Few job descriptions
Information widely shared
Few levels of management
Whole-business focus
Shared goals
Seemingly chaotic
Purpose achievement emphasis
High worker commitment
Continuous Improvements
Self-controlled
Values/Principles based
Management-driven
Workforce of isolated specialists
Many job descriptions
Information limited
Many levels of management
Function/Department focus
Segregated goals
Seemingly organized
Problem-solving emphasis
High management commitment
Incremental Improvements
Management-controlled
Policy/Procedure based

Development Team
Team is cross-functional and consists of 5-9 people
There are no set project roles within the team
Team defines tasks and assignments
Team is self-organizing and self-managing
Maintains the Sprint Backlog
Conducts the Sprint Review
23

ScrumMaster
Holds Daily Scrum meeting
Assures every people related to the project follow the Scrum rules
Removes obstacles
Shields the team from external interference: “Keep Chickens away from Pigs”
Conducts Sprint Retrospective at the end of a Sprint
Is a facilitator, not a manager
24

Product Owner (PO)
Accountable for product success
Defines all product features
Responsible for ordering product features
Maintains the Product Backlog
Insures team working on highest valued features
25

Product Backlog
List of all desired product features
List can contain bugs, and non-functional items
Product Owner responsible for ordering the items
Items can be added by anyone at anytime
Each item should have a business value assigned
Maintained by the Product Owner
26

Examples of Product Backlog
27

A Sprint
Time box: 2-4 weeks (why?)
An iteration for building a piece of increment (potentially shippable) of the whole system
It’s the working time, not planning or asking what to do.
The team manages itself during a Sprint
The team commits to Product Backlog during the Sprint planning meeting
The Sprint Backlog is updated during a Sprint
28

Sprint Backlog
29
Each item is prioritized and estimated

30
The Scrum Skeleton
2.Daily Scrum Meeting
What have you done?
What will you do?
What is impeding you?
3. A Sprint (2-4 weeks)
4. Sprint Review Meeting
1. Sprint Planning Meeting
5. Sprint Retrospective Meeting

Sprint Planning Meeting
Time box: 8 hours
Product backlog prepared prior to meeting
First Half
Team selects items committing to complete
Additional discussion of Product Backlog occurs during actual Sprint
Second Half
Occurs after first half done – PO available for questions
Team solely responsible for deciding how to build
Tasks created / assigned – Sprint Backlog produced
31

Scrum Daily Meeting
Held every day during a Sprint
The most important inspection event in Scrum
Timebox:15 minutes
Team members talk to the whole Development Team, not Scrum Master
Asks 3 questions during meeting
“What have you done since last daily scrum?”
“What will you do before the next daily scrum?”
“What obstacles are impeding your work?”
Opportunity for team members to synchronize their work
It helps removing burdens between members
32

Sprint Review
Time box: 4 hours
Team presents “done” code to PO and stakeholders
Functionality not “done” is not shown
Feedback generated – Product Backlog maybe reprioritized
ScrumMaster sets next Sprint Review
33

Sprint Retrospective
Time box: 3 hours
Participants
ScrumMaster
Scrum Team.
Product Owner is optional
Questions
What went well and what can be improved?
ScurmMaster helps the team in discovery – not provide answers
34

Sprint Backlog
A kind o f To-do list for a Sprint
Created by the Scrum Team (can be originated by one member, responsibility belongs to another)
Product Owner has defined as highest priority
Used for synchronizing works between team members
35

Sprint Backlog examples
36
“digital” Sprint Backlog
“analog” Sprint Backlog >>

The Burn-down Chart
37
Burndown Chart shows the Sprint trend,
the performancevelocity of the team through Sprints

Potentially Shippable Product
Selected items are fully implemented, tested and ready for use
Small but complete, “it will be bigger”
Scrum Team needs to define what does “done” mean, in what aspects and contexts.
“DONE” may be executable, “passed all tests”, “approved by senior engineers”, “reviewed by peers” or just nothing to do more with the item.
38

Distributed Scrum
Isolated Scrums - Teams are isolated across geographies.
Distributed Scrum of Scrums –Scrum teams are isolated across geographies and integrated by a Scrum of
Totally Integrated Scrums – Scrum teams are cross-functional with members distributed across geographies.
39
Sutherland et al.

Top Distributed Scrum Issues
Difficult leveraging available resources, best practices are often deemed proprietary, are time consuming and difficult to maintain
Difficulty synchronizing work between distributed sites
Lack of effective communication mechanisms
Conflicting behaviors, processes, and technologies
Incompatible data formats, schemas, and standards
Ensuring electronic transmission confidentiality and privacy
Difficult to share values [Bas Vodde]
40
Sutherland et al.

eXtreme Programming
From hacking code to a real process
41

eXtreme Programming Project
42

XP Values
Simplicity
encourages starting with the simplest solution
Communication
favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback
Feedback
From the system, customer and from the team, to avoid optimism
Courage
design and code for today and not for tomorrow
Respect
respect for others as well as self-respect
43

44

XP Roles
The Customer
Sets project goals and makes business decisions
The Developer
Turn customer stories into working code
The Tracker
Keeps track of any metrics used by team
The Coach
Guides and mentors the team
45

Test Driven Development
Tests created before coding
Focus on quality
Not a complete development strategy
Derived version: Behavior-Driven Development (BDD)
46

TDD Rationale
47

TDD Strategy
You don’t start programming until you have designed your tests!
Strategy
Make it Fail
No code without a failing test
Make it Work
As simply as possible
Make it Better
Refactor(code, design, test, documentation)
Believe in testing
48

Acceptance TDD
3D strategy
Discuss in requirement workshop
To make tests library
Develop in concurrence
To create more Passed features
Deliver for acceptance
To meet DONE definition, accepted by users
49

Continuous Integration
Continuous integration (CI) implements continuous processes of applying quality control — small pieces of effort, applied frequently.
Supported by a CI system with lots of automated tests, builds and other generated artifacts.
Benefits:
Increases transparency
Increases cooperation and communication
Enables people to work on same code
50

CI System
51

Incremental Design
Flexible complex design on paper|CASE tool
Incremental Design (not simplistic)
52
Something unexpected always changes
Something unexpected always changes
More complexity than needed. Hard to maintain.
Easier to adopt. ID is easier to change. Less complexity

Pair Programming
A pair of developers shares a problem, a computer, a keyboard and a goal: solve the problem
PP was defined in XP
Utilize the R-mode activities
Improve communication and effectiveness
Improve software quality
Widely ADOPTED, but CONTROVERSAL!
2 roles: Driverand Navigator:
The Driver doesn’t see the big picture
The Driver should “step a way from the keyboard”
The Navigator tends to use pattern-matching problem solving technique
53

Refactoring
You practice “code a bit, fix a little” => result in dirty code & bad design.
Refactoring helps in restructure or design your code to make it better.
what does “better” mean?
Keep in mind:
Maintainability
Extensibility
High Cohesion
Low Coupling
54

Crystal Clear
“A human-Powered methodology for small team”
55

Crystal Clear Practices
Frequent Delivery
Reflective Improvement
Osmotic Communication
Personal Safety
Focus
Easy Access to Expert Users
Automated Tests
Configuration Management
Frequent Integration
56

Crystal Clear
“The team can reduce intermediate work products as it produces running code more frequently, as it uses richer communication channels between people.”
- Alistair Cockburn
57

Crystal Clear
Every product is slightly different and evolves over time, so the methodology, the set of conventions the team adopts, must be tuned and evolve.
- Alistair Cockburn
58

Crystal Clear Roles
Sponsor
Allocates money for the project
Expert User
Lead Designer
Lead Technical person, mentors less experienced team members
Designer-Programmer
Each person designs and programs
59

Kanban
Kanban literally means “visual card,” “signboard,” or “billboard.”
Toyota originally used Kanban cards to limit the amount of inventory tied up in “Work In Progress” on a manufacturing floor
60
…
Step 1
Done
Step 2
Step n
In
Process
In
Process
In
Process
Queue
Queue
Queue
…
Work Items

61
Why use Kanban in Software Development?

Time-boxed iterative development has challenges
Short time-boxes give more frequent opportunity to measure progress and inspect software but force development items to be smaller
Smaller development items are often too small to be valuable and difficult to identify
Quality of requirements suffers as analysts rush to prepare for upcoming cycles
Quality of current development suffers when busy analysts are unable to inspect software or answer questions during development
Quality often suffers as testers race to complete work late in the development time-box
62

The time-boxed iteration drama
63

64
Using a Kanban approach in software drops time-boxed iterations in favor of focusing on continuous flow.

Kanban queue
65
…
Done
Step 2
Step n
Work Items
Step 1
In
Process
In
Process
In
Process
Queue
Queue
Queue
…

Kanban queues (cont’d)
Large enough to keep the team busy
Small enough to avoid premature prioritisation
Ideally should be FIFO
66

Kanban - Work In Progress
Reduce multi-tasking
Maximize throughput
Enhances teamwork
67

The multitasking issues
Facts:
20% time lost to context switching per ‘task
Sequential yields results sooner
68
A
A
A
B
B
B
C
C
C
A
B
C
Chart courtesy of Yahoo!

Throughput
69
Organizational overhead goes up as work in progress increases
Total Cycle Time = Number of Things in Process
Average Completion Rate
to improve cycle time
Improve Average Completion Rate
Reduce Number of Things in Process

Enhances Teamwork
Team focus on goals that add value not individual tasks
70

Kanban Example 1
71
Image courtesy to Jeff Patton

Kanban Example 2
72

Kanban Example 3
73

Agile Mashup
It follows the Agile Manifesto and keeps the sprit of agility
It utilizes practices from several methods, for example:
Use sprint backlog and user stories with TDD and standup meeting with a kanban liked dashboard.
Use stand up meeting in daily Scrum
Use Burn down chart in Kanban
74

75
Agile Software Development - a cooperative game.
Alistair Cockburn

76
Paper
Face-to-face communication is better
2 people at
whiteboard
2 people
on phone
Communication Effectiveness
Videotape
2 people
on email
Richness of communication channel
Slide courtesy to Cockburn. A.

References and Further Readings
Agile Software Development: The Cooperative Game, 2ndEdn. By Alistair Cockburn.
Scrum Guide 2010 by Ken Schwaber and Jeff Sutherland
Agile Project Management with Scrum by Ken Schwaber
Agile Java Crafting Code with Test-Driven Development By Jeff Langr
Test-Driven Development in Microsoft .NET by James W. Newkirk and Alexei A. Vorontsov
Extreme Programming Explained by Kent Beck
XP introduction,
http://www.extremeprogramming.org/
http://xprogramming.com/
http://www.agilealliance.org/
Kanban Oversimplified
http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html
Ken Schwaber & Jeff Sutherland, Scrum Guide, Scrum.org
Pete Deemer, Gabrielle Benefield, Craig Larman & Bas Vodde, Scrum Primer, GoodAgile.com
HanoiScrum.net
AgileVietnam.org
ScrumAlliance.org
AgileAlliance.org
77

Q&A
78

79
Thank you!
Let’s Go Agile!
Sunday October 23rd 2011
FPT University, Innovation Building, Quang Trung Software City, District 12, HCMC, Vietnam

Agile methods

by Duong Tan

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Agile methods Presentation Transcript