The Fifth Discipline

1
The Fifth DisciplineApplications to Software
Engineering

• Presented by
• Benjamin Edwards

2
The Fifth DisciplineApplications to Software
Engineering 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

3
The Fifth DisciplineApplications to Software
Engineering 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

4
The Fifth DisciplineApplications to Software
Engineering 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 learning organization

5
Learning Disabilities

• There are 7 Learning Disabilities
• The Learning Disabilities are destructive ways of
  thinking
• They must be unlearned to become a learning
  organization

6
Learning Disabilities1. 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

7
Learning Disabilities2. 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, its
  too used to not having one

8
Learning Disabilities3. 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

9
Learning Disabilities4. 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

10
Learning Disabilities5. 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

11
Learning Disabilities6. Learning from
experience delusion

• Learning from experience is difficult when there
  is a gap between action and consequence
• Its hard to tell when the class you took on
  software processes pays off two years later

12
Learning Disabilities7. The management team myth

• Most organizations reward people for advocating
  their views, not inquiring into complex or
  unpleasant issues
• Whos going to more liked by their manager? The
  developer who questions the architecture up front
  or the one who dutifully codes band-aids?

13
Learning Disabilities

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

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

15
Disciplines of the Learning Organization1.
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
Disciplines of the Learning Organization2.
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
Disciplines of the Learning Organization3.
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
Disciplines of the Learning Organization4. 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
Disciplines of the Learning Organization5.
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 Discipline1. Todays problems
come from yesterdays 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
Laws of the Fifth Discipline2. 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
Laws of the Fifth Discipline3. 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
Laws of the Fifth Discipline4. 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
Laws of the Fifth Discipline5. 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
Laws of the Fifth Discipline6. 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 doesnt
  mean you get it done twice as fast

28
Laws of the Fifth Discipline7. 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 isnt ongoing quality assurance built into
  the process

29
Laws of the Fifth Discipline8. 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
Laws of the Fifth Discipline9. 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
Laws of the Fifth Discipline10. 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 doesnt
  work
• The module, class, etc. you code has to work on
  its own and as part of the whole application

32
Laws of the Fifth Discipline11. 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 wont officially
  adopt a process doesnt mean you cant adopt one
  for yourself

33
Laws of the Fifth Discipline

• Hopefully youve seen some consistent themes here
• Hopefully you see how the laws of system thinking
  apply to software engineering and process
  improvement

34
The Fifth DisciplineApplications to Software
Engineering 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
The Fifth DisciplineApplications to Software
Engineering 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
The Fifth DisciplineApplications to Software
Engineering 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
• Weve already learned all this!!!