This document discusses choosing an agile methodology for software development projects. It provides an overview of various agile methodologies like Scrum, Kanban, Scrumban and SAFe. It emphasizes that there is no single best methodology and that factors like team size, requirements uncertainty, backlog size and maintenance needs should be considered. The document recommends establishing a project evaluation committee to help organizations select the most appropriate methodology based on these factors to improve project success rates.

1. Building the
Foundation of Agile
Looking at Process in your Enterprise
Organization
Michael Dougherty
National Project Manager
Michaeld@magenic.com
April 2016

2. 2
»Methodologies Used
»The Big Methodology Question
»What is Agile?
»Comparison of Methodologies
»How to choose the best Methodology for you
Agenda

3. 3
»Founded in 1995
»Focused on Microsoft and Mobile Technologies
»550+ full time consultants
»Regional offices in
»Chicago
»Boston
»Minneapolis (HQ)
»Atlanta
»San Francisco
»Southern California
»Ann Arbor
»National Markets
»Onshore Development Center in Minneapolis
»Off-shore team in Manila, Philippines
Magenic Corporate Overview

4. 4
What methodology do you use?
How closely do you follow it?
Scrum Waterfall SAFe Kanban
Lean LeSS Scrumban ScrumXP
Google
Design
Sprint
FDD Scrummerfall Your Own?

5. 5
“Agile” describes a set of methodologies, aligned with lean principles focusing on value &
eliminating waste.
Types of Agile Development
Source: Version One
10th Annual State of Agile
Report, 2016

6. 6
The Big Methodology Question
“Which methodology is right for me?”
»Searches for comparing software delivery methodology results in:
› Out of date blogs with fragments of half-baked advice
› White papers w/no clear direction, missing modern methodologies and
relevant detail or just scratching the surface
»You are likely wondering why can’t one find that “prescription for
success”
› It’s not easy and never will be
› PMI, Scrum.org, Scrumalliance.com and Scaled Agile wish to believe their
answer is best
› Even consulting agencies that should have the most experience providing
unbiased advice won’t online because they don’t wish to give away their
“trade secrets”

7. 7
Factors that Influence Project Success
Source: The Standish Group, 2015
Factors of Success Points
Executive Sponsorship 15%   
Emotional Maturity 15%   
User Involvement 15%   
Optimization 15%   
Skilled Resources 10%  
Standard Architecture 8%  
Agile Process 7%  
Modest Execution 6%  
Project Management Expertise 5% 
Clear Business Objectives 4% 

8. 8
Factors of Project Success Explained
Executive Support An executive or group of executives agrees to provide both financial and emotional
backing
Emotional maturity The collection of basic behaviors of how people work together
User Involvement Users are involved in the project decision-making and information-gathering process
Optimization A structured means of improving business effectiveness and optimizing a collection of
many small projects or major requirements
Skilled staff People who understand both the business and the technology
SAME
(Standard Architectural
Management
Environment)
A consistent group of integrated practices, services, and products for developing,
implementing, and operating software applications
Agile proficiency The agile team and the product owner are skilled in the agile process.
Modest execution Having a process with few moving parts, and those parts are automated and streamlined
Project
management
expertise
The application of knowledge, skills, and techniques to project activities in order to meet
or exceed stakeholder expectations and produce value for the organization
Clear Business
Objectives
The understanding of all stakeholders and participants in the business purpose for
executing the project

9. 9
Hitting Failure?
»So many enterprises have tried Agile and failed
»Agile is easy to understand, but hard to master
› The process MUST ALIGN with the business
› The process should be implemented iteratively
› If a methodology is followed too rigidly, it will break
− For instance, requiring all standard scrum ceremonies without inspecting and adapting
› Often, many people within an enterprise are threatened by Agile
− Difficult to adjust
− Attempts to sabotage
› However, Agile is the lynchpin of modern application development

10. 10
Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Source: http://agilemanifesto.org

11. 11
What is Agile?
Finding problems
earlier
Regular Checkpoints
Giving transparency to
the process
Allows for dynamic
delivery change
Continuous
Improvement
Mistakes are smaller
Sees working software
frequently (Inspect and
Adapt)
Producing valuable
results, faster
Accepting of change
(Flexible and Evolving)
Requirements,
architecture and
design continue to
emerge over the
course of the project.
Embrace this.

12. 12
»Agile is not:
› New
› A silver bullet
› A solution to resource issues
› Without planning, documentation, architecture…
› A license to hack
› An excuse for poor quality
› Undisciplined
› About throwing away areas of expertise
› Unproven
› Used only on the lunatic fringe
Agile Myths & Misconceptions

13. 13
Common Delivery Traps
»Not “One Size Fits All”
› Methodologies can coexist (e.g. Scrum and XP, Kanban and Scrum, etc.)
› Different projects will warrant different methodologies
› You can have a mix of methodologies that is completely your own
› Consider Agile as a mindset
› Methodologies are tools that you SHOULD choose and customize
»Pause and reflect upon entry of new projects
› Don’t drop process in order to “go faster”; history has shown it just doesn’t
work
› Need for having quick comparisons when confronted with pressure to deliver

14. 14
Comparison of Methodologies
Factors Measurements
Factors Measurements Scrum ScrumXP Waterfall Kanban Scrumban SAFe LeSS Lean
Delivery Team Size Very Small (<5) 3 4 4 4 3 1 1 5
Delivery Team Size Small (6-15) 4 5 3 4 5 1 1 4
Delivery Team Size Medium (16-50) 3 4 3 3 4 2 3 4
Delivery Team Size Large (50-100) 3 4 2 3 4 4 4 3
Delivery Team Size Very Large (100+) 3 3 2 3 3 4 4 3
Rate of Change (Uncertainty) Very Small (<5%) 3 3 5 3 3 1 1 4
Rate of Change (Uncertainty) Small (6-20%) 4 4 3 4 4 3 3 4
Rate of Change (Uncertainty) Medium (21-35%) 5 5 2 4 4 4 4 3
Rate of Change (Uncertainty) Large (35-50%) 5 5 1 4 4 5 5 3
Rate of Change (Uncertainty) Very Large (51%+) 5 5 1 4 4 5 5 2
Size of Backlog Very Low (<50 stories) 3 4 3 4 4 1 1 3
Size of Backlog Low (51-200 stories) 3 4 3 3 4 2 2 3
Size of Backlog Medium (201-350 stories) 3 4 2 3 3 3 3 2
Size of Backlog Large (351-500 stories) 3 3 2 2 3 4 4 2
Size of Backlog Very Large (500+ stories) 2 3 1 2 2 4 4 2
Maintenance/New Dev Ratio Very Small (25% or less) 4 5 3 3 4 4 4 3
Maintenance/New Dev Ratio Small (26% - 49%) 4 4 3 4 4 4 4 4
Maintenance/New Dev Ratio Medium (50%) 3 4 2 4 5 4 4 4
Maintenance/New Dev Ratio Large (51%-74%) 3 4 2 5 5 3 3 3
Maintenance/New Dev Ratio Very Large (75% or more) 3 3 2 5 4 3 3 3
Methodologies
0
10
20
30
40
50
60
70
80
90
Total
Comparison of Methodologies
Sum of Scrum Sum of ScrumXP Sum of Waterfall Sum of Kanban Sum of Scrumban Sum of SAFe Sum of LeSS Sum of Lean
»Performed Plenty of Research…

15. 15
Many Primary Indicators Came Apparent Quickly
Team Size
Small
Medium
Large
X Large
Level of
Uncertainty
Rate of
Change
Team
Composition
Internal
Local consulting
Global consulting
Blend
Organizational
Culture
Industry
Processes
Standards and
Regulations
Solution
Quality
Defect
count
per
KLOC
Size of Backlog
Small
Medium
Large
X Large
Maintenance
Versus New
Development
% of maint work
Business and
IT alignment
Not aligned
Partially aligned
Fully aligned

16. 16
Research Results
»There is no “perfect rulebook of methodologies”
› Guidelines do exist for which methodology to leverage
› This can be expanded on historical data of project success levels
»Suggest adding into your organization:
Project Evaluation Committee
• Provides methodology selection governance
• Purpose is identifying the best methodology for a given project
• Projects are tracked on a regular basis for compliance and performance
• The Committee is continuously improving the evaluation process
• Group may be built into your existing PMO and requires low overhead

17. 17
»Ask the four primary questions:
› What is the team size?
› What is the level of uncertainty in the end solution?
› What is the size of the requirements backlog?
› How much maintenance versus development needed?
»Keep in mind the Agile Triangle
› budget, schedule, scope, value and quality
»Let’s apply to the following six most used methodologies
Selecting a Methodology
ValueQuality
Constraints
(cost, schedule, scope)

18. 18
Waterfall
Strengths
• Highly Regulated Environments
• Effective with infrastructure, upgrades and package
configurations
• Works for staff augmentation
Weaknesses
• Less effective with distributed teams
• Very inflexible to change
• Most costly for software quality and maintenance work
Size of Team Small Large
Uncertainty of
Requirements
Low High
Size of
Requirements
Backlog
Small Large
State of
Development Cycle
New
Development
Maintenance

19. 19
Scrum (or ScrumXP)
Strengths
• Promotes higher solution quality
• Improves Time To Market
• Very strong for new software development
Weaknesses
• Breaks down for larger projects with multiple delivery
teams
• Easy for scope creep
• Challenging for estimating project costs and schedule
Size of Team Small Large
Uncertainty of
Requirements
Low High
Size of
Requirements
Backlog
Small Large
State of
Development Cycle
New
Development
Maintenance

20. 20
Kanban
Strengths
• Best with a dynamic backlog
• Effective for support
• Great for infrastructure, upgrades and package configurations
Weaknesses
• Poor for fixed budgets
• Challenging to coordinate for larger projects
• Doesn’t leverage shared resources very well
Size of Team Small Large
Uncertainty of
Requirements
Low High
Size of
Requirements
Backlog
Small Large
State of
Development Cycle
New
Development
Maintenance
???????

21. 21
Scrumban
Strengths
• Flexible for both new development and maintenance
• Great for infrastructure, upgrades and package
configurations
• Better with higher uncertainty
Weaknesses
• Challenging with fixed budget limits
• Breaks down for larger projects with multiple delivery
teams
• Requires an experienced team
Size of Team Small Large
Uncertainty of
Requirements
Low High
Size of
Requirements
Backlog
Small Large
State of
Development Cycle
New
Development
Maintenance

22. 22
SAFe (Scaled Agile Framework)
Strengths
• Build for large, collaborative delivery teams
• Effective for new development and maintenance
• Excellent performance metrics
Weaknesses
• Not intended for smaller projects
• Requires high level of maintenance
• Difficult organizational culture change
Size of Team Small Large
Uncertainty of
Requirements
Low High
Size of
Requirements
Backlog
Small Large
State of
Development Cycle
New
Development
Maintenance

23. 23
LeSS (Large Scale Scrum)
Strengths
• Easy to scale from smaller projects
• Effective for multiple teams
• Encourages building your own adjustments
Weaknesses
• Challenging for fixed project budgets
• Difficult to use for smaller projects
• Teams must be experienced
Size of Team Small Large
Uncertainty of
Requirements
Low High
Size of
Requirements
Backlog
Small Large
State of
Development Cycle
New
Development
Maintenance

24. 24
»Use the Kaizen approach for building out the Project Evaluation
Committee
Guidance for Governance
Sort
Set in Order
ShineStandardize
Sustain

25. 25
»The Goal is to deliver software of value, not a methodology
»Be open to multiple methodologies
»Blend methodologies as needed
»Tailor methodologies where appropriate
»Use a governing body to determine the best methodology mix
»Track success/failure metrics for your entire project portfolio
»Determine the root causes of project failure
»Make your governance self-improving through kaizen
Recommendations

26. 26
Michael Dougherty, National Project Manager: MichaelD@Magenic.com
LinkedIn: https://www.linkedin.com/in/agilemichaeldougherty
Blog: https://agilemichaeldougherty.wordpress.com/
Twitter: @doughertymic