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

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: