1. An Introduction
By Mohan Late

2. The unmodified "waterfall model". Progress flows from the top to the
bottom, like a waterfall.

3.  Approach is simple
 It is more disciplined
 Is well structured
 the model itself progresses linearly through
discrete, easily understandable and
explainable phases
 Provides easily markable milestones in the
development process.

4. "Many times, thinking things out in advance saved us serious
development headaches later on. ... [on making a particular
specification change] ...
Making this change in the spec took an hour or two. If we had
made this change in code, it would have added weeks to the
schedule. I can’t tell you how strongly I believe in Big Design Up
Front, which the proponents of Extreme Programming consider
anathema.
I have consistently saved time and made better products by using
BDUF and I’m proud to use it, no matter what the XP fanatics
claim. They’re just wrong on this point and I can’t be any clearer
than that.“
- Joel Spolsky

5.  Software projects that are stable
 Unchanging requirements
 Where it is possible that designers will be
able to fully predict problems
 Where it is possible that designers produce a
correct design

7.  A bug found in the early stages is cheaper in
money, effort, and time, to fix than the same
bug found later on in the process.
 An early defect that is left undetected until
development or maintenance is estimated to
cost 50 to 200 times as much to fix as it
would have cost to fix at requirements time

8.  BDUF is poorly adaptable to changing requirements
 BDUF assumes that designers are able to foresee
problems without extensive prototyping.
 There is an overhead to be balanced between the time
spent planning and the time that fixing a defect would
actually cost.
 In most projects there is a significant lack of
comprehensive written requirements.
 In BDUF a lot of assumptions are made that later
prove to be false
e.g. The program's design should be perfect
before people begin to implement the design

9.  Doesn’t handle change very well
 Requirements specifications are an abstraction
and can be interpreted differently
 Business engagement is high at the start of the
project but then tapers off
 Insufficient testing during development
 Late integration
 QA is trailer-hitched, so quality isn’t baked in
and testing gets crunched at the end
 Progress measured by task % complete
 Often don’t know until it’s too late
 Whole project planned up-front

11.  16.1 % of projects as successful
 31.1% of software development projects get cancelled
 52.7% do not meet their original cost
Conclusion:
 The organization is immature and to aim for more
maturity
 More requirements documentation, more analysis,
more planning and tracking

12. "The Roman bridges of antiquity were very
inefficient structures.
By modern standards, they used too much
stone, and as a result, far too much labour to
build.
Over the years we have learned to build
bridges more efficiently, using fewer
materials and less labour to perform the
same task.―
-Tom Clancy (The Sum of All Fears)

13.  Business practices that accommodate
changes.
 Flexible model

14. Project Success Factors Points
1. User Involvement 19
2. Executive Management Support 16
3. Clear Statement of Requirements 15
4. Proper Planning 11
5. Realistic Expectations 10
6. Smaller Project Milestones 9
7. Competent Staff 8
8. Ownership 6
9. Clear Vision & Objectives 3
10. Hard-Working, Focused Staff 3
TOTAL 100

17.  Adaptive, empirical process
 Small repeating cycles
 Short-term planning with constant feedback,
inspection and adaptation
 Fail-early lifecycle

18.  Breaks complex projects down into simpler mini-projects
 Accommodates change easily
 Improves ROI
 Increased business involvement and satisfaction
 Increased visibility
 Lower development risk, higher quality, less defects
 Produce incremental product quickly
 Progress measured by running tested software
 Early and regular process improvement

19.  35 % of projects as successful
 19% of software development projects get
cancelled
 46% do not meet their original cost
 three reasons for the improvement in
software quality—better project management,
iterative development and the emerging Web
infrastructure.

23.  Individuals and interactions over processes
and tools
 Working software over comprehensive
documentation
 Customer collaboration over contract
negotiation
 Responding to change over following a plan

24. 1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently
4. Working software is the principal measure of progress
5. Sustainable development, able to maintain a constant pace
6. Close, co-operation between business people and developers
7. Face-to-face conversation is the best form of communication
Projects are built around motivated individuals, who should be
trusted
8. Continuous attention to technical excellence and good design
9. Simplicity
10. Self-organizing teams
11. Regular adaptation to changing circumstances

25.  Agile Modeling
 Agile Unified Process (AUP)
 Dynamic Systems Development Method
(DSDM)
 Essential Unified Process (EssUP)
 Extreme Programming (XP)
 Feature Driven Development (FDD)
 Open Unified Process (OpenUP)
 Scrum
 Velocity tracking

26. Scrum

27.  Simple and scaleable
 Empirical process
 Short-term detailed planning with constant feedback
provides simple inspect and adapt cycle
 Simple techniques and work artifacts
 Requirements are captured as user stories in a list of
product backlog
 Progress is made in Sprints
 Teams collaborating with the Product Owner
 Optimises working environment
 Reduces organisational overhead
 Detects everything that gets in the way of delivery
 Fosters openness and demands visibility

28.  Contains all potential features, prioritized as an
absolute ordering by business value.
 It is therefore the ―What‖ that will be built, sorted
by importance.
 It contains rough estimates of both business
value and development effort.
 Those estimates help the Product Owner to
gauge the timeline and, to a limited extent
prioritize.

29.  Captures Product Vision
 Represents the voice of the customer
 Creates initial Product Backlog
 Writes customer-centric items
 Helps set the direction of the product
 Accountable for ensuring that the Team delivers value to the
business
 Responsible for:
◦ Product Backlog
◦ Prioritization

30.  Using story points instead of hours
 numeric sizing (1 through 10)
 t-shirt sizes (XS, S, M, L, XL, XXL, XXXL)
 Powers-of-2 (1,2,4,8...)
 the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.)
 Planning Poker
 Basing on historical trends
 The best people to make the estimates are the people who build the
product.

31.  These are the people who build products,
make estimates
 Scrum recommends team sizes of 7
 The teams are cross functional

32.  Combination of Coach, Fixer and Gatekeeper.
 Make sure the project is progressing
smoothly
 Every team member has the tool they need to
get the job done
 Sets meetings
 Monitors the work done
 Facilitates release planning
 to protect the team and keep them focused
on the tasks at hand
 servant-leader

33.  Three core roles and a range of ancillary roles
 Core Scrum roles:
◦ Product Owner
◦ Team
◦ Scrum Master
 Ancillary roles:
◦ Stakeholders (customers, vendors)
◦ Managers (including Project Managers)

35.  Start with the Product Backlog items
 Identify features to put into release
 Team prioritizes the features

36.  Is an iteration
 Can have 1 day of sprint planning, 4 days of work
and 1 day of sprint review
 Sprints are short duration milestones
 Sprints range from a couple of days to 30 days
 Need atleast 4 to a dozen sprints to get to the
release

37.  Break Release backlog items into several
tasks
 each sprint should deliver a fully tested
product with all the features of that sprint
backlog 100% complete
 late finish of the sprint is a great indicator
that the project is not on schedule

39. Actual estimates for each
feature in the backlog
during the initial planning
process

40. Actual estimates for each
feature in the backlog
during the initial planning
process
Daily progress on one
ore more features is
updated by team
member by updating the
amount of time
remaining for each of
their items

42.  Tracks bugs separately from features in their
own Defect Backlog
 Any bug found relating to the feature should
be dealt with immediately before marking the
feature complete
 Plan for 1-2 sprints focused only on Defect
backlogs

43.  Should not last more than 15 minutes.
 The meeting starts precisely on time.
 Every team member has to answer 3
questions –
◦ What have I done since last meeting?
◦ What will I do until next meeting?
◦ What problems do I have?
 ScrumMaster to facilitate resolution of these
impediments
 resolution should occur outside the Daily
Scrum itself to keep it under 15 minutes

44. Capitalizing software development costs – waterfall, agile
and cloud.

45.  Waterfall model
 Agile methodologies
 Cloud

46.  Preliminary project stage or evaluation phase
◦ essentially R&D costs, and are charged to opex
 Software development or application
configuration phase.
◦ Capex, because the end result is an asset.
 Post implementation or production phase
◦ This is opex because these are day-to-day running
costs

47.  Enterprise software licenses are capex, but the
corresponding annual maintenance costs are opex.
 Functional design is opex and technical design is capex,
but the border between the two can be blurred when done
by collaborative teams.
 Production upgrades or enhancements are capitalizable,
whereas maintenance and bug fixing are not, even though
they both have development costs.
 An ERP-to-CRM order entry interface is a capital cost,
whereas a one-time ERP-to-CRM data migration interface
is an expense.
 Software as a Service or SaaS is pure opex. Even if you end
up customizing a SaaS application, the development costs
will still be opex because you are renting.

48.  it is not the activity in itself that is
capitalizable, but rather the outcome of that
activity and the ownership of the resulting
asset.

49.  According to FASB, technological feasibility can be
based on either a detailed design or a working
product:
◦ Detailed design: ―The detail design of a computer software
product that takes product function, feature, and technical
requirements to their most detailed, logical form and is
ready for coding‖.
◦ Working model (or prototype): ―An operative version of the
computer software product that is completed in the same
software language as the product to be ultimately
marketed, performs all the major functions planned for the
product, and is ready for initial customer testing (usually
identified as beta testing)‖

50.  In Scrum, technological feasibility is reached after
a number of iterations after which capitalization
can start
 Amount of development costs which can be
capitalized is less as compared to waterfall’s
detailed design up-front approach
 Iterative development generally requires far less
time to reach technological feasibility compared
to waterfall, which is heavily front-loaded with
opex prior to the start of development.

51.  A waterfall or an agile project can be developed and run
either on-premises or in the cloud
 For IaaS and PaaS
◦ Capex vs opex rules apply when developing the software using
agile or waterfall.
 For Saas,
◦ There is no software assets created by the client
◦ So, even if you end up customizing your SaaS CRM application, for
example, the development costs will still be opex because you are
renting. You don’t own the asset, ie it doesn’t sit on your
company’s balance sheet.
 Public SaaS is therefore pure opex, and the capex vs opex
rules for waterfall and agile do not apply.

52. Lean startup solutions
We help you answer the question-‖Can a sustainable business be
built around this set of products and services?‖ and ―How can
we raise investment to do so?‖ We help startups follow the lean
startup approach by providing tools to test a vision
continuously.
We help you right from building each component of a sustainable
business model to weaving a financial model based on
extensive market research to producing VC-friendly attractive
data driven business plans.
We strictly follow the Lean Startup methodologies and tools
throughout our approach to help you solve real problems and
provide detailed specifications of what needs to be done to
build solution.

53.  ValueFacture Lean Startup Consultant
http://www.valuefacture.in
 Email me at
◦ Mohan@valuefacture.com
◦ Mohan.Late@gmail.com
 Skype me at
◦ mohan.late
Disclaimer : No animals (pigs/chickens) were harmed in the making of this presentation.