nkdAgility
diff --git a/‎.powershell/dev/Get-EngineeringExcelance.ps1‎
Lines changed: 12 additions & 6 deletions b/‎.powershell/dev/Get-EngineeringExcelance.ps1‎
Lines changed: 12 additions & 6 deletions
diff --git a/‎.resources/reference/content/reference-content--Z5GGUOjc-d.md‎
Lines changed: 2 additions & 4 deletions b/‎.resources/reference/content/reference-content--Z5GGUOjc-d.md‎
Lines changed: 2 additions & 4 deletions
diff --git a/‎.resources/reference/content/reference-content-L7cngB1uzW9.md‎
Lines changed: 69 additions & 0 deletions b/‎.resources/reference/content/reference-content-L7cngB1uzW9.md‎
Lines changed: 69 additions & 0 deletions
diff --git a/‎.resources/reference/content/reference-content-PMnxyczoB1K.md‎
Lines changed: 60 additions & 0 deletions b/‎.resources/reference/content/reference-content-PMnxyczoB1K.md‎
Lines changed: 60 additions & 0 deletions
@@ -9,11 +9,12 @@ $levelSwitch.MinimumLevel = 'Information'
 # Configuration
 $MinScore = 60    # Minimum score threshold (0-100, where 100 is best)
 $ChunkSize = 10   # Score range per file (60-69, 70-79, 80-89, 90-100, etc.)
-$classificationNames = @("Engineering Excellence", "Technical Leadership")
+$classificationNames = @("Engineering Excellence", "Technical Leadership", "Lean", "DevOps", "Product Development", "Accountability", "Capability", "Discipline", "Ethos", "First Principle", "Model", "Observability", "Practice", "Principle", "Strategy", "Tenet", "Operating Model", "One Engineering System", "Adaptive Operating Model", "Predictive Operating Model", "Engineering Practices", "Flow Efficiency", "Throughput", "Lead Time", "Cycle Time", "Value Stream Management", "Value Stream Mapping", "Continuous Integration", "Continuous Delivery", "Deployment Strategies", "Release Management", "Definition of Done", "Technical Debt", "Technical Excellence", "Reversibility", "Change Safety", "Metrics and Learning", "Empirical Process Control", "Evidence Based Management", "Customer Feedback Loops", "Decision Making", "Decision Theory", "Operational Practices", "Platform Engineering", "Internal Developer Platform", "Site Reliability Engineering", "Systems Thinking", "Sociotechnical Systems", "Organisational Physics", "Complexity Thinking", "Feedback Loops", "Flow", "Learning Systems", "Quality as a Constraint", "Authority and Accountability Alignment", "System Design")
 
 # Load all blog posts
 Write-InformationLog "Loading blog posts..."
 $hugoMarkdownObjects = Get-RecentHugoMarkdownResources -Path ".\site\content\resources\blog\" -YearsBack 100
+$hugoMarkdownObjects += Get-RecentHugoMarkdownResources -Path ".\site\content\resources\case-studies\" -YearsBack 100
 
 # Filter for posts with score above minimum, from 2018 onwards, sort by score descending
 $cutoffDate = [DateTime]::Parse("2018-01-01")
@@ -58,7 +59,7 @@ Write-InformationLog "Found $($allPosts.Count) blog posts with score >= $MinScor
 
 # Ensure directories exist
 $referenceDir = ".\\.resources\\reference"
-$contentDir = ".\\.resources\\reference\\content"
+$contentDir = ".\\.resources\\reference\\reference"
 if (-not (Test-Path $referenceDir)) {
     New-Item -Path $referenceDir -ItemType Directory -Force | Out-Null
 }
@@ -92,28 +93,33 @@ foreach ($post in $allPosts) {
 
     # Extract fields
     $itemId = if ($post.FrontMatter.ItemId) { $post.FrontMatter.ItemId } else { "unknown" }
+    $ItemType = if ($post.FrontMatter.ItemType) { $post.FrontMatter.ItemType } else { "unknown" }
     $title = if ($post.FrontMatter.title) { $post.FrontMatter.title } else { "Untitled" }
     $tldr = if ($post.FrontMatter.tldr) { $post.FrontMatter.tldr } else { "" }
     $contentFileName = "reference-content-$itemId.md"
 
+    # Sort classifications by score and take top 3
+    $topClassifications = $classificationResults | Sort-Object -Property score -Descending | Select-Object -First 3
+    
     # Add to catalog
     $catalogEntry = [ordered]@{
         id                     = $itemId
+        type                   = $ItemType
         title                  = $title
         primary_classification = $primaryClassification
-        scored                 = $classificationResults
+        scored                 = $topClassifications
         tldr                   = $tldr
-        content_ref            = "content/$contentFileName"
+        content_ref            = "reference/$contentFileName"
     }
     $catalogEntries += $catalogEntry
 
     # Create individual content file
-    $contentPath = ".\.resources\reference\content\$contentFileName"
+    $contentPath = ".\.resources\reference\reference\$contentFileName"
     $contentData = [ordered]@{
         id              = $itemId
         title           = $title
         tldr            = $tldr
-        classifications = $classificationResults
+        classifications = $topClassifications
         content         = if ($post.BodyContent) { $post.BodyContent } else { "" }
     }
 
 
@@ -2,11 +2,12 @@ id: -Z5GGUOjc-d
 title: Definition of Done - Objective vs Subjective
 tldr: The Definition of Done (DoD) in Scrum is an objective, measurable checklist that sets the minimum quality standard for every product increment, distinct from the more subjective Product and Sprint Goals. Teams should ensure their DoD is clear, comprehensive, regularly reviewed, and as automated as possible, avoiding subjective approval steps. Development managers should treat the DoD as a non-negotiable baseline for quality, not a ceiling, and keep it updated to reflect evolving standards and business needs.
 classifications:
+
 - label: Engineering Excellence
   score: 94
 - label: Technical Leadership
   score: 77
-content: |
+  content: |
   In countless teams, there’s a recurring mix-up between “what” we’re building, “how” it aligns with business objectives, and the objective quality criteria by which it should be measured. The result? Chaos masquerading as agility. To clear the air: in [Scrum]({{< ref "/categories/scrum" >}}), the “what” and “how” are driven by Product and Sprint Goals. These provide directional clarity but remain inherently subjective, a north star guiding your path, not a litmus test of quality.
 
   Contrast this with the [Definition of Done]({{< ref "/tags/definition-of-done" >}}) (DoD). The DoD is your team’s objective compass, a binary, quantifiable checklist that ensures every [Increment]({{< ref "/tags/increment" >}}) meets professional-grade quality. It’s non-negotiable and should be firmly rooted in your product’s brand, user expectations, and technical robustness.
@@ -40,23 +41,20 @@ content: |
   Each team working on a product would then be responsible for creating a DoD that is appropriate for their context within that product.
 
   This is the seed that will grow into each teams unique quality bar that reflects this DoD. A robust reflection should be:
-
   1. **Objective and Measurable**: Avoid vague criteria and instead focus on things that you can measure.
   2. **Comprehensive**: What are all the things that need to be true for a production deployment of your product to be deployed to production?
   3. **Living Document**: The teams DoD as needed to reflect evolving standards, technologies, and stakeholder expectations of the product as it grows.
 
   ### Common Pitfalls
 
   Despite its critical importance, the DoD is often misunderstood, undervalued, or even undermined. Teams frequently:
-
   - **Blur Subjective and Objective**: Adding criteria like “approved by the [Product Owner]({{< ref "/tags/product-owner" >}})”, which shifts focus from quality to stakeholder satisfaction. Any "approved by ... person or department" should be strictly avoided.
   - **Overlook Automation**: Relying on manual checks leads to inconsistencies and slower feedback loops.
   - **Treat the DoD as a Maximum**: Viewing it as a ceiling instead of a floor hampers innovation and improvement.
 
   ### Practices for Defining Done
 
   To maintain focus on quality, consider the following practices:
-
   1. **Automate Everything:** Automated tests and CI/CD pipelines should validate DoD compliance as part of the development process. If you have things that cant be automated right now, plan the work to change the product to enable those activities to be automated.
   2. **Review Regularly**: Incorporate DoD reviews in retrospectives to ensure its relevance and alignment with current product and organizational needs. Keep a list of "things that need to be true to deploy to production that we cant do yet", and regularly move these to Done.
   3. **Train Teams**: Ensure every team member understands the DoD and its importance in delivering professional-grade Increments.
 
@@ -0,0 +1,69 @@
+id: L7cngB1uzW9
+title: 'Beyond Training: How NKD Agility’s Mentorship Model Transformed a Product Management Team Across Borders'
+tldr: A UK insurance software company overcame misalignment between UK product managers and Polish engineers by adopting NKD Agility’s mentorship model instead of standard training. Through hands-on coaching, clearer roles, and real-world practice, teams improved collaboration, decision-making, and problem-solving, leading to higher engagement and better product outcomes. Development managers should consider immersive mentorship to drive lasting change and agility across distributed teams.
+classifications:
+- label: Engineering Excellence
+  score: 85
+- label: Technical Leadership
+  score: 92
+content: |
+  ## Client Context
+
+  A mid-sized UK-based insurance software company serving platforms like *ComparetheMarket* found themselves at a critical inflection point. Product management teams in the UK and engineering teams in Poland struggled to align. The challenge? Building products for a UK market that Polish engineers had no context for, combined with a broader confusion around roles, strategy, and delivery.
+
+  They had five product owners and a senior product manager, but no clarity on how to move away from top-down leadership to an agile, outcome-driven approach. Communication gaps, context loss, and fractured collaboration were stalling progress.
+
+  ## The Ask: Product Owner Training
+
+  The initial request was standard: product owner training. But Martin Hinshelwood, Founder of NKD Agility, saw a bigger opportunity. He proposed a Product Management Mentorship Program, an immersive, work-integrated model rooted in deliberate practice.
+
+  ### Diagnosis: A System Problem, Not a People Problem
+
+  Martin quickly identified systemic dysfunction:
+
+  - **A lack of shared understanding about what a Product Owner actually _does_**: Roles had titles, but little clarity on responsibilities, decision-making rights, or how success was measured. This confusion crippled prioritization and value delivery.
+  - **Engineers disconnected from the business domain**: Developers in Poland were building features for the UK insurance market without understanding its regulatory nuances or customer expectations. This lack of context led to misaligned solutions.
+  - **Misaligned priorities across geographies**: Product management in the UK and development in Poland were operating on different assumptions and uncoordinated timelines, leading to delivery friction and rework.
+  - **Teams stuck between command-and-control habits and agile aspirations**: The organization wanted agility but was still making centralized decisions and enforcing control structures that prevented real empowerment.
+
+  This wasn’t about introducing a new framework. It was about re-engineering how learning, decision-making, and leadership happened day to day.
+
+  ### Approach: Mentorship as Infrastructure
+
+  Over 8 weeks, Martin delivered a customized mentorship experience combining:
+
+  - **Core product management concepts from** [Scrum.org](http://Scrum.org): Grounding the team in a shared language and foundation of modern product thinking.
+  - **Real-world examples and mirrors from other organizations**: Helping participants see that their challenges weren’t unique, and that other teams had overcome them.
+  - **Weekly assignments to apply new practices inside real work**: Instead of theory, the team had to apply what they learned inside their backlog, sprints, and stakeholder conversations.
+  - **Live coaching and feedback loops**: Each week provided space for reflection, challenge, and iteration, not just learning, but *changing*.
+
+  Instead of theory in a vacuum, teams got support applying change where it mattered: *inside their system of work*.
+
+  One week, two sub-teams were given the same assignment. One said, "We can’t do this here." The other succeeded. Same org, same resources. That contrast sparked peer learning, reflection, and creative problem-solving, real agile in action.
+
+  ### Outcomes: Engagement, Capability, and Real Change
+
+  Within 8 weeks:
+
+  - **Product owners became more confident, capable, and collaborative**: They moved from passive coordinators to active shapers of value, engaging stakeholders and engineering with greater clarity.
+  - **Engineering engagement increased as context improved**: Developers began to understand *why* features mattered, not just *what* to build, resulting in better technical decisions.
+  - **Communication between UK and Poland became more fluid and effective**: With aligned language, goals, and rituals, the distributed teams began working as one.
+  - **Teams began solving previously intractable problems on their own**: Empowered by deliberate practice, teams stopped escalating every challenge upward and started experimenting with local solutions.
+
+  The CEO later remarked:
+
+  > "After a full day of training and a time zone shift, they were still engaged, still asking questions, still figuring out how to make this stick. That tells me we’ve got something special happening here."
+
+  ## Strategic Impact for CTOs and Tech Leaders
+
+  This case demonstrates what every CTO is seeking:
+
+  - **Technical Leadership**: By clearly defining roles, empowering decision-making, and supporting mentorship, the organization unlocked a stronger product-engineering partnership.
+  - **Engineering Excellence**: With better context, reduced rework, and stronger feedback loops, the engineering function was able to improve both quality and throughput.
+  - **Organizational Agility**: Instead of pushing frameworks, NKD Agility helped create conditions where people could own problems and lead change from where they stood, a hallmark of resilient, adaptive organizations.
+
+  Martin Hinshelwood doesn’t deliver courses. He delivers transformation, in context, in flow, and in partnership.
+
+  ## Final Takeaway
+
+  Immersive mentorship is not a luxury. It’s the only path to sustainable, scalable change in complex environments.
@@ -0,0 +1,60 @@
+id: PMnxyczoB1K
+title: 'Engineering Excellence in Action: How NKD Agility Helped SLB Streamline Build and Release Across 90 Teams and 13 Countries'
+tldr: NKD Agility helped SLB streamline build and release by guiding 90 teams across 13 countries to adopt a single source control system and consistent branching, shifting ownership of builds to the engineering teams. This reduced central build team size, improved developer autonomy, and made release management more predictable. Development managers should consider empowering teams with clear structure and shared responsibility to achieve faster, more reliable delivery at scale.
+classifications:
+- label: Engineering Excellence
+  score: 95
+- label: Technical Leadership
+  score: 92
+content: |
+  ## Client Context
+
+  [SLB](https://www.slb.com/) (formerly Schlumberger), a global energy technology company, had over 90 engineering teams in 13 locations across 9 countries contributing to a single product: Petrel. Each team operated independently, choosing its own source control system, build environment, and branching strategy. Some used Git, others Team Foundation Version Control (TFVC), SVN, or even in-house tools.
+
+  The result? A sprawling mess of incompatibilities, blind spots, and inefficiencies.
+
+  ## The Ask: Build System Simplification and Consolidation
+
+  Martin Hinshelwood from NKD Agility was asked to assess the situation and recommend a path forward. The goal: consolidate build and source control processes to enable faster, more reliable, and more autonomous development.
+
+  ### Diagnosis: Extreme Fragmentation and Build Fragility
+
+  Martin’s assessment uncovered:
+
+  - **An overloaded central build team**: Eight engineers were running 11,000 builds a day, producing 27 petabytes of data annually just to generate one working version of the product per month.
+  - **Inconsistent tooling and branching**: Each team used their own tools and created custom branches, making traceability and integration nearly impossible.
+  - **Lack of ownership and accountability**: The build process was treated as someone else's problem. Teams weren’t accountable for build quality or integration readiness.
+
+  ### Approach: Advisory Engagement Rooted in Engineering Principles
+
+  Martin didn’t implement the solution directly. Instead, he provided:
+
+  - **A clear architectural recommendation**: Migrate to a single source control system (initially TFVC, later Git) and adopt a consistent branching model across all teams.
+  - **Branching strategy and build design consulting**: Martin guided SLB on how to design a scalable branching structure that balanced autonomy and alignment.
+  - **Education on engineering accountability**: He helped reposition build and release as shared engineering responsibilities, not something delegated to a separate team.
+  - **Ongoing consultation throughout implementation**: While SLB owned the execution, Martin provided iterative guidance and validation.
+
+  ### Outcomes: Ownership, Speed, and Significant Cost Reduction
+
+  - **Shifted ownership of build and release to engineering teams**: 90+ teams began managing their own builds and branches, removing bottlenecks.
+  - **Reduced central build team from 8 to 2 people**: A leaner core team focused on platform support, not firefighting.
+  - **Improved developer autonomy and morale**: Teams had the tools and responsibility to manage their own work, increasing throughput and engagement.
+  - **Simplified engineering processes**: With one source control system and a standard branching model, release management became predictable and transparent.
+
+  ## Strategic Reflection: Engineering Excellence Through Real Ownership
+
+  This case represents a core NKD Agility principle:
+
+  > Real engineering excellence isn’t about tighter control, it’s about giving teams the *right structure* so they can take responsibility for quality, speed, and stability.
+
+  Martin’s advice helped SLB do just that: reframe build and release as team-owned practices rather than operational burdens.
+
+  ### Why It Matters for CTOs and Tech Leaders
+
+  - **Technical Leadership**: Empowering engineers to own build and release is a foundational move toward scalable, resilient development.
+  - **Engineering Excellence**: This engagement demonstrates how structural advice, not new tooling alone, can unlock better results across distributed teams.
+  - **Strategic Impact**: Simplification enabled better forecasting, reduced overhead, and made SLB’s engineering system more future-ready.
+
+  ## Final Takeaway
+
+  When engineers own the system they work in, magic happens. NKD Agility helps organizations create the clarity, structure, and culture where that ownership can thrive.