Dilbert Management tips Scott Adams

Transcription

1 Dilbert Management tips Scott Adams 1

2 Dilbert Management tips Scott Adams 2

3 Dilbert Management tips Scott Adams 3

4 Dilbert Management tips Scott Adams 4

5 Dilbert Management tips Scott Adams 5

6 Dilbert Management tips Scott Adams 6

7 Dilbert Management tips Scott Adams 7

8 Dilbert Management tips Scott Adams 8

9 9

10 10

11 11

12 12

13 13

14 14

15 15

16 16

17 17

18 18

19 19

20 20

21 Scott Adams, the Manager The principles I tried to establish with the staff early on, that seemed to have stuck, include these: Have fun. Loosen up. Try something new. Often. Keep whatever works. No penalty for a new idea failing. Trying is the thing. Employees are more important than customers. Stop asking Scott for approval. Just do it. Managers get to see the financials. Being a jerk to coworkers is grounds for termination. Do whatever seems smart and fair to make customers happy. Watch the competition closely and borrow their best ideas. 21

22 Chapter 8 - Steering the Project CSc 171 Fall 2016 How to get there : 8.1 Steer with rhythm 8.2 Conduct Interim Retrospectives 8.3 Rank Requirements 8.4 Timebox Requirements Work 8.5 Timebox Iterations to 4 or fewer Weeks 8.6 Use Rolling-Wave Planning & Scheduling 8.7 Create a Cross-Functional Project Team 8.8 Select a Life Cycle based on our Project s Risks 8.9 Keep Reasonable Work Hours 8.10 Use Inch-Pebbles 8.11 Manage Interruptions 8.12 Manage Defects from the beginning 22

23 What s the rhythm? Some projects churn, making progress in stops and starts. Some projects zoom, accomplishing more than was expected as they go. What s a reasonable rhythm? Serial life cycle projects may have lots of churning at different phases and mask the problems. Agile life cycle project may churn during iteration planning, but then establish a consistent rhythm of producing time boxed work. 23

24 Shorter iterations the key to establishing rhythm Why? Long iterations make it harder to maintain rhythm Shorter iterations: - Provide more frequent feedback - Reveal problems Causes of lost rhythm : Member estimates are poor Members are doing too much Members don t know what to do first Waiting for task assignments and requirements Waiting for someone else s work 24

25 Causes of lost rhythm (continued) Not knowing the most important requirements. Not knowing when the gathering should end. Allowing GUI changes without knowing the impact. Not knowing how parts fit into the architecture. Not staffing the project with the right people at the right time. 25

26 Introspectives by design! Avoid repeating bad experiences! At the end of the project yes! Throughout the project yes! Serial, iterative & incremental at the completion of each milestone Agile at the end of every iteration 26

27 Rank the Requirements Iteration Planning Knowing what to implement first, second, third, RANKING THE FEATURES First, assign weights Score each alternative against each criterion (Scale: 0-10 with 10 the most favorable) Feature 1 Feature 2 Weights Weighted Weighted Criteria (1,2,4,8, ) Score Score Score Score Impact of feature Time to implement Importance to customer Resource availabiltiy Fig

28 Rolling-Wave Planning CSc 171 Fall 2016 A rolling wave plan is a continuous detailed schedule that's only a few weeks long. As you complete one week of detailed schedule, you add another week to the end of the schedule. With a four- week rolling wave schedule, I never have less than four weeks of detailed schedule, and I never have more than four weeks of detailed schedule. Rothman: 28

29 Beware of Technical Debt Creep CSc 171 Fall 2016 Design and quality flaws in a team's work become a "debt" that must eventually be paid back. Part of the cost is obvious: the time & materials to repair the problem. The non-obvious and probably non-measurable costs: How much effort will it take to get to the root cause of the defect so that it doesn't occur a second time? How much will it affect our "goodwill" and thus reduce further and repeat sales? 29

30 The non-obvious and probably non-measurable costs (continued) How much will the existence of one defect hide the existence of other defects (with their own costs)? How much will the defect demoralize the team and increase staff turnover or reduce productivity? How much of an opportunity will the defect create for competitors? How much will the defect increase maintenance and support costs? In other words, every time someone asks a team to let quality slide, they are asking the team (and the organization) to take on debt with an unknown interest rate. 30

31 TIP (page 154) Build Replanning into the Project Schedule Unless you are using an agile life cycle, make your replanning activities explicit. And make them often enough that the schedule doesn t fly away from you without you realizing it. 31

32 Finishes work faster A Cross Functional Team maybe unless members collaborate across functions Each Single Function team member finishes their parts faster, but with no review or verification by the other function teams. Once their work is complete they return to their silo. Single functional team members wait for work to be assigned. Provides for a diverse project team with collaboration occurring throughout the project. 32

33 What Life-cycle? 8.8 page 156 Select a Life Cycle Based on Your Project s Risks But there must be evidence that the Life Cycle selected has resulted in deliveries that are on time, within budget and provide all of what was expected 33

34 Agile Life Cycle CSc 171 Fall

35 Agile Life Cycle CSc 171 Fall

36 Agile Life Cycle CSc 171 Fall

37 Agile Life Cycle CSc 171 Fall

38 Getting more done with overtime Industrial accidents increase disproportionately as hours increase above forty per week, or above 8 hours per day. CSc 171 Fall 2016 More than half of all industrial accidents occur in jobs with extended working hours. The generally-accepted hypothesis is that the accidents result from tiredness. Does programming require that we be mentally alert? The risk of an accident is essentially doubled at 12 hours compared to 8 what about the risk of inserting bugs? and the ability to find and remove them? 38

39 The more overtime the less work accomplished! Figure on roughly 6 hours of technical work per day 7 or 8 hours a day can be maintained for 1 or 2 weeks Sustained overtime has diminishing returns 39

40 There has also been recent news about the impact of long hours on medical interns, reporting that after long sessions they are twice as likely to have an auto accident while driving, and five times more likely to have a near miss. After a month of overtime, they drive, literally, as if they had had three or four stiff drinks. 40

41 Two types: 1. Project interruptions Manage Interruptions Protect the iteration s work Handle the interruptions between iterations Keep track of all interruptions 2. People interruptions Asking a question is an interrupt Have interrupt places to minimize those interrupted 41

42 Dilbert Management tips Scott Adams 42

43 Dilbert Management tips Scott Adams 43

44 Dilbert Management tips Scott Adams 44

45 Manage Defects throughout! CSc 171 Fall 2016 Minimize the build-up of technical debt Have developers developing and testers testing simultaneously Maintain a Defect Tracking System Number Description Priority Severity Exposure When to fix! 17 Name is address High Low High This iteration! Address is name (Our customers will be will confused!) be 45

46 Prepare for Influence (page 162) Make sure the team owns the problem & the solution. Collaborate give and receive help. Understand team member s motivation (WIIFM 1 ). Listen to the team. Buy-in means the team has a say and maybe the right ideas. Don t let your ideas get in the team s way Other? Remove Yak-shaving impediments 1 What s In It For Me 46

47 Software Development & Software Operations Cause of interrupts and delay in project development Operations: the folks that are responsible for monitoring and operating the production applications The product that is the revenue generator Development: the future product in development The interrupts and delays in development Transfer resources as needed 47

48 Operations (example) CSc 171 Fall 2016 Software Operations Manager: Leads the operations behind the release and on-going success of GBS's innovative O+M Track software product. Works closely with other GBS managers as well as senior consulting staff to define, implement and assess operational enhancements that benefit our clients and our business. Critical areas of responsibility include: - developing short and long-term operations plans - developing and customer support - developing online demonstration and sales processes - working closely with key clients to scope, sell and deliver customized support programs. 48

49 Development and Operations CSc 171 Fall 2016 Interaction of development and operations with operational needs interrupting the development work. Difficult if not impossible to plan and estimate work needed for the development. Advice: Assign some folks to operations full-time (and rotate) for a week or two Assume full-time development can occur 2 to 3 days a week, the rest of the time folks multi-task Add more people with secondary responsibility to the project Treat the operational task as product backlog work 49

50 Looking for defects from day 1! Categorize by severity and priority! Severity CSc 171 Fall 2016 Technical impact High severity: system cannot run or delivers incorrect results Priority Business impact The customer will be adversely affected by the problem Defect When to Number Short Description Priority Severity Exposure Fix 17 Name is address; address is name (reversed) Figure 8.2 High Low High (our customers will be confused) This iteration