Agile and Agile methods: what is the most important to understand to succeed
-
Upload
vaidas-adomauskas -
Category
Technology
-
view
1.867 -
download
1
description
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
http://scrum.agile.lt
Mob. Tel.: 860038860
Facebook, Skype, LinkedIn…
Let’s Scrum!
Thank you!