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
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
3. Avoid Taylor 3
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.”
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.”
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
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
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
9. TEAM = PRODUCT 9
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/
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!
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
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
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
15. Understand: Motivation 15 Autonomy Mastery Purpose
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
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/
18. Knowledge Creation 18
19. Knowledge Creation 19
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
21. Accurate Early Estimagics 21
22. 22 Improve Software Increase Learning
23. Nature of Software 23
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.
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
29. 29 Legacy Being Created
30. Refactoring 30
31. Safety net - Unit tests 31
32. 2 main causes of legacy 32 Pressure for unrealistic commitments Lack of skill
33. 33 Manage Products Not Projects Not all work must be done in “projects.” That is simply one way of organizing work.
34. Missing metrics 34
35. Productivity 35
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
37. Technical Debt 37
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
39. Example: Test Coverage 39
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
41. Go and See 41
42. Performance Reviews 42 http://online.wsj.com/article/SB122426318874844933.html http://www.vanityfair.com/online/daily/2012/07/microsoft-downfall-emails-steve-ballmer
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
44. System Dynamics 44
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
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
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.
48. Closing 48
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
50. Questions 50