Agile Project Planning and Management

Transcription

1 Agile Project Planning and Management Carl Erickson Atomic Object LLC July 2007 Atomic Object 1

2 Plan is a Noun Success requires a plan heavyweight upfront document created at point of maximum ignorance worked backwards from fixed dates often pulled from thin air often created with little technical staff input estimates made without requirements close cousin of traditional, sequential processes July 2007 Atomic Object 2

3 Natural Result Plan is treated as holy writ significant investment in time linear and logical shows a path to successful completion tracking progress according to the plan imposing discipline on developers change is not viewed positively July 2007 Atomic Object 3

4 July 2007 Atomic Object 4

5 Plan is a Verb Plans are worthless, planning essential. Dwight Eisenhower (American general and President) When reality diverges from the plan hide reality, or adjust the plan? Planning in agile dev so important, we do it continuously July 2007 Atomic Object 5

6 Planning The hardest problems are not technical involve people at least proportional to team size July 2007 Atomic Object 6

7 FEAR July 2007 Atomic Object 7

8 Legitimate customer fears Won't get what they ask for Will ask for the wrong things Pay too much for too little Won't see a meaningful plan Won't know where the project really stands Won't be able to react to changes in the business July 2007 Atomic Object 8

9 Legitimate developer fears Will be told to do more than they know how to Will be told to do silly things Will have hard problems to solve without help Will be given responsibility, but no authority Won't be given clear descriptions of what is needed Will have to sacrifice quality to a deadline Won't have enough time to succeed July 2007 Atomic Object 9

10 Results of Fear Unproductive meetings Memos and notes ("you said on Dec 12,...") Unwillingness to share information Coverups Building walls Withdrawal of talent Disengagement emotionally July 2007 Atomic Object 10

11 No One Knows Everything Business people know scope priorities dates Technical people know how long things take consequences process July 2007 Atomic Object 11

12 Planning Addresses Fear, Merges Knowledge It is not anti-change spray stuff happens Embracing change knowing reality vs tracking a plan always work on most important thing coordinate people understand the consequences of change July 2007 Atomic Object 12

13 Why We Plan To address legitimate fears We plan in order to work on the most important thing coordinate people understand the consequences of change We don t plan in order to control events July 2007 Atomic Object 13

14 July 2007 Atomic Object 14

15 July 2007 Atomic Object 15

16 Failures in Planning Planning by activity, not feature Lateness accumulates Activities are not independent Applications are not developed by priorities Confusing estimates with commitments July 2007 Atomic Object 16

17 Activities vs Features Planning by activity, not feature customers don t care about activities it s hard to spot missing features when the plans are in terms of activities activities can t be judged done activities don t finish early (Parkinson s Law) July 2007 Atomic Object 17

18 Lateness Accumulates Activities tend to finish late, but never early Traditional planning focuses on the dependencies of activities Gantt charts Downstream activities are at risk they probably can t start early they may be late themselves they inherit every previous schedule slip July 2007 Atomic Object 18

19 Dependence not Considered Example planning for 10 main web pages, 5 hours each for styling, 50 hours total what if the first one takes 10 hours? Do you update the plan? assume you ll get faster? assume you ll get lucky? July 2007 Atomic Object 19

20 Using Customer Priorities Traditional plans are made in terms of activities or infrastructure customers don t understand these customers don t get value from these customers can t evaluate these When things get tight what gets dropped may be more important than what got built July 2007 Atomic Object 20

21 Dealing with Uncertainty The future is impossible to know Software projects are risky and complex July 2007 or they shouldn t be done Implications of uncertainty dates are really ranges estimates include a probability Don t plan to get it all right, up front iterate Atomic Object 21

22 Summary Agile planning differs from traditional planning more focused on planning, not a plan embraces change is continuous July 2007 Atomic Object 22