Your SlideShare is downloading. ×
Agile intro stldodn2009
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile intro stldodn2009

977
views

Published on

Basic introduction to Agile Methodology from the 2009 Saint Louis Day of Dot Net. Supplement to 2010 STLDODN Presentation for newcomers to the agile methodology

Basic introduction to Agile Methodology from the 2009 Saint Louis Day of Dot Net. Supplement to 2010 STLDODN Presentation for newcomers to the agile methodology

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
977
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Basic Stretches
    An introduction to Agility
    Brian Blanchard
    Interim CIO / Executive Consultant
    Lagovent / Lagovent Ventures
    Email: Brian@devrevival.com
    Blog: www.devrevival.com
    Bio: www.brian-blanchard.com
  • 2. Agenda
    Next ->
  • 3. Quick History Lesson
    Where did agile come from?
  • 4. History Lesson (pre-1970)
    Wild West for fortune 500 companies
    Our forefathers are Geeks Nerds
    Challenged cultural norms
    Didn’t merge with the business - Impossible to manage
    Inconsistent completion rates
    They failed regularly:
    80 – 90% Failure rate
    Next ->
  • 5. History Lesson (1970 – Today)
    Waterfall:
    Serial method of software management created by
    Winston Royce
    Goal:
    Mold dev. into a manufacturing model
    Produce consistent, manageable outputs
    Control the geeks
    Create development assembly lines
    Outcome:
    Major increases in productivity
    Failure dropped to 70% failure!!!
    Fatal Flaw
    Does not handle change well
    Next ->
  • 6. History Lesson (1999 – Future)
    Agile:
    Roots in Japanese models for efficiency
    Lean, Kanban, Kaizan, etc…
    Iterative methods in production took root in IT
    Goal
    Treat dev. like a Product Development/R&D unit
    Allow developers to lead development
    Accept that IT is as much art as it is science
    Demonstrate that the future of IT is found in its ability to drive change
    Outcome
    Increased productivity
    Failure rate decreased to 24% in many studies.
    More manageable code bases
    Average Agile codebase is 20 - 40% smaller than similar waterfall products
    Increase in developer retention
    Engaged development teams are happier
    Increased business value
    30 – 50 % reduction in time to market
    200% increase in innovation & tech. capability
    Next ->
  • 7. Comparison to Waterfall
    Handling failure in an Agile world
  • 8. Reason for Waterfall Failure
    Moore’s Law: The number of transistors on a chip doubles every 24 months
    Universal Law: Change
    Assumptions
    Facts (Moore’s Law & Universal Law)
    Requirements are perfect
    Tech. is stable, mature, well known
    All new or unknown challenges are solved before dev. begins.
    Repetition of a known process.
    Application development aims to hit a fixed target
    Customer demand grows
    Tech. capabilities grow
    New platforms create new challenges & opportunities throughout dev. cycles
    Dev. strive to automate anything repetitious
    Application development is a moving target based on market demand and growth
    Next ->
  • 9. 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
    Working software
    Customer collaboration
    Responding to change
    Processes and tools
    Comprehensive documentation
    Contract negotiation
    Following a plan
    over
    Next ->
  • 10. Handling Change
    Agile
    Change is good
    Waterfall
    The team failed
    Central belief:
    Common project risks
    Poor/changed Conclusions
    App doesn’t meet need
    Plans are incorrect/changed
    Takes too long – cost too much
    Process Failure
    Scope creep, comm. failures, etc…
    Repeat Process Failure
    Continued process issues
    Development Failure
    Poor quality, doesn’t work as expected, doesn’t work at all.
    More analysis
    Create more plans
    Add processes
    More meetings
    Buy tools
    Manage processes
    Terminate
    24% of waterfall projects are terminated
    • Involve the customer
    • 11. Change the plan
    • 12. Feedback loop
    • 13. Embrace improvement
    • 14. More feedback
    • 15. Continue to change slowly
    • 16. Embrace failure early
    • 17. Become responsive to change
    Next ->
  • 18. What is Agile?
  • 19. What is Agile?
    Change:
    It is change, continuing change, inevitable change that is the dominant factor in society today. No sensible decision can be made without taking it into account. …Isaac Asimov
    Agile is a conceptual framework that supports & is defined by several methodologies. All of which exist to steer change.
    Common attributes:
    Embrace change throughout the development cycle
    Iterative or incremental development - Timeboxing
    Focus is placed on creating working products
    Product creation is driven by the customer
    Work is completed by collaborative, self-organized teams
    General focus:
    Producing business value rapidly
    Lean thinking to remove waste and improve the journey
    Next ->
  • 20. What is Agile? – Agile Methodologies
    Scrum
    Prioritized backlog
    Daily standup meetings
    Demo after each iteration
    Correct the process through lessons learned
    XP
    Communication, simplicity, feedback, and courage
    Requires TDD, refactoring, pair programming, continuous integration, open workspaces, and automated acceptance tests
    Lean
    Move closer to customer
    Shorter cycles
    Eliminate waste
    Decisions are made at the last responsible moment
    Empower the team
    build in integrity
    Next ->
  • 21. Agile Myths & Misconceptions
  • 22. Agile Myths & Misconceptions
    Agile means no structure & no management
    Agile’s structure is well defined and easily managed
    Agile means no discipline
    Agile developers must be more disciplined to succeed
    Agile is ad-hoc, we have no plan
    Agile does not support development without planning
    Agile does infuse flexibility into the plan
    Agile creates degraded code bases that are destined for collapse
    In Agile, quality is a way of life not an after thought
    Code ownership throughout the team creates higher quality code
    Next ->
  • 23. Agile Myths & Misconceptions
    Agile is all about paired development
    Some methodologies employ paired dev. techniques to improve quality, but that does not summarize Agile
    Agile is a cult / religion
    Agile is a proven methodology supported by more than statistics collective for more than a century. All of which demonstrate consistent, improvement metrics.
    Employing Agile or other lean management methodologies should be done as a part of a planned, calculated strategy to improve productivity and sustainability.
    Next ->
  • 24. Agile Advantages
    Why Agile
  • 25. Agile Advantages – Iterative Release Cycles
    Smaller batches
    Higher quality
    Increased feedback
    Ease of adjustment
    Increased customer satisfaction
    Frequent releases
    Reduced time to market
    Regular regression testing
    Better team collaboration
    Avoids release based conflicts
    Gauge true value faster
    Compatible with Moore’s Law and Universal Laws of Change
    Next ->
  • 26. Agile Advantages – Increased business value
    Supports IT’s shift from old model People/Process/Technology to Value/People/Process
    Increase innovation
    Business leaders (Product Managers) guess what customers need
    Active customers know what they need
    Reduce IT investment
    Iterative releases allow business to test theories and adjust investments
    Focus on customer need reduces excessive features
    Next ->
  • 27. Agile Advantages – Increased quality
    Less Code / Less Defects:
    Industry average: 15 – 50 defects per 1,000 lines of code
    Agile creates more features with less code
    Code ownership
    Responsible owners write better code
    Cost of change curve
    Next ->
  • 28. Agile Advantages – Delayed technical decisions
    Absolutes are often false
    Uncertainty is acceptable
    Emergence is good
    Absolutes generate waste
    Delayed technical decisions
    Decisions based on absolutes are often poor decisions
    Avoid technical lock-in
    Creates additional options
    Mitigates risk
    Reduces complexity
    Reduces management responsibilities
    Steer technical improvement
    Rather than controlling & planning
    Next ->
  • 29. Agile Advantages – Increased visibility
    Stakeholders are peers in the team
    Unnecessary decisions are adverted
    Necessary decisions are made faster
    Iterative releases
    Clear examples of work completed / eliminates guest-imated completion times
    Visible examples of customer adoption during development
    Create check points to certify completion
    Stakeholders can steer the ship
    Rather than planning the course
    Next ->
  • 30. Agile Shortcoming
    Why isn’t Agile everywhere
  • 31. Agile Shortcomings – Lack of expertise
    Lack of expertise / Self proclaimed experts
    You wouldn’t build a plane without consulting an expert
    Why would you rebuild your organization without an expert
    Forrester 2008 Agile Survey
    33% using some form of Agile
    10% of “Agile” IT teams consider themselves “true practitioners”
    35% using a waterfall approach
    Organizations are more interested in optimizing their processes than defining or understanding them in the first place.
    New EDS ad.
    “We build planes in the sky”
    Next ->
  • 32. Agile Shortcomings – Corporate resistance
    Agile methodologies change the way business is conducted
    Agile requires a fusion of IT and Business practices
    Value / People / Process model
    “Customers” must be active in the development process
    At some point the Agile approach will appear to fail
    People will resist Agile
    Change without proper executive support/understanding will be quickly terminated
    Next ->
  • 33. Agile Shortcomings – Scalability concerns
    Enterprise Agile is a difficult concept
    Implementing a new methodology in the enterprise takes time
    Ex: IBM converted 25,000 developers to Agile
    Challenges:
    5 year completion (2002 – 2007)
    Several $million invested in the methodology conversion
    High degree of risk involved in this conversion
    Required support from several teams
    Executive sponsors
    Architecture committee
    Agile coaches
    Trust from business leaders
    Final result
    Net return of $4 per $1 invested
    400% ROI in 7 years
    ROI continues to grow
    Next ->
  • 34. Life as an Agilist
    What can I expect?
  • 35. Life as an agilistWhat can I expect?
    Before an Iteration:
    Iteration Planning:
    No specs / just user stories (feature requests)
    Discuss the stories with the customer or product
    Iteration planning can last a few hours
    Build a plan
    May include UML, white boarding, defining unit or functional tests, etc…
    Plans / Estimations:
    You will make some decisions w/ little information
    You may have to give rough estimates
    They will be wrong. It’s ok.
    You may have to learn a new way to estimate.
    Next ->
  • 36. Life as an agilistWhat can I expect?
    During an Iteration:
    Accountability:
    Meet with the team at least once a day
    5 minute standup meetings:
    What was completed today?
    What roadblocks need to be resolved?
    The team:
    Delivers code in rapid cycles.
    Possibly once a week.
    Get’R’Done mentality.
    Open to discussion (often working in “bullpens”)
    Development:
    Working features not partial tasks
    Quality is a way of life.
    Responsible code ownership
    Next ->
  • 37. Life as an agilistWhat can I expect?
    After an Iteration:
    Review:
    Show the customer
    Release the product
    New ideas
    Concerns
    The journey:
    Development is a journey not a destination
    Share lessons learned
    Help the team improve
    Improve the process
    Next ->
  • 38. Advanced Discussions / Comparisons
    Concepts that challenge traditional thinking
  • 39. Internal customers
    Business leaders/product managers
    Guess the needs of users
    Guesses may lead to adoption
    Guesses will bloat the application and increase complexity
    Requested features may produce revenue
    External/True customers
    Actual system users
    Understand their own needs
    Clear needs will lead to innovation
    Known needs will streamline the application
    Necessary features will produce revenue immediately
    Advanced Discussions – Who’s the customer
    Next ->
  • 40. Specs / Requirements
    10 or more pages
    Attempt to answer every question that could be asked about a feature.
    Very detailed
    Extensive technical details
    Limit creative input
    Serves internal customers
    User Stories
    3 – 5 sentences
    Attempt to explain the basic need at the highest level
    Only high level detail
    No technical details
    Maximize creative input
    Serves True customers
    Advanced Discussions – What are user stories?
    Sample User Story:
    Search for products. The user wants to view a list of products. The application asks the user to select attributes of a product (price, color, etc…). After the user specifies the search criteria, the application displays a list of products that match the desired attributes.
    Next ->
  • 41. Common misconceptions:
    We know our users…
    We know our product…
    No one can do it better than us…
    We are always right…
    We are good at writing code
    Fact:
    Your users needs change frequently
    The market’s impression of your product changes daily
    Right now, someone is building a new product that does it better
    You are likely wrong
    Every team can improve
    Advanced Discussions – Feedback loops
    • Solution:
    • 42. Embrace customer feedback
    • 43. Applaud team member feedback
    • 44. Openly accepting and encouraging feedback avoids the internal group think that kills products
    • 45. Encourage feedback about the product & processes at the end of each iteration.
    • 46. Work quickly to incorporate feedback
    Next ->
  • 47. Advanced Discussions – Testing
    Agile development does not allow for the quality control cycles seen in a typical waterfall development. It requires new methods for managing product quality.
    Old models:
    Testers are often second class citizens
    Testers write all tests
    Testing occurs in the last 10% of a project
    Defects caught downstream are costly and time consuming
    Only critical defects are addressed before release
    Agile models:
    Testers are always apart of the team
    Developers and testers partner to complete testing.
    I.E. TDD, Unit tests, & Test repositories
    Testing occurs prior to the completion of each iteration
    Defects caught early can be resolved quickly and easily
    I.E. Continuous integration & daily meetings
    All defects are accounted for prior to release
    Next ->
  • 48. Advanced Discussions – Estimation
    Estimates created by a group of direct contributors are more accurate than those from business leaders or IT managers.
    In Agile, you do not estimate time. Instead you estimate the size, complexity, or risk of a story. Overtime, a consistent velocity is established. The velocity per sprint will allow the scrum master to estimate time.
    Size Estimation techniques:
    Story points: Estimates are based on risk and complexity not time. The more complex or risky a request is, the more story points it will consume.
    Power of Two: Team members assign each user story a point value between 1 and 8. 2 is twice as complex or risky than 1. 4 is twice as risky as 2. 6 is twice as risky as 4. Etc…
    Scrum poker: The scrum team “votes” on the story points each user story will require. If the vote is not unanimous, the scrum master may decide to use the highest estimate. Some scrum masters will ask team members to discuss the story, followed by a revote. Usually in either scenario, the highest point value is used as the estimate.
    Next ->
  • 49. Advanced Discussions – Metrics
    To truly accept agile methodologies, you must accept that development does not adhere to old business models. It requires a new management model & new metrics.
    Key metrics:
    Earned value: A measurement of the value created for the business by a given feature, iteration, project, and/or product. Monitoring this metric at each level, after each iteration helps to correct misconceptions regarding adoption, revenue, usability, market presence, etc…
    Velocity: The amount of software a team can create in a given iteration. This is not an estimate of time, it is a gauge of forward motion. It is used to determine if the team can truly meet the commitments made during each iteration. It is also used to set iteration and release expectations.
    Burn Down: The measurement of the features completed over time. Demonstrates the amount of software created against the amount requested. Used to monitor development capacity.
    Burn Up: The measurement of features requested over time. Demonstrates the growth of the applications scope over time. In a waterfall project this is the dreaded “Scope Creep”. In Agile projects, this is applauded innovation. Used to monitor product growth.
    Next ->
  • 50. Advanced Discussions – Collective Code Ownership
    In an agile environment, the team owns the code.
    Effective Agile developers must let go of ego and share their code.
    Agile ownership rules:
    Anyone can make necessary changes anywhere
    Everyone is responsible for fixing problems they find
    Be a responsible owner of the code
    Re-factor dirty code
    Follow coding standards
    Apply naming conventions
    If you do not know the code base, partner with the product expert
    If the product expert does not exist, or is unavailable:
    Assume prior developers followed the rules of responsible code ownership
    Unit test everything you write – No Exceptions
    Next ->
  • 51. Questions & Answers
    Basic Stretches
    An introduction to Agility
    Brian Blanchard
    Interim CIO / Executive Consultant
    Lagovent / Lagovent Ventures
    Email: Brian@devrevival.com
    Blog: www.devrevival.com
    Bio: www.brian-blanchard.com

×