Agile and Agile methods: what is the most important to understand to succeed
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 2,157 views

My presentation at Agile Tour 2010 Vilnius

My presentation at Agile Tour 2010 Vilnius

Statistics

Views

Total Views
2,157
Views on SlideShare
2,149
Embed Views
8

Actions

Likes
2
Downloads
78
Comments
0

2 Embeds 8

http://agilecoach.lt 7
http://static.slidesharecdn.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Goal to put to shelves, not to explain!!!
  • I agila projekt försöka man slippa undan commitmentsEn sprint i taget bara
  • Definition of Done
  • Never blame the tool!
  • Adform – we did it and we are Lithuanians!
  • Cousin story
  • It is not just simple Scrum rules or iterations
  • Define the goal, and measure against it!

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

  • 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 from
    Henrik Kniberg
    Mary Poppendieck
    Google
    ...
  • Agenda (0)
    Vaidas
  • Agenda (1)
    Agile
    Agile
    Agile
    Agile
  • Agenda (2)
    Scrum
    TDD
    XP
    Continuous Integration
    Kanban
    Refactoring
    Pair programming
    Lean
  • 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)
  • 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”
  • Magic word?
    Traditional Process and Statistics
    Agile
  • Traditional SW projects are like a cannon ball
    Assumptions:
    The customer knows what he wants
    The developers know how to build it
    Nothing will change along the way
  • We tend to build the wrong thing
    This graph courtesy of Mary Poppendieck
    The Biggest Opportunity to Increase Software Development Productivity is to Write Less Code!*
    *Mary Poppiendieck, “It’s Not About Working Software”, Agileee 2010 conference
    12
  • Maybe we are successfull?
    “The primary reason [for the improvement] is that projects have gotten a lot smaller.”
    “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.”
    Jim Johnson
    Chairman of
    Standish Group
    “There is no silver bullet but agile methods come very close”
    Sources:
    http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish
    http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
    ”My Life is Failure”, Jim Johnson’s book
    13
  • How about performance of Agile?
    Source: Dr. Dobb’s Journal 2008 Agile Adoption Survey
  • 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)
  • 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)
  • Problem 1
    Separation of design from implementation
    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 batchesof work (usually all project)
    “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”, 1981
    Start with short measurable business goals
    Incremental deliverables (real software, real value)
    Toyota Way
    Just In Time (JIT)
    Lean
    Agile
    ….
  • Agile
    Agile
    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 Beck
    Mike Beedle
    Arie van Bennekum
    Alistair Cockburn
    Ward Cunningham
    Martin Fowler
    James Grenning
    Jim Highsmith
    Andrew Hunt
    Ron Jeffries
    Jon Kern
    Brian Marick
    Robert C. Martin
    Steve Mellor
    Ken Schwaber
    Jeff Sutherland
    Dave Thomas
  • Agile Manifesto (1)
    ...we value:
    Individuals and interactions
    over processes and tools
    http://agilemanifesto.org/
  • Agile Manifesto (2)
    ...we value:
    Working software over comprehensive documentation
    http://agilemanifesto.org/
  • Agile Manifesto (3)
    ...we value:
    Customer collaboration over contract negotiation
    http://agilemanifesto.org/
  • Agile Manifesto (4)
    ...we value:
    Responding to changeoverfollowing a plan
    http://agilemanifesto.org/
  • 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
  • TDD
    XP
    Scrum
    Kanban
    Continuous Integration
    Refactoring
    Pair programming
    Lean
    What is all this stuff?
  • What is all this stuff?
    Practices
    Methods
    Agile
    XP
    Continuous Integration
    TDD
    Scrum
    Lean
    Pair programming
    Refactoring
    Kanban
    ...
    ...
  • Do not mix with time line
    Lean
    Scrum
    XP
    Test Driven Development (TDD)
    Pair programming
    Continues integration
    Refactoring
    Planning poker

    Agile
    Kanban

    Time
  • What is wrong here?
    Using the toolwrong
    Using the wrong tool
    Neither of these problems are caused by the tool!!!
  • More prescriptive
    More adaptive
    Different tools
    Scrum
    (9)
    Kanban
    (3)
    Do Whatever
    (0)
    XP
    (13)
    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
    • 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
    • Requirementsmanagement plan
    • Review record
    • Risk list
    • Risk management plan
    • Software architecturedocument
    • Software developmentplan
    • 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
    • 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
    Which one is better?
    Compare for understanding, not judgement!
  • Agile
    Practices
    Methods
    What is all this stuff?
    Summary
  • How to succeed?
  • We are NOT “different”
  • Respect People
  • Right Toolbox
  • Right Metrics
  • External help
  • Courage
  • Start NOW
  • Thank you!
    Let’s Scrum!
    v.adomauskas@gmail.com
    http://scrum.agile.lt
    Mob. Tel.: 860038860
    Facebook, Skype, LinkedIn…