1.
Creating a development process
that fits your organisation
How we created ours at Loop54

2.
Björn Sundman
- VP Engineering at Loop54
- Computer science and backend developer
- 12 yrs technical management
- Had roles as Product Manager, CTO,
Tech Director and VP Engineering
- Certified Scrum PO & Scrum Master

3.
How do you work with your engineering team?
- Problems we experienced with Scrum
- What we did instead
- Maybe get you to challenge how you work with
your engineering team

4.
Starting point

5.
Loop54 & the Team
- Complex AI search engine for e-commerce
- With a complex product, much of the product
development is technology driven
- Team has wide area of responsibility such as
hosting, infrastructure, ML/AI algorithms,
frontend, backend, data processing etc
- Team members have different skills

6.
Our challenges (using Scrum)
- A lot of smaller urgent tasks filled our sprints
- At least 3 major bodies of work
- Shoehorn in the long term work!
- Long discussions not concerning everyone
- Difficult to plan for different competencies

7.
Consequences
- Frustration!
- Low progress on long term important things
- Low control
- People had a feeling of not moving forward

8.
Creating our own process

9.
Insight #1
Fully understanding all aspects of a complex enough
problem takes time, requires focus and it is a
continuous learning process

10.
Insight #2
Fully understanding a complex problem is a
requirement to come up with a genuinely good long
term solution

11.
Insight #3
You can only work on very few things at a time and
still do it well

12.
Insight #4
Goals are not always obvious to everyone

13.
Insight #5
Developers like to design and build good solutions

14.
Insight #6
Working together results in better solutions

15.
Insight #7
There’s usually no way around problems other than
fixing them

16.
Insight #8
Estimates are unreliable

17.
Insight #9
If it’s important, you should do it

18.
Insight #10
Time plans are a good tool for creating the right
discussion

19.
Trails
Trails are a focused development effort with a
specific goal. They are a way for a smaller group of
developers to work in a dedicated way towards
achieving a result with high degrees of freedom and
responsibility.

20.
Trails
- Have a clear goal
- 2-3 developers
- No developer is on more than 2 trails
- Have a lightweight steering document
including a time plan, deliveries &
delimitations
- Owned by the developers
- Weekly meeting with PO & Eng. manager

21.
What else?
- “No trail” work with a fast lane for PO
- Fix minor issues using your best judgement
- Fix all issues causing incidents immediately
- Weekly review of roadmap as a team
- 20% of time on technical debt / innovation
- Current state on a kanban board

22.
What it looks like
Trail 1
Trail 2
Trail 3
No trail
Dev A & B
Dev A & C
Dev A, B & C
Continuous non-trail “stuff”
Timescale: months

23.
In practice
- Based on kanban

24.
Results

25.
Results
- Happy team
- A strong feeling of making progress
- We have delivered 5 important trails in a year!
Timely and with high quality
- Drastic reduction in firefighting
- We now get much better focus on important
work!

26.
I encourage you to challenge the way you work with
your engineering team!