Agile intro stldodn2009

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