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


Disclaimer

• This is just my opinion and interpretation of information

• Use at your own risk ;)

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


Agenda (0)

Vaidas


Agile

Agenda (1)

Agile

Agile

Agile


Agenda (2)

Lean

XPScrumTDD

KanbanContinuous Integration

Pair

programming

Refactoring


Agenda (3)


ABOUT ME


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)

http://www.lavasoft.com/

http://www.adform.com/


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”

http://scrum.agile.lt/


MAGIC WORD?Traditional Process and Statistics

Agile


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


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


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


How about performance of Agile?

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

http://www.ambysoft.com/surveys/agileFebruary2008.html





Who is using it?


What about Lithuania?

?


MAGIC WORD?Early Software Engineering

Agile


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)

http://userweb.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html


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)

http://www.computer.org/portal/web/csdl/doi/10.1109/TC.1976.1674590


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


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


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• ….


AgileAgile

MAGIC WORD?Umbrella term


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


Agile Manifesto (1)

...we value:

Individuals and

interactions

over

processes and

tools http://agilemanifesto.org/

http://agilemanifesto.org/


Agile Manifesto (2)

...we value:

Working software

over

comprehensive documentation




Agile Manifesto (3)

...we value:

Customer collaboration

over

contract

negotiation




Agile Manifesto (4)

...we value:

Responding to change

over

following a plan




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


Agile

MAGIC WORD?Summary

Agile


WHAT IS ALL THIS STUFF?

Lean

XP Scrum

TDD

KanbanContinuous Integration

Pair

programming

Refactoring


Agile

What is all this stuff?

Lean

XP Scrum TDD

Kanban

Continuous Integration

Pair

programming

Refactoring

Methods Practices

... ...


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


What is wrong here?

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

Using the tool wrong Using the wrong tool


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


Agile

Methods Practices

WHAT IS ALL THIS STUFF?Summary


HOW TO SUCCEED?


We are NOT “different”


Respect People


Right Toolbox


Right Metrics


External help


Courage


Start NOW


[email protected]

http://scrum.agile.lt

Mob. Tel.: 860038860

Facebook, Skype, LinkedIn…

Let’s Scrum!

Thank you!

mailto:[email protected]

http://scrum.agile.lt/

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

Technology

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