Agile methods

Agile MethodsA brief guide to agile software development

Duong Trong [email protected] city, 9- 2011

mailto:[email protected]

A brief introduction to Agile Software Development

2

Objectives0 Software Engineering history & agile0 What is agile development?0 The Agile Manifesto0 The diversity of methods

0 Scrum0 XP0 RAD0 TDD0 Crystal0 Kanban

0 Agile mashup0 The cooperative game


3

Agile Basics“Agile projects succeed when the team gets the spirit of agility.”

– Ron Jeffries

Image courtesy of Pollyanna Pixton


4

Hyper productive

Earned Value Based

Iterative

Kaizen

Continuous improvement

Adaptive

Changes

Rapid

IncrementalLean

Small teams

Agile

Buzzwords


5

HistoryWeinberg: psychology of computer program

1970 1980 1990 2001 2011

Royce: managing the development of large software systems

deMarco: Peopleware

1995

Gilb: Principles of Software Engineering

RAD

Scrum

XP

DSDM

AgileAlliance.org

PMI developed agile certifications

Declaration of Independence

2005

1968

SE


6

So, what are software projects?


7

Partiesand ConcernsUsers?Customers?BO?Developers?


8

What is agile development?


9

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:

0 Individuals and interactions over processes and tools

0 Working software over comprehensive documentation

0 Customer collaboration over contract negotiation

0 Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

AgileAlliance.org


10

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


11

Home ground comparisonAgile Plan-driven Formal methods

• Low criticality• Senior developers• Requirements change often• Small number of developers• Culture that thrives on chaos

• High criticality• Junior developers• Requirements do not change often• Large number of developers• Culture that demands order

• Extreme criticality• Senior developers• Limited requirements, limited features• Requirements that can be modeled• Extreme quality


12

The diversity of methods

Methods

XP

Scrum

Crystal

Kanban

RAD

AgileUP


13

Rapid Application Development0 One of the earliest method0 A strategy instead of comprehensive process0 Utilizing of Prototyping0 “VB – Access Method”0 Still useful, esp. prototyping technique


14

Prototyping0 Early visibility of the

prototype gives users an idea of what the final system looks like

0 Encourages active participation among users and producer

0 Increases system development speed (in RAD)

0 Steps:1. Identify basic

requirements

2. Develop Initial Prototype

3. Review

4. Revise and Enhance the Prototype


15

ScrumA hyper-productive development model


16

Scrum

0 One of the most successful agile methods because of its hyper-productivity

0 It is management – oriented0 Somewhat CMM Level 3 equivalence0 Widely used in various types of projects

0 Google AdWorlds project0 3M0 Universities RnD projects0 In VN: LogiGear, KPM, FSOFT, FAT, etc.


17

Scrum Framework Scrum

Scrum Team

Scrum Events

Artifacts

Rules

Rules

Rule

s


18Image courtesy of ScrumAlliance


19

Scrum Roles0 Scrum Master0 Product Owner0 Development Team0 Other parties (all kinds of ‘chicken’)


20

Transition of roles0 Project Manager0 Tester0 Developer0 System Designer0 QA0 Graphic Designer Cross-functional Scrum Team


21

Management TransformationManagers 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


22

Transition of organization

Self-directed TeamMulti-functional

Team

0 Customer-driven0 Multi-skilled workforce0 Few job descriptions0 Information widely shared0 Few levels of management0 Whole-business focus0 Shared goals0 Seemingly chaotic0 Purpose achievement emphasis0 High worker commitment0 Continuous Improvements0 Self-controlled0 Values/Principles based

0 Management-driven0 Workforce of isolated specialists0 Many job descriptions0 Information limited0 Many levels of management0 Function/Department focus0 Segregated goals0 Seemingly organized0 Problem-solving emphasis0 High management commitment0 Incremental Improvements0 Management-controlled0 Policy/Procedure based


23

Development Team0 Team is cross-functional and consists of 5-9 people0 There are no set project roles within the team0 Team defines tasks and assignments0 Team is self-organizing and self-managing0 Maintains the Sprint Backlog0 Conducts the Sprint Review


24

ScrumMaster0 Holds Daily Scrum meeting0 Assures every people related to the project follow the

Scrum rules0 Removes obstacles0 Shields the team from external interference: “Keep

Chickens away from Pigs”0 Conducts Sprint Retrospective at the end of a Sprint0 Is a facilitator, not a manager


25

Product Owner (PO)0 Accountable for product success0 Defines all product features0 Responsible for ordering product features0 Maintains the Product Backlog0 Insures team working on highest valued features


26

Product Backlog0 List of all desired product features0 List can contain bugs, and non-functional items0 Product Owner responsible for ordering the items0 Items can be added by anyone at anytime0 Each item should have a business value assigned0 Maintained by the Product Owner


27

Examples of Product Backlog


28

A Sprint0 Time box: 2-4 weeks (why?)0 An iteration for building a piece of increment (potentially

shippable) of the whole system0 It’s the working time, not planning or asking what to do.0 The team manages itself during a Sprint0 The team commits to Product Backlog during the Sprint

planning meeting0 The Sprint Backlog is updated during a Sprint


29

Sprint BacklogImportance Item Name Notes How to test

Each item is prioritized and estimated


30

The Scrum Skeleton2. Daily Scrum Meeting What have you done?

What will you do?

What is impeding you?

1. Sprint Planning Meeting

3. A Sprint (2-4 weeks)

4. Sprint Review Meeting

5. Sprint Retrospective Meeting


31

Sprint Planning Meeting0 Time box: 8 hours

0 Product backlog prepared prior to meeting0 First Half

0 Team selects items committing to complete0 Additional discussion of Product Backlog occurs during

actual Sprint0 Second Half

0 Occurs after first half done – PO available for questions0 Team solely responsible for deciding how to build0 Tasks created / assigned – Sprint Backlog produced


32

Scrum Daily Meeting0 Held every day during a Sprint0 The most important inspection event in Scrum0 Timebox:15 minutes0 Team members talk to the whole Development Team, not Scrum

Master0 Asks 3 questions during meeting

0 “What have you done since last daily scrum?”0 “What will you do before the next daily scrum?”0 “What obstacles are impeding your work?”

0 Opportunity for team members to synchronize their work0 It helps removing burdens between members


33

Sprint Review0 Time box: 4 hours0 Team presents “done” code to PO and stakeholders0 Functionality not “done” is not shown0 Feedback generated – Product Backlog maybe

reprioritized0 ScrumMaster sets next Sprint Review


34

Sprint Retrospective0 Time box: 3 hours0 Participants

0 ScrumMaster0 Scrum Team. 0 Product Owner is optional

0 Questions0 What went well and what can be improved?

0 ScurmMaster helps the team in discovery – not provide answers


35

Sprint Backlog0 A kind o f To-do list for a Sprint0 Created by the Scrum Team (can be originated by one

member, responsibility belongs to another)0 Product Owner has defined as highest priority0 Used for synchronizing works between team members


36

Sprint Backlog examples

“digital” Sprint Backlog

“analog” Sprint Backlog >>


37

The Burn-down Chart

Burndown Chart shows the Sprint trend, the performance\velocity of the team through Sprints


38

Potentially Shippable Product0 Selected items are fully implemented, tested and ready

for use0 Small but complete, “it will be bigger”0 Scrum Team needs to define what does “done” mean, in

what aspects and contexts.0 “DONE” may be executable, “passed all tests”, “approved

by senior engineers”, “reviewed by peers” or just nothing to do more with the item.


39

Distributed Scrum0 Isolated Scrums - Teams are isolated across geographies. 0 Distributed Scrum of Scrums – Scrum teams are isolated

across geographies and integrated by a Scrum of0 Totally Integrated Scrums – Scrum teams are cross-

functional with members distributed across geographies.

Sutherland et al.


40

Top Distributed Scrum Issues0 Difficult leveraging available resources, best practices are

often deemed proprietary, are time consuming and difficult to maintain

0 Difficulty synchronizing work between distributed sites0 Lack of effective communication mechanisms0 Conflicting behaviors, processes, and technologies0 Incompatible data formats, schemas, and standards0 Ensuring electronic transmission confidentiality and privacy0 Difficult to share values [Bas Vodde] Sutherland et al.


41

eXtreme ProgrammingFrom hacking code to a real process


42

eXtreme Programming Project


43

XP Values0Simplicity

0 encourages starting with the simplest solution

0Communication0 favors simple designs, common metaphors, collaboration of users and

programmers, frequent verbal communication, and feedback

0Feedback0 From the system, customer and from the team, to avoid optimism

0Courage0 design and code for today and not for tomorrow

0Respect0 respect for others as well as self-respect


44


45

XP Roles

0The Customer0 Sets project goals and makes business decisions

0The Developer0 Turn customer stories into working code

0The Tracker0 Keeps track of any metrics used by team

0The Coach0 Guides and mentors the team


46

Test Driven Development

0Tests created before coding0Focus on quality0Not a complete development strategy0Derived version: Behavior-Driven

Development (BDD)


47

TDD Rationale


48

TDD Strategy0 You don’t start programming until you have designed

your tests!0 Strategy

0 Make it Fail0No code without a failing test

0 Make it Work0As simply as possible

0 Make it Better0Refactor(code, design, test, documentation)

0 Believe in testing


49

Acceptance TDD

3D strategy0 Discuss in requirement workshop

0 To make tests library0 Develop in concurrence

0 To create more Passed features0 Deliver for acceptance

0 To meet DONE definition, accepted by users


50

Continuous Integration0 Continuous integration (CI) implements continuous

processes of applying quality control — small pieces of effort, applied frequently.

0 Supported by a CI system with lots of automated tests, builds and other generated artifacts.

0 Benefits:0 Increases transparency0 Increases cooperation and communication0 Enables people to work on same code


51

CI System


52

Incremental Design0 Flexible complex

design on paper|CASE tool

0 Incremental Design (not simplistic)

• Something unexpected always changes

• Something unexpected always changes

0 More complexity than needed. Hard to maintain.

0 Easier to adopt. ID is easier to change. Less complexity


53

Pair Programming0 A pair of developers shares a

problem, a computer, a keyboard and a goal: solve the problem

0 PP was defined in XP0 Utilize the R-mode activities0 Improve communication and

effectiveness0 Improve software quality0 Widely ADOPTED, but

CONTROVERSAL!

02 roles: Driver and

Navigator:0 The Driver doesn’t see the big

picture0 The Driver should “step a way

from the keyboard”0 The Navigator tends to use

pattern-matching problem solving technique


54

Refactoring0 You practice “code a bit, fix a little” => result in dirty code

& bad design.0 Refactoring helps in restructure or design your code to

make it better. 0 what does “better” mean?

0 Keep in mind:0 Maintainability0 Extensibility0 High Cohesion0 Low Coupling


55

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


56

Crystal Clear Practices0Frequent Delivery0Reflective Improvement0Osmotic Communication0Personal Safety0Focus0Easy Access to Expert Users0Automated Tests0Configuration Management0Frequent Integration


57

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


58

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


59

Crystal Clear Roles

0 Sponsor0 Allocates money for the project

0 Expert User0 Lead Designer

0 Lead Technical person, mentors less experienced team members

0 Designer-Programmer0 Each person designs and programs


60

Kanban0 Kanban literally means “visual card,”

“signboard,” or “billboard.” 0 Toyota originally used Kanban cards to limit the

amount of inventory tied up in “Work In Progress” on a manufacturing floor

Work Items

…

Step 1 DoneStep 2 Step n…

QueueIn

Process QueueIn

Process QueueIn

Process


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


63

The time-boxed iteration drama


64

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

flow.


65

Kanban queue

…

Step 1 DoneStep 2 Step n…Work Items

QueueIn

Process QueueIn

Process QueueIn

Process


66

Kanban queues (cont’d)

0Large enough to keep the team busy0Small enough to avoid premature

prioritisation0Ideally should be FIFO


67

Kanban - Work In Progress

0Reduce multi-tasking0Maximize throughput0Enhances teamwork


68

The multitasking issues0 Facts:

0 20% time lost to context switching per ‘task0 Sequential yields results sooner

Chart courtesy of Yahoo!

A AA

A

B BB CCC

B C


69

Throughput0 Organizational overhead goes up as

work in progress increases

Total Cycle Time = Number of Things in Process Average Completion Rate

to improve cycle timeImprove Average Completion RateReduce Number of Things in Process


70

Enhances TeamworkTeam focus on goals that add value not

individual tasks


71

Kanban Example 1

Image courtesy to Jeff Patton


72

Kanban Example 2


73

Kanban Example 3


74

Agile Mashup

0 It follows the Agile Manifesto and keeps the sprit of agility

0 It utilizes practices from several methods, for example:0 Use sprint backlog and user stories with TDD and standup

meeting with a kanban liked dashboard.0 Use stand up meeting in daily Scrum0 Use Burn down chart in Kanban


75

Agile Software Development - a cooperative game.

Alistair Cockburn

76

Face-to-face communication is better


Richness of communication channel

Com

mun

icat

ion

Effe

ctiv

enes

s

2 people atwhiteboard

2 people on phone

2 peopleon email

Videotape

Paper

Slide courtesy to Cockburn. A.


77

References and Further Readings

0 Agile Software Development: The Cooperative Game, 2nd Edn. By Alistair Cockburn.0 Scrum Guide 2010 by Ken Schwaber and Jeff Sutherland0 Agile Project Management with Scrum by Ken Schwaber 0 Agile Java Crafting Code with Test-Driven Development By Jeff Langr0 Test-Driven Development in Microsoft .NET by James W. Newkirk and Alexei A. Vorontsov 0 Extreme Programming Explained by Kent Beck 0 XP introduction,

0 http://www.extremeprogramming.org/ 0 http://xprogramming.com/

0 http://www.agilealliance.org/ 0 Kanban Oversimplified

0 http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html 0 Ken Schwaber & Jeff Sutherland, Scrum Guide, Scrum.org0 Pete Deemer, Gabrielle Benefield, Craig Larman & Bas Vodde, Scrum Primer, GoodAgile.com

0 HanoiScrum.net0 AgileVietnam.org0 ScrumAlliance.org0 AgileAlliance.org

http://www.extremeprogramming.org/

http://xprogramming.com/

http://www.agilealliance.org/

http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html

78

Q&A


79A brief introduction to Agile Software Development

Thank you!

Let’s Go Agile!

Sunday October 23rd 2011

FPT University, Innovation Building, Quang Trung Software City, District 12, HCMC,

Vietnam

Technology

Agile methods