Personal insights, tips and stories you could use.
(slides you can read offline, expect plenty of text :))
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
• 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)
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.
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)
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.
– 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
– 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.
– 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.
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
• 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.
Eat pizza, watch how your customers using the product, have fun ;)