Agile Intro - Saint Louis Day of Dot Net
Upcoming SlideShare
Loading in...5
×
 

Agile Intro - Saint Louis Day of Dot Net

on

  • 2,371 views

Introduction to Agility from Saint Louis Day of Dot Net session:...

Introduction to Agility from Saint Louis Day of Dot Net session:
History, Definition, Comparison to Waterfall, Agile methodologies, Myths & Misconceptions, Common failure, & Advanced discussion points.

Statistics

Views

Total Views
2,371
Views on SlideShare
2,369
Embed Views
2

Actions

Likes
1
Downloads
73
Comments
0

1 Embed 2

http://www.slideshare.net 2

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

    Agile Intro - Saint Louis Day of Dot Net Agile Intro - Saint Louis Day of Dot Net Presentation Transcript

    • 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
    • Agenda
      Next ->
    • Quick History Lesson
      Where did agile come from?
    • 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 ->
    • 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 ->
    • 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 ->
    • Comparison to Waterfall
      Handling failure in an Agile world
    • 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 ->
    • 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 ->
    • 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
      • Change the plan
      • Feedback loop
      • Embrace improvement
      • More feedback
      • Continue to change slowly
      • Embrace failure early
      • Become responsive to change
      Next ->
    • What is Agile?
    • 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 ->
    • 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 ->
    • Agile Myths & Misconceptions
    • 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 ->
    • 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 ->
    • Agile Advantages
      Why Agile
    • 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 ->
    • 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 ->
    • 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 ->
    • 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 ->
    • 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 ->
    • Agile Shortcoming
      Why isn’t Agile everywhere
    • 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 ->
    • 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 ->
    • 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 ->
    • Life as an Agilist
      What can I expect?
    • 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 ->
    • 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 ->
    • 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 ->
    • Advanced Discussions / Comparisons
      Concepts that challenge traditional thinking
    • 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 ->
    • 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 ->
    • 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:
      • Embrace customer feedback
      • Applaud team member feedback
      • Openly accepting and encouraging feedback avoids the internal group think that kills products
      • Encourage feedback about the product & processes at the end of each iteration.
      • Work quickly to incorporate feedback
      Next ->
    • 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 ->
    • 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 ->
    • 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 ->
    • 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 ->
    • 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