The Human Side of Software Development


Published on

For class in my MSc of Software Engineering (2003)

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Stephen

    Alex: 15 years as embedded, real-time software engineer for military and network security organizations
    Guy: been working in industry for about 4 years now. My background is web-based applications in the oil/gas and health-care industries. My current team practices some aspects of agile such as TDD and scrum meetings, but doesn't do a good job on things such as pair programming and lack of code ownership.
    Stephen: 32 years experience in commercial applications

    We are basing our observations on the agile methods as they are described by their originators and assume they will be implemented as described by their originators.
  • Stephen

    Hockey example
  • Alex
  • Alex
    McConnel p.249
  • Alex
    We will focus on software engineers
  • Alex
  • Alex
    Human beings are motivated by unsatisfied needs. The certain lower needs have to be satisfied before the higher needs can be satisfied. This was a radical departure from two of psychology of this day: Freid.
    Freid: a littlie difference b/w the motivations of humans and animals (studies of mentally ill people).
    Maslow: People are self-protecting, self-govering (autonomous) and trustworthy.
  • Alex
    Guy will discuss environment issues

    Hygiene Factors
    that can demotivate if they are not present - such as supervision, interpersonal relations, physical working conditions, and salary.  Hygiene Factors affect the level of dissatisfaction, but are rarely quoted as creators of job satisfaction.

    Motivation Factors
    that will motivate if they are present - such as achievement, advancement, recognition and responsibility.  Dissatisfaction isn't normally blamed on Motivation Factors, but they are cited as the cause of job satisfaction.

  • Alex
  • Stephen
    The more that people perceive that their personal goals are in harmony with organizational goals, the greater will be their contribution to organizational goals.
  • Stephen
  • Stephen
  • Stephen
  • Stephen
    Some of these are hygiene, some are motivators.
  • Stephen
    Main finding: the very strong emphasis on “possibility for growth”.
    More strongly motivated for opportunities for technical supervision, by peer relationships, and by personal life.
    Less strongly motivated by recognition, responsibility, salary, and status.
  • Stephen
  • Stephen
  • Alex
    Top talent – is it good?
  • Alex
  • Alex
  • Alex
    Opposite of collective ownership and refactoring
  • Alex
  • Alex
  • Alex
  • Alex
  • Alex
  • Alex
  • Alex
  • Guy
  • Guy
    Joel Splosky
  • Highlight:
    - Light on two sides of every office… Layout makes it like everyone has a corner office.
    - Large amount of square footage
  • Highlight:
    - few obstructions under desk
    - non-L shape: straight edge allows for easier pair programming
  • Good things:
    - study actually broke down the space required for a worker in this field. (cabinets, desk, etc) Provided some basis for why they felt 100 sq. ft. was needed.

    - study applies to modes of work practiced by programmers in late ’70s. (for example needed large desk space for reviewing voluminous code listings)
    - some numbers are given but not supported: for example, 50% group, 30% private, 20% other work time requirement split
  • Peopleware -> Coding War Games
    1984 – 1986 : 600 developers from 92 companies have participated
    Each participant designs, implements, and tests a medium-sized application to a spec.
    Work performed in their own work environment with their normal tools, etc…
    If IBM was certain less than 100 sq. ft. was demotivational, what is rest of industry doing?

    Critique of this part of study:
    - numbers somewhat dated
    - dedicated work space per person -> not necessarily easy to compare numbers; different views on “dedicated”
  • How many people work in offices with intercoms?

    How many people can set their phone to “Do not disturb”

    Cornell study on effect of music and programming in the 1960s. Given a task to perform various bitwise operations on an input data stream. Creative people got that the net effect was to have input number == output number.
  • Ask for a show of hands of people who are allowed to work from home…

    What does need for “off-site” work indicate about the quality of the office itself?

  • Current accounting typically treats investment in people as an expense not a capital investment. Weird…

    Other opportunity costs:
    \"situations where you're not able to work at capacity\"

    - customer lists leaving with employees
  • Describe figure as a composition of three different sources (not clear which ones)
    Interesting rules of thumb, however can’t find anything to back this up…
  • Slack is an adjustment of the flexibility versus efficiency tradeoff to provide a capacity for change in the enterprise.
    Question: Is the drive for efficiency seen in the last decade through down-sizing a good thing?
    Can giving 110% be a bad thing in some ways?
  • You’re efficient when you’re doing something with minimal wasted effort.
    You’re effective when you’re doing the right something.
    They are not necessarily fully overlapping in many organizations.
    Winning on tactics, but losing on strategy.

    Example, management wants a new product out yesterday. You need to get X lines of code completed that day to avoid punishment. Brief encounter with customer gives you pause. Do you ignore it and plow ahead? What if you had more time to think about direction.
  • Taken from Demarco’s Slack
    Difficult to propose change when there is fear of repercussions.
    Best time to change is during good results, growth. Difficult when things are going bad, which is most likely when the change was needed.
  • Dilbert re-considered: Dilbert keeps head down, doesn’t take initiative,
    With slack comes increased responsibility to make good use of it.

  • Problem resolution: often for maintenance of live systems, spend time solving complex, poorly-defined problems
    Creativity: new product development, charter is to explore possibilities and alternatives
    Tactical execution: product-upgrade development; sharp focus on carrying out well-defined plan

    Business: team lead who is first among equals in team, presents single voice to management
    Chief-programmer: From Brooks in Mythical Man-Month, highest performer is key, everyone else is just an aid
    Skunkworks: treated as a black-box by management, team is self-organizing
    Feature: assumes standard hierarchy with devs, testers, analysts, and marketing; feature team is overlay team on top of main teams, that are grouped around a distinct functional area
    Search and rescue: team combines specialized knowledge of certain software/hardware with particular business knowledge; used to quickly solve problems (emergency recovery for example); too short-term for tactical exec
    SWAT: “skilled with advanced tools” extensive knowledge of existing tools; goal oriented…
    Athletic: super-start experts in a particular area; management hires the best in each specialty needed
    Theatre: roles of producer, director, actors: significant negotiation before hand on roles to be assumed by people; provides a way to integrate strong individual contributions within a strong central vision
  • Defensive management: Good for dealing with risk, but bad for dealing with team; must trust them
    Bureaucracy: mindless paper-pushing; can account for large portion of work time
    Separation: crucial to have team working together; only way to have team jell
    Time fragmentation: working on multiple projects, context-switching between various tasks, interruptions
    Quality-reduced: AKA cost-reduced; team doesn’t want to be associated with product; no jelling
    Deadlines: team loses motivation when they know deadline is impossible to meet
    Clique control: management policies explicitly break up teams, should be keeping good teams together
    Overtime: not all on team can do optional overtime; will lead to divisions in team based on effort
  • Defn: a group of people so strongly knit that the whole is greater than the sum of the parts (Peopleware) Such teams have incredible momentum, don’t need to be managed traditionally, just have obstacles removed from path.

    Taken from Rapid Development by McConnell

    Sense of Identity: IBM’s Black Team of Testers: dressed all in black, strange customs, high performance
    Mutual trust: honesty, openness, consistency, respect
    Team size: some experts say the maximum is 10 people, no more

  • Open Kimono says to practice risk management on everything but your people’s success. Must trust them to succeed and accept the occasional failure.

    Demarco’s Laws of Bad Management

    - 2
    law is particularly a problem in organizations with no slack as everyone is overworked.

  • Stephen
  • Stephen
  • Stephen
  • Stephen
  • Stephen
  • Stephen
  • Stephen
    Practices that don’t seem to bear on the people factors motivators: Metaphor, Coding standards,
  • Stephen
    Very 80’s and 90’s

  • The Human Side of Software Development

    1. 1. The Human Side of Agile Software Development Stephen Ford Alex Grabelkovsky Guy Davis 1
    2. 2. Agenda  Observations on people  Traditional System Development  Environmental Issues  Team considerations  Agile methods and people factors 2
    3. 3. Conventional approaches  To profit by our own mistakes  Cost-effective transfer from conventional methods to something more effective… 3
    4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13. Vote 13
    14. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31. Sample Floor Plan 31
    32. 32. Sample Desk Layout 32
    33. 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. 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. 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. 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. 37. People Issues Contents  Human Capital  Productivity Differences  Demarco’s concept of “Slack” 37
    38. 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. 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. 40. Slack at Work… 40
    41. 41. Effectiveness versus Efficiency 41
    42. 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. 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. 44. Team Issues Contents  Types of teams and primary goals  Team killing situations  Team jelling pre-requisites  Management effects on teams 44
    45. 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. 46. Teamicide Defensive management  Bureaucracy  Physical Separation  Fragmentation of Time  Quality-reduced product  Phony deadlines  Clique Control  Overtime  46
    47. 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. 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. 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. 50. SCRUM What is Scrum? (from  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. 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 51
    52. 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. 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. 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. 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. 56. Conclusion  The “e” word applies to Agile Methods as far as programmers are concerned. 56
    57. 57. References Adams, Scott. Dilbert Cartoon. 2003.  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.  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://    57