Summary

When I think “Samurai”, I think expert.  This is a book for beginners.  It gives overviews and illustrations on the full range of development, but does not get into great detail. One thing about this book, the chapters and sub-chapter names are not very descriptive about the content, they are more of the main idea in the paragraph than a heading–which makes it difficult to find things.  The Sensei dialogues are not really that effective, more show than content.  Much of each chapter is very light reading with little insight, but there are nuggets and good illustrations sprinkled throughout.  There are some good techniques throughout, but with the disorganization it is difficult to jump right at them.

Top 3 Things I learned

• The inception deck is a wonderful project chartering tool.
• I really like the tradeoff sliders.  A good way to make tough choices early.
• The story gathering workshop was quite good.

---

Notes: Chapter 1: Agile in a Nutshell

TERM: Adaptive Planning: When reality disagrees with your plan, change your plan

QUOTE: If death is on the line,  then you’d better get it done

NOTE: This is a very quick intro, covers a lot of topics quickly

1. Deliver something of value every week
2. How does Agile Planning work: See term adaptive planning
3. Done means done: Shippable and customer happy
4. There simple truths:
   1. Can’t know all the requirements up front
   2. Requirements change
   3. More to do than time available

---

Notes: Chapter 2: Meet your agile team

NOTE: Very good chapter on Agile Teams

TECHNIQUE: In iteration zero, Draw a venn diagram with the following circles: Dev, QA, UX, BA, PM

1. How agile teams are different: See technique above with venn
2. What makes them tick
   1. co-location
   2. enaged customers
   3. self-organizing
   4. accountable and empowered
   5. cross functional
3. Typical team roles
   1. customer
   2. analyst
   3. programmer
   4. tester
   5. pm
   6. ux
4. teammate tips
   1. generalists
   2. ambiguity
   3. no egos

---

 Notes: Chapter 3: How to get everyone on the bus

NOTE: This chapter is strictly about Project Chartering and introduces and talks about a single technique: Inception Deck.  Chapter 4 talks in more detail about the “why” deck elements and Chapter 5 talks in more detail about the “how” deck elements.

Inception Deck

1. Why are we here
2. Create an elevator pitch
3. Design a product box
4. NOT list
5. Meet your neighbors
6. Show the solution
7. What keeps us up at night
8. Size it up
9. Be clear on what’s going to give
10. Show what its going to take

---

 Notes: Chapter 4: See the big picture

NOTE: This chapter expands on the inception deck

QUOTE: Your project community is always bigger than you think.

TECHNIQUE: Elevator Pitch Template (below0

TECHNIQUE: NOT list (IN/OUT/UNRESOLVED)

1. Why are we here
   1. Go visit the customer
   2. Discover the customer’s intent
2. Create an elevator pitch
3. Design a product box
4. NOT like
5. Meet your neighbors

Elevator Pitch Template

• FOR [target customer]
• WHO [statement of need]
• THE [product name]
• IS A [product category]
• THAT [key benefit]
• UNLIKE [current way]
• OUR PRODUCT [primary differentiation]

---

 Notes: Chapter 5: Making it Real

SUMMARY: This chapter deals with the “how” items in the inception deck.

PARAPHRASE: If there is too much to do, then do less

PARAPHRASE: If reality disagrees with the plan, then change the plan

1. Visualize the problem: use butcher paper and make cartoons
2. Project Risks: These are worth sweating
3. Size it up: Rough timeline, max, 6 months out
4. Tradeoff slides:
   1. Most Precious (each gets one level): Quality : Time : Scope : Budget
   2. Not enough time (each gets one level): Out of Scope : More People : Push out release : Sacrifice Quality
   3. Intangibles
5. Clarify stakeholders: he goes for one <– Might be an interesting topic to see how to deal with mult. stakeholders.

---

 Notes: Chapter 6: Gathering User Stories

SUMMARY: Talks about gathering, not writing user stories

QUOTE: Because life is too short to write everything down

IDEA: Capturing requirements in a document, customers rarely get what they want.

IDEA: A user story is a promise of a conversation

Elements of a good user story

• Independent
• Negotiable
• Value
• Estimable
• Small
• Testable

Non-Functional, non-testable user stories turn into constraint cards.

Story Card Gathering Workshop:

1. Big Open Room
2. Draw lots of pictures
   1. Personas
   2. Flowcharts
   3. Scenarios
   4. System Maps
   5. Process Flows
   6. Concept Designs
   7. Storyboards
   8. Paper prototypes
3. Write Lots of User Stories
4. Brainstorm Everything Else
5. Scrub and make shine [I like the story card matrix myself]

---

Notes: Chapter 7: Estimation: The fine art of guessing

1. Cone of Uncertainty.  Beginning of a plan, worse time to try to nail down an estimate.
2. Relative sizing by points
3. Relative Day does not equal calendar day
4. Triangulation (story card matrix helps here)
5. Spike: Time boxed experiment where we do just enough investigation to make an estimate.
6. Planning Poker: Power of a discussion.

---

Notes: Chapter 8: Agile Planning: Dealing with Reality

QUOTE: Why does reality keep messing with my GANTT chart.

To make a plan:

1. Create a master story list
2. Size it up
3. Prioritize
4. Estimate your velocity
5. Pick some dates: delivery by date or feature by date

Examples:

1. New Requirements
   1. Flexible about scope
   2. Push out the date
2. Not as fast as you hoped
   1. Go Spartan
3. Lose team member
   1. adjust expectations
4. Run out of time
   1. Flex scope
   2. Go Spartan

---

Notes: Chapter 9: Iteration Management: Making it happen

SUMMARY: A brief introduction on Iterations and the concept of doing everything within the iteration versus waterfall.

1. Deliver value every week
2. Agile iteration
3. Do just enough analysis
4. Do you deep dive analysis just-in-time
5. Promotes doing analysis one iteration before
6. Likes the following steps for Analysis
   1. Flowchart
   2. Personas
   3. Paper prototypes
7. Introduces Step 0
8. Introduces check work
9. Introduces Kanban: WIP: Work in progress

 

---

Notes: Chapter 10: Creating an Agile Communication Plan

SUMMARY: A short chapter on how an iteration is organized.

4 Activities:

1. Story Planning Meeting: non-customer
2. Showcase: A sprint review
3. Iteration Planning Meeting: customer involvement
4. mini retrospective: Promotes a small, ten minute retrospective at the end of an iteration

---

Notes: Chapter 11: Setting Up a visual workspace

SUMMARY: Introductory material on information radiators.

4 Key Elements:

1. Story Wall (Current Iteration)
2. Release Wall (All iterations)
3. Velocity and BurnDown
4. Inception Deck

---

Notes: Chapter 12: Unit Testing: Knowing it works

SUMMARY: A very superficial chapter on unit testing.

4 must haves:

1. Unit testing
2. Refactoring
3. TDD
4. Continous Integration

---

Notes: Chapter 13: refactoring: Paying down your technical debt

SUMMARY: Illustration and demonstration of refactoring

TERM: Technical Debt; The continuous accumulation of shortcuts, hacks, duplication, and other sins we regularly commit against our code base in the name of speed and schedule.

TERM: Refactoring.  Continuously making small incremental design improvements to software without changing external behavior.

Refactor aggressively:

1. rename variable/method
2. inline variable
3. extract method

---

Notes: Chapter 14: Test Driven Development

SUMMARY: Overview and Illustration of TDD.

Rules:

1. Don’t write code until you have a failing test
2. Test everything that could possibly break

What does TDD get you:

• Lower total cost of ownership
• Less code
• Forces you to think
• Quality baked in from the start
• Reduced complexity
• Simpler design.

---

Notes: Chapter 15: Continuous Integration: Making it production ready

SAYING Production starts on day one

CI:

1. Source Code Repository
2. Check in
3. Automated Build
4. Work in small chuncks