1.
Products and Value
A rough overview from an Agile process perspective
NEW YORK BUSINESS PROCESS PROFESSIONALS MEETUP
Matt Nudelman, CSM, CSPO
11/15/16

2.
What this presentation is about:
• Waterfall vs. Agile methodology
• What a ‘product’ is
• Products in the agile universe
• What defines ‘value’
• Iterative development to add product value

3.
Some background to start with
• I’m a developer turned project manager
• Having worked in traditional Waterfall mode, I have embraced Agile
Methodology for a better approach to project development
• The waterfall model is a sequential (non-iterative) design process,
used in software development, in which progress is seen as flowing
steadily downwards (like a waterfall) through the phases of
conception, initiation, analysis, design, construction, testing,
production/implementation and maintenance.

4.
Waterfall
(or Waterfail?)

5.
How does Waterfall fail?
• Collecting all the requirements upfront is time consuming
• Producing documentation for all the requirements does not help prioritize the
most important features
• A large ‘review chain’ means that a large effort is made to get clients to sign off
on the requirements before building begins
• Most of the discoveries made during development are looked at as ‘change’ and
may not be cleanly rolled into the original design (change management)
• Each phase of development should be completed before the next one begins.
Iterative work is looked as a failure of the previous phase
• By the time a product is built, it may no longer relate to market conditions or
fulfill changing client desires

6.
So, what is Agile?
• Agile evolved as a way of successfully delivering software faster, while reacting to changes
better than other existing methodologies.
• Agile is an umbrella term for development practices like Scrum, Kanban, XP, Lean,
DevOps, test-driven development, and uses techniques from those methodologies as
needed.
• Agile is a time-boxed, iterative approach to software delivery that builds software
incrementally from the start of the project, instead of trying to deliver it all at once near
the end. Time-boxing determines the amount of time spent on an activity.
• It works by breaking projects down into little bits of user functionality called user stories,
prioritizing them, and then continuously delivering them in short two week cycles
called iterations.
• These iterations produce working software that can be shared with clients for further
feedback.

7.
Iterative and Incremental
• Iterative development is a way of breaking down the
software development of a large application into smaller chunks.
In iterative development, feature code is designed, developed and tested
in repeated cycles.
• The incremental build model is a method of software development where
the product is designed, implemented and tested incrementally (a little
more is added each time) until the product is finished. It involves
both development and maintenance.
• Building this way allows teams and stakeholders to review work as it’s
being developed, and change direction if early assumptions do not meet
market needs. It allows corrections to be put in place by the team before a
product is released.

8.
There’s even an Agile Manifesto
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

9.
Providing the foundations of Product
Development
• What’s a Product?
• “A product is something (physical or not) created through a process that
provides benefits to a market” - Mike Cohn.
• Every Product should have a vision
• “Vision is the art of seeing things invisible” - Jonathan Swift.
• This vision is shared with the team and helps to unify development
goals
• Understanding this vision allows a team to release a MVP (minimally
viable product) to consumers

10.
Products are…
• Both iterative and incremental in development
• Evolving, as feedback from the MVP and other releases allows a team to
mature their product
• Unlike projects, they are not a temporary endeavor, as the full product
lifecycle can be seen as an ongoing process
•A project is a temporary endeavor designed to produce a unique
product, service or result with a defined beginning and end (usually
time-constrained, and often constrained by funding or deliverables)
undertaken to meet unique goals and objectives, typically to bring
about beneficial change or added value.

11.
More on the MVP (minimally viable product)
This process allows you to test an idea by
exposing an early version of your product
to the target users and customers, to
collect the relevant data, and to learn
from it.
As lack of knowledge, uncertainty, and
risk are closely related, you can view the
MVP as a risk reduction tool. The MVP
prioritizes feature development, so that
the most important (highest value)
features can be built first.

12.
So, what is value?
• Value can be viewed from many different perspectives :
• Business value (most profitable, competitive differentiation)
• Consumer value (meets and exceeds user needs vs. features in other competing
products, customer loyalty)
• Technical value (efficient or scalable design, satisfying regulatory requirements)
• Some empirical measures of value:
• Analytics and other usage metrics
• User feedback and ratings

13.
Ways to prioritize products and features
based on value ‘guesses’
Rating (based on educated guesses):
• Business Value + User Value / Effort = Priority Rating
• Product Owners rate each 1 – 5 and rank in spreadsheet
Cost of Delay
• Work is prioritized based on ‘what will cost us the most’ by delaying its
delivery. In other words, a business does not profit from a feature that is not
yet built, and Cost of Delay is used to determine which product feature to
finish first.

14.
Moving to Agile in your work
• Think about small steps you can do to improve the process (kaizen)
• Think about a small pilot project your company can do internally
• Embrace both the ‘fail early / fail fast’ and ‘inspect and adapt’
concepts
• kai·zen
• ˈkīzən/
• a Japanese business philosophy of continuous improvement of working
practices, personal efficiency, etc.

15.
Building small - the 80/20 rule
• In some apps, 20% of the features are used by 80% of the users
• The 80/20 Rule can also be interpreted as:
• 20 percent of customers equal 80 percent of sales
• For many events, roughly 80% of the effects come from 20% of the causes
• Maximize the small and powerful 20% and reduce the wasteful 80%
• Build something, release it, get feedback, iterate, release again (an
early version of a product does not have to be the full, feature-rich,
version of the product to provide crucial market data).

16.
References and links
• Agile vs. Waterfall: http://www.base36.com/2012/12/agile-waterfall-methodologies-a-side-by-side-comparison/
• Agile in a Nutshell: http://www.agilenutshell.com/
• The Agile Manifesto: http://agilemanifesto.org/
• Principles behind the Agile Manifesto: http://agilemanifesto.org/principles.html
• Mike Cohn’s definition of a product: https://www.mountaingoatsoftware.com/blog/what-is-a-product
• On MVPs and MMPs: http://www.romanpichler.com/blog/minimum-viable-product-and-minimal-marketable-product/
• Iterative and Incremental: http://c2.com/cgi/wiki?IterativeVsIncremental
• The 80/20 Rule: http://www.simafore.com/blog/bid/102689/Analytics-behind-the-80-20-Rule-to-Increase-Product-
Profitability
• Cost of Delay: http://www.leadingagile.com/2015/06/an-introduction-to-cost-of-delay/
• Misunderstandings of the 80/20 Rule: http://www.lifehack.org/articles/featured/the-top-4-misapplications-of-the-8020-
rule.html

17.
Addendum (Some points from our Q&A session):
1- How to implement Agile when everything's on fire:
Agile works best when companies align on the agile methods they want to use; it goes without saying many
should give it a long hard thought process prior to beginning their agile journey. In an 'everything on fire'
situation, a company may not have the bandwidth for Agile and the full time and commitment it needs to
work. However, I’d recommend a smaller pilot project, one without an instant deadline or a demanding
client, to start with. This could be an internal project, with a team that has at least 50% available time to
commit, for making it work.
2- Whether there are certain verticals or industries that Agile isn't right for:
Agile may not be right for when a large amount of pre-planning and client approval is needed -- this could be
in a service situation like event planning or advertising. However, Agile can still work in industries where a
physical product is the goal, along as incremental prototypes can be produced and reviewed with the client
and team.
3- Discussion around the need for 'Scrum 0':
Scrum 0 (scrum zero) is a useful method for setting aside the time to prepare a team and its environment for
a project. Activities may include setting up development environments, preparing stories for a sprint
backlog, or other business / technical predecessors. It occurs before Sprint 1, where the real work begins.

18.
Addendum (page 2):
4- What if the customer doesn't know what they want/need:
I'd say that's never a good foundation for a project. I'd review any empirical and anecdotal information
(analytics, user reviews/feedback) available to see what potential features may engage a customer base. As
usual, the ability to prioritize the most important product needs so that they are produced first would the
short-term goal in this situation.
5- The value of good documentation/reports (not as black and white as the manifesto might seem):
Documentation should be as minimal as needed, and those needs should be defined early on in a project.
Are there regulatory requirements that need to be met? Will there have to be documentation for legal
reviews? The level of how much documentation produced should be based on the industry and its regulatory
needs. However, a simple ticketing system works best when a company does not have to produce massive
production documentation.
6- Discussion around the importance of maturity of process underlying the methodology for it to succeed:
Like any methodology, process improvement is an ongoing event and companies need to know that you
don’t achieve “100% immersion” in Agile in the first pass. A single project done in a new methodology or
framework may not be evidence of success or failure. A company needs to have defined roles (Product
Owner, Scrum Master, Dev Team) worked in advance, as well as a clear project requirement pipeline, in
place to show the correct level of maturity.