Agile and Agile methods: what is the most important to understand to succeed

Post on 06-May-2015

1.863 views 1 download

description

My presentation at Agile Tour 2010 Vilnius

Transcript of Agile and Agile methods: what is the most important to understand to succeed

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agile and Agile methods: what is the most important to understand

to succeed

Vaidas Adomauskas

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Disclaimer

• This is just my opinion and interpretation of information

• Use at your own risk ;)

• Information and pictures fromo Henrik Knibergo Mary Poppendiecko Googleo ...

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agenda (0)

Vaidas

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agile

Agenda (1)

Agile

Agile

Agile

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agenda (2)

Lean

XPScrumTDD

KanbanContinuous Integration

Pair

programming

Refactoring

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agenda (3)

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

ABOUT ME

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

About me (1)

• VU MIF – Software Engineering(bachelor)

• IT University of Gothenburg – Master in Software Engineering and Management

• Lavasoft (www.lavasoft.com )

• Adform (www.adform.com)

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Apie mane (2)

• Certified Scrum Master (Ken Schwaber, Paris)

• Certified Product Owner (Robin Dymond ,Kiev)

• Agile Conferences

• http://scrum.agile.lt

• Lecturer at VU MIF “Agile Project Management with Scrum”

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

MAGIC WORD?Traditional Process and Statistics

Agile

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Traditional SW projects are like a

cannon ball

Assumptions:o The customer knows what

he wantso The developers know how

to build ito Nothing will change

along the way

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

We tend to build the wrong thing

The Biggest Opportunity to Increase Software Development Productivity is to Write Less

Code!*12

This graph courtesy of Mary Poppendieck

*Mary Poppiendieck, “It’s Not About Working Software”, Agileee 2010 conference

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Maybe we are successfull?

“Doing projects with iterative processes as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.”

“The primary reason [for the improvement] is that projects have gotten a lot smaller.”

Jim JohnsonChairman ofStandish Group

Sources:http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standishhttp://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS”My Life is Failure”, Jim Johnson’s book

“There is no silver bullet but agile methods come very close”

13

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

How about performance of Agile?

Source: Dr. Dobb’s Journal 2008 Agile Adoption Survey

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Who is using it?

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

What about Lithuania?

?

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

MAGIC WORD?Early Software Engineering

Agile

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Avoid bugs (1972)

• “Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with…

• … programmers… should not introduce the bugs to start with.”

Edsger W. Dijkstra, “The Humble Programmer”, 1972 (http://userweb.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html)

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

The Life Cycle Concept (1976)

• The biggest opportunity for cost reduction was finding errors as soon as possible:

Barry W. Boehm, “Software Engineering”, 1976 (http://www.computer.org/portal/web/csdl/doi/10.1109/TC.1976.1674590)

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Problem 1

• Separation of design from implementation

o Swartout and Balzer: “All current software methodologies have adopted a common model that separates specification from implementation. Unfortunately, this model is overly naïve, and does not match reality.”**Swartout and Balzer, “On the Inevitable Intertwining of Specification and Implementation”, 1982

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Problem 2

• Large batches of work (usually all project)

o “Large batches of work tend to queue up during each process step, and so defects are not detected at the point of insertion; they have to wait to be uncovered in a batch validation step”*Mary and Tom Poppiendieck, “Leading Lean Software development”, 2000

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Other opponents

• McCracken and Jackson, “Life Cycle Concept Considered Harmful”, 1982

• Tom Gilb, “Evolutionary Development”, 1981o Start with short measurable business goalso Incremental deliverables (real software, real

value)

• Toyota Way• Just In Time (JIT)• Lean• Agile• ….

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

AgileAgile

MAGIC WORD?Umbrella term

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agile Manifesto

www.agilemanifesto.org We are uncovering better ways of developing software by doing it and helping others do it.

Feb 11-13, 2001

Snowbird ski resort, Utah

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon Jeffries

Jon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agile Manifesto (1)

...we value:

Individuals and

interactions

over

processes and

tools http://agilemanifesto.org/

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agile Manifesto (2)

...we value:

Working software

over

comprehensive documentation

http://agilemanifesto.org/

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agile Manifesto (3)

...we value:

Customer collaboration

over

contract

negotiation

http://agilemanifesto.org/

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agile Manifesto (4)

...we value:

Responding to change

over

following a plan

http://agilemanifesto.org/

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agile projects are like a guided missile

Assumptions:• The customer discovers what

he wants• The developers discover how

to build it• Things change along the way

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agile

MAGIC WORD?Summary

Agile

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

WHAT IS ALL THIS STUFF?

Lean

XP Scrum

TDD

KanbanContinuous Integration

Pair

programming

Refactoring

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agile

What is all this stuff?

Lean

XP Scrum TDD

Kanban

Continuous Integration

Pair

programming

Refactoring

Methods Practices

... ...

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Do not mix with time line

• Lean• Scrum• XP

o Test Driven Development (TDD)o Pair programmingo Continues integrationo Refactoringo Planning pokero …

• Agile• Kanban• …

Tim

e

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

What is wrong here?

Neither of these problems are caused by the tool!!!

Using the tool wrong Using the wrong tool

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

More prescriptive More adaptive

Different tools

• Which one is better?

• Compare for understanding, not judgement!

XP(13)

Scrum(9)

Kanban(3)

Do Whatever(0)

RUP(120+)

• Architecture Reviewer• Business Designer• Business-Model Reviewer• Business-Process Analyst• Capsule Designer• Change Control Manager• Code Reviewer• Configuration Manager• Course Developer• Database Designer• Deployment Manager• Design Reviewer• Designer• Graphic Artist• Implementer• Integrator• Process Engineer• Project Manager• Project Reviewer• Requirements Reviewer• Requirements Specifier• Software Architect• Stakeholder• System Administrator• System Analyst• Technical Writer• Test Analyst• Test Designer• Test Manager• Tester• Tool Specialist• User-Interface Designer• Architectural analysis• Assess Viability of architectural

proof-of-concept• Capsule design• Class design• Construct architectural proof-of-

concept• Database design• Describe distribution• Describe the run-time architecture• Design test packages and classes• Develop design guidelines• Develop programming guidelines• Identify design elements• Identify design mechanisms• Incorporate design elements• Prioritize use cases• Review the architecture• Review the design• Structure the implementation model• Subsystem design• Use-case analysis• Use-case design• Analysis model• Architectural proof-of-concept• Bill of materials• Business architecture document• Business case• Business glossary• Business modeling guidelines• Business object model• Business rules• Business use case

• Whole team• Coding standard• TDD• Collective ownership• Customer tests• Pair programming• Refactoring• Planning game• Continuous integration• Simple design• Sustainable pace• Metaphor• Small releases

• Scrum Master• Product Owner• Team• Sprint planning meeting• Daily Scrum• Sprint review• Product backlogt• Sprint backlog• BUrndown chart

• Visualize the workflow• Limit WIP• Measure and optimize lead time

• Business use case realization• Business use-case model• Business vision• Change request• Configuration audit findings• Configuration management plan• Data model• Deployment model• Deployment plan• Design guidelines• Design model• Development case• Development-organization

assessment• End-user support mateirla• Glossary• Implementation model• Installation artifacts• Integration build plan• Issues list• Iteration assessment• Iteration plan• Manual styleguide• Programming guidelines• Quality assurance plan• Reference architecture• Release notes• Requirements attributes• Requirements

management plan• Review record• Risk list• Risk management plan• Software architecture

document• Software development

plan• Software requirements specification• Stakeholder requests• Status assessment• Supplementary business

specification• Supplementary specification• Target organization assessment• Test automation architecture• Test cases• Test environment configuration• Test evaluation summary• Test guidelines• Test ideas list• Test interface specification• Test plan• Test suite• Tool guidelines• Training materials• Use case model• Use case package• Use-case modeling guidelines• Use-case realization• Use-case storyboard• User-interface guidelines• User-interface prototype• Vision• Work order• Workload analysis model

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Agile

Methods Practices

WHAT IS ALL THIS STUFF?Summary

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

HOW TO SUCCEED?

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

We are NOT “different”

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Respect People

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Right Toolbox

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Right Metrics

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

External help

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Courage

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

Start NOW

Vaidas Adomauskaswww.agileturas2010.agile.lt2010-10-14

v.adomauskas@gmail.com

http://scrum.agile.lt

Mob. Tel.: 860038860

Facebook, Skype, LinkedIn…

Let’s Scrum!

Thank you!