intro to agile
DESCRIPTION
Introduction to what Agile development is, what it isn't, recommendations and the common pitfalls.TRANSCRIPT
Does this sound familiar?
• Do not Document• Do not handle and register Requirements• Do not do formalized testing• Do not plan more than 2 days in advance• Do not follow up on expenses and economy• Do not ____________________ (Fill in yourself)
• “We are doing Agile so we”:
From the movie “Clueless”
Same procedure as last year?
“Even a dead fish can float down a waterfall”
Can 9 women deliver a baby in 1 month?
• More developers on a project decreases developer efficiency – Communication overhead– More ceremony (Documents and Process)
• Close contact with product owner and business experts leads to effective developers
• Writing code typically only amounts to 30% of the total project time
Why Agile?• Focus on the Business and what they need• Focus on delivering quality• Doing the “right thing” – not just doing things right• Get feed-back often and act on it• Work on things that directly improves the end result• Minimize overhead
Do what we are paid for as Developers!
We need an Agile Machine!
Who?• Take 17 IT gurus:
– Kent Beck, Alistair Cockburn, Martin Fowler,…– Add them to a ski resort in Utah
• Let them simmer for 2 days:– February 11-13 2001
• You can now serve:– The Agile Manifesto, The Agile Principles– Agile Software Development Alliance
What? 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
According to the Oxford Dictionary• Agile
– “Able to move Quickly and Easily”– “Able to think Quickly and in an Intelligent way”
• Adaptive– “Concerned with Change”– “Able to change when necessary in order to deal
with different situations”
Can be?
Scrum
AGILE
Lean
Ste
rile
Un
ified
Pro
cess
XP
Virile
Confusing
eXtreme Programming (XP)
User DeveloperWhiteboard
Iteration Plan
Stories
Engineering Practices
XP Practices• The Planning Game• Small Releases• Metaphor• Simple Design• Testing• Refactoring
• Pair Programming• Collective Ownership• Continuous Integration• Normal work week• On-site Customer• Coding Standards
Scrum
Project Management Practices
Scrum Practices• Self managed teams• 30 days iterations, Sprints• Daily Scrum meetings• All participates in Planning• User Stories becomes Tasks• Customer on site
– Product Owner
• Tasks are not assigned but chosen• The Scrum Master is not “just”
project manager
• Estimates are made by those who will do the actual work
• All contact to the project is via the Scrum Master
• Teams on max 10 people• Everyone is in the same room• Use of Sprint and Product
Backlogs and burndown charts• “Pigs and Chickens”
How they compare?
XP
Scrum
Unified Process
Few DocumentsLittle Ceremony
Many DocumentsHigh Ceremony
Many short Iterations
Waterfall(One iteration)
CeremoniIterations
Source: Craig Larman: Agile & Iterative development, a managers guide
So, What’s next?
Please…..• Agile is not a solution. It’s a tool!
– Focus on your problems and how to solve them• There is no such thing as an Agile process!
– Agile is a way of thinking and not a product• You HAVE to work Iteratively to become Agile
– The only way to get feedback from our Customers• Trust in people
– Agile is Trust over Control
Pretty Please……..• Apply your learning's iteratively – It’s the least
expensive way• Pick the right tools for the right job• Use proper test approaches to ensure quality.
– This helps you discover when new learning’s break old assumptions
• Focus on importance and criticality
With sugar on top…….We need:• Smaller teams (5-10 people)• More skilled developers and managers• Close contact to Product owner and Business Experts• Higher level of Abstraction• High degree of Automation • Shorter feedback cycles• Make it cheaper to make mistakes and learn from it
Excerpts from a 3 hour seminar on how to fail with Agile and Iterative Development
Failing with Iterations• Waterfall iterations
– “Analysis iteration”, “Design Iteration”….• Remember to minimize technical risks early• A time box has a fixed length
– Max 1 month! Longer than that it’s no longer an iteration– Do not extend an iteration. Take things out!
• Done is Done!– Done is including TEST! No hidden work
• Changes are a part of the process. Not an exception
Failing on a Management level• Unclear goals. What are we trying to achieve?• Method = Product
– Buy a license and a consultant, then we are OK• Isolate Agile to one project alone• Going Agile is an iterative a process in itself• Use traditional follow-up and management
processes• You will NOT get pay-off from the day one
Failing on a larger scale• Agile affects the whole organization
– Users, business, management, test, deployment,..• Understand what you do. Try before dissing
– Scrum Buts: “We use Scrum, but……”• Be pragmatic and proactive
– Focus on results and not on following the book
What to do?• Communication, communication, …
– Make sure to involve people in the process– Listen, Learn and Adapt– Implement iteratively and actively by doing!
• Have realistic goals. Short and long term• Accept changes
– “Only 10% of what you worry about will ever happen”• Get professional help
How to supercharge AgilityA “radical” shift – to a larger degree of automation
Model Driven Development
Lean & Agile
Are both treatmenting Symptoms not providing a cure!
We can’t control everything
Rather than focus on being Agile which may lead to being successful, focus on being successful, which may lead you to being Agile