Look Before you JUMP: The Trials and Triumphs of Implementing Standard Software Development Processes

1. Look Before you JUMP:The Trials and Triumphs of Implementing Standard Software Development Processes Presented By: Michael Stefanini, Jet Propulsion Laboratory, California Institute of Technology

2. Grady Booch Speaks… “People are more important than any Process. Good people with a good process will out perform good people with no process any time.” - Grady is a Chief Scientist for Rational at IBM, author, and distinguished SW Expert, and the creator of UML

3. Everyone Cares about Process. • Project Managers • Technical Development • QA and Support • Operations • Other

4. Why do Projects Fail? • Ad hoc requirements management • Overwhelming complexity • Failure to address risks early on • Ambiguous communication • Brittle architecture that fails to perform under stress • Undetected inconsistencies in requirements, designs, and implementations • Insufficient testing • Subjective assessment of project status • Uncontrolled change propagation • Insufficient automation

5. How can Projects Succeed? • Pure team talent • Clear team direction • Flexible yet predictable environment • True senior management support • Maintain a project structure to provide planning and quick response • Ensure pre-project readiness assessment & overall project planning • Create a partnership with your partners and your stakeholders • Adequately resource your project • Communicate and manage expectations • Encourage functional ownership of the project • Develop dependency-driven project schedules that can be tracked and managed to provide early warnings and help avoid crises

6. Why does Software Process Adoption Fail? In other industries, process innovation has been the contributing factor in explosive growth.  Software development continues largely unchallenged with a record of late deliveries, budget overruns, missed expectations, and low quality.  6

7. Antagonists to Adoption • Developers and Managers are Undisciplined • Reward, hire, and promote people who demonstrate discipline. • Bloated Process Bureaucracy • When people are given the assignment to develop a process area: they behave as if they are writing a Ph.D. thesis.  • Ineffective Process • Just because you have invested a great deal of time developing and deploying your process, it does not mean it is good or effective . 7 courtesy of the YouWantItWhen.com, Bill Miller

8. Antagonists to Adoption • Management Priority & Commitment • Employees take serious what management demonstrates to be important.  • Don’t expect a good process to be introduced in less than 18 months. • Projects and Customers Are Un-Supportive • Software teams misuse process as a way of defending slips or holding off customers.  • Customers are often satisfied with informality. • Developers pit Customers against the process. Customers are told the process is the reason they aren’t getting what they want or need. 8 courtesy of the YouWantItWhen.com, Bill Miller

9. Antagonists to Adoption • Poor Process Audits • Auditors may find it uncomfortable writing up a negative audit report.  The only question the auditor should set out to answer is, is the team following the documented process? • Doesn’t Promote Change • The first version of your process will be buggy.  You’ll need to tweak it, and maybe even overhaul parts of it.  9 courtesy of the YouWantItWhen.com, Bill Miller

10. Antagonists to Adoption • Been There Before • Usually the process experience isn’t positive: management removes its sponsorship just as things were actually starting to improve. People become cynical about these initiatives, and they come to know if they hold management off long enough, they will abandon the initiative. • Process Fads • Adopting and rolling out process shares many characteristics with keeping to a diet program.  10 courtesy of the YouWantItWhen.com, Bill Miller

11. What is the biggest hurtle in your area? • Discipline • Bad/Bloated Process • Management Support • Developer Support • Poor Implementation

12. JUMP – IT Software Processes at JPL

13. Project Strategy – The Deming Model No one has to change. Survival is optional. Baseline Change Improvement over Time

14. Artifacts Checklists Roles and Phases Responsibility Reviews Components of JUMP Authority Delivery

15. Reviews

16. Review Goals and Intent • Goal One: Achieve Commitment and Consensus The four formal JUMP Reviews are Confirmation and Commitment Reviews, not Design Reviews • Reviews will focus on the completion of Checklists and Artifacts • Reviews will assure commitment from responsible team members and interfaces • Reviews also align projects with the organization’s directives and enforce policies • Only the Configuration Manager can “FAIL” a project

17. How do you document review decisions? • Reviews? What Reviews? • Informally / Show of Hands • Email / Signature • Formal Scorecard with Feedback and Metrics

18. Scorecard for Domain Architect

19. Inception Phase Review Metrics

20. Elaboration Phase Review Metrics

21. Key Process Concepts

22. JIT Training and IT Accelerators

23. JUMP Tools: JUMP Schedule Purpose: Track major schedule and delivery milestones The provided schedule already includes all required (and many optional) JUMP milestones – a turn-key project schedule! Dedicated Project Scheduler helps to keep projects on track and provide a Master Schedule Rollup

24. Technology Positions

25. Measuring Success

26. The Impact of Process • Task with more robust process had 74% fewer defects for every 1000 lines of code and was 20% more productive. Comparison is for period from July 2005 to July 2007 Results from a 2 year study on Mission Design and Navigation Software by William Taber

27. Time Spent in Elaboration NASA Study • Planning < 5% of project costs  150% - 200% Overruns • Planning > 5%, but <10% of project costs 100% - 120% Overruns • Planning > 10% of project costs  0% - 50% Overruns Front-End Planning includes 1. Defining the scope 2. Developing the requirements 3. Preliminary design Source: NASA study performed in 1990

28. PMI Study PMI suggests >20% • In the US, < 5% of total project time is spent planning with 150-200% overruns—NOT ENOUGH • In Japan, > 30% of total project time is spent planning with 0-20% overruns—TOO MUCH • Based on a 1995 study by C. Christensen • PMI suggests >20% of total project time be spent planning • Based on Generic Industry Studies

29. Typical Resource Use by Phase By: Yuri Gomes

30. Do you track your own Project Performance Metrics? • Yes • No

31. Project Metrics

32. UX Evaluation Report

33. Weekly Project Status Reports

34. Best Practices

35. Time Boxing: Set Expectations Early! Schedule(Time) Scope(Quality) Budget(Resources) You can’t get it faster, better and cheaper!

36. Development Services Catalog

38. JUMP TOOLS

39. Tales from the Pit

40. Transition Schedule-Induced Delivery (De-Scoped) Construction Construction Each Phase Builds upon the Previous Elaboration Elaboration Inception Undocumented Requirements Scope Creep Build and Fix Shifting Expectations Initial Agreement Project Failure results from not being in position to meet the customer’s needs

41. Focus on People and Not Artifacts!

42. How Many Faces Did You See?

43. Other Lessons Learned Large Training Classes do NOT work for most people Training is provided “Just In Time” IT Accelerators provides experienced coaching Affinity Groups provide more coaching, as well as Mentoring, on the job Training, and Career Guidance Inject QA Early – Especially during Requirements Gathering Hold Architecture Reviews Early and Often Keep the Review Board Lean 43

44. Thank You Michael.Stefanini@jpl.nasa.gov

45. Traps

46. How Managers Destroy Projects courtesy of the TechRepublic’s Robert Bogue Usually, the Managers drive to deliver on time and on budget will be at odds with the development team’s desire to create a quality product Management is well meaning and may be using proven techniques, but some have the potential for disaster Here are four ways managers may unwittingly sabotage a project

47. Trap #1: False Dates • Project managers must put dates out in front of the group to motivate them but when the dates aren’t realistic and they are consistently missed, it’s time to reevaluate the plan Solution: • Developers need to be involved in setting the schedule • Developers need to be held accountable to the schedule • Managers need to aggressively defend the project schedule and the developers courtesy of the TechRepublic’s Robert Bogue

48. Trap #2: Pretend All Is Well When it comes to project management, ignorance is not bliss Solution Frequent and open status reports: Try the 2-minute status report format on a daily or weekly basis Utilize Project Management Office resources or your line management to report on an issue within a project. You can report anonymously if you need to courtesy of the TechRepublic’s Robert Bogue

49. Trap #3: Ignoring Dependencies • In software development we have a great number of techniques for delaying dependencies Solution • The Task Plan • Developers must communicate with the project manager • If the Project manager ignores or defers any issues, the development team must elevate the problem to another level (see Trap #2) or the project could fail courtesy of the TechRepublic’s Robert Bogue

50. Trap #4: Time Boxing • Getting top honors in the list of things which can destroy software quality is the practice of time boxing • Time boxing works—most of the time—because it does three things • It forces the developer to be creative in finding a solution that fits within their budget • It eliminates unnecessary frills and scope-creep that don’t necessarily add value • It ensures iteration remain smaller and manageable while deferring good ideas for later • Time-Boxing is used to manage scope-creep and defend the project plan – NOT to manage the schedule or deadlines courtesy of the TechRepublic’s Robert Bogue