Agile Discussion - Concur

Agile.md

SCRUM & Agile

​ with SCRUM Master Mark Hervol ​

• Ideal state:
  • Why Agile?
    • little slices that work, until we reach 'good-enough'
    • how fast can we turn around feedback
    • see: Silicone Valley on HBO
• Start with a user story (As a [user] I want [thing] so I can [value]).
  • DON'T "As a user I want a list because I want a list"
    • Why do you want a list?
    • How is that list helpful?
    • What goes on the list and why? etc
• Agile Manifesto: Conversations over Documentation
  • Of course there is documentation, but conversations between all parties is highly encouraged — COMMUNICATION over spec docs.
• Three Primary Roles in a SCRUM team:
  1. Team
  • Build it right (or drown in tech debt)
  2. Product Owner (PO)
  • Build right thing (or build something worthless)
  3. Scrum Master
  • Build thing fast (remove impediments)
  • Kind of an arbitrator (or miss market opportunity)
  • No dev organizations in Concur — SCRUM master is not beholden to anyone
  • 2 sprints should be at the top of the backlog refined and ready to go
    • no need to do refinement in planning
    • refinement should not occur in planning and vice versa
    • don't waste time refining things farther down — we may never get to it
• MVP - minimum viable product(or valuable product) to get feedback on features, etc
  • MMP - minimum marketable product; when we can charge for it
• KANBAN vs SCRUM
  • kanban is VISUAL but just as intense — it is NOT 'SCRUM-lite'
  • in the beginning of SCRUM, index cards were used: the feature on the front and the story on the back, meaning NO ROOM FOR ADDITIONS — do not get off track
• Sprint:
  • planning
    • a contract should come out of this: we believe as a team that we can get all this work done in the end
      • contract should be adhered to and should not have additions or deletions
        • If contract is broken by team, PO will feel the need to give additions; ruining progress made and momentum ultimately resulting in the waterfall rather than agile
  • standup
    • it is not just a check-in — blockers are IMPORTANT; always ask for help if needed
  • review
  • retro
  • refinement (peppered throughout sprint)
    • responsibility of product owner
• What I did/What I think I will do.../Blockers
  • Never "what I will do..." because this is agile and anything may change — a team mate may need help and your plans for the day may change
  • If you have an outstanding PR, you are blocked; and it needs to be a priority of the team to unblock (aka review PR)
• Fist of Five meeting: 1-5 fingers on how well they think they can get something done
• Question to ponder: What would not exist in the industry if you did not pursue this career?
• 3 Amigos
  • a refinement on refinement (every couple of months)
  • do people understand the story? how big do we think it is? etc
  • the amigos: Dev Manager, SCRUM, PO
    • find holes and assign them
    • fibonacci: effort, risk, unknown, tediousness
      • effort, not time!
        • example: junior dev may believe a story is a 3 and senior dev also agrees it is a 3; the effort for each developer is the same but the time it takes to finish the story is different (junior dev may take a day, senior dev may take 20 minutes but the effort on their part is the same).
• inspect and adapt during sprint review
  • review: on the product
  • retro: on the team and sprint process
    • also retro of retro
• definition of done: we did all the things that were necessary to pull it into a sprint
  • double-check against reality
• definition of ready: did not cut corners; customers will not complain
• the burndown (a visual graph of a sprint):
  • it gives scrum questions to ask and how next sprints may improve
• user story mapping
  • go through the motions
  • MVP is barebones - the absolute minimum you need to do in the morning
  • MMP is the other stuff that you would do if you had time and luxury
  • then...we get into personas: the "dog-person", the "fitness fanatic": what do they need to do in the morning, etc.