Your SlideShare is downloading. ×
0
By @rustysf (russwallace.com)
How To Build Software
If You Can’t Write Code
Who This Presentation is For
• You want to build a startup software company
Who This Presentation is For
• You want to build a startup software company
• You’re not a software engineer
Who This Presentation is For
• You want to build a startup software company
• You’re not a software engineer
• You’ve neve...
Who This Presentation is For
• You want to build a startup software company
• You’re not a software engineer
• You’ve neve...
Why Learn to Be a Product Manager (PM)?
• If you're not an engineer, then you're everything else
Why Learn to Be a Product Manager (PM)?
• If you're not an engineer, then you're everything else
• You need to know how to...
Why Listen to Me?
• No sacred cows: I just want to get shit done
@rustysf
Why Listen to Me?
• No sacred cows: I just want to get shit done
• No allegiances: I don't debate the finer points
• Not in...
Why Listen to Me?
• No sacred cows: I just want to get shit done
• No allegiances: I don't debate the finer points
• Not in...
In My Experience
image credit: http://xkcd.com/1349/
Product Management = Non-Technical Building
• Software companies don't start needing sales or culture
Product Management = Non-Technical Building
• Software companies don't start needing sales or culture
• They start needing...
Product Management = Non-Technical Building
• Software companies don't start needing sales or culture
• They start needing...
Product Management = Non-Technical Building
• Software companies don't start needing sales or culture
• They start needing...
Product Management = Non-Technical Building
• Software companies don't start needing sales or culture
• They start needing...
What a PM Does
• Make the decisions about a product that determine if it
succeeds
What a PM Does
• Make the decisions about a product that determine if it
succeeds
• What to build & when it needs to be bu...
What a PM Does
• Make the decisions about a product that determine if it
succeeds
• What to build & when it needs to be bu...
What a PM Does
• Make the decisions about a product that determine if it
succeeds
• What to build & when it needs to be bu...
What a PM Does
• Make the decisions about a product that determine if it
succeeds
• What to build & when it needs to be bu...
What a PM Does Not Do
• PMs DO NOT code
What a PM Does Not Do
• PMs DO NOT code
• It's great to be technical, or to learn coding in order to
communicate, but don'...
What a PM Does Not Do
• PMs DO NOT code
• It's great to be technical, or to learn coding in order to
communicate, but don'...
What a PM Does Not Do
• PMs DO NOT code
• It's great to be technical, or to learn coding in order to
communicate, but don'...
Side Note On Choosing What to Build
• This is where you can help as a “business guy” (or gal)
Side Note On Choosing What to Build
• This is where you can help as a “business guy” (or gal)
• Talk to everyone who is re...
Side Note On Choosing What to Build
• This is where you can help as a “business guy” (or gal)
• Talk to everyone who is re...
Side Note On Choosing What to Build
• This is where you can help as a “business guy” (or gal)
• Talk to everyone who is re...
Before We Dive Into Details…
image credit: http://www.gapingvoid.com/
Being a PM is Difficult
• Becoming an “A-level” PM takes years of experience,
mistakes and mentors
Being a PM is Difficult
• Becoming an “A-level” PM takes years of experience,
mistakes and mentors
• This presentation will...
Being a PM is Difficult
• Becoming an “A-level” PM takes years of experience,
mistakes and mentors
• This presentation will...
Being a PM is Difficult
• Becoming an “A-level” PM takes years of experience,
mistakes and mentors
• This presentation will...
Product Methodologies (“How to Build”)
• Almost as many as there are coding languages
• Waterfall/BDUF
• Agile/Scrum
• Ext...
Product Methodologies (“How to Build”)
!
SKIP IT:
You can cover 80%+ of engineers you'll work with by
understanding a scru...
Agile? Agile what?
• “Agile” is a philosophy/methodology that boils down to:
• Break up the project into discrete delivera...
Agile? Agile what?
• “Agile” is a philosophy/methodology that boils down to:
• Break up the project into discrete delivera...
Agile? Agile what?
• “Agile” is a philosophy/methodology that boils down to:
• Break up the project into discrete delivera...
Agile? Agile what?
• “Agile” is a philosophy/methodology that boils down to:
• Break up the project into discrete delivera...
Agile? Agile what?
• “Agile” is a philosophy/methodology that boils down to:
• Break up the project into discrete delivera...
And Scrum is…?
• A set of procedures that are considered agile
And Scrum is…?
• A set of procedures that are considered agile
• No one actually implements them the same (AFAICT)
And Scrum is…?
• A set of procedures that are considered agile
• No one actually implements them the same (AFAICT)
• For y...
The Details in Four Steps
image credit: http://www.andertoons.com/
Step 1: Stories
• “Stories” are the way you should think about product
features
Step 1: Stories
• “Stories” are the way you should think about product
features
• Think in terms of the user: what goals d...
Step 1: Stories
• “Stories” are the way you should think about product
features
• Think in terms of the user: what goals d...
A Basic Example of User Stories
• To sign into your software:
• Story 1: User can register for an account
A Basic Example of User Stories
• To sign into your software:
• Story 1: User can register for an account
• Task: user mus...
A Basic Example of User Stories
• To sign into your software:
• Story 1: User can register for an account
• Task: user mus...
A Basic Example of User Stories
• To sign into your software:
• Story 1: User can register for an account
• Task: user mus...
A Basic Example of User Stories
• To sign into your software:
• Story 1: User can register for an account
• Task: user mus...
A Basic Example of User Stories
• To sign into your software:
• Story 1: User can register for an account
• Task: user mus...
A Basic Example of User Stories
• To sign into your software:
• Story 1: User can register for an account
• Task: user mus...
Add Each Story to PivotalTracker.com
• 80%+ of engineers will be familiar with it, just use it
Add Each Story to PivotalTracker.com
• 80%+ of engineers will be familiar with it, just use it
• Story writing guidelines:...
Add Each Story to PivotalTracker.com
• 80%+ of engineers will be familiar with it, just use it
• Story writing guidelines:...
Add Each Story to PivotalTracker.com
• 80%+ of engineers will be familiar with it, just use it
• Story writing guidelines:...
Add Each Story to PivotalTracker.com
• 80%+ of engineers will be familiar with it, just use it
• Story writing guidelines:...
Step 2: Organize & Track Your Backlog
• The “backlog” in Pivotal Tracker is the to-do list for the
entire project
Step 2: Organize & Track Your Backlog
• The “backlog” in Pivotal Tracker is the to-do list for the
entire project
• Always...
Keep it Simple for Your Team
• Pivotal Tracker is a reference point for the project; no
need to get fancy
• Ignore the poi...
Keep it Simple for Your Team
• Pivotal Tracker is a reference point for the project; no
need to get fancy
• Ignore the poi...
What Pivotal Tracker Story “States” Should Mean
Unstarted No one has begun work
Started Someone has started work
Finished ...
Step 3: Group Stories Into “Sprints”
• A “sprint” is a protected period of time for pre-
determined work on specific tasks
Step 3: Group Stories Into “Sprints”
• A “sprint” is a protected period of time for pre-
determined work on specific tasks
...
Step 3: Group Stories Into “Sprints”
• Sprints are organized around three crucial meetings:
• Start with a “sprint planner...
Step 3: Group Stories Into “Sprints”
• Sprints are organized around three crucial meetings:
• Start with a “sprint planner...
Step 3: Group Stories Into “Sprints”
• Sprints are organized around three crucial meetings:
• Start with a “sprint planner...
Sprint Planner
• Meet & decide what will get done in the sprint
Sprint Planner
• Meet & decide what will get done in the sprint
• Show up with all stories prioritized ahead of time
Sprint Planner
• Meet & decide what will get done in the sprint
• Show up with all stories prioritized ahead of time
• Rea...
Sprint Planner
• Meet & decide what will get done in the sprint
• Show up with all stories prioritized ahead of time
• Rea...
Each Day During the Sprint, PMs must:
• Conduct daily “standups”
• Each morning, everyone must meet and answer aloud:
• Wh...
Each Day During the Sprint, PMs must:
• Conduct daily “standups”
• Each morning, everyone must meet and answer aloud:
• Wh...
Each Day During the Sprint, PMs must:
• Conduct daily “standups”
• Each morning, everyone must meet and answer aloud:
• Wh...
Each Day During the Sprint, PMs must:
• Assist, answer questions, and “groom” Pivotal Tracker:
• Test the latest version o...
Each Day During the Sprint, PMs must:
• Assist, answer questions, and “groom” Pivotal Tracker:
• Test the latest version o...
Each Day During the Sprint, PMs must:
• Assist, answer questions, and “groom” Pivotal Tracker:
• Test the latest version o...
Each Day During the Sprint, PMs must:
• Assist, answer questions, and “groom” Pivotal Tracker:
• Test the latest version o...
Mid-Sprint DON’Ts:
• DO NOT skip stand ups
• You can’t afford to be that busy
Mid-Sprint DON’Ts:
• DO NOT skip stand ups
• You can’t afford to be that busy
• DO NOT change priorities or add tasks
• Th...
Mid-Sprint DON’Ts:
• DO NOT skip stand ups
• You can’t afford to be that busy
• DO NOT change priorities or add tasks
• Th...
Sprint Review
• What got done? What didn't? Is the project on pace?
Sprint Review
• What got done? What didn't? Is the project on pace?
• Keep it casual
• Friday end of day, 30 minutes max
•...
Sprint Review
• What got done? What didn't? Is the project on pace?
• Keep it casual
• Friday end of day, 30 minutes max
•...
Step 4: Assess Progress via Retrospectives
• “Retros” are meetings that give your team a chance to air
out any issues happ...
Step 4: Assess Progress via Retrospectives
• “Retros” are meetings that give your team a chance to air
out any issues happ...
You’ll Know You Need a Retro If:
• Your project is behind
You’ll Know You Need a Retro If:
• Your project is behind
• Your team is aggressive / passive aggressive
You’ll Know You Need a Retro If:
• Your project is behind
• Your team is aggressive / passive aggressive
• You’re not sure...
You’ll Know You Need a Retro If:
• Your project is behind
• Your team is aggressive / passive aggressive
• You’re not sure...
Format for Retros
• Take a “team temperature” on a scale of 1-10 (10 is
best): “how are we doing as a team?”
• Everyone on...
Format for Retros
• Take an individual temp
• Each person writes down, on a scale of 1-10, how they think
they're doing in...
Format for Retros
• Happy/sad/meh
• Using a whiteboard or Excel sheet, make columns with headers of
:), :| and :(
• Have t...
Format for Retros
• Wrapup
• Turn any action items into stories (if it's an engineering task) or to
PM to-do lists (if it'...
Retros Are Crucial!
• Retros can feel silly, but they’re important:
• Shouldn’t take more than an hour
• Should leave the ...
Summary
image credit: http://thedoghousediaries.com/
Building is Hard
• That’s why PMs are necessary
Building is Hard
• That’s why PMs are necessary
• As a non-engineer, your sole job at first is to organize &
manage progress
Being a PM Makes Everyone’s Life Easier
• Smart people have figured out some basic but important
procedures: agile/scrum
Being a PM Makes Everyone’s Life Easier
• Smart people have figured out some basic but important
procedures: agile/scrum
• ...
Be Organized & Communicate
• Amazingly simple things often undermine startups
• Projects slow down when team members don't...
Be Organized & Communicate
• Amazingly simple things often undermine startups
• Projects slow down when team members don't...
Be Organized & Communicate
• Amazingly simple things often undermine startups
• Projects slow down when team members don't...
Thanks for reading!
I’m happy to answer any questions:
@rustysf
(russwallace.com)
Please share on Twitter, LinkedIn, etc!
...
Upcoming SlideShare
Loading in...5
×

How to Build Software If You Can't Write Code

4,375

Published on

You've got a great app or website idea, but you don't know how to code...what do you do? This deck walks you through how to build your vision successfully and avoid the common pitfalls that non-technical startup founders face.

Transcript of "How to Build Software If You Can't Write Code"

  1. 1. By @rustysf (russwallace.com) How To Build Software If You Can’t Write Code
  2. 2. Who This Presentation is For • You want to build a startup software company
  3. 3. Who This Presentation is For • You want to build a startup software company • You’re not a software engineer
  4. 4. Who This Presentation is For • You want to build a startup software company • You’re not a software engineer • You’ve never worked at a tech company before
  5. 5. Who This Presentation is For • You want to build a startup software company • You’re not a software engineer • You’ve never worked at a tech company before • You believe “perfect” is the enemy of “good”
  6. 6. Why Learn to Be a Product Manager (PM)? • If you're not an engineer, then you're everything else
  7. 7. Why Learn to Be a Product Manager (PM)? • If you're not an engineer, then you're everything else • You need to know how to build the whole company • At first, you're a PM • Then, you're sales (or “Biz Dev” if you want to sound cool) • If lucky, you get to be an exec (culture, long-term plans, M&A, etc)
  8. 8. Why Listen to Me? • No sacred cows: I just want to get shit done @rustysf
  9. 9. Why Listen to Me? • No sacred cows: I just want to get shit done • No allegiances: I don't debate the finer points • Not interested in the “perfect” PM style, methodology, tool, etc. @rustysf
  10. 10. Why Listen to Me? • No sacred cows: I just want to get shit done • No allegiances: I don't debate the finer points • Not interested in the “perfect” PM style, methodology, tool, etc. • My opinion: • Your success doesn't hinge on “perfect” product management • Pick the most widely recognized, get organized and move on @rustysf
  11. 11. In My Experience image credit: http://xkcd.com/1349/
  12. 12. Product Management = Non-Technical Building • Software companies don't start needing sales or culture
  13. 13. Product Management = Non-Technical Building • Software companies don't start needing sales or culture • They start needing a good software product • Everything else comes after that
  14. 14. Product Management = Non-Technical Building • Software companies don't start needing sales or culture • They start needing a good software product • Everything else comes after that • Software engineers build software
  15. 15. Product Management = Non-Technical Building • Software companies don't start needing sales or culture • They start needing a good software product • Everything else comes after that • Software engineers build software • You're not a software engineer
  16. 16. Product Management = Non-Technical Building • Software companies don't start needing sales or culture • They start needing a good software product • Everything else comes after that • Software engineers build software • You're not a software engineer • You're only useful if you can help engineers build reasonably scalable code as fast as possible
  17. 17. What a PM Does • Make the decisions about a product that determine if it succeeds
  18. 18. What a PM Does • Make the decisions about a product that determine if it succeeds • What to build & when it needs to be built
  19. 19. What a PM Does • Make the decisions about a product that determine if it succeeds • What to build & when it needs to be built • Taking responsibility for what to include and what to leave out
  20. 20. What a PM Does • Make the decisions about a product that determine if it succeeds • What to build & when it needs to be built • Taking responsibility for what to include and what to leave out • Approving progress as it happens
  21. 21. What a PM Does • Make the decisions about a product that determine if it succeeds • What to build & when it needs to be built • Taking responsibility for what to include and what to leave out • Approving progress as it happens • Any admin on the project: • Setting up accounts, signing up for tools • Removing “blockers” (things big & small that prevent engineers from continuing to build) • Anything engineers don’t want to (or can’t) do
  22. 22. What a PM Does Not Do • PMs DO NOT code
  23. 23. What a PM Does Not Do • PMs DO NOT code • It's great to be technical, or to learn coding in order to communicate, but don't try to commit code
  24. 24. What a PM Does Not Do • PMs DO NOT code • It's great to be technical, or to learn coding in order to communicate, but don't try to commit code • PMs DO NOT decide how a product is built
  25. 25. What a PM Does Not Do • PMs DO NOT code • It's great to be technical, or to learn coding in order to communicate, but don't try to commit code • PMs DO NOT decide how a product is built • When/Why is not How • Engineers choose language, coding tools, libraries, etc (excepting choices that affect business aspects of the product, such as IP rights or functionality)
  26. 26. Side Note On Choosing What to Build • This is where you can help as a “business guy” (or gal)
  27. 27. Side Note On Choosing What to Build • This is where you can help as a “business guy” (or gal) • Talk to everyone who is relevant to your product • Talk to every potential customer. Take detailed notes on what they want. • If you're really good, sell a product before it's built
  28. 28. Side Note On Choosing What to Build • This is where you can help as a “business guy” (or gal) • Talk to everyone who is relevant to your product • Talk to every potential customer. Take detailed notes on what they want. • If you're really good, sell a product before it's built • DO NOT: read books, guess, or ask your friends and family what they want
  29. 29. Side Note On Choosing What to Build • This is where you can help as a “business guy” (or gal) • Talk to everyone who is relevant to your product • Talk to every potential customer. Take detailed notes on what they want. • If you're really good, sell a product before it's built • DO NOT: read books, guess, or ask your friends and family what they want • Once you know what to build, refer to this presentation to get it built
  30. 30. Before We Dive Into Details… image credit: http://www.gapingvoid.com/
  31. 31. Being a PM is Difficult • Becoming an “A-level” PM takes years of experience, mistakes and mentors
  32. 32. Being a PM is Difficult • Becoming an “A-level” PM takes years of experience, mistakes and mentors • This presentation will help you look like a “B”
  33. 33. Being a PM is Difficult • Becoming an “A-level” PM takes years of experience, mistakes and mentors • This presentation will help you look like a “B” • Repeat: a few slides can't make you an “A” • That's OK: you don't need to be an “A” PM to be an effective non-technical founder
  34. 34. Being a PM is Difficult • Becoming an “A-level” PM takes years of experience, mistakes and mentors • This presentation will help you look like a “B” • Repeat: a few slides can't make you an “A” • That's OK: you don't need to be an “A” PM to be an effective non-technical founder But you can't be a “C”
  35. 35. Product Methodologies (“How to Build”) • Almost as many as there are coding languages • Waterfall/BDUF • Agile/Scrum • Extreme/kanban
  36. 36. Product Methodologies (“How to Build”) ! SKIP IT: You can cover 80%+ of engineers you'll work with by understanding a scrum-based agile format
  37. 37. Agile? Agile what? • “Agile” is a philosophy/methodology that boils down to: • Break up the project into discrete deliverables
  38. 38. Agile? Agile what? • “Agile” is a philosophy/methodology that boils down to: • Break up the project into discrete deliverables • Communicate constantly
  39. 39. Agile? Agile what? • “Agile” is a philosophy/methodology that boils down to: • Break up the project into discrete deliverables • Communicate constantly • Focus on product goals, not features
  40. 40. Agile? Agile what? • “Agile” is a philosophy/methodology that boils down to: • Break up the project into discrete deliverables • Communicate constantly • Focus on product goals, not features • It’s the opposite of: • Creating lengthy, detailed product specifications before getting started
  41. 41. Agile? Agile what? • “Agile” is a philosophy/methodology that boils down to: • Break up the project into discrete deliverables • Communicate constantly • Focus on product goals, not features • It’s the opposite of: • Creating lengthy, detailed product specifications before getting started • Locking engineers into inflexible final product requirements before knowing what bugs/issues will arise
  42. 42. And Scrum is…? • A set of procedures that are considered agile
  43. 43. And Scrum is…? • A set of procedures that are considered agile • No one actually implements them the same (AFAICT)
  44. 44. And Scrum is…? • A set of procedures that are considered agile • No one actually implements them the same (AFAICT) • For your purposes, just know about: • Stories • Sprints (and the rules regarding these) • Retrospectives
  45. 45. The Details in Four Steps image credit: http://www.andertoons.com/
  46. 46. Step 1: Stories • “Stories” are the way you should think about product features
  47. 47. Step 1: Stories • “Stories” are the way you should think about product features • Think in terms of the user: what goals does the user have with respect to each feature?
  48. 48. Step 1: Stories • “Stories” are the way you should think about product features • Think in terms of the user: what goals does the user have with respect to each feature? • Goal is to think through every detail of the user’s experience before building
  49. 49. A Basic Example of User Stories • To sign into your software: • Story 1: User can register for an account
  50. 50. A Basic Example of User Stories • To sign into your software: • Story 1: User can register for an account • Task: user must enter full name, email and a password [include final designs for what this page looks like]
  51. 51. A Basic Example of User Stories • To sign into your software: • Story 1: User can register for an account • Task: user must enter full name, email and a password [include final designs for what this page looks like] • Task: forms must validate that the email address is valid
  52. 52. A Basic Example of User Stories • To sign into your software: • Story 1: User can register for an account • Task: user must enter full name, email and a password [include final designs for what this page looks like] • Task: forms must validate that the email address is valid • Task: after registering, user is taken to their Account Profile page [include destination link]
  53. 53. A Basic Example of User Stories • To sign into your software: • Story 1: User can register for an account • Task: user must enter full name, email and a password [include final designs for what this page looks like] • Task: forms must validate that the email address is valid • Task: after registering, user is taken to their Account Profile page [include destination link] • Story 2: User can sign into their account
  54. 54. A Basic Example of User Stories • To sign into your software: • Story 1: User can register for an account • Task: user must enter full name, email and a password [include final designs for what this page looks like] • Task: forms must validate that the email address is valid • Task: after registering, user is taken to their Account Profile page [include destination link] • Story 2: User can sign into their account • Task: user enters email address and password [include design for page]
  55. 55. A Basic Example of User Stories • To sign into your software: • Story 1: User can register for an account • Task: user must enter full name, email and a password [include final designs for what this page looks like] • Task: forms must validate that the email address is valid • Task: after registering, user is taken to their Account Profile page [include destination link] • Story 2: User can sign into their account • Task: user enters email address and password [include design for page] • Task: user can click “Forgot Password” to get an email with a link to reset their password [include design & copy for email]
  56. 56. Add Each Story to PivotalTracker.com • 80%+ of engineers will be familiar with it, just use it
  57. 57. Add Each Story to PivotalTracker.com • 80%+ of engineers will be familiar with it, just use it • Story writing guidelines: • Each story should relate to a single, discrete feature
  58. 58. Add Each Story to PivotalTracker.com • 80%+ of engineers will be familiar with it, just use it • Story writing guidelines: • Each story should relate to a single, discrete feature • Try to think of every question your engineer will have: • Always include needed design assets (PSDs, images, screenshots, whatever you have)
  59. 59. Add Each Story to PivotalTracker.com • 80%+ of engineers will be familiar with it, just use it • Story writing guidelines: • Each story should relate to a single, discrete feature • Try to think of every question your engineer will have: • Always include needed design assets (PSDs, images, screenshots, whatever you have) • Use the “tasks” section to create checklists for the engineers to double- check before submitting
  60. 60. Add Each Story to PivotalTracker.com • 80%+ of engineers will be familiar with it, just use it • Story writing guidelines: • Each story should relate to a single, discrete feature • Try to think of every question your engineer will have: • Always include needed design assets (PSDs, images, screenshots, whatever you have) • Use the “tasks” section to create checklists for the engineers to double- check before submitting DO NOT assume that your vision for the product is clear to your engineering team.
  61. 61. Step 2: Organize & Track Your Backlog • The “backlog” in Pivotal Tracker is the to-do list for the entire project
  62. 62. Step 2: Organize & Track Your Backlog • The “backlog” in Pivotal Tracker is the to-do list for the entire project • Always keep stories ordered by priority: • Stories that aren't dependent on any others are the highest priority (e.g., login requires sign up, so build sign up first) • Engineer will start at the top and work her way down
  63. 63. Keep it Simple for Your Team • Pivotal Tracker is a reference point for the project; no need to get fancy • Ignore the point system; not necessary for tiny teams • Keep all files, notes, comments, etc. in each story so that the history is in one place
  64. 64. Keep it Simple for Your Team • Pivotal Tracker is a reference point for the project; no need to get fancy • Ignore the point system; not necessary for tiny teams • Keep all files, notes, comments, etc. in each story so that the history is in one place • Simple = always available, always responsive • Respond to any changes in the story within 1 hour • Continually follow & update the status of each story until it is Accepted
  65. 65. What Pivotal Tracker Story “States” Should Mean Unstarted No one has begun work Started Someone has started work Finished Needs code review (if only 1 engineer, skip this step) Delivered PM must review and test the feature Accept Story is completed in full, all requirements are met and have been double-checked Reject Story not completed as requested (always leave notes when Rejecting)
  66. 66. Step 3: Group Stories Into “Sprints” • A “sprint” is a protected period of time for pre- determined work on specific tasks
  67. 67. Step 3: Group Stories Into “Sprints” • A “sprint” is a protected period of time for pre- determined work on specific tasks • One week sprint = plan on Monday, finish on Friday • Once the sprint plan has been agreed to, it cannot be changed (this is why the sprint should only last one week)
  68. 68. Step 3: Group Stories Into “Sprints” • Sprints are organized around three crucial meetings: • Start with a “sprint planner” on Monday
  69. 69. Step 3: Group Stories Into “Sprints” • Sprints are organized around three crucial meetings: • Start with a “sprint planner” on Monday • Conduct daily standups to check in every morning
  70. 70. Step 3: Group Stories Into “Sprints” • Sprints are organized around three crucial meetings: • Start with a “sprint planner” on Monday • Conduct daily standups to check in every morning • Conclude with a “sprint review” on Friday EOD
  71. 71. Sprint Planner • Meet & decide what will get done in the sprint
  72. 72. Sprint Planner • Meet & decide what will get done in the sprint • Show up with all stories prioritized ahead of time
  73. 73. Sprint Planner • Meet & decide what will get done in the sprint • Show up with all stories prioritized ahead of time • Read each story with the engineer, starting with the highest priority • Make sure the engineer knows what the story means and has everything she needs to complete it
  74. 74. Sprint Planner • Meet & decide what will get done in the sprint • Show up with all stories prioritized ahead of time • Read each story with the engineer, starting with the highest priority • Make sure the engineer knows what the story means and has everything she needs to complete it • Add all stories to be completed during a sprint to the “CURRENT” column in Pivotal • This will be your to-do list for the week: if all stories get done, you & your team were productive
  75. 75. Each Day During the Sprint, PMs must: • Conduct daily “standups” • Each morning, everyone must meet and answer aloud: • What did you do yesterday? • What are you doing today? • Are you blocked from further work by anything?
  76. 76. Each Day During the Sprint, PMs must: • Conduct daily “standups” • Each morning, everyone must meet and answer aloud: • What did you do yesterday? • What are you doing today? • Are you blocked from further work by anything? • Standups should be fast (15 mins max)
  77. 77. Each Day During the Sprint, PMs must: • Conduct daily “standups” • Each morning, everyone must meet and answer aloud: • What did you do yesterday? • What are you doing today? • Are you blocked from further work by anything? • Standups should be fast (15 mins max) • Over-communicate: share everything, clear anything preventing progress (“blockers”)
  78. 78. Each Day During the Sprint, PMs must: • Assist, answer questions, and “groom” Pivotal Tracker: • Test the latest version of the product
  79. 79. Each Day During the Sprint, PMs must: • Assist, answer questions, and “groom” Pivotal Tracker: • Test the latest version of the product • Report all bugs in Pivotal Tracker
  80. 80. Each Day During the Sprint, PMs must: • Assist, answer questions, and “groom” Pivotal Tracker: • Test the latest version of the product • Report all bugs in Pivotal Tracker • Accept/Reject any story within one hour after it is delivered
  81. 81. Each Day During the Sprint, PMs must: • Assist, answer questions, and “groom” Pivotal Tracker: • Test the latest version of the product • Report all bugs in Pivotal Tracker • Accept/Reject any story within one hour after it is delivered • Get any needed resources: answers from partners, additional designs, tools or libraries, passwords, etc.
  82. 82. Mid-Sprint DON’Ts: • DO NOT skip stand ups • You can’t afford to be that busy
  83. 83. Mid-Sprint DON’Ts: • DO NOT skip stand ups • You can’t afford to be that busy • DO NOT change priorities or add tasks • The point of a sprint is to agree on the deliverable and allow the engineer to focus
  84. 84. Mid-Sprint DON’Ts: • DO NOT skip stand ups • You can’t afford to be that busy • DO NOT change priorities or add tasks • The point of a sprint is to agree on the deliverable and allow the engineer to focus • DO NOT find out your engineer needs something that’s not in the story • All design assets (buttons, colors, fonts, screenshots, etc.) should be attached to the story before the sprint begins
  85. 85. Sprint Review • What got done? What didn't? Is the project on pace?
  86. 86. Sprint Review • What got done? What didn't? Is the project on pace? • Keep it casual • Friday end of day, 30 minutes max • Often done over beers, should be fun
  87. 87. Sprint Review • What got done? What didn't? Is the project on pace? • Keep it casual • Friday end of day, 30 minutes max • Often done over beers, should be fun • Take notes for next sprint • Organize your backlog over the weekend based on what did/ didn’t get done • Improve your organization (you will miss things at first; that’s OK)
  88. 88. Step 4: Assess Progress via Retrospectives • “Retros” are meetings that give your team a chance to air out any issues happening with respect to the project • “PM is pissing me off” • “My desk is uncomfortable” • “I think we’ve taken on too much,” etc.
  89. 89. Step 4: Assess Progress via Retrospectives • “Retros” are meetings that give your team a chance to air out any issues happening with respect to the project • “PM is pissing me off” • “My desk is uncomfortable” • “I think we’ve taken on too much,” etc. • Do these once every two weeks at the end of the sprint
  90. 90. You’ll Know You Need a Retro If: • Your project is behind
  91. 91. You’ll Know You Need a Retro If: • Your project is behind • Your team is aggressive / passive aggressive
  92. 92. You’ll Know You Need a Retro If: • Your project is behind • Your team is aggressive / passive aggressive • You’re not sure what the project goals are anymore
  93. 93. You’ll Know You Need a Retro If: • Your project is behind • Your team is aggressive / passive aggressive • You’re not sure what the project goals are anymore ! IMPORTANT: DO NOT SKIP RETROS!
  94. 94. Format for Retros • Take a “team temperature” on a scale of 1-10 (10 is best): “how are we doing as a team?” • Everyone on the team writes down their rating • Review any outliers (if 2 folks are a 9 and 1 is a 6, ask the 6 why?) • Try to come up with action items if needed
  95. 95. Format for Retros • Take an individual temp • Each person writes down, on a scale of 1-10, how they think they're doing individually • Review any outliers here as well, make action items
  96. 96. Format for Retros • Happy/sad/meh • Using a whiteboard or Excel sheet, make columns with headers of :), :| and :( • Have the team write bullet points beneath each: what is making you smile, frown or think “meh”? • Can be anything, from “I had great coffee” to “office is too loud” • Review each entry, make action items
  97. 97. Format for Retros • Wrapup • Turn any action items into stories (if it's an engineering task) or to PM to-do lists (if it's anything else) • Review the action items periodically to make sure they’re being resolved
  98. 98. Retros Are Crucial! • Retros can feel silly, but they’re important: • Shouldn’t take more than an hour • Should leave the team feeling like they’re all on the same page
  99. 99. Summary image credit: http://thedoghousediaries.com/
  100. 100. Building is Hard • That’s why PMs are necessary
  101. 101. Building is Hard • That’s why PMs are necessary • As a non-engineer, your sole job at first is to organize & manage progress
  102. 102. Being a PM Makes Everyone’s Life Easier • Smart people have figured out some basic but important procedures: agile/scrum
  103. 103. Being a PM Makes Everyone’s Life Easier • Smart people have figured out some basic but important procedures: agile/scrum • Following them is simple once you get used to it: • Stories & a tool to keep track of them (Pivotal Tracker) • Sprints (planners, standups, reviews) • Retrospectives
  104. 104. Be Organized & Communicate • Amazingly simple things often undermine startups • Projects slow down when team members don't talk • Breakdowns in communication lead to confusion, wasted time, frustration & ultimately business failure
  105. 105. Be Organized & Communicate • Amazingly simple things often undermine startups • Projects slow down when team members don't talk • Breakdowns in communication lead to confusion, wasted time, frustration & ultimately business failure • Don’t let this happen to you
  106. 106. Be Organized & Communicate • Amazingly simple things often undermine startups • Projects slow down when team members don't talk • Breakdowns in communication lead to confusion, wasted time, frustration & ultimately business failure • Don’t let this happen to you Anyone who is detailed, thoughtful and has great taste for quality products can build awesome software
  107. 107. Thanks for reading! I’m happy to answer any questions: @rustysf (russwallace.com) Please share on Twitter, LinkedIn, etc! image credit: http://jimbenton.com/
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×