# Helmholtz AI special edition seminar: </br> Martin Voigt

###### tags: `HelmholtzAI`,`FFT`

[ToC]

## :memo: Seminar details

**01 February 2022, 10:30 - 11:30**

- Speaker: **Martin Voigt** elevait GmbH & Co. KG (elevait.de)
- Title: **Doing Machine Learning Projects in Teams**
- Chair: **Peter Steinbach**, Head of Helmholtz AI consultant team @ HZDR

### VC details

Access to online venue:
old: ~~https://bluejeans.com/742831948/7306 ~~
Meeting ID: 742 831 948
Passcode: 7306
new: https://meet.google.com/pmz-efpn-qvr

Want to dial in from a phone?
Dial the following number: +49.69.808.84246 (Germany (Frankfurt, German))
Enter the meeting ID and passcode followed by #

## :memo: Notes

:::info
:bulb: Write down notes and/or interesting information of the seminar. For example, observations auxiliar to the content which is not contained in the slidedeck.
:::

- company: 'elevait'
- goal: support business processes w/ organization
- product: AI software suite,
- targets: generalization, sparation of concerns, flexibility to adapt and integrate, no-code config by domain experts
- what they sell: go from unstructured to structured data
- i.e. extract content from forms, invoices etc, save it to a database or to other business software, make it index-able
- Guiding question: how to build and grow a SOTA IT company developing AI-based software products?
- MUST DEFINE A GUIDING THEME (that is what they found)
- they want to build their company on trust (laisez-faire management style)
- Core values:
- unity
- integrity
- diversity
- empathy
- save/open env
- responsibility
- Foundation
- Teal organization (organization centric) - [Reinventing Organization by Frederic Laloux (accents on the e's)]
- self-management, wholeness (should see everyone as more than just a tool, up to their family), evolutionary purpose (not just org evolves, but also every individual)
- Agile manifesto (software devel centric)
- indiv/interactions more important thatn processes/tools
- working software more impoarant than comprehensive docs
- customer collab more important than conract negotionat
- responding to chagne more impartant than following a plan
- Agility
- they want to frequently review how they operation to try to improve
- Self-managed teams
- team also shapes vision and other support tasks (planning, recruiting)
- measured by outcome not by output
- **defined routines and synch points to link between teams**
- still have some structure:
- small management team
- natural/fluid hierarchies
- How are decisions made?
- anyone can make a decision, but must seek the advice of the stakeholders

#### Implementation of Agile
- foundation - values and principles
- requirements
- roles, sync points, tooling
- communication - involve people and invite to participate to foster a common understanding
- Methods
- Scrum (good start)[https://scrumguides.org] (another good link)[https://www.atlasian.come/de/agile/scrum]
- devel cycle is typlically 2 week sprints (for them)
- daily sprints defined for single day
- Kanban (start)[https://www.atlassian.com/de/agile/kanban]
- card-based visual org aid
- Trello is a common tool (i dont know what they use)
- advanced
- (SAFe)[https://www.scaledagileframework.com/]
- (LeSS)[https://less.works/]
- what to choose?
- Scrum
- interactively solve complex task (project development)
- follow a plan-do-check-act cycle
- `elevate` -> really all development teams
- Kanban
- better for continuous flow of work (i.e. service, support, business)
- `elevate` -> business (salles, PM, marketing) admin, devops
- LESSON: NEVER START WITH ADVANCED WHEN SIMPLE WILL DO (especialy: first get the foundations with the basic methods right)

#### Agile Roles
- 5 org units
- agile team (3-10 members, self-managed. goal: refine, estimate, execute work)
- scrum master (support planning and exec. shape, support, grow team. 1/team or shared, but IS A MEMBER OF A TEAM)
- product owner (owns the backlog/owns a product from a tech POV, defines acceptance criteria, prioritize work, checks completion, 1/team)
- product manager (part of team connect, 1/PRODUCT, responsible for the business-related topics of a product)
- close colab between product owner + product manager
- maintain a vision of the roadmap for a product
- deal with the clients
- Project manager (part of team connect, planning and exec of customer, partner and research projects)
- Structure:
- management(4 ppl)
- team connect (12 + 8 ppl)
- sales
- branding/comm
- product/project management
- team spitit (3)
- HR
- office management
- team r@d (44)
- atlas (4)
- in:plans
- saturn (5)
- in:forms
- mercury (5)
- in:flow
- jupiter (7)
- in:docs
- wapp (10, splittin soon to maintain focus of groups)
- web apps
- inf (4)
- dev ops
- pyIO (3)
- Python Services
- IO (6)
- ETL Layer
- Planning Onion (Mike Cohn?)
- (smallest to largest) day -> iteration/sprint -> roadmap -> product -> portfolio -> strategy/mission
- MAIN TAKEAWAY: make short term plans on the level of weeks, and combine these tasks into larger goals
- Planning structure
- task/story/bug/enhancement/research spike
- limited to 1 sprint
- subtasks
- no required
- 4-sprint roadmap
- half-day review with client/shareholders
- 1 day workshop to prepare the team
- team discussion of the roadmap
- define the roadmap in this meeting
- bi-weekly planning exchange
- HARD 25 MIN limit
- 2 week sprints
- find meeting structure that workss

### Takeaways
- define values/principles -> make them explicit!
- Actually implement Agile workflows, dont do it half-ass
- external consulting can help (but isnt needed)
- start small
- visualize the work, gain common understanding
- limit work in progress to focus and avoid working over capacity
- do not underestimate the retrospective

## :question: Questions for the speaker

:::info
:bulb: Write down any questions or topics you wish to discuss during the seminar
_(either with your initials or anonymously)_
:::

> Leave in-line comments! [color=#3b75c6]

- Q How do your employees adapt to this 'agile' structure? Often, acedemia has a more rigid approach (Daniel Coquelin) how to prioritize
* new team memebers also from academic are judget reagrding culural fit already during interview
* adaoption to the culture and values is fast, mainly based on teams efforts because we live the values
* having not enough human resources is a common situation
* use business goals to prioritize,
* if there are timelines required, they have priority
* value outcome over output!

- Q your approach to organizing work is common in some domains (perhaps the s/w industry) and foreign in others (perhaps academia). How do you structure onboarding of new team members?
* There is a general introduction from management (mainly Martin) about vision, mission, values, principles, main organizational topics (not detail) as well as the technology stack in the first work days
* every team developed its own onboardign process on the paradigm "learning by doing" after inital setup phase
* the onboarding is an important task in every team, so an epic with task for the team members and the new one is defined - it is as important as to achieve the increment in developemtn

- Q how do you balance, deliverable constraints (with respect to time) and self expression. For example some meetings can attract quite a personal (non-topic related) weight if people feel that they can have a stage (in an extreme case: the more I talk, the more I work - but the meeting will feel unproductive with respect to the backlog).
* We have define some meeting guide lines
* it includes definition of the scope and objective
* meetings are time-boxed
* usually most attendees take care of staying in scope -> it is an unwritten principle

* Q "trust-based" teams typically only works up to a certain size because direct
communication usually doesn't scale, seen issues like that when you grew?
* there is an informal structure, of course
* yes, thats why we scale team max to 10 people
* the teams or the management are recognizing the need to split
* We started with one team in development and are 8 now

* Q what is a stakeholder?
* sometimes its a teammake to get their requirements
* sometimes its a client (with different personas)
* it is who definies the requirements for a feature

* Q communication: who is the stakeholder in that case?
* internal need (I need lib X to work) or a customer

* Q technical
* one product code base, adapt for customers?
* yes, we maintain mainly one code based
* adopation are by configuration on deployment but there are a view ML models trained specifically, eg, a classifier but also here all the infrastructure is common for all customers
* what would you say is the most widely used ML method in that product
* it really depends, detailed discussion required

- Q how do you manage switching projects in an agile environment?
- keep people working one single projects/products as much as possible such that they feel responsible for that
- project for us is "advancing" the general product in relation to some customer specific needs which should be generalizationable
- so it is planned as other topics in a team

- Q Is a daily meeting not creating a lot of pressure to generate output/results on a daily basis? (HH)
- **elevait**: Basically the daily meetings are limited to the team members only, there is no stakeholder requesting results in these meetings. The major goal is to provide a possibilty for exchange between team members about questions, blockers etc. Knowledge Sharing at any layer is very important to avoid so called knowlegde silos, the daily meetings are one way to address this. However, it is also a sync point to show up because with all the freedem you have, you are accountable for the task.

- Q how do you deal with the inherent limitations of digital Kanban tools (DC)
- **elevait**: Since our team is working partly remotely from the early days of our company, we are quite used to work with remote digital boards. So far we did not recognize major limitations while using a digital kanban board. Due to the aim of self-organization team members try to re-organize and optimize the tooling and its configuration constantly by their own. So in different teams, different tooling configuration is used. And this is constantly changing based on the retrospective meetings we do at the end of each sprint.

- Q How is the increased responsibility of individual employees reflected in compensation? e.g. company shares
- **elevait**: There are two parts necessary to consider. A) yes responsibility should also reflect in compansation. So therefore all of our team members that are a while with us receive shares of the company. So every member is working also for his "own" company. But similarly important it is also about "self-motivation". We recognized, that giving members to possibitly to contribute to "something meaningful" and empower them to do decisions on their own lead to highly motivated team members. Purpose and ownership are the main drivers.

* Q still seems like a lot of structure and processes, just less hierarchy?
* yes :) key point is communication, responsibility of team members and engagement

* Q all that only applicable to teams working on one project iteratively, vs. teams where 1 person = 1 project with occasional overlap and no long-lasting product?
* I do not understand it

- Are people always part of one team only or can they have multiple projects and therefore multiple teams as well? (HH)
- related to this: or can they change roles at some point? For example, let's say I worked as a scrum master for some time and would love to work again with ML models, would I be able to change roles?
- a team member is associated with one team
- changing roles is possible but not every sprint :-) it need to be organized and planned
- a scrum master at elevait fills this role not 100% ist usually developing as well

- Q one challenge with scrum is to estimate efforts of items in the backlog. How well have you established heuristics for planning? In other words: how well do you estimate time for a given task so far?
* consider time, but also risk
* can use Fibonacci numbers to estimate times b/c humans are bad at estimating differences
* method to estimate time has to be agreed upon in the team
* estaimations are all relative

- Q about the roadmap meeting you said there is a review with shareholders. Is this an other work for stakeholders here, or is it about stocks?

- Q What perspectives are there for professional development of your employees? You mentioned average age <35 years, is there any perspective to develop professionally within elevait, or are you more focussed on early-career software developers?
- good point! right now, we are developing a career system relfecting the little hierarchy and the agile mindeset - not an easy task
- if we have the 1st version running, I'm happy to tell about (Q3 2022?)

- Q Is there any statistic on the success of Agile vs. traditionally functioally organisations ?
- PS: both terms are hard to define I think (e.g. in agile, it is the goal of the method to adapt the goals while in a traditional waterfall style - the goals remain fixed from the beginning), but if there is some quantitive analysis, that would be cool to see! ;-)
- I do not know, hwoever, we are also defining the term success right now at elevait

## :question: Your Feedback

:::info
:bulb: Write down your feedback about the seminar
_(either with your initials or anonymously)_
:::

### Share something that you learned or liked :+1:

- ...

### Share something that you didn’t like or would like us to improve :-1:

- ...

:::info
:pushpin: Want to learn more? ➜ [HackMD Tutorials](https://hackmd.io/c/tutorials)
:::