vault backup: 2025-01-15 12:18:05

.obsidian/plugins/text-extractor/cache/21bae4b635d8291747b543e5479aadb7.json

@@ -0,0 +1 @@
+{"path":"Attachments/Pasted image 20250115111900.png","text":"2 \"_--—._—\"'—-___ — Sequential Approach 8 (Idealistic, Prearranged, wä Controlled) $ --- Agile Approach S (Empirical, Responsive, z 4 Improvement-Oriented) —ë “._ Increased Chance of & \\___ Success Obvious Complicated Complex Chaotic Uncertainty Figure 3-3 Probability of success on different kinds of problems with Sequential vs. Agile approaches.","libVersion":"0.3.2","langs":"deu+eng+fra"}

.obsidian/plugins/text-extractor/cache/3a56d82ae582d6af37125ec77c679244.json

@@ -0,0 +1 @@
+{"path":"Attachments/Pasted image 20250115113740.png","text":"/ Olrilcm \\ ?},L;:ril(jie — Obser\\;e A 'I?ccidc Figure 3-5 The full OODA loop. Any step can shortcut straight to Act or back to Observe, as indicated by dashed lines.","libVersion":"0.3.2","langs":"deu+eng+fra"}

.obsidian/plugins/text-extractor/cache/4ba54727d030f2d770834fc2239ec67d.json

@@ -0,0 +1 @@
+{"path":"Attachments/Pasted image 20250115121640.png","text":"Sp(i% Planning Sprint Backlog ‚\\ }';älr);dic;um ps l[ÿfçÿ“\\\\ Refinement ‘À\"À‘ Sprint Review (LU Cross-Functional, ‘ \"\" Self-Managing \\“-‚ Sprint Development Team m Retrospective [\\ Scrum Master Product Owner Figure 4-6 A diagnostic tool that shows a Scrum team 5 performance according to key Scrum success factors.","libVersion":"0.3.2","langs":"deu+eng+fra"}

.obsidian/plugins/text-extractor/cache/75074a6d61de0cf4a749ecf0a4382986.json

@@ -0,0 +1 @@
+{"path":"Attachments/Pasted image 20250115112343.png","text":"/ Orient \\ ?;;iiläe —— —> Observe Decide \\ Act / Figure 3-4 The basic OODA loop contains four steps that begin with observation.","libVersion":"0.3.2","langs":"deu+eng+fra"}

.obsidian/workspace.json

@@ -633,12 +633,16 @@
   },
   "active": "d0f5cd8f5ab689e9",
   "lastOpenFiles": [
-    "Attachments/Pasted image 20250115111654.png",
+    "Attachments/Pasted image 20250115121640.png",
     "Temporary/Agile Implementation Plan.md",
     "5 Media/0 Books/More Effective Agile by Steve McConnell.md",
+    "Attachments/Pasted image 20250115113740.png",
+    "Attachments/Pasted image 20250115112343.png",
+    "Temporary/Startup Culture List.md",
+    "Attachments/Pasted image 20250115111900.png",
+    "Attachments/Pasted image 20250115111654.png",
     "Dashboard Canvas.canvas",
     "0 Journal/Meetings/Vidit Update - 8.1.25.md",
-    "Temporary/Startup Culture List.md",
     "Temporary/Untitled 6.md",
     "5 Media/0 Books/Software Project Survival Guide by Steve McConnell.md",
     "2 Personal/Alkademiker/Projekte/Tischbeine Motorisiert.md",
@@ -660,12 +664,8 @@
     "Attachments/Pasted image 20250108160138.png",
     "Attachments/Pasted image 20250108155841.png",
     "Attachments/Pasted image 20250108151953.png",
-    "Attachments/Pasted image 20250108110043.png",
     "Temporary/Vidit Update - 8.1.24.md",
     "2 Personal/Lists/Business Ideas.md",
-    "Attachments/Pasted image 20250107121222.png",
-    "Attachments/Pasted image 20250107120429.png",
-    "Attachments/Pasted image 20250107114628.png",
     "0 Journal/0 Daily/2024-12-06.md",
     "Temporary/Untitled 5.md",
     "2 Personal/Home Lab/NAS/Zerotier Installation.md",

5 Media/0 Books/More Effective Agile by Steve McConnell.md

@@ -77,13 +77,31 @@ In the **Chaotic Domain** there is no discoverable relationship between cause an
 
 In the **Disorder Domain** you lack clarity which domain applies to your problem. The approach here is to decompose the problem into subelements and assess the domains of each subelement. Remember that each project might have problems in various domains. 
 
+![[Pasted image 20250115111900.png]]
+As shown in the graph above, it is always better to use an agile approach and maybe sacrifice some efficiency if your problem was only complicated. The other way round could be disastrous and lead to the cancellation of the project.
+
+#### Succeeding on Complex Projects: OODA
+![[Pasted image 20250115113740.png]]
+The origin of OODA was the US military in order to accelerate decision making. It is a method to establish context, formulating a plan, performing work observing results and incorporating learnings into the next cycle. 
+
+**Observe** the current situation, outside information that is relevant and any aspects of the situation that are unfolding (emergent). OODA places a strong emphasis on observation, experience and learning and thus is very empirical.
+
+**Orient** is where you relate the observations to your situation, meaning you decide how the observations are relevant to you and your current situation and how possible responses look like. This is an opportunity to challenge your assumptions, adjust for cultural and company cultural blind spots, de-biasing data and information. A classical example is the first iPhone, which was technically inferior to many other phones, but solved the user experience problem instead, which turned out to be more important.
+
+**Decide** is where you make a decision based the observations and the orientation in the previous two steps. The goal is to disrupt the opponents OODA-loop by forcing them to play your game instead of you playing their game. 
+
+**Act** is finally where you implement the decision, after which you start over in the cycle by observing the impact of your actions and learning from them. 
+
+In contrary to sequential development practices, OODA considers uncertainty as opportunity to act and create something new, something you can exploit to gain an advantage over your opponent.
 
 
-
+> [!important] Inspect and Adapt
-
+> Inspect and Adapt is a useful shorthand for OODA. Agile teams should avoid being idealistic about their practices and instead adjust their practices based on empirical observations about what has been proved to work. Apply Inspect and Adapt to *everything* (plans, designs, code quality, tests, processes, team interactions, organizational interactions, etc), meaning every factor that can make a difference to a team's effectiveness. 
 
 ### More effective Agile beginnings: Scrum
 
+- [ ] Summarize everything until failure mode #todo/b 
+
 The main common failure is not to use SCRUM in its entirety, but only implement certain parts. Scrum is already broken down to the minimum processes, everything you take away in addition will break the system (might not apply to power scrum users, but certainly to beginners).
 #### Most common Challenges
 - **Ineffective Product Owner**: Before agile the most common source of failure was poor definition of requirements. Since the product owner is responsible for requirements it comes at no surprise that this is a common challenge. Businesses should treat this role as the highest leverage role for the scrum team and fill it accordingly. With former training business analysts, customer support staff and testers can make excellent POs.
@@ -116,6 +134,40 @@ The main common failure is not to use SCRUM in its entirety, but only implement
 
 All points above share that they usually diverge from pure Scrum, meaning they implement "Scrum, but...". Further all attributes demand high discipline practices, meaning if the system is not properly set-up the people tend to drift away from it. The scrum master is responsible for ensuring those practices and the meetings (sprint planning, daily scrum, sprint review and sprint retrospective) provide structural support as well as social support to stick to the scrum.
 
+
+> [!Tip] Success Factors in Scrum
+> Each of the failure modes above can be converted into a success factor.
+
+#### A Successful Sprint
+A successful sprint will support the main goal of Scum which is maximizing the value of the product:
+- deliver usable, valuable increment (aggregate functionality) fulfilling DoD.
+- the sprint's increment increases in value compared to the previous sprint
+- the Scrum process is improved compared to the previous sprint
+- Scrum team learns something about itself, its business, its product or its customers
+- Motivation remains the same or increases with each sprint
+
+The time allocation per developer should be something like the following (out of 60 hours: 6h project focus for 10 business days. Startups have less overhead and thus more likely 7-8h of project work per day):
+- *48h* development work, including testing
+- *2h* daily standups
+- *3h* product backlog refinement (5%)
+- *4h* sprint planning
+- *2h* sprint review
+- *1h* sprint retrospective
+
+Summarizing: 80% of the work should go into development and 20% into planning and process improvement.
+
+#### A Scrum Scorecard
+![[Pasted image 20250115121640.png]]
+
+
+| Score | Description                                |
+| ----- | ------------------------------------------ |
+| 2     | used infrequently and ineffectively        |
+| 4     | Used occasionally with mixed effectiveness |
+| 7     | Used consistently and effectively          |
+| 10    | Optimizing                                 |
+
+
 ### Enjoy the Fruits of Your Labor
 The agile mindset is about decriminalising mistakes and develop a Growth Mindset. Use mistakes as learning opportunities, Inspect and Adapt, and gradually become better.
 The main benefits for your organisation:

Temporary/Agile Implementation Plan.md

@@ -35,4 +35,9 @@ The product owner is responsible for the requirements definition. The right requ
 ## Risks associated with Scrum at OneSec
 - We don't understand scrum well enough to properly implement it. Or to properly coach the entire team how to stick to the rules
 - [[Floris]] cannot give away responsibility to the team.
-- Not following it a 100% --> do "Scrum, but..."
+- Not following it a 100% --> do "Scrum, but..."
+
+## What are characteristics of the Software that we need to implement at OneSec?
+- we have changing hardware
+- safety
+- What exactly is the business plan, who are the customers, what is the product?

Temporary/Startup Culture List.md

@@ -8,4 +8,6 @@ tags:
 # Startup Culture List
 - Decriminalize Mistakes: Decriminalize mistakes so that teams surface them without hesitation and you can learn from them. A mistake you don't learn from penalizes your organization twice. (Page 227 in [[More Effective Agile by Steve McConnell]])
 - Have a KPI dashboard for everyone to see
-- Have a mission statement who is signed by everyone and also influenced by everyone
+- Have a mission statement who is signed by everyone and also influenced by everyone
+- problem characterization guideline / checklist: write short 1 pagers whenever a problem appears that we might want to solve. Use the [[More Effective Agile by Steve McConnell#Responding to the Challenges of Complexity and Uncertainty|Cynefin and OODA]]  approach to characterize them. 
+-