Johanna Rothman Teams Deliver Features Chapter 6 Copyright © 2017

Rothman “In the past you might have worked on a team that received a gigantic product-requirements document from a project manager. You worked on that project for months – maybe longer and invited the product manager in to see the wok you finished.” That product manager might have had any of these reactions: “You gave me what I asked for. It’s not what I need.” “The market changed. I don’t want this now. I want something else, yesterday.” “This isn’t what I wanted. You read what I wrote, but that’s not what I meant.”

Maybe… “You needed more collaboration with the business, or to deliver something more often, or to finish some work to release early.” “Agile approaches address all those problems. That’s because agile teams deliver finished features on a regular basis.” Agile teams use Feature Driven Development (FDD) “When a team delivers features, everyone can see the shape of the product from the beginning… as it evolves”

Plan at several levels… “How much certainty do you have about what your customers want?” “Agile and lean approaches help when you don’t have a lot of certainty about the requirements or the technical approaches that might work?” “Product managers [often Product Owners] plan the product roadmap, that is… what the product people want and when.”

Agile Roadmap for a Product Six Quarter View Q1 Q2 Q3 Q4 Q5 Q6 External Release Tulip Daisy Rose Carnation   Feature Sets/ Themes

Agile Roadmap for a Product Six Month View M1 M2 M3 M4 M5 M6   External Release Tulip External Release Daisy Internal Release 1 Internal Release 2 Internal Release 3 Internal Release 4 Internal Release 5 Internal Release 6 Feature Sets/ Themes

Releases for Learning, Feedback, and Value “Releasing is not just to deliver value to your customers. Releasing creates an environment of feedback for the team about its deliverables. The team can learn if the deliverables meet the customers’ needs for functionality and performance.”

Deliver Value Through the Architecture Not when the work is done separately for the “front end” and the “back end” Value is realized only after full integration The squiggly ones indicate a small and complete story through the architecture… one slice. SCRUM!

Deliver Value to Someone by Using Features Some Terms Story: The smallest possible value to a specific user. It might not be sufficient to release by itself. Theme: Related group of stories… the “feature set”. You can deliver any of the related stories and realize value. Epic: A compound story that’s not easy to teas apart… often contains feature sets.

The “story” A “feature” for a specific user that provides value to that user – is the unit of requirement in agile … (?) Define Stories so you can see the Value “Here is what I mean by a story:” As an (already registered) user, I need (want) to download my bank statement, so (I can see if my budget is on track) Creating user-based small stories makes the value transparent to the Product Development team.

Experiment and Spike to Explore “Spikes are timeboxed prototypes that provide the team with information about the rest of the feature or the feature set.” Think of the smallest possible experiment that “you” can learn from. Experiment in order to try something… prototype something to get feedback… Teams can reduce waste and time by such experiments…

Consider Minimum Viable Products & Experiments A minimum viable produce (MVP) has enough functionality for the customer to use, even if it’s not the full functionality. A minimum viable experiment (MVE) provides feedback for the team and the Product Owner.

One-Month Agile Roadmap & Rolling Wave Plan for the Next Month Internal Release MVE Minimum Viable Experient MVP Minimum Viable Product

Original Sequence: Two Months Internal Release 1 Internal Release 2 Secure Login Part 1 New ID Text Transfer Admin, Part 1 Diagnostics, Part 1 Admin, Part 2 File Transfer, Part 1 Engine, Part 1 Engine, Part1 Changed Sequence after one Iteration/Cadence: Plan for Remainder of Time Internal Release 1 Internal Release 2 Secure Login Part 1 New ID Text Transfer Admin, Part 1 Diagnostics, Part 1 Admin, Part 2 File Transfer, Part 1 Engine, Part 1 Engine, Part1

Use a Feature Parking Lot to See Possibilities The maybe’s (Separates “what we do now” from “what we want to do later”)

Eric Ries’s Build-Measure-Learn Feedback Loop Select the riskiest assumption Learn if your assumption is True or False True: move on to the next riskiest assumption False: review your hypothesis Build an experience or MVP to test this Assumption on the market Measure customer behaviors During that experience

Recognize Value Traps The goal… to work on defining and delivering value… but the traps” The Product Owner has feature-itis People in the organization want detailed schedules, such as Gantt charts People are unsure about developing using MVP or an MVE, so they think they cannot recognize any value until “all” of the work is done.

Gantt Chart “Planning”

Gantt Chart

Trap: It’s Not Done Until Everything is Done Will not release anything until “everything” is done, because… lack of perspective and discipline! “While I’m in there, I’ll do this, too” “It will take longer to do it later. I’ll just finish it now.” “But no one can use it like this. I need to finish everything before we can release anything.” People are concerned they will look incompetent if they don’t finish everything. People might worry they can’t get the rest of the value if they don’t do it now. People don’t understand the value an MVP or an MVE can provide.

“It’s possible a Product Owner or Team Member doesn’t understand how to slice and dice features so a team can release interim value.” “Help people see that adding more work that’s not on the board adds to the WIP and increases cycle time. That means the team has less ideas of its estimates and when it might complete work.”