agile intro - saint louis day of dot net
DESCRIPTION
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.TRANSCRIPT
Basic Stretches
An introduction to Agility
Brian BlanchardInterim CIO / Executive
ConsultantLagovent / Lagovent Ventures
Email: [email protected]: www.devrevival.comBio: 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:
o 80 – 90% Failure rate
Next ->
History Lesson (1970 – Today)
Waterfall:o Serial method of software management created by
Winston Royce
o Goal: • Mold dev. into a manufacturing model• Produce consistent, manageable outputs• Control the geeks• Create development assembly lines
o Outcome:• Major increases in productivity• Failure dropped to 70% failure!!!
o Fatal Flaw• Does not handle change well
Next ->
History Lesson (1999 – Future) Agile:
o Roots in Japanese models for efficiency• Lean, Kanban, Kaizan, etc…
o Iterative methods in production took root in IT
o 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
o 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.
capabilityNext ->
Comparison to Waterfall
Handling failure in an Agile world
Reason for Waterfall Failure
Assumptions
• 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
Facts (Moore’s Law & Universal Law)
• 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
Moore’s Law: The number of transistors on a chip doubles every 24 monthsUniversal Law: Change
Next ->
Agile Manifesto
• Individuals and interactions• Working software • Customer collaboration• Responding to change
• Processes and tools • Comprehensive
documentation• Contract negotiation • Following a plan
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value
over
Next ->
Handling ChangeCentral 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.
WaterfallThe team failed
• More analysis
• Create more plans
• Add processes– More meetings
• Buy tools – Manage
processes
• Terminate– 24% of waterfall
projects are terminated
AgileChange is good
• 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:o 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:o Embrace change throughout the development cycleo Iterative or incremental development - Timeboxingo Focus is placed on creating working productso Product creation is driven by the customero Work is completed by collaborative, self-organized teams
General focus:o Producing business value rapidlyo Lean thinking to remove waste and improve the journey
Next ->
What is Agile? – Agile Methodologies
Scrumo Prioritized backlogo Daily standup meetingso Demo after each iterationo Correct the process through lessons learned
XPo Communication, simplicity, feedback, and courageo Requires TDD, refactoring, pair programming, continuous integration, open workspaces,
and automated acceptance tests Lean
o Move closer to customero Shorter cycleso Eliminate wasteo Decisions are made at the last responsible momento Empower the teamo build in integrity
Next ->
Agile Myths & Misconceptions
Agile Myths & Misconceptions
Agile means no structure & no managemento Agile’s structure is well defined and easily
managed
Agile means no disciplineo Agile developers must be more disciplined to
succeed
Agile is ad-hoc, we have no plano Agile does not support development without
planningo Agile does infuse flexibility into the plan
Agile creates degraded code bases that are destined for collapseo In Agile, quality is a way of life not an after
thoughto Code ownership throughout the team creates
higher quality codeNext ->
Agile Myths & Misconceptions
Agile is all about paired developmento Some methodologies employ paired dev.
techniques to improve quality, but that does not summarize Agile
Agile is a cult / religiono Agile is a proven methodology supported by
more than statistics collective for more than a century. All of which demonstrate consistent, improvement metrics.
o 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 batcheso Higher qualityo Increased feedbacko Ease of adjustmento Increased customer
satisfaction
Frequent releaseso Reduced time to marketo Regular regression testingo Better team collaborationo Avoids release based conflicts o 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 o Business leaders (Product Managers)
guess what customers needo Active customers know what they need
Reduce IT investmento Iterative releases allow business to test
theories and adjust investmentso Focus on customer need reduces
excessive features
Generate Value36%
Rarely used19%
Never used45%
Standish Group CHAOS Study
Next ->
Agile Advantages – Increased quality
Less Code / Less Defects:o Industry average: 15 – 50 defects per 1,000 lines of codeo Agile creates more features with less code
Code ownershipo Responsible owners write better code
Cost of change curve
Next ->
Agile Advantages – Delayed technical decisions
Absolutes are often falseo Uncertainty is acceptableo Emergence is goodo Absolutes generate waste
Delayed technical decisionso Decisions based on absolutes are
often poor decisionso Avoid technical lock-ino Creates additional optionso Mitigates risko Reduces complexityo Reduces management
responsibilities Steer technical improvement
o Rather than controlling & planning
Next ->
Agile Advantages – Increased visibility Stakeholders are peers in the
teamo Unnecessary decisions are
advertedo Necessary decisions are made
faster
Iterative releaseso Clear examples of work completed
/ eliminates guest-imated completion times
o Visible examples of customer adoption during development
o Create check points to certify completion
Stakeholders can steer the ship o Rather than planning the course
Next ->
Agile Shortcoming
Why isn’t Agile everywhere
Agile Shortcomings – Lack of expertise
Lack of expertise / Self proclaimed expertso You wouldn’t build a plane without consulting an experto Why would you rebuild your organization without an expert
Forrester 2008 Agile Surveyo 33% using some form of Agile
• 10% of “Agile” IT teams consider themselves “true practitioners”o 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”
"Agile"30%
True Agile3%
Waterfall35%
Other32%
Methodologies
Next ->
Agile Shortcomings – Corporate resistance Agile methodologies change the way business
is conducted
Agile requires a fusion of IT and Business practiceso 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
o 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
o 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 agilist What can I expect?
Before an Iteration: Iteration Planning:
o No specs / just user stories (feature requests)
o Discuss the stories with the customer or product
o Iteration planning can last a few hours
o Build a plan• May include UML, white boarding,
defining unit or functional tests, etc…
Plans / Estimations:o You will make some decisions w/
little informationo You may have to give rough
estimates• They will be wrong. It’s ok.
o You may have to learn a new way to estimate.
Next ->
Life as an agilist What can I expect?
During an Iteration: Accountability:
o Meet with the team at least once a dayo 5 minute standup meetings:
• What was completed today? • What roadblocks need to be
resolved?
The team: o Delivers code in rapid cycles. o Possibly once a week. o Get’R’Done mentality.o Open to discussion (often working in
“bullpens”)
Development:o Working features not partial taskso Quality is a way of life.o Responsible code ownership
Next ->
Life as an agilist What can I expect?
After an Iteration: Review:
o Show the customero Release the producto New ideaso Concerns
The journey:o Development is a
journey not a destination
o Share lessons learnedo Help the team improveo Improve the process
Next ->
Advanced Discussions / Comparisons
Concepts that challenge traditional thinking
Internal customerso Business leaders/product
managers o Guess the needs of userso Guesses may lead to adoptiono Guesses will bloat the application
and increase complexityo Requested features may produce
revenue
External/True customerso Actual system userso Understand their own needso Clear needs will lead to
innovationo Known needs will streamline the
applicationo Necessary features will produce
revenue immediately
Advanced Discussions – Who’s the customer
Next ->
Specs / Requirementso 10 or more pages o Attempt to answer every
question that could be asked about a feature.
o Very detailedo Extensive technical detailso Limit creative inputo Serves internal customers
User Storieso 3 – 5 sentenceso Attempt to explain the basic
need at the highest levelo Only high level detailo No technical detailso Maximize creative inputo 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: o We know our users…
o We know our product… o No one can do it better than us…
o We are always right…
o We are good at writing code
Fact:o Your users needs change frequently
o The market’s impression of your product changes daily
o Right now, someone is building a new product that does it better
o You are likely wrong
o Every team can improve
Advanced Discussions – Feedback loops
Solution:o Embrace customer feedbacko Applaud team member feedbacko Openly accepting and encouraging feedback avoids the internal group think
that kills productso Encourage feedback about the product & processes at the end of each iteration.o 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: o Testers are often second class citizenso Testers write all testso Testing occurs in the last 10% of a projecto Defects caught downstream are costly and time
consumingo Only critical defects are addressed before release
Agile models:o Testers are always apart of the teamo Developers and testers partner to complete testing.
• I.E. TDD, Unit tests, & Test repositorieso Testing occurs prior to the completion of each
iterationo Defects caught early can be resolved quickly and
easily• I.E. Continuous integration & daily meetings
o 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:o 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.
o 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…
o 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:o 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…
o 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.
o 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.
o 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:o Anyone can make necessary changes anywhereo Everyone is responsible for fixing problems they findo Be a responsible owner of the code
• Re-factor dirty code • Follow coding standards • Apply naming conventions
o If you do not know the code base, partner with the product experto If the product expert does not exist, or is unavailable:
• Assume prior developers followed the rules of responsible code ownershipo Unit test everything you write – No Exceptions
Next ->
Questions & Answers
Basic StretchesAn introduction to Agility
Brian BlanchardInterim CIO / Executive
ConsultantLagovent / Lagovent Ventures
Email: [email protected]: www.devrevival.comBio: www.brian-blanchard.com