Agile Organizations

INDR3076/ INDR3055
Dr. Pınar Efe
[email protected]
Lecture 2 – Introduction to Agile concepts
How are we doing projects in a traditional way?
• We strive to see the big picture in advance, estimate from the very beginning,
and plan each stage from the very beginning
• We measure the success of the project according to the success of the
predictions and plans made
• We want the customer to know and define what they want from the very
beginning
• We can show the product to the customer/end user in the final stages of the
project
• We do not want changes after analysis
• We see employees as resources like machines and include them in the planning

Initiation Planning Execution Monitoring Closure

Problems of Traditional Models
Predictive
Planning
Controlling
Upfront Design
Low Customer Value
Poor Visibility
Too Risky
High Cost of Change
High Reworking
Cost of Change
64 percent of features in products are “rarely
or never used” in software projects

Standish Group Study Report

What is ‘agility’?
SPEED
A
A O
D
D N
A
A
P
P
T
T
A
T
A
I
S
O
Y
N 10
The ability of a business
system to rapidly respond
to change by adapting its
initial stable configuration
Agile methods first emerged in software
industry
• Agile methods emerged as a response to the challenges and limitations of
traditional software development approaches
• Traditional methods often emphasized
• rigid planning
• long development cycles
• a sequential process,
which struggled to adapt to rapidly changing requirements and customer needs
• Agile is not just a methodology, it is a cultural shift that encouraged
collaboration, transparency, and continuous improvement.
• Its principles have expanded beyond software development, influencing
industries like manufacturing, marketing, and even education.
History of agile approaches - 1
1. The Early Foundations (1950s-1990s):
Iterative and Incremental Approaches Emerge
1950s-60s: Early iterative approaches appeared in manufacturing and engineering
fields. Concepts like Toyota's Lean Manufacturing introduced principles of waste
reduction and continuous improvement, which later influenced Agile.
1970s-80s: Software development began to move away from rigid, linear models:
• Waterfall Model (1970): Introduced as a sequential development approach, but its limitations—such
as inflexibility to changes—spurred interest in iterative models.
• Incremental Development (1980S): Delivered parts of the software in smaller iterations, focusing on
delivering functional features early.
• Spiral Model (1986): Combined iterative development with risk management.
History of agile approaches - 2
2. Pioneer Methods (1990s):
Seeds of Agile in Early Frameworks
• Rapid Application Development (RAD): Focused on prototyping and user feedback
for faster delivery.
• Scrum (1995): Introduced by Jeff Sutherland and Ken Schwaber. Scrum defined
concepts like sprints, product backlogs, and daily stand-ups.
• Extreme Programming (XP, 1996): Introduced practices such as pair programming,
test-driven development, and frequent releases.
• These methods emphasized adaptability, collaboration, and frequent delivery of
working software, setting the stage for Agile principles.
History of agile approaches - 3
3. The Birth of Agile (2001):
Agile Manifesto
• In February 2001, 17 software developers met in Snowbird, Utah, to create a
unifying philosophy for lightweight development methods.
• The Agile Manifesto was published.
• The manifesto introduced 12 principles, including delivering value early, embracing
change, and empowering self-organizing teams.
History of agile approaches - 4
4. The Rise of Agile Frameworks (2001-2010):
Scaling Agile and Broad Adoption
• Scrum (Expanded): Scrum gained significant traction as organizations began adopting
its ceremonies (e.g., sprints, retrospectives).
• Kanban (2004): Derived from Lean, Kanban emphasized visualizing workflows,
limiting work in progress, and continuous delivery.
• Scaled Frameworks: As Agile adoption grew, frameworks for large organizations
emerged:
o SAFe (Scaled Agile Framework): Provided a roadmap for implementing Agile across entire
enterprises.
o LeSS (Large-Scale Scrum): Adapted Scrum for multi-team setups.
o Disciplined Agile (DA): Offered a toolkit for scaling Agile practices.
History of agile approaches - 5
5. Agile Beyond IT (2010-2020):
Expansion into Other Domains
• Agile in Business: The principles of Agile began influencing business processes,
marketing, and operations. Concepts like Agile Marketing and Agile HR emerged.
• Agile Leadership: Leadership practices shifted toward servant leadership,
empowering teams, and fostering adaptability.
• Cross-Industry Adoption: Agile spread to industries such as healthcare, education,
and manufacturing, where adaptability and iterative feedback loops added value.
• DevOps Integration: Agile was integrated with DevOps practices, emphasizing
automation, collaboration between development and operations, and continuous
delivery.
History of agile approaches - 6
6. Agile Organizations(2015s and beyond):
A Holistic Transformation
• What Are Agile Organizations?
• Agile organizations are those that operate with the principles of flexibility, responsiveness,
and customer-centricity across all functions besides IT.
• They are designed to quickly adapt to change, leveraging cross-functional teams and
decentralized decision-making.
• Key Characteristics of Agile Organizations:
• Team of Teams: Fluid, cross-functional teams empowered to make decisions.
• Flat Structures: Reduced hierarchy to enable faster communication and decision-
making.
• Customer-First Approach: Delivering continuous value through customer feedback.
• Agile Operating Models: Using frameworks like SAFe or LeSS across the enterprise.
Agile Manifesto
• On February 11-13, 2001
• the Lodge at Snowbird ski resort in the Wasatch mountains of Utah
• Seventeen people
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Individuals and interactions over
processes and tools
❑ Skills and mindset of team members, team spirit and collaboration
are more important for the success of a project than processes and
tools
➢ Co-location and direct communication are important drivers for
team productivity
➢ Written documents and workflow tools should be seen as starting
points for direct communication, they don‘t replace it!
➢ Good processes will help a good team perform better but they
won‘t save a poor team or a doomed project.
➢ Individuals sign up for tasks and commit to goals
Working software over
comprehensive documentation
❑ Implemented use cases and passed test cases are a good way to
measure progress in a project
❑ Delivered business value is the ideal way to measure progress in a
project
❑ Development documentation (Requirements, Design) does not have
a business value by itself. Nevertheless they are necessary
prerequisites and valuable assets.
➢ Project burnup charts are used for monitoring progress
➢ Temporary documents are reduced or eliminated from the
process where possible
Customer collaboration over
contract negotiation
❑ Written documents are a limited means of communication with the
potential of misunderstandings
❑ Requirements originate from stakeholders: our customers
❑ Ideally the stakeholders are involved directly
➢ Progressive lockdown of requirements in parallel to development
➢ No sign-off on requirements before implementation
➢ Direct dialogue between Development and PO
➢ Direct involvement of external customers wherever possible
Responding to change over
following a plan
❑ New information is continuously generated within a project and coming from
outside
❑ Requirements change at a considerable pace, no process is able to provide
100% stable requirements
➢ Planning is done with different levels of granularity
➢ Fine-grained planning is done only with a short planning horizon
➢ Change is considered normal, not an exception
➢ Customer orientation and maximizing the business value are considered
more important than scope stability
➢ Scope stability is not considered a value by itself
➢ Product Owner has the right to make changes to the backlog for iterations
that are not started, at any time
➢ Very lightweight CR process
Principles behind the Agile Manifesto
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Principles behind the Agile Manifesto-2
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Principles behind the Agile Manifesto-3
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Agile Manifesto on the Web:

http://www.agilemanifesto.org/

http://www.agilemanifesto.org/iso/tr/
Agile Methods

FDD
XP DSDM

Crystal
Scrum
Kanban
Some Statistics
• Scrum is the most used agile method, 63% of agile teams follow the Scrum
methodology
• Over 70% report using Agile in their SDLC, while 42% said their organizations use
a hybrid model that includes Agile, DevOps, or other choices
• The larger the organization, the more likely it is to use a hybrid model — 49% of
large companies and 45% of medium-sized companies are doing so
• Bigger teams are also more likely to still use Waterfall (31% of large and 38% of
medium-sized)

Source: 17th Annual State of Agile Development Survey, Version One, 2023.
Agile Methods Highlights
• Early and continuous delivery of software
• Iterative and incremental development
• Variable scope
• Adaptive planning
• Continuous collaboration with customer
• Continuous update according to changes, embracing the change even in late
phases
• Value people and their interaction
• Continuous improvement
Development is iterative and incremental
Analysis, design, coding, and testing are
continuous activities
Scope can vary
Adaptive Planning in Agile

«Plans are nothing; planning is everything.» Dwight D. Eisenhower

Traditional Agile

Predictive Adaptive
Planning Planning
Predictive Planning
Traditional approach carry out planning for the whole project at the
start of the project
«Plan your work, work your plan»

• Success => According to plan

• Requires stable requirements
Requirements change in software projects are never stable
Adaptive Planning
• Planning and execution is done multiple times for small slices
• Subsequent planning takes input from the previous iterations
• Planning is ongoing activity
Early and continous delivery
 3
Client

Server 2
value
DB 1

1 2 3 4
Dikey değer üretimi
Client 1 2 3
value
Server

DB

1 2 3 4 5
People vs Process

Motivated Employees
Face to face communication
Low hierarchy
Self organization

Satisfied Customers
Inspect and Adapt
12nd principle of Agile Principle
“At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.”
Comparison of Traditional and Agile Development processes
Traditional Agile
Development Process Development Process
«Fail-late» is typical Risk-driven approach enforces a
Project Failure Problems become visible «Fail-early» if major problems
after Integration occur
Due to short iterations that deliver
executable software, the project
Release date is hard to
Ability to progress becomes very
predict and influence
meet release transparent.
towards the end of a
dates Even a troubled project is able to
troubled project
meet the release date (by
reducing functionality)
 Traditional Agile
Development Process Development Process
Changes are treated as a
Goal is to reduce changes after business as usual. Agile practices
Requirements
requirements «sign-off» to a such as progressive requierments
changes
minimum lock-down reduce impact of
changes.
Product owner can correct
requirements based on feedback
Quality of from customers by delivering
Often irrelevant or over-
requirements intermediate product versions.
engineered requirements
definition
Focus on business value reduces
over-engineering.
ROI is considered in initial Process requires prioritization
ROI business case, prioritization and and supports permanent
optimization optimization of ROI are not optimization of ROI. Features are
enforced prioritized by business value.
 Traditional Agile
Development Process Development Process
Management of Dependencies are Dependencies are managed
project managed on task level in on goal level in product
dependencies Gantt charts backlogs
Priorities can be shifted
Effect on Domino effect may delay
easier to protect most
corresponding several projects, shift of
important projects from
projects priorities is difficult
delays
Opportunity to ship the
Opportunity for implemented parts after any
early testing and No shippable product iteration with limited
project-specific before test phase additional effort. Each
shipments iteration creates an
intermediate product release.
 Traditional Agile
Development Process Development Process
Seperate projects or project One project and one team
Project
teams: Definition, defines and realizes the
organization
Development, Test Teams..etc product.
Product Owner define the
Project manager assigns
Team goals. The team manages
tasks, project members
management itself. Scrum master coaches
execute them.
team.
Methods and tools are
Methods and No or little standardization of
standardized across projects,
tools methods and tools.
e.g., TDD and JUnit.
Agile Myths
• Agile is a silver bullet.
• Agile is anti-documentation.
• Agile is anti-planning.
• Agile is undisciplined.
• Agile is anti-architecture.
• Agile doesn't scale.
Agile is not a silver bullet
• There is no silver bullet ☺
• It is just a method: you can fail just as spectacularly on an agile
project as you can using any other traditional methods
• «Fail fast, fail cheap» (due to transparency and visibility it brings)
Agile is not anti-documentation
• Many documents need to be written on agile methods as well
• Do not write documents for documentation's sake.
• Documents support working software
Agile is not anti-planning
• A lot of planning in agile projects
• Already many planning activites: Iteration planning, Daily planning,
Release planning…etc
• Planning is ongoing activity. «Not anti-static planning» would be
correct
• The plans are expected to change and tools like burndown charts are
used track and make these changes visible
Agile is disciplined
Agile methods require a lot of hard work, courage, and discipline
Technical excellence is key
• You have to test.
• You have to get feedback.
• You have to regularly ship software.
• You have to change and update the plan.
• You have to deliver bad news early
Agile is not anti-architecture
• Keep things simple, and only add the complexity when
you need it.
• Leave upfront complex architectures, instead encourage
emergent architectures developing by needs
Agile could scale
• Like any other software process models, agile could scale
• Scaling is hard work – no easy magical way to coordinate,
communicate and keep large groups of people but
• There are some frameworks, Nexus, SAFE, we will cover thorough the
end of semester
How the agile methodology really
works?

• https://www.youtube.com/watch?v=1iccpf2eN1Q&ab_c
hannel=InfoWorld

59
Thanks!

60