Your SlideShare is downloading. ×
Rapid Project Inception
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rapid Project Inception

6,707
views

Published on

PDF Version

PDF Version

Published in: Technology, Business

0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,707
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
10
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. RAPID PROJECT INCEPTION Opportunity for Increased Agility
  • 2. INTRODUCTION • Rajeev Singh • ThoughtWorks – Global IT Consultancy – Helps organizations drive agility and create software www.thoughtworks.com 1
  • 3. AGENDA • PRESENTATION (30 mins) – History of Agile and it’s benefits – Focus of Agile – Big Picture of Agile in our industry – Anatomy of Rapid Project Inception • Q&A (20 mins) 2
  • 4. Genesis in Iterative and Incremental Development HISTORY OF AGILE 3
  • 5. Concept of agility has been around for almost 50 years 4
  • 6. LAST 50 YEARS Reference: Craig Larman, Victor R. Basili, quot;Iterative and Incremental Development: A Brief History,quot; Computer, vol. 36, no. 6, pp. 47-56, Jun., 2003 • X-15 Hypersonic jet • Project Mercury software development • TRW /Army Site Defense – Ballistic Missile Defense • LAMPS (Light Airborne Multipurpose System), Navy’s Helicopter-to-Ship weapon’s system • NASA’s Shuttle Program (1977-1980) • Spiral Model of Software Development and Enhancement (1985) 5
  • 7. THE COMMON THREAD • These projects had timeboxed ITERATIONS • They all wanted to identify and eliminate risk early 6
  • 8. IT WASN’T ALWAYS AGILE • The approach was called ITERATIVE and INCREMENTAL software development 7
  • 9. BENEFITS WERE ENORMOUS • Allowed a retreat • Provided feedback early • In-Tune with End User needs • Responsive (not predictive) 8
  • 10. IT ALSO PROMOTED • Collaboration • Self-Organization • Learning and Communication 9
  • 11. MAINSTREM ADOPTION • This new approach to software development gained momentum in the industry in the 1990s • Software developers realized the benefits and were willing to adopt and adapt 10
  • 12. BUT NOT SO FAST The PMO/Planning/Governance bodies are still document drive, plan sequentially, and have a gated approach 11
  • 13. Where are we today? FOCUS OF AGILE 12
  • 14. WE HAVE EVOLVED • A wider community in Software Developer practice Agile • Benefits perceived are not just Risk Elimination, collaboration, communication, etc. but also Time to Market. • Agile is seen as an enabler to delivery Quality Products More Often 13
  • 15. Agile’s Economic Impact – Early breakeven compared to Waterfall We can move faster from Idea to Income (Concept to Cash) Reference: Examining the quot;Big Requirements Up Front (BRUF) Approach“ – Scott Ambler http://www.agilemodeling.com/essays/examiningBRUF.htm 14
  • 16. IS THERE ROOM FOR IMPROVEMENT? • Yes! • We can focus on upstream and downstream areas to software development • Agile can be a competitive strategy 15
  • 17. COMPETITIVE STRATEGY? • Hmm, how so? • Well, beat your competition in the race to market • Change your motto from Quality Products More Often to Quality Products More Often and Quickly 16
  • 18. How can we be Quick? FOCUS ON UPSTREAM 17
  • 19. WHY UPSTREAM? • That’s where it all starts • That’s where most time is spent • It may take months to prepare business cases, fund ideas, and charter projects 18
  • 20. What happens before the first release to market? Inception (can be as much as 70% of the time before release-1) Development Deployment and Rollout 19
  • 21. IMPACT OF A SHORT INCEPTION OR RAPID INCEPTION Still release as often First release is quicker Quality Product More Often and Quickly 20
  • 22. How can we speed up and shorten the inception? RAPID PROJECT INCEPTION 21
  • 23. DO WE NEED INCEPTION? • It depends. It’s not a required activity. • Larger project usually require inception to establish project parameters and set pre- design direction 22
  • 24. IS THERE ROOM FOR IMPROVEMENT? • “We already do inceptions, and I don’t see how we can speed it up or improve it.” • “What do you mean by, “It’s too long”? Ours only take 2-3 months.” 23
  • 25. Answer the following questions and if it’s a YES for more than one question, there’s a case for improvement 24
  • 26. HOW’S YOUR INCEPTION • Does inception take more than 40% of the time of the first release cycle? • Is it being done in silos? Are Product Ideation and Product Management teams not collaborating? • Is it scattered between departments and teams? • As a participant do you find inception unproductive? • Do you find inappropriate consumables (deliverables) coming out of inception? 25
  • 27. Participants seem to understand and agree, but actually they don’t Do you find team members having different mental models even after project inception? 26
  • 28. What is Rapid Project Inception? ANATOMY OF RAPID PROJECT INCEPTION 27
  • 29. IT IS • Collaborative & • Workshop Driven Inclusive • Utilizes Low-Fi • Time boxed and Rapid Techniques • Iterative and Feedback Driven • Highly Visual (Tangible Models) • Business Value Focused 28
  • 30. Collaborative and Inclusive There’s wide representation in the workshops 29
  • 31. WORKSHOPS AIM TO • Define the problem • Achieve Common Understanding • Identify Key Business Features • Prioritize the features • Estimate • Consider Technical Options • Develop initial plan and timeline 30
  • 32. Everyone participates Only the right people are in the room. Distractions like electronic toys are discouraged. 31
  • 33. WORKSHOPS • Business Process Model • Lo-Fi Prototypes • Future Perspective* • Estimation • Anchors & Engines* • Prioritization • Roles and Goals • Release Planning • As-Is • Iteration 0, 1 Planning • To-Be • Showcase • Integration Points Patterned on Luke Hohmann’s workshops • Initial Systems http://www.enthiosys.com Architecture 32
  • 34. Low -Fi White boards, index cards, sticky notes and markers are about as much as we need. 33
  • 35. Facilitator Driven To maximized knowledge generation, trained facilitators runs the sessions so that the key participants are best utilized. 34
  • 36. WHO PARTICIPATES? • Business Analysts, Developers, Quality Analysts, Project Managers, Sponsors, Sbuject Matter Experts, End-Users, Legal • Empowered Individuals, who can make decisions • Duration – 2-3 Weeks • Timeboxed – Not Rigid, Not Schedule Driven • Heavy Visual Aides 35
  • 37. TIME TABLE? • Duration – 2-3 Weeks • Schedule is not rigid • Facilitators plan the sessions but may choose not to share it with all the participants 36
  • 38. THE GOAL IS SUFFICIENT DETAILS Analysis is just enough details so that everyone is on the same page 37
  • 39. WORKSHOPS ARE TECHNICAL ENOUGH Integration Points are identified, if there’s a need. 38
  • 40. 39
  • 41. ISN’T TIMEBOXING COUNTERPRODUCTIVE? • Usually not • Every workshop has a goal and an acceptance criteria • Workshops are aimed at answering specific questions 40
  • 42. ACCEPTANCE CRITERIA 41
  • 43. DELIVERABLES OR CONSUMABLES? • The aim is to produce artifacts that we think will be utilized and are necessary at that stage • We, therefore, try to create artifacts that are consumables and not deliverables 42
  • 44. CONSUMABLES • Objectives, Roles & Goals, Future Perspective, Scenarios • As-Is / To-Be (processes) • Lo-Fi Prototypes, Master Story List • Priority List • Estimates • Integration Points, Initial Systems and Application Architecture • Release Plans, Iteration 0, 1 Plans • Risk Logs 43
  • 45. Although the workshops utilize Lo-Fi techniques, the information is still compiled electronically daily, outside of the core collaborative hours, by the facilitators 44
  • 46. MASTER STORY LIST This is just one example of the consumables that are created. An Excel sheet (electronic format) is compiled and made available to the participants 45
  • 47. ARE ALL WORKSHOPS REQUIRED? • No • Rapid Project Inception is tailored for every project • Greenfield Vs. Brownfield projects, maintenance or enhancement projects are just some considerations that determine the structure of a rapid project inception 46
  • 48. PERIPHERAL ACTIVITIES • Because we meet for 6-7 hours daily, energizing activities are utilized to keep the participants productive • At the end of day everyday there’s a retrospective. The objective is to get feedback from participants on how they feel the process is going and what the facilitators can improve upon 47
  • 49. WEEK - 1 48
  • 50. WEEK - 2 49
  • 51. Rapid Project Inception definitely seems very structured What are some of the benefits you have realized with this apporach? 50
  • 52. BENEFITS • Build efficiency in the process • Early identification of dependencies • Increased understanding of requirements and business value • Strong Working Relationships between project team, customers, and business partners • Builds the pace for start of development • Clear and Unified Vision 51
  • 53. Clear and unified vision We end up having the same mental models 52
  • 54. There definitely must be some challenges If it were so easy, everyone would be already doing it 53
  • 55. CHALLENGES • Availability of Participants for 2-3 weeks • Scalability – What if you have multiple projects? • Effective Facilitation Skills – It is only as good as the facilitators. Where do we get these effective facilitators from? • Time reporting – Believe it or not, but this is a challenge. “Our time reporting system doesn’t have a code for it yet.” • Determining a fit – Creating a workshop roadmap is not trivial 54
  • 56. THANK YOU ! RAJEEV SINGH (312) 543-7347 rsingh@thoughtworks.com bizvalu.blogspot.com 55

×