1. Scrum
1.1. by Ken Schwaber, Sutherland, Beedle; 2001
1.2. www.scrum.org
1.3. www.scrumalliance.org
1.4. derived
1.4.1. Scrum-of-Scrums
1.4.1.1. http://guide.agilealliance.org/guide/scrumofscrums.html
1.5. derived
1.5.1. ScrumBan
1.6. derived
1.6.1. Large-Scale Scrum (LeSS)
1.6.1.1. by Craig Larman, Bas Vodde
1.6.1.1.1. http://www.craiglarman.com/
1.6.1.2. http://less.works/
1.6.1.3. derived
1.6.1.3.1. LeSS Huge
1.7. derived
1.7.1. Agility Path
1.7.1.1. by Ken Schwaber
1.8. derived
1.8.1. Scrum@Scale (ScrumPLoP)
1.8.1.1. by Jeff Sutherland, Alex Brown
1.8.1.2. www.scrumplop.org
1.8.1.3. http://www.scruminc.com/
1.8.1.4. https://scrumatscale.scruminc.com/
1.9. derived
1.9.1. Scrum Nexus™ Framework
1.9.1.1. by Ken Schwaber; 2014/15
1.9.1.2. https://www.scrum.org/Resources/What-is-Scaled-Scrum
1.9.1.3. https://www.scrum.org/Resources/Nexus
1.10. derived
1.10.1. eXtreme Manufacturing (XM)
1.10.1.1. by Joe Justice; 2012
1.10.1.2. https://en.wikipedia.org/wiki/EXtreme_Manufacturing
1.11. derived
1.11.1. XSCALE
1.11.1.1. by Peter Merel; 2014
1.11.1.2. http://agiletng.org/2014/04/21/xscale/
1.12. derived
1.12.1. Spotify Tribal model
1.13. derived
1.13.1. Type A, B, and C Sprints
1.13.1.1. http://blog.xebia.com/type-c-scrum-explained/
1.13.1.2. https://www.scruminc.com/scrum-evolution-type-b-and-c-sprints/
2. Unified Process
2.1. IT only
2.2. by Jacobson, Kruchten, Royce, Kroll
2.3. derived
2.3.1. Rational Unified Process (RUP)
2.3.1.1. IT only
2.3.1.2. by Philippe Kruchten (Director of Process Development)
2.3.1.3. derived
2.3.1.3.1. Dynamic Systems Development Method (DSDM)
2.3.1.4. derived
2.3.1.4.1. Open Unified Process (OpenUP)
2.3.1.4.2. Essential Unified Process (EssUP)
2.3.1.4.3. Agile Modelling (AM)
2.3.1.4.4. Agile Unified Process (AUP) status: EoL
2.3.1.4.5. Enterprise Unified Process (EUP)
3. This freeware, non-commercial mind map was carefully hand crafted with passion and love for learning and constant improvement ... (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)
3.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Please don't hesitate to contact me for :-) Mirosław Dąbrowski, Poland/Warsaw.
3.1.1. http://www.miroslawdabrowski.com
3.1.2. http://www.linkedin.com/in/miroslawdabrowski
3.1.3. https://www.google.com/+MiroslawDabrowski
3.1.4. https://play.spotify.com/user/miroslawdabrowski/
3.1.5. https://twitter.com/mirodabrowski
3.1.6. miroslaw_dabrowski
4. Legend
4.1. Icon
4.1.1. means this approach is dedicated to large scale a.k.a. Scaling Agility
4.2. Icon
4.2.1. means this approach is dedicated to IT only
5. What is Agile?
5.1. Agile Manifesto
5.1.1. http://agilemanifesto.org/
5.1.2. 17 It industry veterans met at Snowbird Resort on February 11-13 2001 and created Agile Manifesto
5.1.2.1. Introduced 4 Values and 12 Principles defining Agile for Software Development
5.1.3. disciplines that gave rise to the Agile Manifesto
5.1.3.1. Extreme Programming, SCRUM, Dynamic Systems Development Method (DSDM®), Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming.
5.2. Agile Alliance
5.2.1. http://www.agilealliance.org/
5.3. Agile currently is buzzword, a marketing term
5.3.1. Agile is like any other newly introduced popular concept. “… Everybody is talking about it. Very few are doing it and those who are, are doing it badly” (James O. Coplien)
5.3.2. Agile as a word by it's own simply means - nothing more than merketing term.
5.3.2.1. there are so many Agile methodologies, Agile standards, Agile techniques, Agile tools, Agile good / best agile practices, Agile frameworks etc., that 'Agile' word itself is to general
5.3.3. Agile is a generic description of a “Style of Working” and Philosophy.
5.3.3.1. Not only style of working on project but rather culture in ENTIRE organization including also it's management level, clients and partners
5.3.3.2. ‘Agile Project Management’ is perhaps an oxymoron
5.4. The Agile Mindset, Values and Principles
5.4.1. 4 Agile Value
5.4.1.1. 1. Individuals and interactions over processes and tools
5.4.1.2. 2. Working software over comprehensive documentation
5.4.1.3. 3. Customer collaboration over contract negotiation
5.4.1.4. 4. Responding to change over following a plan
5.4.2. 12 Agile Principles
5.4.2.1. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
5.4.2.2. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
5.4.2.3. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
5.4.2.4. 4. Business people and developers must work together daily throughout the project.
5.4.2.5. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
5.4.2.6. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
5.4.2.7. 7. Working software is the primary measure of progress.
5.4.2.8. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
5.4.2.9. 9. Continuous attention to technical excellence and good design enhances agility.
5.4.2.10. 10. Simplicity - the art of maximizing the amount of work not done - is essential.
5.4.2.11. 11. The best architectures, requirements, and designs emerge from self-organizing teams.
5.4.2.12. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
5.4.3. The unlimited number of Agile Practices
5.4.3.1. The 'forest' of Agile Methods, Frameworks, Standards ...
5.4.3.1.1. Being Agile vs Doing Agile
5.5. Agile is a umbrella term enclosing different methodologies, tools, techniques, practices and frameworks
5.5.1. In Agile community umbrella symbolizes different approaches in implementing Agile Manifesto but yet all from them are "Agilelish"
5.5.2. SCRUM, Lean, KANBAN, XP are not ‘Agile Project Management’ practices but rather team level practices
5.5.2.1. No Project Manager role
5.5.2.2. No project definition and etablished project / programme governance
5.5.2.3. ...
5.6. Plan-Driven Projects vs. Change-driven Project Projects
5.6.1. Traditional (waterfall or sequential) Project Management metaphor
5.6.1.1. Railway metaphor
5.6.1.1.1. Moving forward, based on delivering predicted upfront requirements in accepted tolerances with limited tolerance to change, destination (final product specification) is known upfront and it will hardly change to any other destination
5.6.1.1.2. Changing course of train based on requirements
5.6.1.2. a.k.a. Plan-driven
5.6.1.2.1. build around paradigm of process
5.6.1.3. defined process control model
5.6.1.3.1. All work is understood before execution
5.6.1.3.2. Given a well-defined set of inputs, the same outputs are generated every time
5.6.1.3.3. Follow the pre-determined steps to get known results
5.6.2. Agile (iterative + incremental + adaptive) Project Management metaphor
5.6.2.1. Sailing metaphor
5.6.2.1.1. Embracing change of requirements, finding TRUE value for stakeholders by experimenting, testing, changing status quo.
5.6.2.1.2. Adapting / changing course of sailing based on business TRUE business needs and priorities, which could be different than requirements
5.6.2.2. a.k.a. Change-driven
5.6.2.2.1. build around paradigm of change / adaptation
5.6.2.3. empirical (adaptive) process control model
5.6.2.3.1. Frequent inspection and adaptation occurs as work proceeds
5.6.2.3.2. Processes are accepted as imperfectly defined
5.6.2.3.3. Outputs are often unpredictable and unrepeatable
5.7. Agile is best for complex projects
5.7.1. Simple (straightforward)
5.7.1.1. Everything is known and predicatable
5.7.1.2. Characteristics
5.7.1.2.1. Repeating patterns and consistent events
5.7.1.2.2. Clear cause‐and‐effect
5.7.1.2.3. Well establish knowns
5.7.1.2.4. Fact based management
5.7.1.3. Leader’s/Manager’s job
5.7.1.3.1. Use best practices
5.7.1.3.2. Extensive communication not necessary
5.7.1.3.3. Establish patterns and optimize to them
5.7.1.3.4. Command and control
5.7.2. Complicated
5.7.2.1. More is known than unknown
5.7.2.2. Characteristics
5.7.2.2.1. More predictability than unpredictability
5.7.2.2.2. Fact‐based management
5.7.2.2.3. Experts work out wrinkle
5.7.2.3. Leader’s/Manager’s job
5.7.2.3.1. Utilize experts to gain insights
5.7.2.3.2. Use metrics to gain control
5.7.2.3.3. Sense, analyze, respond
5.7.2.3.4. Command and control
5.7.3. Complex
5.7.3.1. More is unknown than known
5.7.3.2. Characteristics
5.7.3.2.1. More predictability than unpredictability
5.7.3.2.2. Fact‐based management
5.7.3.2.3. Experts work out wrinkle
5.7.3.3. Leader’s/Manager’s job
5.7.3.3.1. Create bounded environments for action
5.7.3.3.2. Increase levels of interaction and communication
5.7.3.3.3. Servant leadership
5.7.3.3.4. Generate ideas
5.7.3.3.5. Probe, sense, respond
5.7.4. Chaotic (unpredictable)
5.7.4.1. Very little is known
5.7.4.2. Characteristics
5.7.4.2.1. High Turbulence
5.7.4.2.2. No clear cause‐and‐effect
5.7.4.2.3. Unknowables
5.7.4.2.4. Many decisions and no time
5.7.4.3. Leader’s/Manager’s job
5.7.4.3.1. Immediate action to re‐establish order
5.7.4.3.2. Prioritize and select actionable work
5.7.4.3.3. Look for what works rather than perfection
5.7.4.3.4. Act, sense, respond
5.7.5. See also Cynefin framework (by Dan Snowden)
5.7.5.1. different view on Cynefin Framework
5.7.5.2. https://www.youtube.com/watch?v=N7oz366X0-8
5.7.6. Relating Complexity and Management Style
5.8. Agile is about delivering "best possible value" not maximum possible value
5.8.1. VALUE is NOT the same as BENEFIT
5.8.1.1. Benefits
5.8.1.1.1. Benefit is about outputs
5.8.1.1.2. Benefit is a objective
5.8.1.1.3. Benefit is an advantage to stakeholders (internal or external to the organization)
5.8.1.1.4. Benefit can be financial and non financial
5.8.1.1.5. Benefit can be ...
5.8.1.1.6. Benefit MUST be measurable and observable
5.8.1.1.7. Benefits are identifiable and quantifiable
5.8.1.1.8. Benefits SHOULD have baselines
5.8.1.1.9. Benefits SHOULD have priorities
5.8.1.1.10. Benefits types:
5.8.1.1.11. in general benefit = delivered requirements on time, on budget, within scope etc.
5.8.1.2. Value
5.8.1.2.1. Value is about outcomes
5.8.1.2.2. Value is subjective
5.8.1.2.3. Value can be measurable (if required but not natural to use such techniques in any Agile approach)
5.8.1.2.4. Value can be ...
5.8.1.2.5. Values SHOULD have priorities
5.8.1.2.6. in general value = designed fit for purpose, as small as possible solution
5.9. Agile is about focusing on business value / outcome, not strictly project plan / output
5.9.1. Focusing on value delivery not on fixed product definition or strict adherence to plan
5.9.1.1. That's why most Agile approaches define Project Vision
5.10. Agile respects the urgency and importance of priorities conveyed by the customer / user, most prominently by incremental delivery and flexible sequencing
5.11. Agile respects the common sense that all requirements can not be known at the outset, particularly when the outcomes are intangible and subject to an evolving understanding.
5.11.1. “People don’t know what they want until you show it to them” (Steve Jobs, 1955 - 2011)
5.12. Agile is about empowering people, treating them as intellectual individuals
5.12.1. “You have to learn to manage in situations where you don’t have command authority, where you are neither controlled nor controlling. That is the fundamental change.” (Peter F. Drucker)
5.13. Agile is about working closely and constantly (active two side collaboration) with customer throughout (including more than just feedback loops)
5.13.1. “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer)
5.14. Agile is about change, constant change which leads to better value
5.14.1. “If a process is too unpredictable or too complicated for the planned, (predictive) approach, then the empirical approach (measure and adapt) is the method of choice“ (Ken Schwaber)
5.14.2. "Move Fast and Break Things" Mark Zuckerberg, Facebook
5.14.3. "Change is the only constant." Heraclitus, Greek philosopher
5.15. Agile thinking / approach often requires mind change and cultural shift
5.15.1. Not every organization is ready for that change!
5.15.2. "It is quite difficult for a highly structured and seniority-based organization to mobilize itself for change, especially under noncrisis conditions. this effort collapses somewhere in the hierarchy" (K. Imai, I. Nonaka, H. Takeuchi)
5.15.3. "Scrum exposes every cultural dysfunction that impedes developing software [...] It is not an approach or process that can be modified to fit the existing organizational culture; the culture must change to enable Scrum" (K. Schwaber, J. Sutherland)
5.15.4. “We cannot become what we need by remaining what we are.” (John C. Maxwell)
5.16. Why Agile Works
5.16.1. 1. The customer's representative is in the driver's seat
5.16.2. 2. Quick reaction to the changing market and needs
5.16.3. 3. More visibility
5.16.4. 4. Ideal environment for development
5.16.5. 5. Self-manged teams
5.16.6. 6. Removes confusion and distraction
5.16.7. 7. No fortune tellers; Plan as you go
5.16.8. 8. Issues are less disruptive
5.16.9. 9. Continuous improvement
5.17. The 10 Golden Rules for Successful Agile Projects (by Keith Richards)
5.17.1. https://www.youtube.com/watch?v=P84PqqJV7Es
5.17.2. No. 1: Define the project objective in less than 10 words
5.17.2.1. You must start with the end in mind
5.17.2.2. You need to know exactly where you are going
5.17.2.3. The business case is your best friend
5.17.2.4. This will take you a long time to do
5.17.2.5. It will help you to kill a project going nowhere
5.17.2.6. The scope of the project will map on to this.
5.17.2.7. TIP
5.17.2.7.1. Can you write the project objective on a Post-it note with a flip chart marker?
5.17.3. No. 2: Build a team with those who say ‘can’
5.17.3.1. A lot of being agile is about options
5.17.3.2. If you get the right people you are half way there
5.17.3.3. Choose the right person above the right skill set
5.17.3.4. “If you think you can’t, you’re right” - Carol Bartz
5.17.3.5. You need collaboration and team spirit.
5.17.3.6. TIP
5.17.3.6.1. Ask a team member this question: Can I ask a favour?
5.17.4. No. 3: Go slow early to go fast later
5.17.4.1. This is counter intuitive
5.17.4.2. How much ‘DUF’ is enough? Answer EDUF!
5.17.4.3. Build from firm foundations
5.17.4.4. You must avoid analysis paralysis
5.17.4.5. Try and spot early solutioneering.
5.17.4.6. TIP
5.17.4.6.1. Ask yourself: Is it safe to move on?
5.17.5. No. 4: Look backwards to go forwards
5.17.5.1. Learn your lessons - both good and bad
5.17.5.2. Evolve the process - it has to evolve
5.17.5.3. If it doesn’t work - do something else!
5.17.5.4. Try this! - Review, Plan, Do
5.17.5.5. Share your experiences with other teams.
5.17.5.6. TIP
5.17.5.6.1. Ask yourself how many of your projects have ended with a project review.
5.17.6. No. 5: Change is great!
5.17.6.1. You need to anticipate change and embrace it
5.17.6.2. This allows a more accurate solution to result
5.17.6.3. Do not confuse the breadth of the scope with the depth
5.17.6.4. Evolve and converge on the solution with the right kind of change.
5.17.6.5. TIP
5.17.6.5.1. How do you feel when a customer says “I’ve changed my mind”?
5.17.7. No. 6: To be understood, seek first to understand.
5.17.7.1. Command and control may not work with Agile
5.17.7.2. Facilitation is a core competency
5.17.7.3. Big ears, big eyes, small mouth
5.17.7.4. You have to play with the cards you are dealt
5.17.7.5. This will give you ownership.
5.17.7.6. TIP
5.17.7.6.1. Try the 10 second silence when getting a progress update - nothing else can compete with it!
5.17.8. No. 7: Collect Actuals – this is the oxygen for your project
5.17.8.1. ‘You cannot control what you cannot measure’ - Tom de Marco
5.17.8.2. Meten is weten - to measure is to know
5.17.8.3. Start now - build a metrics database
5.17.8.4. Keep it simple to start with
5.17.8.5. Calibrate your estimates.
5.17.8.6. TIP
5.17.8.6.1. Do you know (to the nearest day) how much time was spent on testing during your last project?
5.17.9. No. 8: Use fat communication channels
5.17.9.1. Shift the communication traffic to bigger pipes
5.17.9.2. The written word is a silent killer
5.17.9.3. Go visual
5.17.9.4. Use workshops
5.17.9.5. “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer)
5.17.9.6. TIP
5.17.9.6.1. Try turning a document over and take a look at what is on the back
5.17.10. No. 9: Work hard at controlling what you can’t control
5.17.10.1. Continuously manage external risks
5.17.10.2. You may get your team right but what about 3rd parties?
5.17.10.3. Are they playing by the same rules as you?
5.17.10.4. Get the team involved
5.17.10.5. Be ‘a bit of a worrier’.
5.17.10.6. TIP
5.17.10.6.1. Actively manage your risk log - it is not a storage area
5.17.11. No. 10: One more day? NO! We’ll catch up? NO!
5.17.11.1. Time focus is your greatest weapon
5.17.11.2. Force the issue – understand your condition
5.17.11.3. Timeboxes not milestones
5.17.11.4. If you are going to fail – fail early
5.17.11.5. Prioritise with MoSCoW – it should be natural.
5.17.11.6. TIP
5.17.11.6.1. Set a deadline and hit it - never extend it, not even once!
6. PRINCE2 Agile
6.1. by Keith Richards; 2015
6.2. https://www.axelos.com/qualifications/prince2-qualifications/prince2-agile
7. Management 3.0
7.1. https://management30.com/
8. Beyond Budgeting
8.1. http://bbrt.org/
9. The Vanguard Method
9.1. by John Seddon
9.2. https://www.vanguard-method.com/
9.3. https://en.wikipedia.org/wiki/The_Vanguard_Method
10. Enterprise Transition Framework (ETF)
10.1. by agile42
10.2. http://www.agile42.com/en/agile-transition/etf/
11. Evo methodology
11.1. by Tom Gilb; 1990s
12. Managed Agile Development Framework
12.1. by Charles G. Cobb; 2013
12.2. hybrid project-level framework
13. Agile Assessment Tools (a.k.a. Maturity Models)
13.1. DSDM/AgilePM Project Health Check Questionnairr (PHCQ)
13.1.1. by Miroslaw Dabrowski
13.2. Evidence Based Management (EBM)
13.2.1. by Ken Schwaber
13.2.2. http://www.ebmgt.org/
13.3. Comparative Agility
13.3.1. by Cohn
13.3.2. https://comparativeagility.com/
13.4. Agile and Lean Forrester’s assessment framework
13.4.1. by Forrester
13.4.2. https://www.forrester.com/Determine+If+Youre+Agile+And+Lean+Enough/fulltext/-/E-RES72701
13.5. Agile Realized Benefits & Improvements (AgileRBI)
13.5.1. by DavisBase Consulting
13.6. Scaled Agile Framework assessments
13.6.1. by Dean Leffingwell
13.6.2. http://www.scaledagileframework.com/new-team-and-release-train-self-assessments/
13.7. Agile Adoption Index
13.7.1. by Ahmed Sidky
13.7.2. http://agile2007.agilealliance.org/downloads/presentations/AgileAdoption_489.pdf
13.8. Sidky Agile Measurement Index (SAMI)
13.8.1. by Ahmed Sidky
13.9. Agile Journey Index (AJI)
13.9.1. by AgileBill Krebs
13.10. XP Evaluation Framework (XP:EF)
13.10.1. by AgileBill Krebs, Laurie Williams
13.11. Agile Coach Health Assessment
13.11.1. by Agile Transformation Inc.
13.11.2. http://www.agilityhealthradar.com/agile-coach-health-assessment/
13.12. TeamHealth Retrospective Assessment
13.12.1. by Agile Transformation Inc.
13.12.2. http://www.agilityhealthradar.com/teamhealth-assessment/
14. Sociocracy 3.0
14.1. http://sociocracy30.org/
15. Liquid Organization Model
15.1. http://p2pfoundation.net/Liquid_Organization_Model
15.2. http://www.amazon.com/Liquid-Organization-Routledge-Management-Organizations/dp/0415706629
16. The Open Organization
16.1. https://www.redhat.com/en/explore/the-open-organization-book
17. The Agile Software Development Lifecycle
17.1. by BearingPoint / infonova, 2016
18. Agile Project Management
18.1. by Trans-Atlantic Consulting Group BV; Polychor, 2014
18.2. http://polychor.com/
19. Personal Software Process (PSP)
19.1. IT only
19.2. by Watts Humphrey; late 1994
19.3. http://www.sei.cmu.edu/reports/00tr022.pdf
19.4. derived
19.4.1. Team Software Process (TSP)
19.4.1.1. IT only
19.4.1.2. by Watts Humphrey; 1996
19.4.1.3. https://en.wikipedia.org/wiki/Team_software_process
19.4.1.4. https://resources.sei.cmu.edu/asset_files/TechnicalReport/2000_005_001_13754.pdf
20. Test Driven Development (TDD)
20.1. IT only
20.2. https://en.wikipedia.org/wiki/Test-driven_development
20.3. derived
20.3.1. Acceptance Test Driven Development (ATDD)
20.3.1.1. IT only
20.3.1.2. Adds ‘A’ before TDD which stands for acceptance.
20.3.1.3. In ATDD the acceptance criteria are defined in early in application development process and then those criteria can be used to guide the subsequent development work.
20.3.1.4. ATDD is a collaborative exercise that involves product owners, business analysts, testers, and developers.
20.3.1.5. ATDD helps to ensure that all project members understand precisely what needs to be done and implemented.
20.3.1.6. http://www.amazon.com/Lean-Agile-Acceptance-Test-Driven-Development-Collaboration/dp/0321714083/
20.3.1.7. a.k.a.
20.3.1.7.1. Specification By Example (SBE)
20.3.1.7.2. Example-Driven Development (EDD)
20.3.1.7.3. Behavior Driven Development (BDD)
20.3.1.7.4. Story Test-Driven Development (SDD)
20.3.1.7.5. Functional Test Driven Development (FTDD)
20.3.1.7.6. Executable acceptance test-driven development (EATDD)
20.3.2. Developer Test Driven Development (DTDD)
20.3.2.1. IT only
20.4. derived
20.4.1. Context-Driven-Testing
20.4.1.1. IT only
20.4.1.2. http://context-driven-testing.com/
21. Domain Driven Design (DDD)
21.1. IT only
21.2. by Eric Evans
21.3. http://domaindrivendesign.org/
22. Joint Application Development (JAD)
22.1. IT only
22.2. by Chuck Morris, Tony Crawford; late 1970s
22.3. derived
22.3.1. Rapid Application Development (RAD)
22.3.1.1. IT only
23. Adaptive Project Framework
23.1. by Robert K. Wysocki Ph.D.
24. Continous Integration (CI)
24.1. IT only
24.2. by Grady Booch; 1991
24.3. https://en.wikipedia.org/wiki/Continuous_integration
24.4. derived
24.4.1. Continuous Deployment (CD)
24.4.1.1. IT only
25. eXtreme Programming (XP)
25.1. IT only
25.2. by Kent Beck, Erich Gamma; 1999
25.3. https://en.wikipedia.org/wiki/Extreme_programming
25.4. www.extremeprogramming.org/map/project.html
25.5. derived
25.5.1. eXtreme Manufacturing (XM)
25.5.1.1. by Joe Justice; 2012
25.5.1.2. https://en.wikipedia.org/wiki/EXtreme_Manufacturing
25.6. derived
25.6.1. Mob programming
25.6.1.1. IT only
25.6.1.2. by Hunter Industries; 2014
25.6.1.3. http://context-driven-testing.com/
26. Agile Data (AD)
26.1. IT only
26.2. by Scott Ambler
26.3. www.agiledata.org
27. Scaled Agile Framework (SAFe)
27.1. IT only
27.2. by Dean Leffingwell; 2012 v1.0
27.3. www.scaledagileframework.com
28. Feature Driven Developmement (FDD)
28.1. IT only
28.2. by Peter Coad, Jeff DeLuca; 1997
28.3. https://en.wikipedia.org/wiki/Feature-driven_development
29. Kanban
29.1. by David J.Anderson; 2010
29.2. derived
29.2.1. ScrumBan
29.2.1.1. by Corey Ladas; 2009
29.2.1.2. http://leansoftwareengineering.com/ksse/scrum-ban/
29.3. derived
29.3.1. eXtreme Manufacturing (XM)
29.3.1.1. by Joe Justice; 2012
29.3.1.2. https://en.wikipedia.org/wiki/EXtreme_Manufacturing
30. Lean Software Development
30.1. IT only
30.2. by Mary Poppendieck, Tom Poppendieck; 2003
31. Sappient|Approach
32. Continuous Delivery (CD)
32.1. IT only
32.2. Continuous Delivery doesn't mean every change is deployed to production ASAP. It means every change is proven to be deployable at any time
32.3. https://en.wikipedia.org/wiki/Continuous_delivery
33. Crystal Methodologies
33.1. IT only
33.2. by Allistar Cockburn; 1998
33.3. Comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow, Crystal Orange and others.
33.4. Crystal Clear
33.4.1. 2004
33.5. Crystal Yellow
33.6. Crystal Orange
33.6.1. 1998
33.7. Crystal Orange Web
33.7.1. 2001
33.8. Crystal Red
33.9. Crystal Maroon
33.10. Crystal Diamond
33.11. Crystal Sapphire
34. Adaptive Software Development (ASD)
34.1. IT only
34.2. by Jim Highsmith, Sam Bayer; 2000
34.3. https://en.wikipedia.org/wiki/Adaptive_software_development
35. DevOps
35.1. IT only
35.2. derived
35.2.1. Rugged DevOps