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

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

1 Because people prefer reasoning over details.

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.

2 Changes lead to distributed ownership -> scalable process

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

3 Scalable company: scaling your people by scaling your process

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.

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.

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

4 Tactics you can apply

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

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

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

Happy Scrumming! oren.ellebogen@gmail.com rowanbank Photo credit: