Skip to content

Instantly share code, notes, and snippets.

@ys-qb
Last active July 11, 2017 01:52
Show Gist options
  • Save ys-qb/fce103003fb247472c278246e6291960 to your computer and use it in GitHub Desktop.
Save ys-qb/fce103003fb247472c278246e6291960 to your computer and use it in GitHub Desktop.
agile@startup

Problems


source: [projectcartoon.com](http://www.projectcartoon.com/cartoon/2)

Thinking, Fast and Slow




A strong team is needed for success


Technical Debt

source: [philippe.kruchten.com](https://philippe.kruchten.com/)

The Project Management Triangle

schedule+budget+feature=quality


Scrum


Process


Key Roles


Ceremonies 1/2

Continuous, Incremental and Evolutionary change

source: wikipedia

Ceremonies 2/2

  • PLAN - Sprint Planning meeting
    • 4 hour : Prioritizing the Product Backlog
    • 4 hour : Resulting in the Sprint Backlog
  • DO - Daily Scrums
    • 15min everyday, 10 days duration.
  • CHECK - Sprint Review meeting
    • 1 ~ 2 hours
  • ACT - Sprint Retrospective
    • 1 hours

Planning meeting

  • Product Owner set priority based on business value.
  • Team estimates effort
    • Planning Poker
    • “look ahead” stories
  • 1st half meeting : Product Owner + Team
    • Product backlog with updated priority and estimate.
    • Define output (or demo) to be shown at Sprint Review
  • 2nd half meeting : Team only (+ Product Owner if needed)
    • Sprint backlog with tasks to be done in the next Sprint.

Product Backlog


Sprint Backlog


Daily Scrums

  • Everyday same room, same time, stand-up and time-boxed 15min.
    • 11:00 AM – PRJ#3 11:30 AM – lunch time
  • Self-management, self-organizing.
    • Chicken role cannot speak. Team protected from outside influence during sprints
    • Report to team(not Scrum Master or Product Owner)
  • Input
    • What have you done since yesterday?
    • What are you planning to do today? Choose own task
    • Do you have any problems that would prevent you from accomplishing your goal? ScrumMaster to resolve
  • Output: Updated Scrum board including burndown chart

Scrum Board


Sprint Review

  • Demo to stakeholders and get feedback.
  • Open to anyone interested in Sprint output.
  • Just demo a working software, a potentially shippable increment (PSI). No significant effort for slide preparations.
  • In-completed work cannot be demoed.
  • Input
    • E.g. - Demo video clip, Hands on demo, Design document, Effort estimation for future user stories, customer feedback and etc.
  • Output
    • Gathered feedbacks are added to Product backlog.

Sprint Retrospective

  • The most important part to improve gradually and to reach huge improvement after all.
  • Input
    • What went well during the sprint?
    • What could be improved in the next sprint?
    • Output – act!
      • E.g.
        • Adjust Sprint duration from 2weeks to 1 week.
      • Use different colored post-it for originally unplanned tasks.

Burn-down Chart

  • Visible!
  • See Velocity over iterations.
  • Estimation will be more accurate as Sprint repeats.
  • Transparency builds trust!

Tools

- whiteboard! - online tools: zenhub, github project, trello, standuply and etc.

Kanban and XP


source: wikipedia

Kanban - cumulative flow diagram


Scrum vs Kanban

Scrum Kanban
Timeboxed iterations Eevent-driven
Team commits for work amount
Velocity(burndown chart) Lead time(CFD)
One cross-functional team
Items must be broken down
WIP limited
Add Item at planning time On available capacity
Board is reset btw iterations
Roles No prescribed roles

Scrum vs Kanban

Scrum Kanban
Transparency Flexibility
Improved credibility with clients Focus on continuous delivery
High product quality Increased productivity and quality
Product stability Increased efficiency
Team members reach sustainable pace Team members have ability to focus
Allows client to change priorities and requirements quickly Reduction of wasted work/wasted time

XP + Scrum

...


서투른 목수가 대패 탓만 한다.

ANY process or methodology (that is not actively destructive), applied to a skilled, disciplined, high-functioning, motivated team, will succeed, regardless of the process. Likewise, any process applied to a low-functioning team will likely fail.


further study...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment