Skip to content

Commit 1d2be5a

Browse files
authored
Merge pull request #15034 from romanoroth/ZRH2025AddVideosWeek13
[ZRH-2025] Added video links to 5 speakers
2 parents 63e197b + 2c1758a commit 1d2be5a

5 files changed

Lines changed: 111 additions & 111 deletions

File tree

Lines changed: 18 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -1,19 +1,19 @@
1-
+++
2-
City = "Zurich"
3-
Year = "2025"
4-
talk_date = "2025-03-13"
5-
talk_start_time = "14:35"
6-
talk_end_time = "14:40"
7-
title = "Code & risk"
8-
type = "talk"
9-
speakers = ["adam-zieba"]
10-
youtube = ""
11-
vimeo = ""
12-
speakerdeck = ""
13-
slideshare = ""
14-
slides = ""
15-
+++
16-
17-
### Ignite
18-
1+
+++
2+
City = "Zurich"
3+
Year = "2025"
4+
talk_date = "2025-03-13"
5+
talk_start_time = "14:35"
6+
talk_end_time = "14:40"
7+
title = "Code & risk"
8+
type = "talk"
9+
speakers = ["adam-zieba"]
10+
youtube = "cgtZhq3bhE8"
11+
vimeo = "1070639184"
12+
speakerdeck = ""
13+
slideshare = ""
14+
slides = ""
15+
+++
16+
17+
### Ignite
18+
1919
Code is a liability/risk not an asset. Hedging this risk can be done by writing more code, having good practices etc. Developers think that they are the ones producing value and see HR , Finance etc as risk avoidance entities. However software development should understand that they should be risk managers too. Undocumented, tested code that does not meet the non-functional requirements that are expected is risk exposure. Before you ship you have 1 problem after you ship you have to maintain that problem and develop the new thing.
Lines changed: 18 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -1,19 +1,19 @@
1-
+++
2-
City = "Zurich"
3-
Year = "2025"
4-
talk_date = "2025-03-13"
5-
talk_start_time = "14:10"
6-
talk_end_time = "14:15"
7-
title = "The perfect match: How Extreme Programming enables Team Topologies concepts"
8-
type = "talk"
9-
speakers = ["antonio-alvino"]
10-
youtube = ""
11-
vimeo = ""
12-
speakerdeck = ""
13-
slideshare = ""
14-
slides = ""
15-
+++
16-
17-
### Ignite
18-
1+
+++
2+
City = "Zurich"
3+
Year = "2025"
4+
talk_date = "2025-03-13"
5+
talk_start_time = "14:10"
6+
talk_end_time = "14:15"
7+
title = "The perfect match: How Extreme Programming enables Team Topologies concepts"
8+
type = "talk"
9+
speakers = ["antonio-alvino"]
10+
youtube = "cUAEdKbHCGs"
11+
vimeo = "1070638982"
12+
speakerdeck = ""
13+
slideshare = ""
14+
slides = ""
15+
+++
16+
17+
### Ignite
18+
1919
How can we make Team Topologies actionable in our daily work? As a programmer, I’ve discovered how Extreme Programming (XP) practices can bring these concepts to life. In this ignite talk, I’ll share how methodologies like pair programming, test-driven development, and iterative delivery can help reduce cognitive load, foster effective team interactions, and streamline the flow of value.
Lines changed: 19 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -1,20 +1,20 @@
1-
+++
2-
City = "Zurich"
3-
Year = "2025"
4-
talk_date = "2025-03-13"
5-
talk_start_time = "14:30"
6-
talk_end_time = "14:35"
7-
title = "No estimates? Try Flow Metrics."
8-
type = "talk"
9-
speakers = ["kamali-wickramage"]
10-
youtube = ""
11-
vimeo = ""
12-
speakerdeck = ""
13-
slideshare = ""
14-
slides = ""
15-
+++
16-
17-
### Ignite
18-
19-
Story point estimations have been around for a while, but more and more teams are moving towards #noestimates.
1+
+++
2+
City = "Zurich"
3+
Year = "2025"
4+
talk_date = "2025-03-13"
5+
talk_start_time = "14:30"
6+
talk_end_time = "14:35"
7+
title = "No estimates? Try Flow Metrics."
8+
type = "talk"
9+
speakers = ["kamali-wickramage"]
10+
youtube = "nVxUQK_d_gk "
11+
vimeo = "1070639366"
12+
speakerdeck = ""
13+
slideshare = ""
14+
slides = ""
15+
+++
16+
17+
### Ignite
18+
19+
Story point estimations have been around for a while, but more and more teams are moving towards #noestimates.
2020
Sure, estimations have its own problems, but what is the alternative? I present my experience using flow metrics (as introduced by the Kanban guide) as the alternative, and how they can help you improve the flow of value in your teams while reducing waste of endless estimation discussions.
Lines changed: 36 additions & 36 deletions
Original file line numberDiff line numberDiff line change
@@ -1,37 +1,37 @@
1-
+++
2-
City = "Zurich"
3-
Year = "2025"
4-
talk_date = "2025-03-13"
5-
talk_start_time = "14:25"
6-
talk_end_time = "14:30"
7-
title = "How I Started Worrying and Stopped Loving DevOps"
8-
type = "talk"
9-
speakers = ["marcel-britsch"]
10-
youtube = ""
11-
vimeo = ""
12-
speakerdeck = ""
13-
slideshare = ""
14-
slides = ""
15-
+++
16-
17-
### Ignite
18-
19-
Summary:
20-
In this cautionary tale, I’ll share three real-world product-building experiences, mapping my journey as a product manager from a DevOps enthusiast to a wary cynic. I’ll share examples of how infrastructure can drift into ‘purgatory’: pipelines that are ‘never done,’ painfully complex to maintain, or beautifully engineered yet devoid of applications to support. My goal is to highlight the missteps I encountered, so future teams might avoid these traps and sidestep the costly pursuit of infrastructure perfection that can derail real progress.
21-
22-
How the talk will unfold:
23-
Introduction: The Allure of DevOps
24-
To bring us onto the same page - and this should not be controversial - I’ll share my attitude towards DevOps, where I see it being valuable and beneficial when building products and services.
25-
26-
Pitfalls: When Reality meets Ideology
27-
Drawing on my personal experience I will share a number of examples, where despite best intentions, our DevOps endeavours, descended into, at best waste and pain, at worst total dysfunction. I will touch on aspects such as technology ‘greed’, over-engineering, gold-plating, premature optimisation, strategic misalignment and others, and show how, from excitement and enthusiasm about DevOps users, stakeholders and ‘the business’ can easily become disillusioned, cynical and frustrated.
28-
29-
Conclusion: The moral of the tale, advice for the real world
30-
I will conclude with guiding principles to avoid falling into the same traps.
31-
32-
What participants will take away:
33-
An awareness of the important to adopt a critical view on
34-
- DevOps (and other) technical decisions
35-
- A list of potential pitfalls and challenges
36-
- Actionable guidance and suggestions on how to manage these tensions, risks and challenges to avoid falling into the same traps
1+
+++
2+
City = "Zurich"
3+
Year = "2025"
4+
talk_date = "2025-03-13"
5+
talk_start_time = "14:25"
6+
talk_end_time = "14:30"
7+
title = "How I Started Worrying and Stopped Loving DevOps"
8+
type = "talk"
9+
speakers = ["marcel-britsch"]
10+
youtube = "YMK4lgZjV54"
11+
vimeo = "1070639076"
12+
speakerdeck = ""
13+
slideshare = ""
14+
slides = ""
15+
+++
16+
17+
### Ignite
18+
19+
Summary:
20+
In this cautionary tale, I’ll share three real-world product-building experiences, mapping my journey as a product manager from a DevOps enthusiast to a wary cynic. I’ll share examples of how infrastructure can drift into ‘purgatory’: pipelines that are ‘never done,’ painfully complex to maintain, or beautifully engineered yet devoid of applications to support. My goal is to highlight the missteps I encountered, so future teams might avoid these traps and sidestep the costly pursuit of infrastructure perfection that can derail real progress.
21+
22+
How the talk will unfold:
23+
Introduction: The Allure of DevOps
24+
To bring us onto the same page - and this should not be controversial - I’ll share my attitude towards DevOps, where I see it being valuable and beneficial when building products and services.
25+
26+
Pitfalls: When Reality meets Ideology
27+
Drawing on my personal experience I will share a number of examples, where despite best intentions, our DevOps endeavours, descended into, at best waste and pain, at worst total dysfunction. I will touch on aspects such as technology ‘greed’, over-engineering, gold-plating, premature optimisation, strategic misalignment and others, and show how, from excitement and enthusiasm about DevOps users, stakeholders and ‘the business’ can easily become disillusioned, cynical and frustrated.
28+
29+
Conclusion: The moral of the tale, advice for the real world
30+
I will conclude with guiding principles to avoid falling into the same traps.
31+
32+
What participants will take away:
33+
An awareness of the important to adopt a critical view on
34+
- DevOps (and other) technical decisions
35+
- A list of potential pitfalls and challenges
36+
- Actionable guidance and suggestions on how to manage these tensions, risks and challenges to avoid falling into the same traps
3737
- An understanding that infrastructure is an important - but nevertheless - means to an end, that needs to serve a greater purpose
Lines changed: 20 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -1,21 +1,21 @@
1-
+++
2-
City = "Zurich"
3-
Year = "2025"
4-
talk_date = "2025-03-13"
5-
talk_start_time = "14:05"
6-
talk_end_time = "14:10"
7-
title = "Post Accelerate: Why are we still failing at adopting DevOps in the Enterprise?"
8-
type = "talk"
9-
speakers = ["rasmus-lystrom"]
10-
youtube = ""
11-
vimeo = ""
12-
speakerdeck = ""
13-
slideshare = ""
14-
slides = ""
15-
+++
16-
17-
### Ignite
18-
19-
24 years of agile, 17 years of DevOps and 6 years after "Accelerate" got published we see enterprises doing business as usual reaping no real benefits of either agile nor DevOps.
20-
1+
+++
2+
City = "Zurich"
3+
Year = "2025"
4+
talk_date = "2025-03-13"
5+
talk_start_time = "14:05"
6+
talk_end_time = "14:10"
7+
title = "Post Accelerate: Why are we still failing at adopting DevOps in the Enterprise?"
8+
type = "talk"
9+
speakers = ["rasmus-lystrom"]
10+
youtube = "PuoAJ4SEOyo"
11+
vimeo = "1070639488"
12+
speakerdeck = ""
13+
slideshare = ""
14+
slides = ""
15+
+++
16+
17+
### Ignite
18+
19+
24 years of agile, 17 years of DevOps and 6 years after "Accelerate" got published we see enterprises doing business as usual reaping no real benefits of either agile nor DevOps.
20+
2121
Reflecting back on 10 years as a principal consultant and cloud solution architect at Microsoft working with practically all the major Danish enterprises and a big number of European ones, I want to share my views on why enterprises fail at adopting DevOps and what we should be doing to change that.

0 commit comments

Comments
 (0)