For class in my MSc of Software Engineering (2003)

1. The Human Side of Agile
Software Development
Stephen Ford
Alex Grabelkovsky
Guy Davis
1

2. Agenda
 Observations on people
 Traditional System Development
 Environmental Issues
 Team considerations
 Agile methods and people factors
2

3. Conventional approaches
 To profit by our own mistakes
 Cost-effective transfer from
conventional methods to something
more effective…
3

4. Why Human Factor?
Software development - human and an

intellectual activity
 Intellect - is it enough to develop a successful
project?
More dimensions?

Physical?

Emotional?

Spiritual?

Do courage, honesty, helpfulness or ... improve an

overall work process?
Manager dilemmas:

How to measure it? How to control it? How to

motivate people?
4

5. Major Issue: Human Being
 Alistair
Cockburn: “People are different,
people are non-linear, people make
mistakes and people work in certain
ways better than others.”
 People:
 Customer, End-user
 Software Vendor (Managers, Engineers)
Everybody does mistakes.
5

6. Classic Mistakes
Steven C.McConnell
- Undermined motivation. Has a larger effect on productivity and
-
quality that any other factor (Boehm 1981)
-
- Weak personnel (Boehm 1981, Lakhanpal 1993)
•
- Uncontrolled problem employees. Failure to take action to deal
•
with a problem employee (Weinberg quot;Phychology of a Computer
Programmingquot;, 1971)
- Heroics. It can be beneficial. (Bach 1995), but quot;can-do attitudes
•
escalate minor setback into true disastersquot; (De Marco 1995)
- Developers-Customer friction: poor communication, conflicts
•
(Jones 1994)
- Lack of user input. (Standish Group 1994)
•
- More ...
•
6

7. Motivation in General
 Maslow’s hierarchy of needs (1954)
Self-actualization
Esteem and autonomy
Belongingness and love
Safety and security
Physiological (food and drink)
7

8. 2 Factor Hygiene and Motivation Theory
Frederick Herzberg, 1987
Hygiene factors: basic conditions

(administration, company policy, working
conditions, salary, security...)
 Conventional software development cares
perfectly about the job environment - Hygiene
factors.
 Hygiene and Motivation MUST be done
simultaneously.
Treat people as best as you can, so they have a

minimum of dissatisfaction
Use people so they get achievement, interest and

they can grow and advance in their work
8

9. Motivation & Movement
Frederick Herzberg: Motivation or Movement?
Motivation – function of growth from getting

intrinsic rewards out of interesting work.
 Movement – function of fear of punishment or
failure to get intrinsic rewards.
 Motivating factors: simulate honest growth and
performance
9

10. Harmony of Objectives
 ThePrinciple of Harmony of Objectives
(Koontz-O’Donnell, 1972)
 The more that people perceive that their
personal goals are in harmony with
organizational goals, the greater will be
their contribution to organizational goals.
10

11. Motivational Factors (1)
Achievement: getting work done; building something that works;

 Advancement: getting more responsibility
Company policy and admin: being in line with written company

direction;
 Job security: a quaint 20th century notion;
 Personal life: the opportunity to spend time with family and
friends and to pursue hobbies and interests unconnected with
work;
Possibility for growth: learn new skills; improve the use of

current skills; become more knowledgeable; unique for each
person;
 Recognition: identification by organization, customers, whatever
of an individual’s contribution,
11

12. Motivational Factors (2)
Relations peers: how you get on with your day-to-day

colleagues;
Relations superior: access to the boss and decision makers;

Relations with subordinates:

Responsibility: ability to make / influence decisions.

Salary:

Status: how your peers value you

Supervision technical: the ability to provide leadership and

oversight in technical activities
Work itself: do the job well;

Working conditions: physical comfort, style and grace;

12

13. Vote
13

14. Motivation: General
Population
Achievement 9. Status
1.
10. Relations superior
Recognition
2.
11. Relations peers
Work itself
3.
12. Supervision technical
Responsibility
4. 13. Company policy and
administration
Advancement
5.
14. Working conditions
Salary
6.
15. Personal life
Possibility for growth
7.
16. Job security
Relations subordinate
8.
14

15. Motivation: Software People
9. Relations subordinate
Achievement
1.
10. Salary
Possibility for growth
2.
11. Personal life
Work itself
3.
12. Relations superior
Recognition
4. 13. Job security
Advancement 14. Status
5.
15. Company policy and
Supervision
6.
technical administration
16. Working conditions
Responsibility
7.
Relations peers
8.
15

16. Motivators by Job Level
Importance of Motivational Factors by Job Level
100
75
Importance
50
Programmer Analyst
Project Leader
Manager
25
0
f
t
t
th
us
s
in
e
el
en
en
er
lif
m
w
Its
at
em
em
pe
ro
al
Ad
St
on
k
G
ev
nc
ns
or
d
rs
an
W
hi
va
tio
Pe
Ac
Ad
la
y
lic
rre
Po
te
In
ny
pa
om
C
Motivator
16

17. Growth Needs vs. Social Needs
Cougar-Zawicki, 1978 Growth Needs vs Social Needs
10.0
7.5
Average Survey Score
5.0
Growth Need
Social Need
2.5
0
Data Processing Professionals Sales Other Professionals Service Clerical Managerial
Profession
17

18. Staffing
Boehm: 5 basic principles

Top talent

Job matching

Career progression

Team balance, coverage

Affected members

Human Resource Management (HRM)

The proactive acquisition, retention, and development of human

resources necessary for organizational success.
HRM has moved from a support staff function (personnel) to a

more strategic role in organizations.
-> job interviews, weekly meetings, birthdays

18

19. ‘70s, 80s, 90s’ Methodologies
All development projects might fit into predefine

templates:
 Tasks
 Tools
 Techniques
 All details are prescribed. Plan-driven, control.
Roles. Documents. Contract-focused.
Responsibility level.
Cost of BUG (left by an inept testing tool might risk

human’s life: software for military, space, medical,
industrial areas)
Punishment.

 Is it draggy? Does it care about emotional &
psychological aspects ?
19

20. Management in conventional
Software Development
 Software management principles haven’t
changed in almost 40 years.
 To organize, ensure, supply, connect, deliver…
 Why do projects fail?
 Critical mission: to recognizing early warning
signs that indicate that something has gone
wrong.
 Project spirit & Team morale
 Mutual Trust (Honesty, Openness, Consistency, Respect)
 Morale problems don’t happen overnight, and they
can’t be resolved overnight
20

21. “Traditional” development
approach: People in Boxes
Gather Requirements (Analyst, Architect)

 Document Requirements (Analyst, Architect)
 Prototype (Architect, Engineers)
 Specifications (business needs to technical
language) (Architect): up to 30% of time
 Program: (Engineers, Manager) 30%
 Testing, fixing (QA, Engineers, Manager):
30%
 Documentation & Delivery
21

22. Boehm- Waterfall Methodology
• The granddaddy of all lifecycle models
• Review and Validation at each step to
determine whether it’s ready to advance
to the next phase
• Document driven – main work products
at each phase: documents
• Interactive back step between each
stage.
Projects: Stable requirements, well-
understood technical methodologies
Not flexible
Different teams: requirements, dev., …
Communication time. Communication
errors.
22

23. Spiral Methodology
 Risk oriented
 Each completed - one stage of
the process. As the spiral
continues, the product matures
 Steady progress from one
stage into the next stage
 Explicit review between stages
 Adv: cost increases, but risks
decrease. Early indications of
any insurmountable risks
 Disadv: complicated, attentive
and knowledgeable
management.
23

24. WinWin Spiral Model
Boehm, Kwan, Port, Madachy …U of South California

Management theory: Make winners of the system’s

key stakeholders
Spiral + TheoryW activities to the front of each step:

priority setting step, introducing intermediate goals.
Decision points: to establish objectives, constraints

and alternatives -> WinWin condition for each point.
Groupware tool: to negotiate mutually satisfactory

(WinWin) system specs.
To extend USC’s Integrated Library System to access

multimedia archives, including films, maps, and
videos.
24

25. WinWin Case Study
Flexibility. The model let the teams adapt to

accompanying risks and uncertainties, such as a rapid
project schedule and changing team composition.
Discipline. The modelling framework was sufficiently

formal to maintain focus on achieving three main, or
“anchor-point,” milestones: the life-cycle objectives,
the life-cycle architecture, and the initial operational
capability.
Trust enhancement. The model provided a means for

growing trust among the project stakeholders,
enabling them to evolve from adversarial, contract-
oriented system development approaches
25

26. Is that so bad?
 We know successful projects
 Technological innovations (military,
academic, non-profitable…)
 Long term projects
 Project deliverables are often not just a
software: OEM, Research, hardware…
26

27. Conclusion: Current Situation
 Market has changed
 Business model has changed
 Players have changed
 Technology has changed
 Last4000 years: Human being …
 Good people or high technology?
27

28. Conclusion: Awkward Age
Software Engineering - 35/40 years (DARPA …)

Software Management - 35/40 years

Software Market - 25 years

E-Market - 10 years

PC: 15 years

WWW: 15 years

Standards: TCP, RFCs …

Software people (22-35 years, today younger)

Computer Science/special education - 20 years

Exigence: we need something Agile

28

29. Environmental Issues
Contents
 Workspace issues
 Sample floor plans, desk designs
 IBM study looking at optimum design
 Comparison of space across industry
 Noise level issues
 Off-site work
29

30. Workspace
Considerations Joel’s Bionic Office
Private offices required
 Cubicle, office, 1.
common-area? Lots of power outlets
2.
Ease of rewiring
 Light and windows 3.
Allow pair
4.
 Furniture
programming
Easy on eyes (rest
5.
vision)
Cool place to hang out
6.
30

31. Sample Floor Plan
31

32. Sample Desk Layout
32

33. IBM Study
Santa Teresa Laboratory, San Jose, 1977

 Interviews and actual use of sample offices
 Based design on actual work practices
 Key results:
Separate offices crucial, noise protection

Minimum of 100 sq. ft. office space

Minimum of 30 sq. ft. desk work space

33

34. Space across industry
Demarco compared

participants in his
“Coding War
Games” to IBM
study
 Average space is
significantly less
than IBM minimum
requirement.
34

35. Noise Level Issues
 Phones, mobiles, pagers, intercoms
 Workers with acceptable noise were 1/3
more likely to produce zero-defect work
in “Coding War Games”
 Study on effect of music on
programming
 No effect found on overall productivity
 Effect on creativeness in problem solving
35

36. Hiding Out
Find workers in conference rooms, lunch

room, libraries… not in their noisy office.
 “Skunkworks” teams in off-site work spaces
 Telecommuting and distributed teams
36

37. People Issues Contents
 Human Capital
 Productivity Differences
 Demarco’s concept of “Slack”
37

38. Human Capital
High cost of turnover (25%+ per year in IT)

Direct cost: job ads, interviewing, overtime,

training
Opportunity cost: missed chances, customer

satisfaction handling
Indirect cost: loss of organizational knowledge,

reduced productivity, lower growth rates
Training cost (ramp-up time in months?)

38

39. Productivity Differences
Best outperform the worst by a factor of 10:1

Best performer is ~2.5 times better than median

performer
Better than half of the median performers outperform

by 2:1 over the other half
39

40. Slack at Work…
40

41. Effectiveness versus
Efficiency
41

42. Capacity for Change
 Requires a corporate vision; shared
identity
 Requires a feeling of safety and trust
 Should be timed to a period of growth
 Demarco argues “Reinvention” is a key
role of middle management; change-
center
 Why is change important?
42

43. Slack’s Impact on People
 Less stress, more time for creativity
 Increased job satisfaction
 Increased responsibility
 Increased trust and respect in
management
 Increased effectiveness
 What are the drawbacks?
43

44. Team Issues Contents
 Types of teams and primary goals
 Team killing situations
 Team jelling pre-requisites
 Management effects on teams
44

45. Types of Teams
Business Team
Primary Goal 
Chief-Programmer

Problem Resolution
 Team
Skunkworks Team
Feature: Trust 

Feature Team

Creativity

Search and Rescue

Feature: Autonomy

Team
Tactical Execution
 SWAT Team

Feature: Clarity Professional Athletic


Team
Theatre Team

45

46. Teamicide
Defensive management

Bureaucracy

Physical Separation

Fragmentation of Time

Quality-reduced product

Phony deadlines

Clique Control

Overtime

46

47. Team Jelling
Shared, elevating vision or Sense of team identity
 
goal Effective

Communication
Results-driven structure

A sense of autonomy

Competent team members

A sense of

Commitment to the team

empowerment
Mutual trust

Small team size

Interdependence among

A high level of

team members
enjoyment
47

48. Team Management
 “Open kimono” management approach
 Opposite of defensive management
 Must trust people to succeed or fail with
autonomy once set to task
 Management mistakes
 Doing more of something that isn’t working
 Shirking management duties to do worker
tasks
48

49. Agile Methods
 XP
 ThePlanning Game, Small Releases,
Metaphor, Simple Design, Testing,
Refactoring, Pair Programming, Collective
Ownership, Continuous Integration, 40-
hour Week, On-site Customer, Coding
Standards
49

50. SCRUM
What is Scrum? (from controlchaos.com)
 Scrum is an iterative, incremental process for developing any product or
managing any work. It produces a potentially shippable set of functionality
at the end of every iteration. It's attributes are:
 Scrum is an agile process to manage and control development work.
 Scrum is a wrapper for existing engineering practices.
 Scrum is a team-based approach to iteratively, incrementally develop
systems and products when requirements are rapidly changing
 Scrum is a process that controls the chaos of conflicting interests and
needs.
 Scrum is a way to improve communications and maximize co-operation.
 Scrum is a way to detect and cause the removal of anything that gets in the
way of developing and delivering products.
 Scrum is a way to maximize productivity.
 Scrum is scalable from single projects to entire organizations. Scrum has
controlled and organized development and implementation for multiple
interrelated products and projects with over a thousand developers and
implementers.
 Scrum is a way for everyone to feel good about their job, their
contributions, and that they have done the very best they possibly could.
50

51. DSDM
Active user involvement is imperative.
1.
The team must be empowered to make decisions.
2.
The focus is on frequent delivery of products.
3.
Fitness for business purpose is the essential criterion for
4.
acceptance of deliverables.
Iterative and incremental development is necessary to converge on
5.
an accurate business solution.
All changes during development are reversible.
6.
Requirements are baselined at a high level.
7.
Testing is integrated throughout the life-cycle.
8.
Collaboration and cooperation between all stakeholders is
9.
essential.
From http://www.dsdm.org/tour/principles.asp
51

52. Are Agile Methods People Friendly?
XP SCRUM DSDM
The Planning Game, Small controls the chaos of Active user involvement,
Achievement
Releases, Simple Design, conflicting interests and team empowered to
Testing, Refactoring, Pair needs; detect and cause make decisions, focus is
Programming, Collective the removal of anything on frequent delivery,
ownership, Continuous that gets in the way of Iterative and incremental
integration, On-site developing and delivering development, all changes
customer, products during development are
reversible, testing is
integrated
Refactoring, Pair team empowered to
Possibility of
Programming, Collective make decisions, all
growth
ownership, changes during
development are
reversible
On-site customer, Active user involvement ,
Work itself
Refactoring, team empowered to
make decisions, all
changes during
development are
reversible
Pair Programming, Active user involvement
Recognition
Collective ownership, On-
site customer,
52

53. Are Agile Methods People Friendly?
XP SCRUM DSDM
Pair Programming, Active user involvement
Advancement
Collective ownership, On-
site customer,
Refactoring, Pair all changes during
Supervision
Programming, Collective development are
technical
ownership, reversible
The Planning Game, Active user involvement,
Responsibility
Testing, Collective testing is integrated
ownership, 40 hour work
week, On-site customer,
Refactoring, Pair improve all changes during
Relations peers
Programming, Collective communications and development are
ownership, 40 hour work maximize co-operation reversible
week,
53

54. Are Agile Methods People Friendly?
XP SCRUM DSDM
Relations
subordinate
Salary
40 hour work week,
Personal life
40 hour work week,
Relations
superior
54

55. Are Agile Methods People Friendly?
XP SCRUM DSDM AM
Temporary + Temporary + Temporary + Temporary +
Job security
On-site customer,
Status
Company policy
and
administration
40 hour work week,
Working
conditions
55

56. Conclusion
 The “e” word applies to Agile Methods
as far as programmers are concerned.
56

57. References
Adams, Scott. Dilbert Cartoon. 2003. http://www.dilbert.com

Boehm “Software Engineering Economics”

Boehm, Barry; Turner, Richard; “Balancing Agility and Discipline” Addison

Wesley, Boston, 2004
Cockburn and Highsmith “Agile Software Development: The People Factor”

Computer IEEE magazine
Demarco, Tom and Timothy Lister. Peopleware: Productive Projects and

Teams. Dorset House Publishing. New York. 1987
Demarco, Tom. Slack: Getting past burnout, busywork, and the myth of total

efficiency. Broadway Books. New York. 2001
Essex, David. “Employee turnover: the costs are staggering”. IT World. 2000.

http://www.itworld.com/Career/1993/ITW2491/
McConnell, Steve. Rapid Development.Microsoft Press. Redmond. 1996

McCue, Gerald. “Architectural Design for Program Development”. IBM

Systems Journal. Vol 17. 1979
Splosky, Joel. “Bionic Office”. Joel On Software. 2003. http://

www.joelonsoftware.com/articles/BionicOffice.html
www.controlchaos.com

http://www.dsdm.org/tour/principles.asp

57