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
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
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
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
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
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
41. ISN’T TIMEBOXING
COUNTERPRODUCTIVE?
• Usually not
• Every workshop has a goal and an acceptance
criteria
• Workshops are aimed at answering specific
questions
40
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
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
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
