The document provides a timeline and overview of various software methodologies and frameworks including Waterfall, Scrum, Extreme Programming, Feature Driven Development, Agile Manifesto, Lean, Kanban, Scrum Guide, Kanban for Scrum, and DevOps. It discusses the origins and key principles of each approach. The timeline shows how newer frameworks built upon lessons learned from prior methods and helped evolve practices over time to support more flexible and collaborative development.

1. Software Methodologies &
Frameworks
Maisara Khedr

2. Scrum
Waterfall
Rapid
Development
Agile
Kanban
ExtremeProgramming
Lean
SAFe
Feature Driven
Development
DevOps
Nexus
Agenda
Scrumban

3. History Timeline
1970
Waterfall

4. ● Originated in manufacturing and construction industries
● 1970, Cited by Winston W.Royce.
● 1976, Bell & Thayer firstly used the term.
Waterfall
Royce’s Paper

5. Rapid Application
Development
History Timeline
1970
Waterfall
1991

6. ● 1986, Barry Boehm developed the Spiral model.
Rapid Application Development

7. ● 1991, James Martin published RAD Book.
Rapid Application Development

8. 1995
1991
Rapid Application
Development
History Timeline
1970
Waterfall Scrum

9. Scrum

10. ● 1986, Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum.
● 1990s, Ken Schwaber used what would become Scrum at his company.
● 1990s, Jeff Sutherland, John Scumniotales and Jeff McKenna, developed a similar
approach at Easel Corporation, referring to it as Scrum.
● 1995, Sutherland and Schwaber jointly presented a paper describing the Scrum
framework.
● 2002, Schwaber, Sutherland, Mike Cohn and others founded the Scrum Alliance.
Scrum

11. 1995
Scrum
1991
Rapid Application
Development
History Timeline
1970
Waterfall
1996
Extreme
Programming

12. ● 1993, The C3 project started in Chrysler.
● 1996, Kent Beck & Ron Jeffries was hired to get the thing working.
● System is delivered in 14 months. the development team adopted a way of
working which is now formalized as Extreme Programming methodology.
● Extreme Programming Team
○ The Customer
○ The Developer
○ The Tracker
○ The Coach
Extreme Programming

13. ● Every contributor to the project is an
integral part of the “Whole Team”
● Extreme programming teams use a
simple form of planning and tracking to
decide what should be done next and to
predict when the project will be done.
Focused on business value, the team
produces the software in a series of small
fully-integrated releases that pass all the
tests the Customer has defined.
Extreme Programming - Practices
What is Extreme Programming? Ron Jeffries

14. ● The Extreme Programming team keeps
the system integrated and running all the
time.
● The programmers code in a consistent
style so that everyone can understand and
improve all the code as needed.
● Extreme Programming is about team
responsibility for all code, for coding in a
consistent pattern so that everyone can
read everyone’s code.
● The Extreme Programming team works at
a pace that can be sustained indefinitely.
Extreme Programming - Practices
What is Extreme Programming? Ron Jeffries

15. ● Extreme Programmers work
together in pairs and as a group,
with simple design and obsessively
tested code, improving the design
continually to keep it always just
right for the current needs.
Extreme Programming - Practices
What is Extreme Programming? Ron Jeffries

16. ● 2001, the 3C’s model is proposed by Ron Jeffries to distinguish "social" user
stories from "documentary" requirements practices such as use cases.
● 3C’s are Card, Conversation and Confirmation.
● User stories are written on cards. The card does not contain all the information
that makes up the requirement. Instead, the card has just enough text to identify
the requirement, and to remind everyone what the story is.
● The requirement itself is communicated from customer to programmers through
conversation. The conversation is largely verbal, but can be supplemented with
documents. The best supplements are examples; the best examples are executable,
We call these examples confirmation.
User Stories
Essential XP: Card, Conversation, Confirmation By Ron Jeffries

17. 1995
Scrum
1991
Rapid Application
Development
History Timeline
1970
Waterfall
1996
Extreme
Programming
1997
Feature Driven
Development

18. ● 1997, initially devised by Jeff De Luca to meet the specific needs of a 15-month,
50-person software development project at a large Singapore bank.
● FDD is a model-driven short-iteration process that consists of five basic activities.
○ Develop overall model
○ Build feature list
○ Plan by feature
○ Design by feature
○ Build by feature
Feature Driven Development

19. 1995
Scrum
1991
Rapid Application
Development
History Timeline
1970
Waterfall
1996
Extreme
Programming
1997
Feature Driven
Development
Agile Manifesto
2001

20. ● Ken Schwaber
● Jeff Sutherland
● Kent Beck
● Ron Jeffrie
● Ward Cunningham
● Martin Fowler
● Mike Beedle
● Andrew Hunt
● Dave Thomas
Agile Manifesto
● Robert C. Martin (Uncle Bob)
● James Grenning
● Jim Highsmith
● Steve Mellor
● Alistair Cockburn
● Arie van Bennekum
● Brian Marick
● Jon Kern
17 Authors of Agile Manifesto

21. ● Individuals and Interactions Over Processes and Tools.
● Working Software Over Comprehensive Documentation.
● Customer Collaboration Over Contract Negotiation.
● Responding to Change Over Following a Plan.
While there is value in the items on the right, we value the items on the left more.
Agile - Values
Agile Manifesto

22. Agile - Principles
Agile Manifesto
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.

23. Agile - Principles
Agile Manifesto
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity --the art of maximizing the amount of work not done-- is essential.
11. The best architectures, requirements, and designs emerge from self-organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.

24. Agile - ?
The Agile Mindset By Ahmed Sidky

25. Agile - Mindset

26. 1995
Scrum
1991
Rapid Application
Development
History Timeline
1970
Waterfall
1996
Extreme
Programming
1997
Feature Driven
Development
2001
Agile Manifesto
2003
Lean

27. Lean
● 1930s, Kiichiro Toyoda, Taiichi Ohno, and others at Toyota revisited Ford’s
original thinking, and invented the Toyota Production System.
● 2003, Mary and Tom Poppendieck published “Lean Software Development: An Agile
Toolkit” book.
● Mary had worked in a manufacturing plant that had adopted lean manufacturing
and her husband Tom is an experienced software developer.

28. Lean Software Development - Principles
● Eliminate waste
Manufacturing Waste Software Waste
Inventory Partially Done Work
Overproduction Extra Features
Extra-Processing Relearning
Transportation Handoffs
Waiting Delays
Motion Tasks Switching
Defects Defects
The 7 Wastes of Software

29. ● Amplify learning
○ Improve software development by learning continuously.
● Decide as late as possible
○ Delay decisions - as possible - until they can be based on facts not assumptions & predictions.
● Deliver as fast as possible
○ Customer value rapid and frequent delivery of a quality product.
● Empower the team
○ Find good people and let them do their job.
● Build integrity in,
○ Maintain integrity by focusing in customer needs, keeping things simple and eliminating waste.
● See the whole
○ Think big but act small. We build a large system by breaking it into smaller parts,but attention
needs to be given to the larger interactions with other components and systems.
Lean Software Development - Principles
Foundations of Disciplined Agile Delivery

30. 1995
Scrum
1991
Rapid Application
Development
History Timeline
1970
Waterfall
1996
Extreme
Programming
1997
Feature Driven
Development
2001
Agile Manifesto
2003
Lean
2009
Scrum Guide

31. ● Scrum is founded on empiricism. Empiricism asserts that knowledge comes from
experience and making decisions based on what is known.
● Scrum employs an iterative, incremental approach to optimize predictability and
control risk.
● Three pillars uphold every implementation of empirical process control:
○ Transparency
○ Inspection
○ Adaptation
● Scrum Artifacts
○ Product Backlog
○ Sprint Backlog
○ Increment
Scrum Guide - Theory
Scrum Guide 2017

32. ● Sprint Planning (8 Hours for 1 month sprint)
● Daily Scrum (15 Minutes)
● Sprint Review (4 Hours for 1 month sprint)
● Sprint Retrospective (3 Hours for 1 month sprint)
Scrum Guide - Events
Scrum Guide 2017

33. ● Responsible for managing the Product Backlog which includes:
○ Clearly expressing Product Backlog items;
○ Ordering the items in the Product Backlog to best achieve goals and missions;
○ Optimizing the value of the work the Development Team performs;
○ Ensuring that the Product Backlog is visible, transparent, and clear to all.
○ Ensuring the Development Team understands items in the Product Backlog to the level needed.
● The Product Owner may do the above work, or have the Development Team do
it. However, the Product Owner remains accountable.
Scrum Guide - Team (Product Owner)
Scrum Guide 2017

34. ● They are self-organizing. No one (not even the Scrum Master) tells the
Development Team how to turn Product Backlog into Increments of potentially
releasable functionality;
● Development Teams are cross-functional, with all the skills as a team necessary to
create a product Increment
● Individual Development Team members may have specialized skills and areas of
focus, but accountability belongs to the Development Team as a whole.
● 3:9 development team members. The Product Owner and Scrum Master roles are
not included in this count unless they are also executing the work of the Sprint
Backlog.
Scrum Guide - Team (Development Team)
Scrum Guide 2017

35. Scrum Guide - Team (Scrum Master)
● Servant-leader
● Facilitator
● Coach
● Scrum master to the product owner
○ Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as
well as possible;
○ Finding techniques for effective Product Backlog management;
○ Helping the Scrum Team understand the need for clear and concise Product Backlog items;
○ Understanding product planning in an empirical environment;
○ Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
○ Understanding and practicing agility; and,
○ Facilitating Scrum events as requested or needed.
Scrum Guide 2017

36. Scrum Guide - Team (Scrum Master)
● Scrum master to the team
○ Coaching the Development Team in self-organization and cross-functionality;
○ Helping the Development Team to create high-value products;
○ Removing impediments to the Development Team’s progress;
○ Facilitating Scrum events as requested or needed; and,
○ Coaching the Development Team in organizational environments in which Scrum is not yet fully
adopted and understood.
Scrum Guide 2017

37. Scrum Guide - Team (Scrum Master)
● Scrum master to the organization
○ Leading and coaching the organization in its Scrum adoption;
○ Planning Scrum implementations within the organization;
○ Helping employees and stakeholders understand and enact Scrum and empirical product
development;
○ Causing change that increases the productivity of the Scrum Team; and,
○ Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the
organization.
Scrum Guide 2017

38. Scrum Guide - Team
● The most famous questions when adopting scrum
○ Where is the project manager?
○ What about the analyst?
○ Can Scrum master and Product owner be the same person?
○ Should the technical team leader be the scrum master?

39. 1995
Scrum
1991
Rapid Application
Development
History Timeline
1970
Waterfall
1996
Extreme
Programming
1997
Feature Driven
Development
2001
Agile Manifesto
2003
Lean
2006
Kanban
2009
Scrum Guide

40. ● Kanban is Japanese for “visual signal” or “card.”
● 1940s, Toyota developed Kanban.
● Kanban Principles
○ Visualize work - Kanban Board
○ Limit work in progress (WIP)
○ Focus on flow
○ Continuous Improvement
Kanban

41. Kanban
● Scrum vs Kanban
Scrum Kanban
Pre-defined roles of Scrum master, Product owner
and team member
No prescribed roles
Timeboxed sprints Continuous flow
At the end of each sprint if approved by the PO Continuous delivery or at the team's discretion
Velocity Cycle time
Teams should strive to not make changes to the
sprint forecast during the sprint.
Change can happen at any time

42. 1995
Scrum
1991
Rapid Application
Development
History Timeline
1970
Waterfall
1996
Extreme
Programming
1997
Feature Driven
Development
2001
Agile Manifesto
2003
Lean
2006
Kanban
2009
Scrum Guide
2018
Kanban for
Scrum

43. ● The flow-based perspective of Kanban can enhance and complement the Scrum
framework and its implementation.
● Scrum mandates that the Sprint Backlog be transparent, but it provides limited
guidance on how to accomplish this.
● Scrum doesn’t it define how to achieve explicit transparency to the flow of work
into the Product Backlog.
● This is where Kanban can help. By visualizing work in new way.
● Scrum team needs to define its workflow.
● The definition of "Workflow" includes a shared understanding within the Scrum
Team of how work is defined (work items), the start state of the process, the
active states for the work items, and the finished state of the process.
Kanban Guide for Scrum Teams
Scrum.org: Kanban Guide for Scrum Team

44. ● Kanban Practices
○ Visualization of the Workflow - the Kanban Board
○ Limiting WIP
○ Active Management of Work Items in Progress
○ Inspect and Adapt Workflow
● The four basic metrics of flow that Scrum Teams using Kanban will need to track
are as follows:
○ Work in Progress (WIP): The number of work items started but not finished
○ Cycle Time: The amount of elapsed time between when a work item "starts" and when a work item
"finishes."
○ Work Item Age: The amount of elapsed time between when a work item "started" and the current
time.
○ Throughput: The number of work items "finished" per unit of time.
Kanban Guide for Scrum Teams
Scrum.org: Kanban Guide for Scrum Team

45. ● 2014, Scrumban combines the structure of Scrum with the flow-based methods of
Kanban.
● Scrumban is a great solution for teams who need the structure of Scrum with the
flexibility of a flow-based method, or for teams who are looking to transition from
Scrum to Kanban.
Scrumban

46. Scrumban
● Here are the elements of Scrum & Kanban that are incorporated into the
Scrumban method:
Scrum
Iteration planning at regular intervals, synchronized
with reviews and retrospectives
Assure necessary level of analysis before starting
development
Prioritization on demand -- provides team with the
best thing to work on next
Kanban
Pull system and continuous workflow: Pull items into
Doing as the team has capacity
Explicit limits on how many items are in progress at
any time
Short lead times -- emphasize just-in-time analysis
and planning
Focus more on cycle time than burndown

47. 1995
Scrum
1991
Rapid Application
Development
History Timeline
1970
Waterfall
1996
Extreme
Programming
1997
Feature Driven
Development
2001
Agile Manifesto
2003
Lean
2006
Kanban
2009
Scrum Guide
2009
DevOps
2018
Kanban for
Scrum

48. ● DevOps is a culture, a movement, a philosophy.
● DevOps is the combination of cultural philosophies, practices, and tools that
increases an organization’s ability to deliver applications and services at high
velocity.
● Transitioning to DevOps requires a change in culture and mindset. At its simplest,
DevOps is about removing the barriers between two traditionally siloed teams,
development and operations.
DevOps

49. ● Continuous Integration
● Continuous Delivery
● Microservices
● Infrastructure as Code
● Monitoring and Logging
● Communication and Collaboration
DevOps - Practices
AWS: What is DevOps?

50. 1995
Scrum
1991
Rapid Application
Development
History Timeline
1970
Waterfall
1996
Extreme
Programming
1997
Feature Driven
Development
2001
Agile Manifesto
2003
Lean
2006
Kanban
2009
Scrum Guide
2009
DevOps
2011
SAFe
2018
Kanban for
Scrum

51. SAFe
Scaled Agile Framework

52. Nexus
Scrum.org: Nexus Guide

53. 1995
Scrum
1991
Rapid Application
Development
History Timeline
1970
Waterfall
1996
Extreme
Programming
1997
Feature Driven
Development
2001
Agile Manifesto
2003
Lean
2006
Kanban
2009
Scrum Guide
2009
DevOps
2011
SAFe
2018
Kanban for
Scrum
2014
Spotify

54. Spotify Engineering Culture
Tribe Tribe
Squad
Chapter
Guild
[Video] Spotify Engineering Culture - Part 1

55. 1995
Scrum
1991
Rapid Application
Development
1976
Waterfall
1996
Extreme
Programming
1997
Feature Driven
Development
2001
Agile Manifesto
2003
Lean
2006
Kanban
2009
Scrum Guide
2014
Spotify
2009
DevOps
2011
SAFe
History Timeline
2018
Kanban for
Scrum

56. Agile Methodologies Used
State of Agile Report, 2018

57. Agile Techniques Employed
State of Agile Report, 2018

58. Engineering Practices Employed
State of Agile Report, 2018

59. Engineering Practices Employed
State of Agile Report, 2018

60. Shu-Ha-Ri
Shu (Follow the rule)
The student follows the teachings
of one master precisely. He
concentrates on how to do the task,
without worrying too much about
the underlying theory.
Ha (Break the rule)
the student begins to branch out.
With the basic practices working he
now starts to learn the underlying
principles and theory behind the
technique. He also starts learning
from other masters and integrates
that learning into his practice.
Ri (Be the Rule)
Now the student isn't learning from
other people, but from his own
practice. He creates his own
approaches and adapts what he's
learned to his own particular
circumstances.
Shu-Ha-Ri is a way of thinking about how you learn a technique. The name comes
from Japanese martial arts (particularly Aikido),
Shu-Ha-Ri By Martin Fowler
Alistair Cockburn introduced it as a way of thinking about learning techniques
and methodologies for software development.

61. Thank you :)
Don’t forget to record you happiness @ Happiness Door