Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Lessons Learned Implementing Scrum (presentatio...

Lessons Learned Implementing Scrum (presentation mode)

Personal insights, tips and stories you could use.

Presentation mode, expect high-level bullets.
You can find "offline reading mode" here - https://speakerdeck.com/orenellenbogen/lessons-learned-implementing-scrum

Oren Ellenbogen

May 28, 2013
Tweet

More Decks by Oren Ellenbogen

Other Decks in Technology

Transcript

  1. • Engineer at Commerce Sciences • Curator of SoftwareLeadWeekly •

    ex. Delver (Sears IL) Director of Engineering Blog: lnbogen.com @orenellenbogen SoftwareLeadWeekly.com + Oren Ellenbogen
  2. • Implemented Scrum at Delver from Day 1 – Sprints

    of 3 weeks. – Releasing versions at the end of each sprint. – Retrospective at the end of each sprint. • No (official) Scrum Master • Daily Standup Meeting at 10:30 • Managed to scale it as we go (details to follow)
  3. The important stuff: • What are we trying to achieve

    with it? • Can this process fit our people? • Will it scale? Stop worrying about: • DSM time, Scrum Master role, Sprint length etc.
  4. • Sprint length was changed to 2 weeks. • We

    hated the “no touch” sprints, so we changed it. • Sprints were decoupled from releases. • We conducted “Sprint Retrospection” once a month. • We started to use Feature Ownership. • We started to use Poker Planning (gradually).
  5. Distributing culture values by letting everyone to participate in it.

    • Were responsible to deliver feature, end-to-end. • Why? – Things happen when you’re not there. – Distributed “one man show” is actually a good thing. – Great chance for people to practice leadership. – Great chance for team lead to learn how to mentor. – Strong FOs enable scalable company.
  6. 1. Own a given domain – Deliveries – KPIs (Business

    Metrics) – Work on things that move the needle (provide feedback) 2. Enable company’s scale – Clear the way. – Make your people happy (turnover slows us down.) – What will happen to your team if we’ll double it? – Always be ready for growth (team lead candidates?) – Delegate as much as possible. – Stay hands-on by working on non-critical features.
  7. • Limits: – 1 hour in total, up to 5

    minutes per estimation. – Feature is too big? break into “design” + “implementation”. Estimate only “design” part. • We did it to enable scale by: – Improve at the art of estimation (ask the right questions). – Team ownership. • Alignment is not always easy: – We had to align with Product – We had to align with Technical Leads
  8. Feelings are key: if people feel their technical debt is

    unmanaged, it will demotivate them going forward. • Invest in it per feature – Need to carefully understand tradeoffs of course. – Estimate it as part of the feature (Poker Planning) • Invest in it per sprint – Set a range (e.g. 1-2 days) and don’t change it too often. – It will force “small improvements” state of mind instead of a technical-debt-sprint.
  9. • “design” phase: – Goal: get better estimation of the

    work required. – Does not have to include architecture spec. – With Product’s help - offer deliverable milestones. • Invest time in the “design” task as soon as you can. (assuming the feature is interesting) • Once you’ve got estimation: – Be willing to change current sprint plan. – Be willing to stop after reaching some milestone.