1. Personal Software Process (PSP)
1.1. IT only
1.2. by Watts Humphrey; late 1994
1.3. http://www.sei.cmu.edu/reports/00tr022.pdf
1.4. derived
1.4.1. Team Software Process (TSP)
1.4.1.1. IT only
1.4.1.2. by Watts Humphrey; 1996
1.4.1.3. https://en.wikipedia.org/wiki/Team_software_process
1.4.1.4. https://resources.sei.cmu.edu/asset_files/TechnicalReport/2000_005_001_13754.pdf
2. Test Driven Development (TDD)
2.1. IT only
2.2. https://en.wikipedia.org/wiki/Test-driven_development
2.3. derived
2.3.1. Acceptance Test Driven Development (ATDD)
2.3.1.1. IT only
2.3.1.2. Adds ‘A’ before TDD which stands for acceptance.
2.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.
2.3.1.4. ATDD is a collaborative exercise that involves product owners, business analysts, testers, and developers.
2.3.1.5. ATDD helps to ensure that all project members understand precisely what needs to be done and implemented.
2.3.1.6. http://www.amazon.com/Lean-Agile-Acceptance-Test-Driven-Development-Collaboration/dp/0321714083/
2.3.1.7. a.k.a.
2.3.1.7.1. Specification By Example (SBE)
2.3.1.7.2. Example-Driven Development (EDD)
2.3.1.7.3. Behavior Driven Development (BDD)
2.3.1.7.4. Story Test-Driven Development (SDD)
2.3.1.7.5. Functional Test Driven Development (FTDD)
2.3.1.7.6. Executable acceptance test-driven development (EATDD)
2.3.2. Developer Test Driven Development (DTDD)
2.3.2.1. IT only
2.4. derived
2.4.1. Context-Driven-Testing
2.4.1.1. IT only
2.4.1.2. http://context-driven-testing.com/
3. Domain Driven Design (DDD)
3.1. IT only
3.2. by Eric Evans
3.3. http://domaindrivendesign.org/
4. Joint Application Development (JAD)
4.1. IT only
4.2. by Chuck Morris, Tony Crawford; late 1970s
4.3. derived
4.3.1. Rapid Application Development (RAD)
4.3.1.1. IT only
5. Adaptive Project Framework
5.1. by Robert K. Wysocki Ph.D.
6. Continous Integration (CI)
6.1. IT only
6.2. by Grady Booch; 1991
6.3. https://en.wikipedia.org/wiki/Continuous_integration
6.4. derived
6.4.1. Continuous Deployment (CD)
6.4.1.1. IT only
7. eXtreme Programming (XP)
7.1. IT only
7.2. by Kent Beck, Erich Gamma; 1999
7.3. https://en.wikipedia.org/wiki/Extreme_programming
7.4. www.extremeprogramming.org/map/project.html
7.5. derived
7.5.1. eXtreme Manufacturing (XM)
7.5.1.1. by Joe Justice; 2012
7.5.1.2. https://en.wikipedia.org/wiki/EXtreme_Manufacturing
7.6. derived
7.6.1. Mob programming
7.6.1.1. IT only
7.6.1.2. by Hunter Industries; 2014
7.6.1.3. http://context-driven-testing.com/
8. Agile Data (AD)
8.1. IT only
8.2. by Scott Ambler
8.3. www.agiledata.org
9. Scaled Agile Framework (SAFe)
9.1. IT only
9.2. by Dean Leffingwell; 2012 v1.0
9.3. www.scaledagileframework.com
10. Feature Driven Developmement (FDD)
10.1. IT only
10.2. by Peter Coad, Jeff DeLuca; 1997
10.3. https://en.wikipedia.org/wiki/Feature-driven_development
11. Scrum
11.1. by Ken Schwaber, Sutherland, Beedle; 2001
11.2. www.scrum.org
11.3. www.scrumalliance.org
11.4. derived
11.4.1. Scrum-of-Scrums
11.4.1.1. http://guide.agilealliance.org/guide/scrumofscrums.html
11.5. derived
11.5.1. ScrumBan
11.6. derived
11.6.1. Large-Scale Scrum (LeSS)
11.6.1.1. by Craig Larman, Bas Vodde
11.6.1.1.1. http://www.craiglarman.com/
11.6.1.2. http://less.works/
11.6.1.3. derived
11.6.1.3.1. LeSS Huge
11.7. derived
11.7.1. Agility Path
11.7.1.1. by Ken Schwaber
11.8. derived
11.8.1. Scrum@Scale (ScrumPLoP)
11.8.1.1. by Jeff Sutherland, Alex Brown
11.8.1.2. www.scrumplop.org
11.8.1.3. http://www.scruminc.com/
11.8.1.4. https://scrumatscale.scruminc.com/
11.9. derived
11.9.1. Scrum Nexus™ Framework
11.9.1.1. by Ken Schwaber; 2014/15
11.9.1.2. https://www.scrum.org/Resources/What-is-Scaled-Scrum
11.9.1.3. https://www.scrum.org/Resources/Nexus
11.10. derived
11.10.1. eXtreme Manufacturing (XM)
11.10.1.1. by Joe Justice; 2012
11.10.1.2. https://en.wikipedia.org/wiki/EXtreme_Manufacturing
11.11. derived
11.11.1. XSCALE
11.11.1.1. by Peter Merel; 2014
11.11.1.2. http://agiletng.org/2014/04/21/xscale/
11.12. derived
11.12.1. Spotify Tribal model
11.13. derived
11.13.1. Type A, B, and C Sprints
11.13.1.1. http://blog.xebia.com/type-c-scrum-explained/
11.13.1.2. https://www.scruminc.com/scrum-evolution-type-b-and-c-sprints/
12. Kanban
12.1. by David J.Anderson; 2010
12.2. derived
12.2.1. ScrumBan
12.2.1.1. by Corey Ladas; 2009
12.2.1.2. http://leansoftwareengineering.com/ksse/scrum-ban/
12.3. derived
12.3.1. eXtreme Manufacturing (XM)
12.3.1.1. by Joe Justice; 2012
12.3.1.2. https://en.wikipedia.org/wiki/EXtreme_Manufacturing
13. Lean Software Development
13.1. IT only
13.2. by Mary Poppendieck, Tom Poppendieck; 2003
14. Sappient|Approach
15. Unified Process
15.1. IT only
15.2. by Jacobson, Kruchten, Royce, Kroll
15.3. derived
15.3.1. Rational Unified Process (RUP)
15.3.1.1. IT only
15.3.1.2. by Philippe Kruchten (Director of Process Development)
15.3.1.3. derived
15.3.1.3.1. Dynamic Systems Development Method (DSDM)
15.3.1.4. derived
15.3.1.4.1. Open Unified Process (OpenUP)
15.3.1.4.2. Essential Unified Process (EssUP)
15.3.1.4.3. Agile Modelling (AM)
15.3.1.4.4. Agile Unified Process (AUP) status: EoL
15.3.1.4.5. Enterprise Unified Process (EUP)
16. Continuous Delivery (CD)
16.1. IT only
16.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
16.3. https://en.wikipedia.org/wiki/Continuous_delivery
17. Crystal Methodologies
17.1. IT only
17.2. by Allistar Cockburn; 1998
17.3. Comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow, Crystal Orange and others.
17.4. Crystal Clear
17.4.1. 2004
17.5. Crystal Yellow
17.6. Crystal Orange
17.6.1. 1998
17.7. Crystal Orange Web
17.7.1. 2001
17.8. Crystal Red
17.9. Crystal Maroon
17.10. Crystal Diamond
17.11. Crystal Sapphire
18. Adaptive Software Development (ASD)
18.1. IT only
18.2. by Jim Highsmith, Sam Bayer; 2000
18.3. https://en.wikipedia.org/wiki/Adaptive_software_development
19. DevOps
19.1. IT only
19.2. derived
19.2.1. Rugged DevOps
20. 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!)
20.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.
20.1.1. http://www.miroslawdabrowski.com
20.1.2. http://www.linkedin.com/in/miroslawdabrowski
20.1.3. https://www.google.com/+MiroslawDabrowski
20.1.4. https://play.spotify.com/user/miroslawdabrowski/
20.1.5. https://twitter.com/mirodabrowski
20.1.6. miroslaw_dabrowski
21. Legend
21.1. Icon
21.1.1. means this approach is dedicated to large scale a.k.a. Scaling Agility
21.2. Icon
21.2.1. means this approach is dedicated to IT only
22. What is Agile?
22.1. Agile Manifesto
22.1.1. http://agilemanifesto.org/
22.1.2. 17 It industry veterans met at Snowbird Resort on February 11-13 2001 and created Agile Manifesto
22.1.2.1. Introduced 4 Values and 12 Principles defining Agile for Software Development
22.1.3. disciplines that gave rise to the Agile Manifesto
22.1.3.1. Extreme Programming, SCRUM, Dynamic Systems Development Method (DSDM®), Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming.
22.2. Agile Alliance
22.2.1. http://www.agilealliance.org/
22.3. Agile currently is buzzword, a marketing term
22.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)
22.3.2. Agile as a word by it's own simply means - nothing more than merketing term.
22.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
22.3.3. Agile is a generic description of a “Style of Working” and Philosophy.
22.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
22.3.3.2. ‘Agile Project Management’ is perhaps an oxymoron
22.4. The Agile Mindset, Values and Principles
22.4.1. 4 Agile Value
22.4.1.1. 1. Individuals and interactions over processes and tools
22.4.1.2. 2. Working software over comprehensive documentation
22.4.1.3. 3. Customer collaboration over contract negotiation
22.4.1.4. 4. Responding to change over following a plan
22.4.2. 12 Agile Principles
22.4.2.1. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
22.4.2.2. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
22.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.
22.4.2.4. 4. Business people and developers must work together daily throughout the project.
22.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.
22.4.2.6. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
22.4.2.7. 7. Working software is the primary measure of progress.
22.4.2.8. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
22.4.2.9. 9. Continuous attention to technical excellence and good design enhances agility.
22.4.2.10. 10. Simplicity - the art of maximizing the amount of work not done - is essential.
22.4.2.11. 11. The best architectures, requirements, and designs emerge from self-organizing teams.
22.4.2.12. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
22.4.3. The unlimited number of Agile Practices
22.4.3.1. The 'forest' of Agile Methods, Frameworks, Standards ...
22.4.3.1.1. Being Agile vs Doing Agile
22.5. Agile is a umbrella term enclosing different methodologies, tools, techniques, practices and frameworks
22.5.1. In Agile community umbrella symbolizes different approaches in implementing Agile Manifesto but yet all from them are "Agilelish"
22.5.2. SCRUM, Lean, KANBAN, XP are not ‘Agile Project Management’ practices but rather team level practices
22.5.2.1. No Project Manager role
22.5.2.2. No project definition and etablished project / programme governance
22.5.2.3. ...
22.6. Plan-Driven Projects vs. Change-driven Project Projects
22.6.1. Traditional (waterfall or sequential) Project Management metaphor
22.6.1.1. Railway metaphor
22.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
22.6.1.1.2. Changing course of train based on requirements
22.6.1.2. a.k.a. Plan-driven
22.6.1.2.1. build around paradigm of process
22.6.1.3. defined process control model
22.6.1.3.1. All work is understood before execution
22.6.1.3.2. Given a well-defined set of inputs, the same outputs are generated every time
22.6.1.3.3. Follow the pre-determined steps to get known results
22.6.2. Agile (iterative + incremental + adaptive) Project Management metaphor
22.6.2.1. Sailing metaphor
22.6.2.1.1. Embracing change of requirements, finding TRUE value for stakeholders by experimenting, testing, changing status quo.
22.6.2.1.2. Adapting / changing course of sailing based on business TRUE business needs and priorities, which could be different than requirements
22.6.2.2. a.k.a. Change-driven
22.6.2.2.1. build around paradigm of change / adaptation
22.6.2.3. empirical (adaptive) process control model
22.6.2.3.1. Frequent inspection and adaptation occurs as work proceeds
22.6.2.3.2. Processes are accepted as imperfectly defined
22.6.2.3.3. Outputs are often unpredictable and unrepeatable
22.7. Agile is best for complex projects
22.7.1. Simple (straightforward)
22.7.1.1. Everything is known and predicatable
22.7.1.2. Characteristics
22.7.1.2.1. Repeating patterns and consistent events
22.7.1.2.2. Clear cause‐and‐effect
22.7.1.2.3. Well establish knowns
22.7.1.2.4. Fact based management
22.7.1.3. Leader’s/Manager’s job
22.7.1.3.1. Use best practices
22.7.1.3.2. Extensive communication not necessary
22.7.1.3.3. Establish patterns and optimize to them
22.7.1.3.4. Command and control
22.7.2. Complicated
22.7.2.1. More is known than unknown
22.7.2.2. Characteristics
22.7.2.2.1. More predictability than unpredictability
22.7.2.2.2. Fact‐based management
22.7.2.2.3. Experts work out wrinkle
22.7.2.3. Leader’s/Manager’s job
22.7.2.3.1. Utilize experts to gain insights
22.7.2.3.2. Use metrics to gain control
22.7.2.3.3. Sense, analyze, respond
22.7.2.3.4. Command and control
22.7.3. Complex
22.7.3.1. More is unknown than known
22.7.3.2. Characteristics
22.7.3.2.1. More predictability than unpredictability
22.7.3.2.2. Fact‐based management
22.7.3.2.3. Experts work out wrinkle
22.7.3.3. Leader’s/Manager’s job
22.7.3.3.1. Create bounded environments for action
22.7.3.3.2. Increase levels of interaction and communication
22.7.3.3.3. Servant leadership
22.7.3.3.4. Generate ideas
22.7.3.3.5. Probe, sense, respond
22.7.4. Chaotic (unpredictable)
22.7.4.1. Very little is known
22.7.4.2. Characteristics
22.7.4.2.1. High Turbulence
22.7.4.2.2. No clear cause‐and‐effect
22.7.4.2.3. Unknowables
22.7.4.2.4. Many decisions and no time
22.7.4.3. Leader’s/Manager’s job
22.7.4.3.1. Immediate action to re‐establish order
22.7.4.3.2. Prioritize and select actionable work
22.7.4.3.3. Look for what works rather than perfection
22.7.4.3.4. Act, sense, respond
22.7.5. See also Cynefin framework (by Dan Snowden)
22.7.5.1. different view on Cynefin Framework
22.7.5.2. https://www.youtube.com/watch?v=N7oz366X0-8
22.7.6. Relating Complexity and Management Style
22.8. Agile is about delivering "best possible value" not maximum possible value
22.8.1. VALUE is NOT the same as BENEFIT
22.8.1.1. Benefits
22.8.1.1.1. Benefit is about outputs
22.8.1.1.2. Benefit is a objective
22.8.1.1.3. Benefit is an advantage to stakeholders (internal or external to the organization)
22.8.1.1.4. Benefit can be financial and non financial
22.8.1.1.5. Benefit can be ...
22.8.1.1.6. Benefit MUST be measurable and observable
22.8.1.1.7. Benefits are identifiable and quantifiable
22.8.1.1.8. Benefits SHOULD have baselines
22.8.1.1.9. Benefits SHOULD have priorities
22.8.1.1.10. Benefits types:
22.8.1.1.11. in general benefit = delivered requirements on time, on budget, within scope etc.
22.8.1.2. Value
22.8.1.2.1. Value is about outcomes
22.8.1.2.2. Value is subjective
22.8.1.2.3. Value can be measurable (if required but not natural to use such techniques in any Agile approach)
22.8.1.2.4. Value can be ...
22.8.1.2.5. Values SHOULD have priorities
22.8.1.2.6. in general value = designed fit for purpose, as small as possible solution
22.9. Agile is about focusing on business value / outcome, not strictly project plan / output
22.9.1. Focusing on value delivery not on fixed product definition or strict adherence to plan
22.9.1.1. That's why most Agile approaches define Project Vision
22.10. Agile respects the urgency and importance of priorities conveyed by the customer / user, most prominently by incremental delivery and flexible sequencing
22.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.
22.11.1. “People don’t know what they want until you show it to them” (Steve Jobs, 1955 - 2011)
22.12. Agile is about empowering people, treating them as intellectual individuals
22.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)
22.13. Agile is about working closely and constantly (active two side collaboration) with customer throughout (including more than just feedback loops)
22.13.1. “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer)
22.14. Agile is about change, constant change which leads to better value
22.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)
22.14.2. "Move Fast and Break Things" Mark Zuckerberg, Facebook
22.14.3. "Change is the only constant." Heraclitus, Greek philosopher
22.15. Agile thinking / approach often requires mind change and cultural shift
22.15.1. Not every organization is ready for that change!
22.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)
22.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)
22.15.4. “We cannot become what we need by remaining what we are.” (John C. Maxwell)
22.16. Why Agile Works
22.16.1. 1. The customer's representative is in the driver's seat
22.16.2. 2. Quick reaction to the changing market and needs
22.16.3. 3. More visibility
22.16.4. 4. Ideal environment for development
22.16.5. 5. Self-manged teams
22.16.6. 6. Removes confusion and distraction
22.16.7. 7. No fortune tellers; Plan as you go
22.16.8. 8. Issues are less disruptive
22.16.9. 9. Continuous improvement
22.17. The 10 Golden Rules for Successful Agile Projects (by Keith Richards)
22.17.1. https://www.youtube.com/watch?v=P84PqqJV7Es
22.17.2. No. 1: Define the project objective in less than 10 words
22.17.2.1. You must start with the end in mind
22.17.2.2. You need to know exactly where you are going
22.17.2.3. The business case is your best friend
22.17.2.4. This will take you a long time to do
22.17.2.5. It will help you to kill a project going nowhere
22.17.2.6. The scope of the project will map on to this.
22.17.2.7. TIP
22.17.2.7.1. Can you write the project objective on a Post-it note with a flip chart marker?
22.17.3. No. 2: Build a team with those who say ‘can’
22.17.3.1. A lot of being agile is about options
22.17.3.2. If you get the right people you are half way there
22.17.3.3. Choose the right person above the right skill set
22.17.3.4. “If you think you can’t, you’re right” - Carol Bartz
22.17.3.5. You need collaboration and team spirit.
22.17.3.6. TIP
22.17.3.6.1. Ask a team member this question: Can I ask a favour?
22.17.4. No. 3: Go slow early to go fast later
22.17.4.1. This is counter intuitive
22.17.4.2. How much ‘DUF’ is enough? Answer EDUF!
22.17.4.3. Build from firm foundations
22.17.4.4. You must avoid analysis paralysis
22.17.4.5. Try and spot early solutioneering.
22.17.4.6. TIP
22.17.4.6.1. Ask yourself: Is it safe to move on?
22.17.5. No. 4: Look backwards to go forwards
22.17.5.1. Learn your lessons - both good and bad
22.17.5.2. Evolve the process - it has to evolve
22.17.5.3. If it doesn’t work - do something else!
22.17.5.4. Try this! - Review, Plan, Do
22.17.5.5. Share your experiences with other teams.
22.17.5.6. TIP
22.17.5.6.1. Ask yourself how many of your projects have ended with a project review.
22.17.6. No. 5: Change is great!
22.17.6.1. You need to anticipate change and embrace it
22.17.6.2. This allows a more accurate solution to result
22.17.6.3. Do not confuse the breadth of the scope with the depth
22.17.6.4. Evolve and converge on the solution with the right kind of change.
22.17.6.5. TIP
22.17.6.5.1. How do you feel when a customer says “I’ve changed my mind”?
22.17.7. No. 6: To be understood, seek first to understand.
22.17.7.1. Command and control may not work with Agile
22.17.7.2. Facilitation is a core competency
22.17.7.3. Big ears, big eyes, small mouth
22.17.7.4. You have to play with the cards you are dealt
22.17.7.5. This will give you ownership.
22.17.7.6. TIP
22.17.7.6.1. Try the 10 second silence when getting a progress update - nothing else can compete with it!
22.17.8. No. 7: Collect Actuals – this is the oxygen for your project
22.17.8.1. ‘You cannot control what you cannot measure’ - Tom de Marco
22.17.8.2. Meten is weten - to measure is to know
22.17.8.3. Start now - build a metrics database
22.17.8.4. Keep it simple to start with
22.17.8.5. Calibrate your estimates.
22.17.8.6. TIP
22.17.8.6.1. Do you know (to the nearest day) how much time was spent on testing during your last project?
22.17.9. No. 8: Use fat communication channels
22.17.9.1. Shift the communication traffic to bigger pipes
22.17.9.2. The written word is a silent killer
22.17.9.3. Go visual
22.17.9.4. Use workshops
22.17.9.5. “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer)
22.17.9.6. TIP
22.17.9.6.1. Try turning a document over and take a look at what is on the back
22.17.10. No. 9: Work hard at controlling what you can’t control
22.17.10.1. Continuously manage external risks
22.17.10.2. You may get your team right but what about 3rd parties?
22.17.10.3. Are they playing by the same rules as you?
22.17.10.4. Get the team involved
22.17.10.5. Be ‘a bit of a worrier’.
22.17.10.6. TIP
22.17.10.6.1. Actively manage your risk log - it is not a storage area
22.17.11. No. 10: One more day? NO! We’ll catch up? NO!
22.17.11.1. Time focus is your greatest weapon
22.17.11.2. Force the issue – understand your condition
22.17.11.3. Timeboxes not milestones
22.17.11.4. If you are going to fail – fail early
22.17.11.5. Prioritise with MoSCoW – it should be natural.
22.17.11.6. TIP
22.17.11.6.1. Set a deadline and hit it - never extend it, not even once!
23. PRINCE2 Agile
23.1. by Keith Richards; 2015
23.2. https://www.axelos.com/qualifications/prince2-qualifications/prince2-agile
24. Management 3.0
24.1. https://management30.com/
25. Beyond Budgeting
25.1. http://bbrt.org/
26. Product Development Flow
27. The Vanguard Method
27.1. by John Seddon
27.2. https://www.vanguard-method.com/
27.3. https://en.wikipedia.org/wiki/The_Vanguard_Method
28. Radical Management
28.1. by Steve Denning
28.2. https://en.wikipedia.org/wiki/Steve_Denning
29. Theory of Constraints
29.1. by Eliyahu M. Goldratt; 1997
29.2. https://en.wikipedia.org/wiki/Theory_of_constraints
30. Enterprise Transition Framework (ETF)
30.1. by agile42
30.2. http://www.agile42.com/en/agile-transition/etf/
31. The Mikado Method
31.1. http://www.amazon.com/Mikado-Method-Ola-Ellnestam/dp/1617291218
32. Holocracy
32.1. by Brian Robertson; 2007
32.2. http://www.holacracy.org/
32.3. https://en.wikipedia.org/wiki/Holacracy
33. Evo methodology
33.1. by Tom Gilb; 1990s
34. Managed Agile Development Framework
34.1. by Charles G. Cobb; 2013
34.2. hybrid project-level framework
35. Agile Assessment Tools (a.k.a. Maturity Models)
35.1. DSDM/AgilePM Project Health Check Questionnairr (PHCQ)
35.1.1. by Miroslaw Dabrowski
35.2. Evidence Based Management (EBM)
35.2.1. by Ken Schwaber
35.2.2. http://www.ebmgt.org/
35.3. Comparative Agility
35.3.1. by Cohn
35.3.2. https://comparativeagility.com/
35.4. Agile and Lean Forrester’s assessment framework
35.4.1. by Forrester
35.4.2. https://www.forrester.com/Determine+If+Youre+Agile+And+Lean+Enough/fulltext/-/E-RES72701
35.5. Agile Realized Benefits & Improvements (AgileRBI)
35.5.1. by DavisBase Consulting
35.6. Scaled Agile Framework assessments
35.6.1. by Dean Leffingwell
35.6.2. http://www.scaledagileframework.com/new-team-and-release-train-self-assessments/
35.7. Agile Adoption Index
35.7.1. by Ahmed Sidky
35.7.2. http://agile2007.agilealliance.org/downloads/presentations/AgileAdoption_489.pdf
35.8. Sidky Agile Measurement Index (SAMI)
35.8.1. by Ahmed Sidky
35.9. Agile Journey Index (AJI)
35.9.1. by AgileBill Krebs
35.10. XP Evaluation Framework (XP:EF)
35.10.1. by AgileBill Krebs, Laurie Williams
35.11. Agile Coach Health Assessment
35.11.1. by Agile Transformation Inc.
35.11.2. http://www.agilityhealthradar.com/agile-coach-health-assessment/
35.12. TeamHealth Retrospective Assessment
35.12.1. by Agile Transformation Inc.
35.12.2. http://www.agilityhealthradar.com/teamhealth-assessment/