obsidian/Main
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2025-01-16 15:38:06

Browse Source
This commit is contained in:
Claudio Fritsche
2025-01-16 15:38:06 +01:00
parent f48300f985
commit 7cfa1cf56a
3 changed files with 136 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

95
.obsidian/workspace.json vendored
View File

@@ -16,8 +16,8 @@
"state": {
"file": "Dashboard Canvas.canvas",
"viewState": {
"x": -891.4599999999994,
"y": -49.010000000000005,
"x": -980.7399999999994,
"y": -694.4300000000002,
"zoom": 0
}
},
@@ -86,7 +86,8 @@
"title": "2024-05-04"
}
}
]
],
"currentTab": 4
}
],
"direction": "vertical"
@@ -403,12 +404,22 @@
"state": {
"type": "review-queue-list-view",
"state": {},
"icon": "lucide-file",
"title": "Plugin no longer active"
"icon": "SpacedRepIcon",
"title": "Notes Review Queue"
}
},
{
"id": "6215365c5ee0babc",
"type": "leaf",
"state": {
"type": "review-queue-list-view",
"state": {},
"icon": "SpacedRepIcon",
"title": "Notes Review Queue"
}
}
],
"currentTab": 22
"currentTab": 23
},
{
"id": "7324c8ef0d6e53cb",
@@ -445,15 +456,76 @@
"obsidian-spaced-repetition:Review flashcards": false,
"omnisearch:Omnisearch": false,
"vantage-obsidian:Vantage - Advanced search builder": false,
"templater-obsidian:Templater": false
"templater-obsidian:Templater": false,
"periodic-notes:Open today": false
}
},
"active": "7a8f2e9dbf8d503c",
"floating": {
"id": "234f239d245f8bf3",
"type": "floating",
"children": [
{
"id": "23c5a3f4dda71b8e",
"type": "window",
"children": [
{
"id": "95e3c6f14d006417",
"type": "tabs",
"children": [
{
"id": "ca433fc0421feebe",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "5 Media/0 Books/More Effective Agile by Steve McConnell.md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "More Effective Agile by Steve McConnell"
}
}
]
},
{
"id": "03566a73db019f21",
"type": "tabs",
"children": [
{
"id": "bc313c3af0e1a14e",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "Temporary/Agile Implementation Plan.md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "Agile Implementation Plan"
}
}
]
}
],
"direction": "vertical",
"x": 1440,
"y": -496,
"width": 1246,
"height": 1055,
"maximize": false,
"zoom": 0
}
]
},
"active": "ca433fc0421feebe",
"lastOpenFiles": [
"0 Journal/Meetings/Vidit Update - 8.1.25.md",
"Dashboard Canvas.canvas",
"5 Media/0 Books/More Effective Agile by Steve McConnell.md",
"Temporary/Agile Implementation Plan.md",
"5 Media/0 Books/More Effective Agile by Steve McConnell.md",
"0 Journal/0 Daily/2024-05-04.md",
"Dashboard Canvas.canvas",
"0 Journal/Meetings/Vidit Update - 8.1.25.md",
"0 Journal/0 Daily/2025-01-15.md",
"Attachments/Pasted image 20250115121640.png",
"Attachments/Pasted image 20250115113740.png",
@@ -471,7 +543,6 @@
"Attachments/Pasted image 20250110145533.png",
"2 Personal/Hobbies/Gelbes Velo von Mänu.md",
"0 Journal/0 Daily/2025-01-10.md",
"0 Journal/0 Daily/2024-05-04.md",
"0 Journal/Meetings/OneSec Cofounder Verhandlung.md",
"Temporary/Startup Organisation.md",
"0 Journal/0 Daily/2024-09-25.md",

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

@@ -180,6 +180,52 @@ It is difficult to find a full set of skills and remain small (5-9 people), whic
Beyond skills **Ability and Authority** to make decisions should lie within the team in order for it to implement actual agile
Treat teams as *black boxes* where you only give inputs and receive outputs. The teams commit to a sprint goal that they will deliver, but the management should not care about how this is delivered. Managers should also not review minute and miniature details and not do micromanagement.
### More effective Agile Team Culture
Motivate teams through *Autonomy, Mastery, Purpose*. This principle comes from the psychologist Daniel Pink. Motivation always needs to be intrinsic and cannot be forced upon someone.
**Autonomy** refers to the ability to direct your own life and work - what you do, when you do it and who you do it with. If a person doesn't believe their organization trusts them, thy won't believe they have real autonomy.
**Mastery** refers to the desire to learn and improve, thus to the idea to constantly getting better. This is especially important for technical staff. The opportunity of growth has been a stronger motivator for developers than advancement, recognition, salary, status, level of responsibility and other factors.
**Purpose** refers to understanding why what you're working on matters. What is the big picture? How it the thing you're working on more important than yourself? How does it support the company or the world at large?
Another important point is to consider not only the project in a business perspective, but also consider the team to be part of the project. If the team is energized after the project has finished, they have grown, and will be an asset to the company for future projects. If they are burnt out they won't be of any use after the project. As a company you should grow as well, so take care of your people.
Developing a business focus means putting every single developer in direct contact with customers. This helps them to see the big picture and will teach them to think through the lens of the customer instead of overly technical. Further it enhances the Purpose pillar of the developers, which increase motivation. Keep in mind that this should become / be a habit, not a one time thing.
Assigning clear team roles, improves the efficacy of teams.
### More Effective Distributed Agile Teams
One of the key principles of distributed agile teams is to **tighten the feedback loop**, such that problems arise early and can be solved timely and effectively, which in turn allows the team to grow. In fact, a lot of suggestions in the book are about tightening the feedback loops: Product Owners are there to tighten the feedback loop around requirements, cross-functional teams with different skillsets allow for faster decision making, fast automated testing tightens the loop between coding and testing.
Geographically distributed teams loosen the feedback loop because of:
- non-ideal communication
- time difference
- larger batches of work before they are being shipped,
- differences in languages
- differences in culture
- development and testing happening at different locations
- product ownership and development at different locations
- work on shared functionality 50/50
Once again, the goal is to have self-directed cross-functional teams that have the ability and the authority to make binding decisions locally.
#### Dos
- **routine face-to-face communication (scheduled)**: most of the problems are miscommunication. Plan with visits every 6 weeks
- **increase logistical support for distributed teams**: Scheduled meetings: make good meeting habits. Make sure all members have good devices (microphones, headsets, etc) and that a communication tool like slack is used. Consider using remote proxies, meaning someone at the remote office is responsible. Make sure to provide onboarding and training. Mentoring is also important.
- **Leverage Autonomy, Mastery and Purpose**: Treat all offices equally, don't use terminology like main office, secondary office; onshore vs offshore, etc. This reduces the Autonomy, Mastery and Purpose of the offshore office. Each site should be able to perform work autonomously and be able to grow autonomously
- **Respect Conway's Law**: Technical structure of a system reflects the structure of the human organization that built the system. This is a two-way street, meaning the system also influences the teams.
- **Treat Agile teams as black boxes**: Don't focus on how the teams perform the work.
- **Maintain high quality**: keeping software close to a releasable state minimizes the discrepancy across distributed teams
- **Be aware of cultural differences**: willingness to communicate bad news or answering "no" to questions, response to authority, individual vs team accomplishment, work-hour expectations, work life balance.
- **Inspect and Adapt**: regular retrospectives to assess what is working and what is not. Teams must be empowered to make the changes they identify as causes.
> [!Important] Key Principle: Fix the System, Not the Individual
> Increased miscommunication leads to errors, meaning people spend more time fixing defects. It is crucial to **decriminalize errors**, such that people embrace them and learn from them. Treat errors as *system errors* and not personnell problems.
>
> What is it about our system that allowed this error to occur?
### More Effective Individuals and Interactions
### 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:

8
Temporary/Agile Implementation Plan.md
View File

@@ -13,9 +13,15 @@ tags:
The product owner is responsible for the requirements definition. The right requirements and their appropriate prioritization is crucial for the success of a project. Therefore it is very important to hire excellent personnell for this role, since it has a high leverage. See [[More Effective Agile by Steve McConnell#Most common Challenges|Most common Challenges with product owners]] for more details.
### Meetings
> [!Tip] Good Meeting Habits
> - Create agendas
> - define deliverables
> - stay on topic
> - start and end on time
#### Sprint Planning
#### Daily Standup
#### Retrospectives
### Work Units
- Stories should be completable within a single sprint: