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

Lessons Learned Implementing Scrum

Lessons Learned Implementing Scrum

Personal insights, tips and stories you could use.
(slides you can read offline, expect plenty of text :))

Oren Ellenbogen

May 27, 2013
Tweet

More Decks by Oren Ellenbogen

Other Decks in Technology

Transcript

  1. Personal insights, tips and stories you could use.
    Oren Ellenbogen [reading mode]

    View Slide

  2. • Engineer at Commerce Sciences
    • Curator of SoftwareLeadWeekly
    • ex. Delver (Sears IL) Director of Engineering
    Blog: lnbogen.com
    @orenellenbogen
    SoftwareLeadWeekly.com
    +
    Oren Ellenbogen

    View Slide

  3. • Implemented Scrum at Delver from Day 1
    – Sprints of 3 weeks.
    – Version deployed 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)

    View Slide

  4. 1
    Because people prefer reasoning over details.

    View Slide

  5. The important stuff:
    • What are we trying to achieve with it?
    – Openness, short feedback loops, team building, fun, focus, celebrate success.
    • Can this process fit our people?
    – “We want to work with people who […] in an environment where […]”
    – Write it down, use it as a goal. Adjust process to people, not the other way around.
    • Will it scale?
    – People should believe that process value > cost.
    – If people afraid it won’t fit as the company grows, they will be reluctant to support it.
    – Everyone should be able to explain the motivation behind it (not only the rituals)
    Stop worrying about:
    • DSM time, Scrum Master, Sprint length etc.

    View Slide

  6. 2
    Changes lead to distributed ownership -> scalable process

    View Slide

  7. • Sprint length was changed to 2 weeks.
    – Increase release cycles, quicker product changes.
    • We hated the “no touch” sprints, so we changed it.
    – Business needs to adjust, we shouldn’t hold back.
    – Take out other features that weren’t started instead.
    • Sprints were decoupled from releases
    – We believed that sprint is a planning unit, not a release unit.
    Allowed us to move toward Continuous Delivery.
    • We conducted “Sprint Retrospection” once a month.
    – To reduce amount of meetings.
    – We also had release retrospections when needed.
    • We started to use Feature Ownership & Poker Planning
    – To prepare our company for growth.
    – (More details to follow)

    View Slide

  8. 3
    Scalable company: scaling your people by scaling your process

    View Slide

  9. Distributing culture values by letting everyone to participate & lead.
    • Responsible to deliver feature, end-to-end
    – (including deployment & support)
    – We also had QA FO and Ops FO to join Dev FO.
    – Worked directly with Product.
    • Why?
    – Things happen when you’re not there.
    • Let them teach others. Have some faith, they will surprise you.
    – “One man show” is actually a good thing, if everyone gets to do it.
    • Skill: communicate with Product, Development, QA, Ops.
    • Skill: conduct retrospection and drive actions from it.
    • Own failures & successes.
    – Great chance for people to practice leadership.
    • Lead by example first.
    • Learn how difficult yet rewarding it can be.
    – Great chance for team lead to learn how to mentor their teammates.
    • Learn how to give feedback and push people to improve.
    • Learn who’s doing it to gain control and who’s doing it to empower others (team lead candidates?).
    – If you have strong FOs in your team, you’re on the right track to scalable company.

    View Slide

  10. 1. Own a given domain
    – Deliveries
    – KPIs (Business Metrics)
    – Work on things that move the needle
    • It’s your responsibility to provide feedback if you think it’s not the case.
    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.

    View Slide

  11. • Limits:
    – 1 hour in total, up to 5 minutes per estimation.
    – If feature is too complex: break into “design” + “implementation”.
    Estimate only “design” part (more on that later.)
    • We did it to enable scale by:
    – Improve at the art of estimation
    • Just like you’re Pair Programming, to get better at programming.
    – Team ownership
    • Eliminating “You said 5, but I’m implementing it, and it’s a 13”
    • Alignment is not always easy:
    – We had to explain Product
    • Not only for their immediate benefit (can help, but not time efficient).
    – We had to explain our Technical Leads
    • I need them to teach others the right questions to ask. Patience is key.

    View Slide

  12. 4
    Tactics you can apply

    View Slide

  13. • Feelings are key: if people feel their technical debt is
    unmanaged, it will demotivate them going forward.
    – Have an internal backlog.
    – They have to feel you’re on top of it.
    – Communicate with your boss & peers – you’re going to invest the
    right amount of time (not too much, not too little)
    • Invest in it per feature
    – Need to carefully understand tradeoffs, of course.
    • “always leave the system better than you found it”
    – Estimate it as part of the feature (Poker Planning)
    • Invest in it per sprint
    – TIP: 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.

    View Slide

  14. • Break them into “design” and “implementation(s)”
    – Goal of design: create understanding and estimation of the
    work required. It does not have to include architecture spec or
    any other document.
    – 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 plans
    – Maybe you can implement 80% of the feature (and value) now.
    • Be willing to stop after reaching some milestone
    – Maybe the feature is not as important as initially thought.

    View Slide

  15. Bonus
    Eat pizza, watch how your customers using the product, have fun ;)

    View Slide

  16. Happy Scrumming!
    [email protected]
    rowanbank
    Photo credit:

    View Slide