Fifth discipline presentation (1)

The Fifth Discipline
Applications to Software Engineering
The Fifth Discipline:
Applications to
Software Engineering
Presented by
Benjamin Edwards
1

and Processes
• The Fifth Discipline was written by Peter
M. Senge of the Organization Learning
Center at MIT
• It is written in the “language of
managers”
• It is applicable to software engineers
and organizations and software
engineering processes
2

and Processes
• The Fifth Discipline is about creating a
Learning Organization
• It is not a “how to” guide
• It introduces 5 Disciplines that must be
learned by the people of a learning
organization
3

and Processes
• It introduces 7 Learning Disabilities that
must be overcame by the people of a
learning organization
• It introduces 11 Laws that are
fundamental to understanding a
4

Learning Disabilities
• There are 7 Learning Disabilities
• The Learning Disabilities are destructive
ways of thinking
• They must be “unlearned” to become a
5

Learning Disabilities:
1. “I am my position”
• When people in organizations focus
only on their position
• Tends to produce little sense of
responsibility for the results produced
when all positions interact
• “I am a programmer, I am not
responsible for testing or architecture”
6

2. “The enemy is out there”
• Produces a sense of “out there” and “in
here”
• Reduces the likelihood of leverage
and/or solutions being found “out there”
that can be used “in here”
• “Our team could never adopt a new
process, it’s too used to not having
one”
7

3. The illusion of taking charge
• Disguises reactive solutions as
proactive
• Fighting the “enemy out there” rather
than seeing how we contribute to our
own problems”
• “We are finding more bugs in our code,
thus we need to hire more testers”
8

4. The fixation on events
• Trying to associate a problem in the
organization with a specific event
• “The admin module had too many bugs
in it. John programmed the admin
module. John must be a bad
programmer.”
• Maybe John has been put in charge of
too many modules
9

5. The parable of the boiled frog
• Learning to see slow, gradual
processes
• Processes, not events, are often the
problems in organizations
• Recognize that the all night coding
sessions may help meet short-term
deadlines, but it continually makes
maintenance improvements harder
10

6. Learning from experience delusion
• Learning from experience is difficult
when there is a gap between action and
consequence
• It’s hard to tell when the class you took
on software processes pays off two
years later
11

7. The management team myth
• Most organizations reward people for
advocating their views, not inquiring into
complex or unpleasant issues
• Who’s going to more liked by their
manager? The developer who questions
the architecture up front or the one who
dutifully codes band-aids?
12

Learning Disabilities
• How many of the Learning Disabilities
are prevalent in organizations you’ve
worked in?
• They can be overcome by mastering the
Disciplines of a learning organization
13

The disability and ability to form a
Disability Ability
1. “I am my position” 1. “I am part of the whole”
2. “The enemy is out there” 2. “I am part of the problem”
3. The illusion of taking charge 3. I am willing to change myself to
bring about broader changes
4. The fixation on events 4. Ability to identify patterns and
root causes
5. The parable of the boiled frog 5. Ability to slow down and detect
gradual and slow changes
6. Learning from experience
delusion
6. Ability to anticipate effects
through the use of field
management practices
7. The management team myth 7. Learning team (balance giving
and receiving advice)
14

Disciplines of the Learning
Organization
• There are 5 Disciplines* of the Learning
Organization
• They deal with ways of thinking
• The Disciplines must be understood and
followed by everyone in a learning
organization
*) Discipline = a branch of knowledge
15

Disciplines of the Learning Organization:
1. Personal Mastery
• “Personal mastery”: the discipline of
personal growth and learning integrated
into everyday activities
• It entails mastery of skills and personal
understanding (learning)
• PSP is similar to personal master on a
software engineering level
16

2. Mental Models
• Mental models are pre-conceived
notions that restrict creative thinking
• Mental models are largely responsible
for self-fulfilling prophecies
• If you think from the start that your team
is incapable of adopting a rigid process,
you will probably find that you are right
17

3. Shared Vision
• A shared vision is an idea that becomes
a force in those who adopt it
• At the simplest level, a shared vision is
an answer to the question of “what do
we want to create”
• When software builders buy into a
shared vision, development becomes
more than just “writing code to spec”
18

4. Team Learning
• Team learning is what the allows the
whole to become more than the sum of
its parts
• Team learning builds upon personal
mastery and shared vision
• Team learning requires facilitation
(dialogue) and results in teams that
perform better together
19

5. Systems Thinking
• Systems Thinking is the Fifth Discipline
• Systems thinking entails understanding
that processes are cyclical, not just
cause and affect
• Mastering the Fifth Discipline entails:
– mastery of the other disciplines
– mitigation of learning disabilities, and
– obeying the laws of the 5th Discipline
20

Disciplines of the Learning
Organization
• The Disciplines are applicable to
software development organizations
• They represent ways of thinking that
allow organizations to improve their
process
• They are applicable to all organizations
21

Laws of the Fifth Discipline
• There are 11 Laws of the Fifth
Discipline
• They are the fundamental principles that
guide Systems Thinking
22

Laws of the Fifth Discipline:
1. Today’s problems come from
yesterday’s solutions
• Shifting a problem from one part of a
system to another is not a solution
• Coding a band-aid for a bug is not a real
solution, it just calls for more band-aids
in the long-run
23

2. The harder you push, the harder the
system pushes back
• “Compensating feedback”: when well
intentioned actions cause the system
reaction to offset the benefit
• The longer and later you code, it seems
the more bugs you create and more
longer and later nights
24

3. Behavior grows better before it grows
worse
• Compensating feedback usually
involves a time delay
• Short-term benefits may be easy to
recognize, but not long-term disbenefits
• Coding a band-aid for a problem may fix
it temporarily, but somebody has to
maintain that band-aid code
25

4. The easy way out usually leads back in
• Pushing harder on familiar remedies
while fundamental problems persist
• “We need a bigger hammer” syndrome
• “We are behind on the schedule, better
stay late and code all night” – the next
week we are behind on the schedule
again
26

5. The cure can be worse than the
disease
• Applying more and more of “the
solution” can make matters worse
• Long term solutions must strengthen the
system (improve the process) to
shoulder its own burdens
• Problems with the schedule may not
mean work longer and harder
27

6. Faster is slower
• Virtually all natural systems have
intrinsically optimal rates of growth
• A software project is no different
• Adding twice as many people to a team
doesn’t mean you get it done twice as
fast
28

7. Cause and effect are not closely
related in time and space
• Cause and effect are not always close
together in time and space
• A bad architectural decision may not
reveal itself until weeks or months into
the project
• Bugs injected in code early are not
revealed if there isn’t ongoing quality
assurance built into the process
29

8. Small changes can produce big results
• The areas of highest leverage are often
the least obvious
• The principle of leverage: small,
focused actions can produce significant,
enduring results
• An improvement in the process
probably yields more benefits than
hiring a new contractor
30

9. Can can have your cake and eat it too,
but not at once
• Decision making cannot be the product
of just static thinking
• Consider the benefits of long-term
employees vs. contractors: competitive
labor vs. committed employees
• How both options can improve over time
must be considered
31

10. Dividing an elephant in half does not
produce two small elephants
• Living systems have integrity that
depends on the whole
• A piece of software that “kind of works”
doesn’t work
• The module, class, etc. you code has to
work on its own and as part of the whole
application
32

11. There is no blame
• Systems thinking shows us there is no
“out there”
• You and the cause of your problems are
part of a single system
• Just because your organization won’t
officially adopt a process doesn’t mean
you can’t adopt one for yourself
33

Laws of the Fifth Discipline
• Hopefully you’ve seen some consistent
themes here
• Hopefully you see how the laws of
system thinking apply to software
engineering and process improvement
34

and Processes
• The Fifth Discipline is about creating a
Learning Organization
• The Disciplines, Laws, and Learning
Disabilities are applicable to all types of
organizations, and even the software
development process
35

and Processes
• So how would the software process of a
Learning Organization look?
• The process would be cyclical, dealing
with dynamic complexities
• Problems and risks would be openly
discussed between developers and
managers
36

and Processes
The process would be adopted by
everyone in the organization:
developers through managers
• The process would be ever-improving
• The process would be adaptable
• We’ve already learned all this!!!
37

Fifth discipline presentation (1)

More Related Content

Similar to Fifth discipline presentation (1)

Recently uploaded

Fifth discipline presentation (1)