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

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

• 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)

1 Because people prefer reasoning over details.

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.

2 Changes lead to distributed ownership -> scalable process

• 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).

3 Scalable company: scaling your people by scaling your process

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.

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.

• 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

4 Tactics you can apply

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.

• “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.

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

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