The Evolution of Agile Development Process The main sections of this presentation 1. Overview 2. The Waterfall Model as a baseline 3. Waterfall Model – Phases of the process 4. The problem in traditional models 5. Agile Software Development as the Alternative 6. The Agile Manifesto – The Beginning 7. The Manifesto for Agile Software Development 8. The benefits of the agile methodology

1. THE EVOLUTION OF
AGILE
DEVELOPMENT
PROCESS
DAVID TZEMACH
WWW.DTVISIONTECH.COM
MAR 11 2016

2. THE EVOLUTION OF AGILE
DEVELOPMENT
PROCESS

3. THE WATERFALL MODEL AS A BASELINE
• IT’S THE FIRST DEVELOPMENT PROCESS TO BE INTRODUCED (HERBERT D. BENINGTON 1956).
• THE FIRST FORMAL DESCRIPTION OF THIS MODEL IS CONNECTED TO WINSTON ROYCE’S ARTICLE
FROM 1970 “MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS”.
• THE MAIN CONCLUSIONS FROM THIS ARTICLE:
EVERY PHASE IN THE PROCESS MUST END, PRIOR TO CONTINUING TO THE NEXT ONE.
IDENTIFY THE 5 PHASES OF A PROJECT DEVELOPMENT PROCESS (NEXT SLIDE ).
AS LONGER THE PROJECT CONTINUES, THE DESIGN WILL BE MORE UNDERSTANDABLE BY THE
PROJECT ENGINEERS(WE CAN NEVER DESIGN A SYSTEM AT THE BEGINNING AND FULLY
UNDERSTAND IT).
EACH PHASE OF THE MODEL, WILL PROVIDE A NEW KNOWLEDGE THAT MAY AFFECT THE OTHER
PHASES.

4. WATERFALL MODEL – PHASES OF THE PROCESS

5. THE PROBLEM IN TRADITIONAL MODELS
THE TRADITIONAL TESTING METHODOLOGIES ARE NOT SUITABLE TO HANDLE THE FAST GROWING SOFTWARE INDUSTRY
WHERE YOU NEED TO DELIVER A FAST AND QUALITY PRODUCT DUE TO FURIOUS COMPETITION AND CLIENT DEMANDS.
THE DISADVANTAGES OF THE THOSE “DINOSAURS”:
• THERE IS NO INDICATION ABOUT THE QUALITY OF THE SOFTWARE UNTIL THE START OF THE TESTING PROCESS.
• THERE IS A HUGH RISK IN ALMOST ANY CODE MODIFICATION AFTER THE TESTING STAGE IS STARTED.
• THERE IS A LIMITED COMMUNICATION BETWEEN THE ENGINEERING TEAMS AND THE CLIENT.
• THE PRELIMINARY PREPARATION AND PLANNING CAN TAKE A HUGH AMOUNT OF TIME.
• IN MANY CASES, THE PROJECT IS PLANNED WITHOUT A REAL SPECIFICATION FROM THE CUSTOMER (THAT IN MOST CASES WILL
FAILL TO PREDICT THE SPECIFIC FUNCTIONALITY AND BEHAVIOR THAT HE NEEDS).
• A MASSIVE AMOUNT OF TEST DOCUMENTS THAT REDUCE THE ACTUAL TESTING TIME.
• BOTH THE TESTING AND CODING STAGES CAN TAKE MONTHS AND EVEN YEARS.
• THERE IS A NARROW ABILITY TO ADD NEW REQUIREMENTS AFTER THE FIRST THREE PHASES OF THE SDLC
MODEL(REQUIREMENTS ,DESIGN AND DEVELOPMENT).
• THERE IS A STRICT “ENTRY” AND “EXIT” CRITERIA.
• SOMETIMES THE ORIGINAL DESIGN MAY LOOK GREAT ON PAPER, BUT VERY COSTLY IN THE ACTUAL DEVELOPMENT PROCESS.

6. AGILE SOFTWARE DEVELOPMENT
AS THE ALTERNATIVE

7. THE AGILE MANIFESTO – THE BEGINNING
• THE SOFTWARE INDUSTRY IS EVOLVED DRAMATICALLY SINCE THE
WATERFALL MODEL IS WAS PRESENTED.
• IN THE YEAR OF 2001, A GROUP OF PIONEERS WHICH DISCOVERED THEIR
OWN WAYS TO DEVELOP A SOFTWARE ARE GOT TOGETHER TO SHARE THEIR
COMMON EXPERIENCES.
• AT THE END OF THIS WEEKEND, THIS GROUP OF PEOPLE PRODUCE THE
“BIBLE” OF THE AGILE MODEL CALLED “MANIFESTO FOR AGILE SOFTWARE
DEVELOPMENT”.

8. THE MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT
“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.”
KENT BECK ET AL

9. THE BENEFITS OF THE AGILE
METHODOLOGY

10. ITERATIVE
THE DEVELOPMENT PROJECTS ARE DIVIDED INTO SMALLER CYCLES
(ITERATIONS OF 1-4 WEEKS) THAT WILL LEAD TO INCREMENTAL RELEASES
(INSTEAD OF ONE MAJOR RELEASE THAT AS THE FULL FUNCTIONALITY).

11. VALUE BASED
WE CAN DEVELOP THE IMPORTANT THINGS FIRST, RELEASE IT TO THE CLIENT
AND THAN CONTINUE WITH THE DEVELOPMENT OF OTHER LESS IMPORTANT
FEATURES.

12. ADAPTIVE
IN AN AGILE PROCESS, THERE IS A HUGH IMPORTANCE TO ADAPT AND
EMBRACE ANY DYNAMIC CHANGE THAT COME FROM THE CLIENT (PER
CYCLE). THIS ADAPTIVE APPROACH WILL INCREASE THE ACCURACY OF
DEVELOPMENT AGAINST THE CLIENT EXPECTATIONS.

13. TEAM PROCESS
THIS PROCESS EMPATHIZE FACE-TO-FACE COMMUNICATION IN ADDITION
TO FULL COLLABORATION BETWEEN ALL THE TEAMS THAT INVOLVED IN THE
PROJECT (QA/R&D/PM).

14. EASY TO UNDERSTAND
VERY SIMPLE AND STRUCTURED PROCESS, ALMOST EVERY PERSON
WILL SUCCEED TO FOLLOW IT (IT’S NOT A ROCKET SCIENCE...).

15. FOR ADDITIONAL KB’S PLEASE
VISIT MY BLOG
WWW.DTVISIONTECH.COM