A development process is essentially a framework for how to work together in an engineering team and the way the team works together has great impact on how well it supports the product and the organisation. Ideally, the way that the process is outlined should be aligned with the business strategy. For example, if innovation is important for your business, you need a process that supports innovation. If timely deliveries is more important, you need to adapt your process to that requirement. In this talk Bjorn will explain what the Loop54 development process looks like and give concrete examples of what effects it was designed to create and how that is manifested in the process.
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
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
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
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!
Notes de l'éditeur
What I want to talk to you about today is how we work with our development teams.
How many of you are developers, designers, product owners/managers? How many of you use Scrum, Kanban in your teams today? I’m going to assume that you are familiar with scrum and kanban, I’m sorry if that’s not the case.
Like I said, I want to talk about how we work with our engineering teams. I’m going to give you a quick glimpse into what problems we experienced at Loop54 using Scrum and what we ended up doing instead. The results for us have been more positive than I ever could have imagined and I hope this will bring you some inspiration and ideas about things you might try in your organisation.
In this section I’ll introduce you to Loop54, our product, our team and the challenges we were facing using Scrum
Those of you who have worked with Scrum recognize the scrum planning session where you look at the ordered list of stuff you need done and based on the estimates you include enough tasks to fill your average velocity. When we did it, we ended up filling almost the entire sprint with smaller urgent tasks that needed to get done.
A the same time, we had at least 3 major long term important product development bodies of work that we needed to work on. We had shoehorn those in when a large part of the sprint was already filled with urgent tasks.
I mentioned that the team has a very broad area of responsibility and different skills. Quite often, we would have lengthy discussions about backend development or infrastructure with our AI engineer and frontend developer bored out of their mind. We also struggled to plan work for said frontend and AI engineers as their focus was often on more isolated work.
As you can understand, this was really frustrating!
Not only were planning meetings painful and generally hated. We also had a feeling of not making progress on the things that mattered to us, and this is not a good feeling to have in a development team.
Our product manager wanted to understand when we were completing important initiatives and it was almost impossible to give an answer.
Last but not least, people didn’t feel that they were developing themselves or that they were doing qualified work.
So, what do you do?
We stuck with Scrum for about 6 months and made smaller alterations to it but ultimately realised that it just wasn’t for us.
Outcomes of retrospectives and 1on1 conversations with team members combined with general experience on leading development teams led us to a set of insights that I will share with you now.
Development work, especially when dealing with a complex product, isn’t easy and requires time and focus to get right. Basically, the more you work on something, the better you get at it. Hopefully this feels intuitively right for you.
An important extension of the first insight. A better understanding of a problem and the complexities involved will increase your chances of creating a good solution. This means that the knowledge and experience acquired by one team member when developing a particular piece of functionality makes that very person a much better choice than other team members to continue developing that functionality.
As humans, we are much better at doing one thing at a time than doing them at once. Unsurprisingly this applies to development too!
Our goals often feel obvious to us, so much so that it’s easy to not talk about them enough. My experience is that most people have an idea of what the goals are but they can be very different from your idea of the goals. This can be problematic of course since we increase the chances of building the right thing if everyone is in agreement on the goals.
I don’t have any scientific facts to back this up but it’s my personal belief that almost all developers enjoy building good stuff.
This I do believe is scientifically supported by several studies although I will not site any here.
Although there may be some generic truth to it, I’m referring here mostly to problems in production. If you have a bug in production that affects your availability then you should basically always fix it right away.
Yep, they are
What I’m trying to say here is that if you know something is really important then don’t worry about estimating it, just do it and work with the scope along the way. To give you an example, we spent 1,5 building a new API. It wasn’t estimated to take nearly that of course but things happened along the way. In retrospect, would we have made another decision if we had known it would take that long? No, we needed that API and now that it’s in place it just as good as we had hoped it would be.
Deadlines don’t work very well for us. That’s not to say that it doesn’t matter how long time things take. It’s just a lot more important that we do things right than by a certain date. The good thing about time plans is that they clarify what parts are of unknown complexity and give rise to important discussions about scope.
We took all of these insights and we created something we call trails. The function of the trail is to let developers keep their focus on a larger delivery until that delivery is done.
In more details… (next slide)
In addition to trails we added a few more routines.
We do a lot of work that’s not in a trail because of course “stuff” didn’t just stop happening because we started working in trails. We also have a “fast lane” for the PO when minor things that take priority from a product point of view show up.
We review our shared roadmap every week. This is so that everyone understands what’s going on, even in trails where they are not an active part. This is also a good opportunity to repeat goals.
Every developer spends every 5th week fixing technical debt or work on an idea they have. The choice of what to work on is almost entirely theirs.
After years developing a product, there are many small annoyances lying around for developers. Our policy is to fix those as you encounter them without going through any kind of planning process
Whenever we’ve had any kind of incident, we find out the cause and fix it so that I doesn’t happen again. This sounds simple enough and it is in a way if you allow yourself the time.
We visualise the current state of all ongoing work in a Trello kanban board.
This is a sketch of the rough idea.
Development roadmap
This is what 2018 looked like in reality for us. We automatically collect the total number of completed hours per trail each week. The reason it’s so spiky is that only when cards are completed do the hours count toward the trail. You can see that the blue (no trail work) is the most significant component but also that clear progress is being made on other trails.
We’ve been doing things this way for 1,5 years now
