Agile Software Development Overview

TurboBoost your development performance

1

SESSION 1 THE COOPERATIVE GAME

AgileDev Tour

Duong Trong TanHanoi, December 2010


2

Objectives

Software Engineering trendsWhat is agile development?The agile manifestoThe diversity of adoptions

Scrum XP TDD Crystal Kanban

Agile mashupThe cooperative game


3

“AGILE PROJECTS SUCCEED WHEN THE TEAM GETS THE SPIRIT OF AGILITY.”

– R O N J E F F R I E S

AgileDev Basics

Image courtesy to Pollyanna Pixton

TurboBoost your development performance 4

Hyper productive

Earned Value Based

Iterative

Kaizen

Continuous improvement

Adaptive

Changes

Rapid

IncrementalLean

Small teams

Agile


5

About Trends

Agile techniques were in use since the beginning.Agile techniques did not show competitive

advantage in the 1970s / 1980s, but did during the 1990s and do now.Trial runs of current agile methodologies, 1993 -

1995RAD Crystal XP Crystal Scrum Kanban

In chaos, there are special kinds of controlled pattern => agile methods.


So, what are software projects?

7


Partiesand Concerns

Users?

Customers?

BO?

Developers?


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:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

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

AgileDev Plan-driven

Low criticalitySenior developersObjectives change

very oftenSmall number of

developersCulture that thrives

on chaos

High criticalityJunior developersLow objectives

changeLarge number of

developersCulture that

demands order

Home ground comparison


12

The diversity of methods

Methods

XP

Scrum

Crystal

Kanban

RAD

YAADM


13

A HYPER-PRODUCTIVE DEVELOPMENT MODEL

Scrum


14

Scrum

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

It is management – orientedSomewhat CMM Level 3 equivalenceWidely used in various types of projects

Google AdWorlds project 3M Universities RnD projects In VN: LogiGear, KPM, FSOFT, FAT, etc.

TurboBoost your development performance 15Image courtesy to ScrumAlliance


16

Scrum Roles

ScrumMasterProductOwnerScrum TeamOther parties (all kinds of chicken)


17

Scrum Team

Team is cross-functional and consists of 5-9 people

There are no set project roles within the teamTeam defines tasks and assignmentsTeam is self-organizing and self-managingMaintains the Sprint BacklogConducts the Sprint Review


18

ScrumMaster

Holds daily 15 minute team meeting (Daily Scrum)

Assures every people related to the project follow the rules

Removes obstaclesShields the team from external interference:

“Keep Chickens away from Pigs”Maintains the Sprint Burndown ChartConducts Sprint Retrospective at the end of a

SprintIs a facilitator, not a manager


19

Product Owner (PO)

Accountable for product successDefines all product featuresResponsible for prioritizing product featuresMaintains the Product BacklogInsures team working on highest valued

features


20

The Product Backlog

List of all desired product featuresList can contain bugs, and non-functional

itemsProduct Owner responsible for prioritizingItems can be added by anyone at anytimeEach item should have a business value

assignedMaintained by the Product Owner


21

A Sprint

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

(potentially shippable) of the whole systemIt’s the working time, not planning or asking

what to do.The team manages itself during a SprintThe team commits to Product Backlog during

the Sprint planning meetingThe Sprint Backlog is updated during a

Sprint


22

The Sprint Backlog

Each item is prioritized and estimated

Importance Item Name Notes How to test


2. 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

The Scrum Skeleton


24

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 SprintSecond Half

Occurs after first half done – PO available for questions

Team solely responsible for deciding how to build Tasks created / assigned – Sprint Backlog produced


25

Scrum Daily Meeting

Held every day during a SprintTimebox:15 minutesTeam members report to each other not Scrum

MasterAsks 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


26

Sprint Review

Time box: 4 hoursTeam presents “done” code to PO and

stakeholdersFunctionality not “done” is not shownFeedback generated – Product Backlog

maybe reprioritizedScrumMaster sets next Sprint Review


27

Sprint Retrospective

Time box: 3 hoursParticipants

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


28

The Sprint Backlog

A kind o f To-do list for a SprintCreated 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


29

The Burn-down Chart

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


30

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.


31

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.

Sutherland et al.


32

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 mechanismsConflicting behaviors, processes, and technologiesIncompatible data formats, schemas, and

standardsEnsuring electronic transmission confidentiality

and privacy

Sutherland et al.


33

FROM HACKING CODE TO A REAL PROCESS

eXtreme Programming


34

eXtreme Programming Project


35

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


37

XP Roles

The CustomerSets project goals and makes business decisions

The DeveloperTurn customer stories into working code

The TrackerKeeps track of any metrics used by team

The CoachGuides and mentors the team


Test Driven Development

This is not a complete dev strategy. It is ‘embedded’ into methods.

Tests created before coding

This strategy focused on quality

Derived version: Behaviors Driven Development


39

“A HUMAN-POWERED METHODOLOGY FOR SMALL TEAM”

Crystal Clear


40

Crystal Clear Practices

Frequent DeliveryReflective ImprovementOsmotic CommunicationPersonal SafetyFocusEasy Access to Expert UsersAutomated TestsConfiguration ManagementFrequent Integration


41

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


42

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


43

Crystal Clear Roles

Sponsor Allocates money for the project

Expert UserLead Designer

Lead Technical person, mentors less experienced team members

Designer-Programmer Each person designs and programs


44

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

Work Items

…

Step 1 DoneStep 2 Step n…

QueueIn

Process

QueueIn

Process

QueueIn

Process


Why use Kanban in Software Development?


Time-boxed iterative development has challenges 46

• 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


47

The time-boxed iteration drama


Using a Kanban approach in software drops time-

boxed iterations in favor of focusing on continuous

flow.


49

Kanban queue

…

Step 1 DoneStep 2 Step n…Work Items

QueueIn

Process

QueueIn

Process QueueIn

Process


50

Kanban queues (cont’d)

Large enough to keep the team busy

Small enough to avoid premature prioritisation

Ideally should be FIFO


51

Kanban - Work In Progress

Reduce multi-taskingMaximize throughputEnhances teamwork


52

The multitasking issues

Facts: 20% time lost to context switching per ‘task Sequential yields results sooner

Chart courtesy to Yahoo!

A AA

A

B BB CCC

B C


53

Throughput

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


54

Enhances Teamwork

Team focus on goals that add value not individual tasks


55

Kanban Example 1

Image courtesy to Jeff Patton


56

Kanban Example 2


57

Kanban Example 3


58

Agile Mashup

It is so-called Yet Another Agile Development Method (YAAM)

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


Agile Software Development, it is a cooperative game.


60

Face-to-face communication is better

Richness of communication channelCom

mu

nic

ati

on

Eff

ect

iven

ess

2 people atwhiteboard

2 people on phone

2 peopleon email

Videotape

Paper

Slide courtesy to Cockburn. A.


61

References and Further Readings

Agile Software Development: The Cooperative Game, 2nd Edn. 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

http://www.extremeprogramming.org/

http://xprogramming.com/

http://www.agilealliance.org/

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

Agile Software Development Overview

Education

Transcript of Agile Software Development Overview