Products and Value A rough overview from an Agile process perspective

NEW YORK BUSINESS PROCESS PROFESSIONALS MEETUP

Matt Nudelman, CSM, CSPO

11/15/16

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

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.

Waterfall

(or Waterfail?)

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

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.

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.

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

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

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.

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.

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

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.

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.

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).

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

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.

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.