1. Johanna Rothman Teams Deliver Features Chapter 6
Copyright © 2017

2. 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.”

3. 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”

4. 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.”

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

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

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

8. 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!

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

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

11. 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…

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

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

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

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

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

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

18. Gantt Chart “Planning”

19. Gantt Chart

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

21. “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.”