Guilt free agile development
Download
1 / 55

Guilt-Free Agile Development - PowerPoint PPT Presentation


  • 210 Views
  • Updated On :

Guilt-Free Agile Development Plan-Driven or Agile–Why Choose When You Can Have The Benefits of Both? John Manzo Managing Partner USC/CSE Research Review March 18, 2004 Topics Who Are We, And Why Might Our Perspective Be Of Value? The Limitations of Plan-Driven and Agile Methods

Related searches for Guilt-Free Agile Development

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Guilt-Free Agile Development' - Mia_John


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Guilt free agile development l.jpg

Guilt-Free Agile Development

Plan-Driven or Agile–Why Choose When You Can Have The Benefits of Both?

John ManzoManaging Partner

USC/CSEResearch Review

March 18, 2004


Topics l.jpg
Topics

  • Who Are We, And Why Might Our Perspective Be Of Value?

  • The Limitations of Plan-Driven and Agile Methods

  • A Brief Overview Of Agile+ - Best of Breed Practices from ADMs and Plan-Driven Approaches

  • Overcoming the Limitations of Agile Development – Preserving the Baby While Throwing Out The Bath Water

  • Wrap Up

  • Q & A


Agiletek company snapshot l.jpg
AgileTek Company Snapshot

  • A privately held professional services firm specializing in custom software development and software advisory and training services

  • Decades of experience

  • Comprised of distinguished software professionals

  • Led by a highly experienced management team

  • Conveniently located in Chicago (Just a 5-minute drive from O’Hare Airport)

  • Financially stable and profitable

    • No debt

    • No investors


Agiletek company details l.jpg
AgileTek Company Details

  • We were early pioneers in Agile Development and among its first practitioners (our first eXtreme Programming project was conducted prior to Kent Beck even publishing his first book on XP)

  • We've also continuously refined our agile development methodology over the past six years... based on learning from real-world projects across a broad spectrum of application domains

  • AgileTek tends to work with clients that are developing new products with dynamic and changing requirements where time to market and the need for tight user feedback loops are critical factors


Agiletek s service offerings l.jpg
AgileTek’s Service Offerings

  • Custom Software Development and Co-Development

  • Advisory Services

    • Agile+ ,Agile, and Hybrid Development Consulting

    • Architecture Evaluation/Development

    • Project Risk-Based Assessments

    • Project Health Checks and Monitoring

    • Project Turnarounds/Rejuvenation

    • Software Size-Time-Effort Estimation

    • All-Aspect Software Development Environment Evaluation

    • Software Engineering Management

    • Managing Complex Systems Development

  • Training/Workshops

    • Managing Complex Systems Development

    • The Power of Architecture

    • Pre-Launch/Re-Launch Workshops

    • Custom Tailored Courses


Why clients engage agiletek l.jpg
Why Clients Engage AgileTek

  • Accelerate time to market

    • One of the highest productivity indices (PI) in our industry

    • Average of 35 LOCs per coding hour

  • Ability to accommodate change at minimum cost

  • Higher quality

    • 0.5 defects for 1KLOC (~5-sigma, 6-sigma on life or safety-critical projects)

  • Experience with emerging technologies

  • Pragmatic, battle-tested approaches

Wireless

XML

XSL


Slide7 l.jpg

Preamble

“They [Barry and Rich] remind us:

If one has strong discipline without agility, the result is bureaucracy and stagnation. Agility without discipline is the unencumbered enthusiasm of a startup company before it has to turn a profit.”

Alistair CockburnIn his Foreword to: Balancing Agility and Discipline


Agiletek s secret sauce l.jpg
AgileTek’s Secret Sauce

  • Top Software Engineering talent

  • Decades of real-world experience developing complex systems

  • An extremely effective Software Development Methodology influenced by:

    • Contemporary Agile Methods

    • Airlie Council’s Principal Best Practices

    • Traditional battle-tested methods




Slide11 l.jpg

Complex Microprocessor Array Test Beds For The Traditional Methods Used In Agile+

9.3 Million Transistors


Complex telecommunication system test beds for the traditional methods used in agile l.jpg
Complex Telecommunication System Test Beds For The Traditional Methods Used In Agile+


The airlie council developed the nine principal best software practices for dod l.jpg

1. Norm Brown (Director) Traditional Methods Used In

6. Capers Jones

11. Tim Lister

12. Tom McCabe (not pictured)

2. Vic Basili

7. Tom DeMarco

13. Grady Booch (not pictured)

3. Frank McGrath

8. LarryPutnam

14. Roger Pressman (not pictured)

4. Ed Yourdon

9. John Manzo

5. Lou Mazzucchelli

10. Mike Evans

The Airlie Council Developed The Nine Principal Best Software Practices For DOD


Contemporary agile methods l.jpg
Contemporary Agile Methods Traditional Methods Used In


Slide15 l.jpg

Impetus For A Best-Of-Breed Approach Traditional Methods Used In

Traditional Plan-Driven Methods can be highly effective

but, they have their limitations.

They often:

  • Deny the need for software to evolve and assume that requirements are stable, and can be determined before initiation of coding activities

  • Define processes and plans with such detail and rigidity that it is difficult to deal with inevitable contingencies

  • Cause more emphasis to be placed on checking off a task than on providing value to a customer

  • Diffuse accountability and tend to invite bureaucracy

  • Result in documentation bloat

  • Put too many layers of formality between the developers and a palpable understanding of the problem and the state of the project


The agile software manifesto l.jpg
The Agile Software Manifesto Traditional Methods Used In

  • 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

  • That is, while there is value in the items on the right, we value the items on the left more.

February 2001

Jim Highsmith (+…)*

*…15 others representing XP, and several other Agile Development Methods (ADMs)


Slide17 l.jpg

Impetus For A Best-Of-Breed Approach Traditional Methods Used In

XP (and other ADMs) can be highly effective…

but, they have their limitations.

They are:

  • Only predictable on a micro versus a macro level

  • Difficult to scale

  • Vulnerable to changes at the system level

  • Vague about the nature of tests

  • Inflexible to special needs

  • Impractical in some respects

  • Lack explicit management of risks


Adjusting and extending x p specific approaches l.jpg

Overcoming the Limitations Traditional Methods Used In

Adjusting and Extending XP

Specific Approaches


Agiletek s secret sauce agile l.jpg
AgileTek’s Secret Sauce = Traditional Methods Used In Agile+

Agile+

is…

Contemporary Agile Development Methods

+

Best of the Last 20 Years of Proven Best Practices

Agile+

=

XP

+


Agile and x p l.jpg
Agile Traditional Methods Used In + And XP

Agile+=XP+

  • + Business Process Analyses (BPAs)

  • + Story “Actors”

  • + Delphi-STE Estimation

  • + Risk-Based Situation Audits (RBSAs)

  • + Componentized Architecture

  • + Wall Gantts and Instrument Panels

  • + Automated Contract and Regression Testing

  • + Automatic Document Generation

  • Strict Pair Programming

  • 40-Hour Work Week Restriction

  • + Flexibility to meet special needs


Meeting at the wall gantt l.jpg
Meeting at the Wall-Gantt Traditional Methods Used In

Everyone at any time can see the picture emerge and evolve. They can see how the whole depends on their work and how their work is connected to every other part of the effort


Adjusting and extending x p specific approaches22 l.jpg

Overcoming the Limitations Traditional Methods Used In

Adjusting and Extending XP

Specific Approaches


Most adms are unpredictable at a macro level l.jpg
Most ADMs Are Unpredictable At A Macro Level Traditional Methods Used In

  • Solution:

  • Delphi Estimation

  • STE usage for larger projects


Slide24 l.jpg

Delphi And The Oracle Traditional Methods Used In


Size time effort chart l.jpg
Size - Time - Effort Chart Traditional Methods Used In

PI - Productivity Index

MBI - Staff Buildup Index

Region of Feasibility

Region of Infeasibility


Beta distributed risk profile l.jpg
Beta-Distributed Risk Profile Traditional Methods Used In


Most adms are notoriously difficult to scale l.jpg
Most ADMs Are Notoriously Difficult To Scale Traditional Methods Used In

  • Solution:

  • Componentized Architecture - Interface Definitions

  • Automated Build and Test Processes

  • (Virtual) Team Rooms


So just what is architecture a working definition l.jpg
So Just What Is “Architecture?” Traditional Methods Used In (A Working Definition)

Architecture - the structure of the components of a program/system, their interrelationships, and the principles and guidelines governing their design and evolution over time1.

[1] David Garlan and Dewayne Perry, guest editorial to the April 1995 IEEE Transactions on Software Engineering devoted to software architecture


Some commonly ascribed advantages benefits l.jpg
Some Commonly Ascribed Advantages/Benefits Traditional Methods Used In

  • Architectures permit independent evolution of the exploitation of changing technologies in the major elements of a system.

  • Architectures ease sharing of data and building of distributed applications.

  • Architectures ease communications and movement of data across levels.

  • Architectures facilitate assimilation of new employees.

  • Architectures preserve investment in training.

In Essence, Architectures Enable and Facilitate Scaling and Distributed Development




Most adms leave the software vulnerable to changes at the system level l.jpg
Most ADMs Leave The Software Vulnerable To Changes At the System Level

  • Solution:

  • Componentized Architecture


Good architectures ease the effects of change l.jpg
Good Architectures Ease The Effects Of Change… System Level

They keep visible the interrelationships among the elements of the system and help the team make informed change decisions in the context of these interrelationships

They limit the degree of change and its sphere of influence


Most adms are vague about testing l.jpg
Most ADMs Are Vague About Testing System Level

  • Solution:

  • Use Automated Contract and Regression Testing


Contract testing l.jpg
Contract Testing System Level

Involves Testing For:

Pre-Conditions

Post-Conditions

Class Invariants


Most adms are inflexible to special needs l.jpg
Most ADMs Are Inflexible To Special Needs System Level

  • Solution:

  • Treat the Special Need as a User Story and prioritize it accordingly


Documentation as an example of a special need l.jpg
Documentation As An Example Of A Special Need System Level

Systems created under the auspices of a regulatory agency will require certain documentation specified by CFRs1

This can be treated as just another software deliverable and prioritized accordingly

[1] CFR – Code of Federal Regulations


Some adm practices are impractical l.jpg
Some ADM Practices Are Impractical System Level

  • Solution:

  • Use practices that make sense and work in real-world situations

  • Abandon or modify those that don’t


Adm practices we ve found impractical some examples l.jpg
ADM Practices We’ve Found Impractical System Level(Some Examples)

  • Pair Programming rigidly applied

  • Refusal to estimate total project size, time and effort

  • Building without at least a “sketch”

  • On-site customer

  • Weekly/bi-weekly iterations

  • 40-Hour work week


Most adms do not manage risks explicitly l.jpg
Most ADMs Do not Manage Risks Explicitly System Level

  • Solution:

  • Use Risk-Based Situation Audits

  • Establish a risk management philosophy


Adms and risk l.jpg
ADMs And Risk System Level

Most ADMs manage risk through project transparency

This is highly effective

Adding up-front risk characterization and a philosophy of on-going risk mitigation yields superlative results

If you’re not managing risk, you are not managing1

[1] Airlie Council


Do adms add risk to a project l.jpg
Do ADMs Add Risk To A Project? System Level

  • The greatest risk in software development is not knowing what you don’t know until it’s too late…

  • Every Agile+project begins with an RBSA; then,

  • Though short iterations,Agile+provides a means to:

    • Challenge assumptions

    • Make informed choices and decisions

    • Evolve understanding

    • …early and often

  • Moreover,

    • Project progress is continuously visible to the developers

      • Wall Gantts

      • Daily Stand-Up Meetings

    • … and to our clients

      • Placed at the project’s center

      • Frequent reviews

  • Unlike some methodologies where Risk Management is “bolted on”, it’s an integral part of Agile+


The agile software manifesto43 l.jpg
The Agile Software Manifesto System Level

  • 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

  • That is, while there is value in the items on the right, we value the items on the left more.

False Dichotomy

February 2001

Jim Highsmith (+…)*

*…15 others representing XP, and several other Agile Development Methods (ADMs)


The agiletek software manifesto a measured and balanced approach l.jpg
The AgileTek Software Manifesto System LevelA Measured And Balanced Approach

  • 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

  • That is, while there is value in the items on the right, we value the items on the left more.

with streamlined

with appropriate

balanced by

while being guided by

That is, while we most value the items on the left, we also place importance in the items on the right


What is agile really l.jpg
What Is Agile—Really? System Level

Agile  No Process

Agile  Undisciplined

Agile  Essential, Streamlined Processes

Agile  No Nonsense, Intensely Practical

Agile  Bias Toward Action

Agile  Highly Disciplined

Agile  Flexible and Adaptable

Agile  Execution With Swiftness And Precision


Preserving the essence of agility l.jpg
Preserving The Essence Of Agility System Level

  • Eliminate gratuitous processes, and rework any processes and behaviors that are not intensely practical

  • Wherever possible, minimize formality and ceremony

  • Maintain a bias toward action—come up with a 70% plan and begin to move forward while figuring out the remaining 30% as you go

  • Develop momentum quickly and maintain it

  • Stay flexible and adaptable

  • Know the “why” of processes and do what makes sense when the rules don’t


The numbers the testimonials l.jpg

Can This Really Work And Is It Really Agile? System Level

I’m From Missouri—Show Me!

The Numbers

The Testimonials

AGILETEK


Productivity and quality l.jpg
Productivity and Quality System Level

  • Using Agile+ we’ve achieved a PI1 of 22

  • That translates into an average of ~ 35 ESLOC/Coding Hour

  • Our average defect rate is 0.5/KLOC ~ 5, higher for safety critical software

  • [1]Our most recent audit revealed an overall average Productivity Index (PI) of 22 (as defined by Larry Putnam in his Measures of Excellence: Reliable Software On Time, Within Budget). This index is a management scale corresponding to the overall process productivity achieved by an organization during the main software build. An index of 25 has been considered among the highest ever recorded.




Slide51 l.jpg

A Recent Reference Process

The groundbreaking perspective outlined in this book serves as an expert guide for successful planning and execution of development projects.

Auerbach Publications London, New York, Washington© 2004

“…a highly competent and innovative consulting company called AgileTek.”

Philip Armour is a contributing editor for the Association of Computing Machinery (the ACM) and writes a regular column "The Business of Software" for their flagship periodical: Communications of the ACM.

“…AgileTek is manfully carrying on one of the best examples of these actual ideas in practice that I can imagine.”



Summary l.jpg
Summary Process

In applying ADMs over the last six years, we’ve learned that:

  • Most ADMs purely applied can be highly effective for certain niche projects, but are not very useful for the broad spectrum of projects in which we engage

  • Modifying some ADM practices while adding and carefully streamlining some traditional practices enables effective discharge of today’s demanding software projects

  • Agile+ is a methodology that has proven as disciplined as it is agile… and manages risk as well as or better than most plan-driven approaches

  • True agility requires much discipline

Mary Lou Retton’s perfect vault wins an Olympic Gold Medal


Slide54 l.jpg
Q & A Process

?


Slide55 l.jpg

Thank You Process

For Further Information Please Contact:

John Manzo

847 989-1026

[email protected]

1400 East Touhy Avenue  Des Plaines, Illinois 60018

Phone: + 1 847 699--4041  Fax: + 1 847 813-4903

www.agiletek.com


ad