Principles of Managing Software Development - Bas Vodde - Agile SG 2013

Presented in Agile Singapore 2013 Conference

Managing software is different from other management because of the nature of software development. It is the softness, the focus on learning, the complexity and the lack of physical material that causes this difference. Companies who manage software development without understanding this different nature will grossly mismanage their development effort, causing it to be ineffective at best and resulting in low quality software. In this session, Bas will explore five principles of managing software development that he has distilled out of his own development experience and the experience of coaching management of several large agile development projects.

Transcript

1. www.odd-e.com
   Things you need to know
   about managing software
   development
   For Agile Singapore
   

   View Slide

2. Who am I?
   •Name: Bas Vodde
   •Originally from Holland
   •Lives in Singapore
   -Lived in China and
   Finland
   •Works for Odd-e
   •Agile coach, SW developer
   •Experience with large
   embedded products
   2
   Scaling Lean & Agile
   Development
   Thinking and Organizational Tools
   for Large-Scale Scrum
   Craig Larman
   Bas Vodde
   Practices for
   Scaling Lean & Agile
   Development
   Large, Multisite, and Offshore Products
   with Large-Scale Scrum
   Craig Larman
   Bas Vodde
   

   View Slide

3. Avoid Taylor
   3
   

   View Slide

4. Konosuke Matsushita (1)
   4
   "We will win and you will lose. You cannot
   do anything about it because your failure is
   an internal disease. Your companies are
   based on Taylor's principles. Worse, your
   heads are Taylorized, too. You firmly
   believe that sound management means
   executives on one side and workers on the
   other, on one side men who think and on
   the other side men who can only work. For
   you, management is the art of smoothly
   transferring the executives' ideas to the
   workers' hands.”
   

   View Slide

5. Konosuke Matsushita (2)
   5
   “We have passed the Taylor stage. We are aware that business has
   become terribly complex. Survival is very uncertain. Therefore, a
   company must have the constant commitment of the minds of all of its
   employees to survive. For us, management is the entire workforce's
   intellectual commitment at the service of the company.
   We know that the intelligence of a few technocrats—even very bright
   ones—has become totally inadequate to face these challenges. Only
   the intellects of all employees can permit a company to live with the
   ups and downs and the requirements of its new environment. Yes, we
   will win and you will lose. For you are not able to rid your minds of the
   obsolete Taylorisms that we never had.”
   

   View Slide

6. 6
   There is no question that the
   cost of production is lowered by
   separating the work of
   planning and the brain work
   as much as possible from the
   manual labor
   

   View Slide

7. Scientific Management
   • Application of Science to find “one best method”
   • Separation of “‘planning/improving” and execution
   • Strongly influenced existing management practices:
   - Project Management
   - Management by Objectives
   - Incentive systems
   - Sig Sigma / CMMi
   7
   

   View Slide

8. Deming / Juran
   8
   The Taylor System
   has become so
   obsolete that is should
   be replaced.
   Remove barriers that
   rob people of their
   right to pride of
   workmanship
   

   View Slide

9. TEAM = PRODUCT
   9
   

   View Slide

10. Jim McCarty
    10
    Anything you need to
    know about the team can
    be discovered by
    examining the product,
    and visa versa
    TEAM = PRODUCT
    http://www.mccarthyshow.com/the-23-rules-of-thumb/
    

    View Slide

11. Team = Product
    • Focus on improving people!
    - Working together, sharing work!
    - Books, movies, learning sessions.
    - Training, coaching.
    • More than on:
    - Process (let the people do that!)
    - Metrics... also for people themselves
    11
    Avoid adding people!
    

    View Slide

12. People matter *most*!
    12
    1
    28x
    Original
    1968
    Sackman
    study
    Between
    fastest and
    slowest
    1
    14x
    Corrected
    Sackman
    study
    (2000)
    Between
    fastest and
    slowest
    1
    5x
    Boehm
    study
    (1975)
    Common
    difference
    1
    4x
    Prechelt
    (2000)
    Between top
    quarter
    and bottom
    quarter
    For Software teams.
    This difference
    is even bigger
    

    View Slide

13. Joel Spolsky
    13
    It's not just a matter of "10 times more productive."
    It's that the "average productive" developer never
    hits the high notes that make great software.
    http://www.joelonsoftware.com/articles/HighNotes.html
    

    View Slide

14. 14
    What is the most often-overlooked
    risk in software engineering?
    Incompetent programmers. There are
    estimates that the number of
    programmers needed in the U.S.
    exceeds 200,000. This is entirely
    misleading. It is not a quantity problem;
    we have a quality problem. One bad programmer can easily
    create two new jobs a year. Hiring more bad programmers will just
    increase our perceived need for them.
    If we had more good programmers, and could easily identify them,
    we would need fewer, not more.
    David Parnas
    

    View Slide

15. Understand: Motivation
    15
    Autonomy
    Mastery
    Purpose
    

    View Slide

16. Work re-design
    16
    Principles of Job Enrichment:
    1. Combine tasks
    2. Form natural work units
    3. Client relationships
    4. Vertically load the job
    5. Feedback channels
    

    View Slide

17. 17
    22
    My passion has been to build an enduring
    company where people were motivated
    to make great products. Everything else
    was secondary. Sure, it was great to
    make a profit, because that was what
    allowed you to make great products.
    Ref: http://hbr.org/2012/04/the-real-leadership-lessons-of-steve-jobs/
    

    View Slide

18. Knowledge Creation
    18
    

    View Slide

19. Knowledge Creation
    19
    

    View Slide

20. Knowledge / Time
    20
    Time
    Customer Understanding &
    Product Knowledge
    Decisions likely wrong.
    Made with the least
    amount of knowledge
    More chance that
    the decision is good.
    Made with the max
    amount of knowledge
    

    View Slide

21. Accurate Early Estimagics
    21
    

    View Slide

22. 22
    Improve
    Software
    Increase
    Learning
    

    View Slide

23. Nature of Software
    23
    

    View Slide

24. View Slide

25. Gardening - Hunt / Thomas
    25
    Rather than construction, software is
    more like gardening -- it is more organic than
    concrete.
    You constantly monitor the health of your
    garden, and make adjustments as needed.
    People are comfortable with the metaphor of
    building construction: it is more scientific
    than gardening, it’s repeatable.
    But we’re not building skyscrapers -- we
    aren’t as constrained by the boundaries of
    physics and the real world.
    

    View Slide

26. View Slide

27. View Slide

28. Refactoring visualized
    28
    Original program:
    Making changes:
    More changes:
    Without refactoring:
    Cost of change
    increases rapidly!
    With refactoring:
    Small change
    Refactor
    Etc
    Cost of change
    does not increase
    

    View Slide

29. 29
    Legacy Being Created
    

    View Slide

30. Refactoring
    30
    

    View Slide

31. Safety net - Unit tests
    31
    

    View Slide

32. 2 main causes of legacy
    32
    Pressure for unrealistic
    commitments
    Lack of skill
    

    View Slide

33. 33
    Manage
    Products
    Not
    Projects
    Not all work must be done in “projects.”
    That is simply one way of organizing work.
    

    View Slide

34. Missing metrics
    34
    

    View Slide

35. Productivity
    35
    

    View Slide

36. Productivity - Martin Fowler
    36
    We see so much emotional discussion about
    software process, design practices and the like.
    Many of these arguments are impossible to resolve
    because the software industry lacks the ability to
    measure some of the basic elements of the
    effectiveness of software development. In particular
    we have no way of reasonably measuring
    productivity.
    Productivity, of course, is something you determine
    by looking at the input of an activity and its output.
    So to measure software productivity you have to
    measure the output of software development - the
    reason we can't measure productivity is because
    we can't measure output.
    http://martinfowler.com/bliki/CannotMeasureProductivity.html
    

    View Slide

37. Technical Debt
    37
    

    View Slide

38. 38
    Ohno / Deming
    Don’t look with your eyes,
    look with your feet...
    people who only look at the
    numbers are the worst of all.
    Deadly Disease #5
    Running a company on
    visible figures alone
    

    View Slide

39. Example: Test Coverage
    39
    

    View Slide

40. Metrics and their use...
    40
    Don’t focus on the
    metric and the numbers
    But on who sets them
    and how they use them
    

    View Slide

41. Go and See
    41
    

    View Slide

42. Performance Reviews
    42
    http://online.wsj.com/article/SB122426318874844933.html
    http://www.vanityfair.com/online/daily/2012/07/microsoft-downfall-emails-steve-ballmer
    

    View Slide

43. 43
    Point #12
    Remove barriers that rob people of their
    right to pride of workmanship. This means
    abolishment of the annual or merit rating.
    Deming
    Deadly Disease #3
    Evaluation by performance, merit
    rating, or annual review of
    performance
    

    View Slide

44. System Dynamics
    44
    

    View Slide

45. Systems Thinking
    45
    • Making better decisions by seeing:
    • Systems dynamics
    - What variables are there,
    how do they relate?
    - Especially considering time
    • Mental models
    - What assumptions are there?
    • Root causes
    • Optimizations
    - and local optimizations
    • And... Go and See
    

    View Slide

46. Example: Refactoring
    46
    amount of bad
    code
    panic
    amount of code
    smells
    time spend on
    bug fixing
    motivation
    developers
    quick hacks
    opportunity for
    # of bugs
    indicates
    O
    refactoring
    O
    

    View Slide

47. Example:
    Product Management
    47
    # difficult-to-achieve
    promises to customers
    (new feature)
    development
    speed
    # of quality-destroying and
    other shortcuts to apparently
    meet the contract
    Goal:
    get sales
    commissions
    difference
    between
    R&D
    capability
    and
    commitment
    customer
    satisfaction
    & trust in us
    - bad quality
    - # defects
    - # good people
    who quit
    O
    O
    O
    QF
    O
    O
    P-M
    flexibility and control
    of product content,
    release date, and
    investment
    Goal:
    meet competitor
    offer to get deal
    ROI of resource
    allocation
    decisions
    competitors promise
    matching plus extra
    features
    customer wants
    "everything" from us
    Goal:
    differentiate to
    compete
    QF
    transparency
    in R&D
    O
    O
    O
    O
    time until
    feedback
    O
    sequential life-
    cycle practices
    O
    O
    QF
    O
    same dynamic
    in competitors
    P-M
    collaboration
    & trust with
    R&D
    - # of features
    - lines of code
    O
    effort dedicated
    to maintenance
    of existing code
    customer
    collaboration
    handing over
    commitments
    by negotiating
    a contract
    with R&D
    R&D expected to
    "meet their
    commitments"
    transparency in
    organization
    www.craiglarman.com
    www.odd-e.com
    Copyright © 2010
    C.Larman & B. Vodde
    All rights reserved.
    

    View Slide

48. Closing
    48
    

    View Slide

49. Principles of Managing
    Software Development
    49
    • Be aware of Taylor
    • Team == Product
    • Software Development is Knowledge Creation
    • The Nature of Software is to Grow Ugly
    • The 2 Forever Missing Metrics
    Meta-principle:
    Systems Thinking
    

    View Slide

50. Questions
    50
    

    View Slide