The document provides an overview of an engineering team's culture and process. It discusses aiming for excellence, staying open, and never stopping learning as cultural values. It also describes using a Kanban-style system to manage work items like epics, stories, tasks and bugs through different statuses and columns. Technical details are provided on how to estimate tasks, track time, and follow branching strategies when working on assignments. New employees within their first two months are expected to publicly discuss implementation strategies before coding tasks.

1. #1 Our Culture
#2 Our Engineering Process
2021

2. Welcome to the team!
• We're excited to have you as part of our team!
• The
fi
rst part of these slides focus on our overall culture and way
of doing things.
• The second part focuses on our software engineering process, but
it's still a helpful read for everybody who wants to get familiar with
our approach.
• It might seem a bit overwhelming at
fi
rst, but don't fret, you'll get
used to everything in a blip and there are tons of nice colleagues
around to help you get started. There's a big chance that you'll
end up loving it here!
Disclaimer: The second part of this presentation assumes a fundamental understanding of engineering management. This
includes basic principles such as code versioning using Git.
🎉

3. Our Culture
#1

4. Aim for Excellence
• We strive to deliver excellence in everything we do,
from business process to engineering product.
• Excellence cannot be tasked from above,
or put on a roadmap.
• If excellence is not visible at every step along the way,
it is impossible for the
fi
nal result to be excellent.
• We believe that to achieve excellence,
we need a precise and thorough culture to do so.

5. Stay Open
• We believe that staying open is key to continued success and growth.
• Being open means to be open for ideas and feedback but extends to
being open to people and challenges.
• It translates to having information
fl
ow freely within the company, and
allowing everybody to participate and follow the discourse.
• In practice, this results in us not hiding our discussions in emails or
private chats. Instead, our discussions take place in a way that they’re
visible to all of our colleagues.
• This approach works well for us, as it ensures that information is not lost
between two parties. But more importantly, it's great for people new to
the team, as the learning process is immediately available to everybody
in the same way.

6. Never Stop Learning
• Being unable or unwilling to learn unavoidably
results in stagnation and ultimately leads to
frustration and the inability to deliver excellence.
• We believe learning is a continuous process, not
just for humans but also for companies.
• We welcome all constructive and well-spirited
feedback; whether it's for our code-style
guidelines, our management or our culture.

7. A Worthwhile Work Experience is...
• working next to high performing and excited colleagues,
• on a project that aims to challenge the status quo,
• with the
fl
exibility to self-organize and determine how things are done,
• in an environment that is continuously evolving with new challenges and
opportunities.
...but it's not...
• Excessive parties, coffeeshop perks or sleeping areas.*
• The ability to waste company resources by setting countless meetings,
• or slow poking on a task that your colleagues depend on.
* Of course we have great perks and do parties — but it's not what makes us great!

8. Excellence is not for Everyone
• Being on a mission to deliver excellence at every step is an adventure.
• Adventures are exciting and challenging, and it's why people love us and stay for a long time.
• These people thrive in an environment that values excellence, honesty and openness.
• If somebody from this group parts ways, the person typically fondly remembers the work
experience with us.
• Other people, however, prefer job security, predictability and a static working
environment over doing something amazing.
• They tend to feel like they cannot deliver, or feel pressured due to seeing others perform well.
• They don't feel well when having conversations in the open or their skillset is presented in a
transparent environment.
• They feel like that our culture is too strict or asking for too much.
• These people are bitter and frustrated when let go.
• It took us a while to understand this, and we're getting better at displaying our
values and culture proudly, to ensure that we're attracting the right kind of people.

9. Key Skills 1. Motivated and Enthusiastic — You're excited about the
success of others but your own as well.
It's what motivates you on a daily basis.
2. Self-Organized — You don't need somebody to tell you
what to do. You're ready to work on whatever needs to be
done.
3. Responsible — You're bold and ready to be an agent of
change and get praise for it. But if something goes wrong,
you're not afraid to step up and be accountable for it.
4. Making the right calls — The decisions you made in your
life and career are the right ones and you're con
fi
dent that
this was due to your logical and strategic thinking.
5. Great communicator — You know that words matter and
it's not dif
fi
cult for you to strike the right tone. You're
always honest but even more, you're always respectful.
6. Heavy hitter — Your work makes a difference, it moves
the project forward and your contributions are easily visible.
7. Curious Learner — Even though you're great at what you
do, you immediately acknowledge that you keep learning at
every interaction.
8. Sel
fl
ess — You don't mind going the extra mile to help
somebody out, even if it might cost you a bit of your own
time.
• We highly value the following
eight character traits and skills.
• Hopefully, you see a re
fl
ection of
yourself in a majority of our key
skills.
• If you're not, then it's likely that
you would not mesh well with our
team and our culture.
• Thank you for taking the time to
read through the slides that aim
to capture the spirit of our culture.

10. Our Engineering Process
#2

11. Methodology
• A project is driven by work-items that can be categorized into
different groups with different statuses
• Groups: EPIC, STORY, TASK, BUG
• Statuses: Backlog, Selected for Development, In Progress,
Done
• Each work-item element represents something that needs to be
done by the team. Displayed as a “card” on the project board.
• Statuses are represented by different columns on the project
board (applies to Kanban and Scrum)

12. Terminology
• EPIC
• An EPIC takes several months to complete.
• A project might have only a couple of EPICs per year.
• STORY
• A STORY is assigned to an EPIC and tells a user-journey.
• E.g. the user wants to be able to upload photos.
• NOTE: for R&D projects it is typically a step of the project such as “Computation of distance
fi
elds”
More Information on how to handle R&D projects will follow later.
• A STORY typically takes up to a few weeks to complete.
• TASK
• A TASK is a concrete implementation, the description of the TASK lists its actual requirements.
• A TASK should be a sub-item of a STORY.
• A TASK may take only a few days to complete at maximum. If the TASK would exceed this time it should
be split into more granular pieces.
• BUG
• An issue that needs to be solved.
• A BUG may take only a few days to complete at maximum. If the BUG would exceed this time it should
be split into more granular pieces.

13. Columns
Work-items

14. A story
4 sub-tasks, stored in the
backlog

15. This is how we do it

16. How to create a work-
item.
• Remember:
• A TASK de
fi
nes the smallest working unit.
• A TASK should in most-cases be directly related to a STORY.
• The ideal workload of a TASK SHOULD NOT exceed 3 days.
• If the workload exceeds this, it SHOULD BE further broken down into multiple TASKs.
• MUST add topic and detailed description.
• Watch out for correct grammar and spelling for all work-items (EPICS, STORIES, TASKS, BUGS)
• MUST add time estimate for the TASK. A STORY calculates its time automatically based on TASKs.
• If a TASK or STORY is blocked or depending on another work-item the relation must be setup
properly in the work-item.

17. Rules of Engagement
1. Check into Project and TASK using TimeLock. (specify its TASK ID)
TimeLock is our in-house time tracking app that we're using to capture the time spent on a TASK and correlate that with the actual JIRA TASK. It helps our project management to
understand the work process and it will also help you to see how you spent your time during the last sprint. It's also a helpful step to grow your TASK estimation skills as you can compare the
estimate vs. actual time spent.
TimeLock is under continuous development and is available on both Windows and MacOS, if you have some ideas on how to improve it - let us know!
2. Assign the TASK to yourself and move in JIRA from Selected for Development to In Progress.
⚠ Make sure a plausible time estimate is set in the “Original Estimate” column - otherwise your lead will not be able to ensure that we won't miss an important
deadline.
⚠ Only have a single TASK - and, if available, the corresponding STORY - in the "In Progress" column - otherwise your lead will not be able to see what you're working
on.
ℹ The project-lead is instructed to set the estimate for all TASKs that are Selected for Development. However, if the project-lead opted out of setting the TASK’s “Original Estimate”,
then the engineer that begins working on the TASK is required to set the estimate based on his predictions. Once you have set the estimate, write a comment to the JIRA TASK justifying
the estimate.
Example:
“I’m setting the estimate to 4d and 2h because the feature is quite complex and requires extending the rendering backend. Getting the shader to run properly through the pipeline will require several iterations. I might have to split the
vectorizer into several classes to implement the integral properly.”
3. Before coding, create branches according to the branching rules on the next slide.
4. If you want to discuss your TASK implementation strategy: create a post in the corresponding MS Teams channel.
⚠ If you recently joined our company and you're within your
fi
rst 2 months: Create the post immediately and elaborate your implementation strategy and the estimate for
the TASK you'll now start working on. Keep in mind, that it is always important to be concise and to the point in communication — your colleagues will certainly appreciate
it. This helps you and us to align on how things should be done.
5. During coding, make sure to not miss time constraints. The major constraint is to submit a PR every other
day. Ideally, submit one at the end of every day. Please review the next slides for
more information.
6. Once completed, create a pull request according to the branching rules on the
next slide.
7. Create a post in the corresponding MS Teams channel, to inform others that your
work is done and a PR is available. Provide a brief description of your
achievement and include a link to your PR.

18. When or how to branch?
• For each STORY, a branch (the "feature branch") should be created.
• For each SUB-TASK of a STORY, a development branch must be created from the STORY's feature branch.
• Once the SUB-TASK is
fi
nished or it needs to be submitted due to time constraints, a pull request (PR) from the
TASK's development branch into the STORY's feature branch should be created.
• Once all SUB-TASKS are completed and the STORY is
fi
nished. A PR from the STORY's feature branch into
master must be created.
• For each BUG, a BUG branch should be created.
• One the BUG has been
fi
xed, a pull request into master should be created.
• BUG speci
fi
c: Make sure to provide a brief description on what caused the BUG in the PR
description.
• If a TASK does not have an associated STORY
• a feature branch must be created
fi
rst,
• then a development branch must be created from the TASK's feature branch.
• Once the TASK needs to be submitted due to time constraints, a pull request from the TASK's
development branch into TASK's feature branch should be created.
• Once the TASK has been
fi
nished, the development branch should be merged directly into the TASK's
feature branch. Then a pull request should be created from feature branch into master.
If the development branch contains all the latest changes a PR should be directly submitted into master.

19. How often to submit a development branch
Pull Request into the feature branch?
• Ideally every day, at least every other day.
• This helps you to avoid spending weeks on work product that is not usable by the project due
to a bad engineering choice.
• It helps the learning process and improves code quality as you will get direction and
immediate feedback from your project-lead and your colleagues.
• This also helps your colleagues, as large PRs with 1000s of LOC changed, cannot be
reviewed - even when spending large amounts of time.
• If you fail to submit a PR in the required interval, you’re required to inform the project-lead in
your Teams “Task Post” (more on the “Task Post” later) and provide progress updates and a
justi
fi
cation.
Spending large amounts of time on work product that needs
to be discarded is 1) disappointing for all parties, 2) a huge
waste of your time and 3) a money loss for our company.
⚠

20. When to commit?
• MUST commit at the end of each day.
• MUST commit at the end of each TASK.
• IDEALLY commit once per hour.
• IDEALLY commit only a single TASK per commit.

21. How to commit?
• MUST reference the TASK in the commit by including the ID of the TASK at the end of
the commit message (IP-1 in the screenshot).
• Commit verbs
• ADDED: functionality was added (could be
fi
les)
• CHANGED: functionality was changed but the change is neutral in terms of overall
project improvement
• IMPROVED: functionality was changed leading to an improvement of overall project
• FIXED: broken functionality was healed or corrected
• REMOVED: functionality was removed (could be
fi
les)
• Each line in the commit must be pre
fi
xed by a commit verb

22. How to create a pull-request
• Depends on GIT management software, we use Atlassian’s
SourceTree.
• Right-click on the branch and select
“Create Pull Request…”
• Website opens.
• Specify all reviewers.
• Mandatory reviewers:
1. All Project Leads
2. At least one peer/colleagues
• Setup descriptions and meta data.
• If this is the
fi
nal pull request for a STORY, TASK or
BUG:
• Tick “Close Branch after the pull request is
merged”

23. Teams “Task Post”
• One the PR has been created, a post must be created in the corresponding
MS Teams channel.
⚠ If you’re working on a SUB-TASK of a STORY create a single umbrella “Task Post” for the STORY and
create individual “Task Posts” for each SUB-TASK as comment in the STORY thread. When posting SUB-
TASK updates, make sure to use proper headline formatting so the style matches the the preview on the
right.
• This helps to inform your colleagues and provides a forum to discuss the
changes and potential next-steps. It also serves as a platform to discuss the
PR post merge in case bugs or other issues surface.
• The topic of the post must be in the format TASKID: TASK
DESCRIPTION. The example task to the right has the ID IG-861 and the
description was “Correct PBRPreview”
• The
fi
rst line of the body must be
URL: <URL to the TASK>
• There should not be any special characters or URL parameters pasted
• Add a single empty line before writing the content of your body. Use modern
emojis such as the ✅ checkmark when you're done with a TASK or ℹ the
information symbol to highlight an important information.
• The frequency is expected to be identical to PRs that are submitted at least
every other day. If you fail to submit a PR in the interval, use the “Task Post”
to inform about your current task status.

24. How to Peer Review
• If reviewing as a lead, take the time that is necessary to ensure high code quality in terms
of functionality and quality.
• If reviewing as a peer, aim for 5 minutes - hard limit at 10 minutes. Your review process
should be fast and also serves the information
fl
ow, so you're aware what's happening.
• TimeLock:
• Book the time under the "Peer Review" project.
• Commit message should include project name, JIRA ID and paste a link to the PR.

25. Peer Discussions:
"I'm helping a colleague!"
• You can add value to the project by helping a stalled colleague or by assisting
with a tricky problem that's part of your core expertise.
• It is important to assist and you're free to make the right call when it is best for the
project to assist.
• However, the time spent needs to be properly logged in TimeLock.
• If it will take you more than a minute or sentence to assist, log the time.
Basically, as soon as you have to do a context switch of your current
mental model to assist your colleague, it is time to check-in with TimeLock.
• For this check-in there is a dedicated project called "Peer Discussion"
• The commit message should include the name of the colleague, the
project and in a single line what you're helping with.
• You should log this time, anytime that you're assisting: whether writing a reply on
MS Teams, JIRA, a short standup meeting, a web-meeting or any other form of
assistance.
✅

26. R&D Stories I.
• “A STORY is a work-item from the user’s perspective.”
• How does this apply to projects where there is no user?
• How does this apply to projects where the project is a
feature itself but at the scale of an EPIC?
• Ex.: An implementation of poisson reconstruction.
• Ex.: An implementation of a quad-meshing algorithm.
• How does research apply to agile methodologies.

27. R&D Stories II.
• If it is necessary for the project to revise the
fi
eld, the project is kicked-off with a TASK: “Revising
Field”
• Time is booked onto this TASK and all papers that are being revised will be added to the TASK.
• Result research and meta-studies will be documented in the internal knowledge-base.
The internal document must reference the research TASK ID.
• Once the topic has been researched and a strategy for its implementation can be articulated, the
project EPIC is broken down into STORY items.
• Each STORY will not be a user-story but a step necessary to achieve the
fi
nal implementation. Each
STORY needs to contain detailed information on the STORY based on the research incl. papers.
• Ex.: Compute Orientation Field
• Ex.: Decompose Concave Polygon into Convex Polygons
• Ex.: Perform Mesh Extraction
• Ex.: Implement Non-Linear Least-Squares Solver
• Results STORY items are further broken down into TASK items as with regular stories.

28. Thanks!