An Alternative Method To The Madness
0 likes274 views
This document discusses a shift towards a more agile project delivery mindset. It advocates for an iterative, incremental framework like Scrum to deliver working products more quickly. This allows companies to get feedback sooner, reduce risks, and adapt to changes instead of attempting to plan all requirements upfront. The document compares the agile philosophy which values collaboration, working software, and responding to change, to a more traditional waterfall approach of sequential planning and control.
An Alternative Method To The Madness
- 1. A shift in the Project Delivery Mindset Ronald T Kimura
- 2. “Insanity: doing the same thing over and over again and expecting different results.” – Albert Einstein Ronald T Kimura 7/2/2010 2
- 3. All requirements are not known from the “get-go” Uncertainties and changes are a fact of life Working products aren’t available until after the final stages of the development cycle The project triangle’s flexibility isn’t so flexible Most projects attempt to “boil the ocean” “Information is not knowledge. The only source of knowledge is experience.” – Albert Einstein Ronald T Kimura 7/2/2010 3
- 4. get more for every dollar on development spend? have customer accountability and deliver products that meets their needs? get a competitive advantage by releasing products to market sooner? ROI sooner rather than later? reduce schedule, budget, technical and market risks? maintain a predictable and stable project cash flow? identify problems sooner rather than later? improve employee retention and recruiting? Companies must be adaptable to survive and prosper during these economic times Ronald T Kimura 7/2/2010 4
- 5. An iterative, incremental framework, one of the methods of Agile development Framework: ◦ 3 roles – Product Owner, SCRUM Master, team ◦ 4 artifacts – Product Backlog, Release burn down, Sprint backlog and Sprint burn down ◦ 5 meetings – Release & Sprint planning, Daily SCRUM, Sprint review & retrospective Rules bind the framework Controls - Transparency, Inspection and Adaption “You have to learn the rules of the game. And then you have to play better than anyone else.” – Albert Einstein Ronald T Kimura 7/2/2010 5
- 6. Speed is the new competitive advantage Ronald T Kimura 7/2/2010 6
- 7. Agile (SCRUM) Waterfall Philosophy The agile philosophy holds that the best way to meet customer Process driven, command and control needs is through the collaboration of a committed group of Evaluate it – is it worth doing, who will be involved what will be the impact? people, who focus on achieving results quickly, with as little Plan it – what is involved, what are the risks, what are the costs? process overhead as possible. Do it – according to the plan and guided by key behaviors… Close it – review what have we learnt. Paradigm Empowerment Control Collaboration Contracts Code Documentation Project Vision The vision creates the features estimates The plan creates cost/schedule estimates Values Individuals and interactions Processes and tools Working Software Comprehensive documentation Customer collaboration Contract negotiation Responding to change Following the plan Success Defined by responsiveness to customer requests Achieved by the planned scope Working software / product On‐time and on‐budget Assumption Requirements change frequently, even month to month Requirements are well understood and will not change Focus Working product incrementally Product delivery at end Process Empowerment Sequential, linear ‐ upfront planning and scheduling activities, then execution No steps involve long lead time or lots of specialized resources All steps are known and can be estimated with reasonable accuracy Control – defined (every piece of work be completely understood) Control ‐ empirical (frequent inspect & adapt) Start with requirements, leads to results, stops Incremental results Requirements Collaboration through direct dialogue Documentation and specifications upfront It is not enough to just trim budgets and postpone strategic initiatives Ronald T Kimura 7/2/2010 7
- 8. Leads to “cowboy” programming Lack of planning No documentation Rework is needed and costly Only for small simple projects The most effective way to create value is to deliver, get feedback and adapt Ronald T Kimura 7/2/2010 8
- 9. Ronald T Kimura 7/2/2010 9
- 10. Ronald T Kimura 7/2/2010 10
- 11. Ronald T Kimura 7/2/2010 11
- 12. Source: The Standish Group Ronald T Kimura 7/2/2010 12