Agile software development is probably the most common methodology used by organizations today, as such; many people have started to ask more and more questions about this methodology that sometimes based on wrong assumptions. In this presentation, I will review the most common Myths and Misconceptions that I encounter during agile training courses, hopefully, to help people to divide the truth from the assumptions.

1. DAVID TZEMACH
MAR 14 2018
TOP AGILE MYTHS &
MISCONCEPTIONS

2. AGILE SOFTWARE DEVELOPMENT IS
PROBABLY THE MOST COMMON
METHODOLOGY USED BY ORGANIZATIONS
TODAY, AS SUCH; MANY PEOPLE HAVE
STARTED TO ASK MORE AND MORE
QUESTION ‫ד‬ABOUT THIS METHODOLOGY
THAT SOMETIMES BASED ON WRONG
ASSUMPTIONS.
IN THIS PRESENTATION, I WILL REVIEW THE
MOST COMMON MYTHS AND
MISCONCEPTIONS THAT I ENCOUNTER
DURING AGILE TRAINING COURSES,
HOPEFULLY, TO HELP PEOPLE TO DIVIDE THE
TRUTH FROM THE ASSUMPTIONS.

3. AGILE MYTHS &
MISCONCEPTIONS

4. MYTH 1 - AGILE IS A NEW FORCE IN THE SOFTWARE INDUSTRY
IF WE COMPARE AGILE TO OTHER
TRADITIONAL METHODOLOGIES
LIKE WATERFALL WE CAN SAY
THAT AGILE IS NEW J, BUT THE
TRUTH IS THAT THE AGILE
MANIFESTO WAS CREATED IN
2001, AND THEREFORE WE CAN
SAY THAT AGILE IS CERTAINLY
NOT NEW IN THE SOFTWARE
INDUSTRY.

5. MYTH 2 - AGILE IS BETTER THAN TRADITIONAL METHODOLOGIES
ALTHOUGH MORE AND MORE COMPANIES ARE
USING AGILE AS THE PREFERRED
METHODOLOGY, THIS ASSUMPTION IS WRONG!
THE TYPE OF WHICH DEVELOPMENT
METHODOLOGY SHOULD BE USED SHOULD BE
DETERMINED PER PROJECT AND BASED ON THE
ENVIRONMENTAL VARIABLES.
FOR EXAMPLE, WE CAN USE THE WATERFALL
METHODOLOGY IN ANY CASE THAT WE HAVE
CLEAR AND INFORMATIVE REQUIREMENTS FROM
DAY ONE OF THE PROJECT AND STABLE
ENVIRONMENT THAT INCREASE THE
PREDICTABILITY OF THE PROJECT IN A MATTER
OF THE RELEVANT WORK THAT NEEDED TO BE
DONE.

6. MYTH 3 – THERE IS NO DOCUMENTATION IN AGILE
THIS MISCONCEPTION IS MOST LIKELY RELATED TO THE
MISUNDERSTANDING OF THE AGILE MANIFESTO, WHERE IT
DESCRIBES THE FOUR PRINCIPALS:
• INDIVIDUALS AND INTERACTIONS OVER PROCESSES AND TOOLS.
• WORKING SOFTWARE OVER COMPREHENSIVE DOCUMENTATION.
• CUSTOMER COLLABORATION OVER CONTRACT NEGOTIATION.
• RESPONDING TO CHANGE OVER FOLLOWING A PLAN.
NOW, AS YOU CAN SEE THERE IS NO INDICATION THAT AGILE
MEANS NO DOCUMENTATION OR THAT DOCUMENTATION IS NOT
NEEDED, WHAT IT SAYS IS THAT THE FOCUS SHOULD BE ON
DELIVERING A WORKING PRODUCT INSTEAD OF INVESTING MAJOR
TIME IN CREATING A DETAILED DOCUMENTATION THAT MAY REDUCE
THE % OF SUCCESS TO DELIVER THE WORKING PRODUCT.
THERE IS SOME BASIC TYPE OF DOCUMENTATION THAT IS VERY
COMMON DURING EACH ITERATION (STD’S, HLD ETC.), THE ONLY
DIFFERENCE IS THE NUMBER OF DETAILS AND EFFORT PUT BY THE
TEAM TO CREATE THEM.

7. MYTH 4 – AGILE PROJECTS ARE NOT LIMITED BY DEADLINES
SIMILAR TO TRADITIONAL METHODOLOGIES, AGILE IS
NOT A FREE TICKET TO ABUSE THE PROJECT
TIMELINES, REMEMBER THAT IN THE END, THERE IS A
CUSTOMER THAT PAYS FOR THE SOFTWARE (AND A
COMPANY THAT NEEDS TO EARN MONEY…), THERE IS
NO CHANCE THAT THIS CUSTOMER WILL AGREE TO
WORK WITH THE COMPANY ONCE HE BEEN TOLD
THAT THERE IS NO EXPECTED TIME FOR THE PROJECT
COMPLETION.
THE MAIN THING IN AGILE IS THAT WE CAN DELIVER
INCREMENTAL RELEASES OF THE PRODUCT IN A WAY
THAT WILL ALLOW THE CUSTOMER TO REVIEW THE
PROJECT PROGRESS AND TO USE A BASIC SET OF
FUNCTIONALITIES THAT SHOULD BE INCREASED PER
ITERATION.

8. MYTH 5 – AGILE REVOKING THE NEED FOR PLANNING
IN AGILE, PLANNING IS EVERYTHING! THERE IS NO A
SINGLE PROJECT THAT DOES NOT INVOLVE A SIGNIFICANT
PLANNING, THE PLANNING IS STARTED IN THE PROJECT
ROADMAP, MANAGING THE WORK PRIORITIZATION AND
CONTINUES UNTIL THE TEAM CHOOSES THEIR
COMMITMENTS FOR THE UPCOMING ITERATION.
THE MAIN DIFFERENCE BETWEEN AGILE AND
TRADITIONAL METHODOLOGIES IS THAT THERE IS A LESS
UPFRONT PLANNING IN AGILE COMPARED TO
TRADITIONAL MODELS THAT THE ENTIRE PLANNING IS
DETERMINED AT THE BEGINNING OF THE PROJECT. IN
ADDITION, IN AGILE, THE PLANNING PROCESS PERFORMED
PER ITERATION (USUALLY TWO WEEKS OF WORK)
CONTINUALLY UNTIL THE END OF THE PROJECT.

9. MYTH 6 – AGILE IS ONLY SUITABLE FOR SOFTWARE PROJECTS
THE SOFTWARE DEVELOPMENT COMMUNITY
FIRST USES AGILE TECHNIQUES AND THE AGILE
MANIFESTO DESCRIBES AGILE IN THE CONTEXT
OF SOFTWARE DEVELOPMENT.
THAT’S THE TRUTH, BUT AGILE IS NOT
RESTRICTED TO SOFTWARE DEVELOPMENT
PROJECTS, THINK ABOUT AGILE AS A
FRAMEWORK THAT WE CAN USE TO IMPROVE
THE QUALITY AND RESULTS OF A PROJECT, THIS
PROJECT MAY BE RELATED TO SOFTWARE
DEVELOPMENT, MARKETING AND FOR ALMOST
ANY PROJECT THAT IS BASED ON
UNPREDICTABLE ENVIRONMENT.

10. MYTH 7 – AGILE IS THE CURE FOR ALL PROBLEMS
AGILE WILL NOT CURE ALL PROBLEMS THAT ARE
PART OF A SOFTWARE DEVELOPMENT LIFECYCLE
(SDLC), BUT IT WILL HELP THE ORGANIZATION
TO ENJOY A FEW MAJOR BENEFITS THAT WILL
INCREASE THE % OF PROJECT SUCCESS,
EXAMPLES:
• REDUCE THE RISKS.
• INCREASE VISIBILITY.
• BETTER TRACKING OF THE PROJECT PROGRESS.
• BETTER COLLABORATION.
• EFFICIENT COMMUNICATION.

11. MYTH 8 – AGILE IS NOT SUITABLE TO HANDLE LARGE
PROJECTS
MANAGING LARGE PROJECTS IS
HARD AS ITSELF, NO MATTER
WHAT IS THE METHODOLOGY
THAT YOU USE TO MANAGE IT,
THE MAIN DIFFERENCE BETWEEN
AGILE AND TRADITIONAL
METHODOLOGIES, IS THAT IN
AGILE WE TAKE A LARGE PROJECT
AND BREAK IT DOWN TO SMALL
PIECES, WHICH DELIVERED IN
VERY SHORT ITERATIONS.

12. MYTH 9 – AGILE MEANS NO DESIGN
THE MAIN DIFFERENCE
BETWEEN AGILE AND OTHER
TRADITIONAL MODELS IS THAT
IN AGILE WE PERFORM DESIGN
PER ITERATION (PLANNING
MEETING) AND NOT IN ONE
CENTRALIZED PHASE LIKE THE
ONE WE HAVE IN THE
WATERFALL MODEL.

13. CONTACT INFO
• EMAIL: DZCOMP@GMAIL.COM
• LINKEDIN: IL.LINKEDIN.COM/IN/DAVIDTZHMACH
• FACEBOOK: FACEBOOK.COM/DAVID.TZHMACH
• PHONEN: +972 526982298
• TWITTER: @DAVIDTZHMACH
• GOOGLE+: +DAVID
FOR ADDITIONAL KB’S PLEASE
VISIT MY BLOG
WWW.MACHTESTED.COM