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

Lessons Learned Implementing Scrum (presentation mode)

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


  1. Personal insights, tips and stories you could use. Oren Ellenbogen

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

    ex. Delver (Sears IL) Director of Engineering Blog: lnbogen.com @orenellenbogen SoftwareLeadWeekly.com + Oren Ellenbogen
  3. • 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)
  4. 1 Because people prefer reasoning over details.

  5. 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.
  6. 2 Changes lead to distributed ownership -> scalable process

  7. • 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).
  8. 3 Scalable company: scaling your people by scaling your process

  9. 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.
  10. 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.
  11. • 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
  12. 4 Tactics you can apply

  13. 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.
  14. • “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.
  15. Bonus Eat pizza, watch how your customers using the product,

    have fun ;)
  16. Happy Scrumming! oren.ellebogen@gmail.com “Reading mode” slides - https://speakerdeck.com/orenellenbogen/lessons-learned-implementing-scrum rowanbank Photo