Monthly Archives: August 2025

[kcdc 2025] AI Vulnerabilities in 2025 – Some of the darker sides of AI

Posted on by
Reply

Speaker: Andreas Erben

For more see the table of contents

From the news

What drives model behavior?

  • Initial training
  • Fine puning
  • Potential customer fine tuning
  • System prompt – how the model should behave.
  • Data/prompt
  • Filters on data, prompts, output

Other links

My take

After the first example, there was a bunch of content on how LLMs work. I tuned out a little during that section probably because familar. Then it got interesting again.

[kcdc 2025] having daily standups people actually care about

Posted on by
Reply

Speaker: Phil Ledgerwood

For more see the table of contents

Scrum survey

  • Asked who doing Scrum – most of room
  • Had people sit if no sprint goals – a bunch
  • Had people sit whose sprint goal is to complete X stories – a bunch more

Standup pains

  • Ghost man – I won’t make standup today, but here’s my update
  • Arena – two people debate for 45 minutes and everyone else watches
  • Captive Audience – “since we got everyone together, I’d like to talk about something completely different”
  • Hunger Games – every week, less people come
  • Inquisition – does anyone from business/management have questions for the team
  • The Questions Three – did yesterday, today, any blockers – these questions were dropped from the scrum guide

Missing

  • Right people – developers (per Scrum Guide). Developers are people doing the work of delivery.
  • Right purpose – for Scrum, to inspect progress toward sprint goal and adapt the backlog. On track? What adjustments needed? Adjustments can include cancelling spring because goal no longer relevant. For non Scrum teams, purpose is to review state of work in progress/make appropriate decisions for day.
  • Right value proposition – team walks away with plan of action for day that they have come up with themselves

More notes

  • Even if not doing Scrum, probably got ideas from there
  • Ok for anyone to come to standup but don’t get to participate. Some teams limit for safety, etc
  • in Scrum, committing goal not the set of stories (at iteration planning
  • Standup timebox is the investment the organization is making towards the goal
  • Deliverable of standup is the team’s collaborative plan for the day
  • People miss standup because its not valuable to them
  • Helps to have a facilitator at beginning

What’s wrong with the three questions

  • individual plan
  • status report
  • don’t orient towards the goal
  • more value to people not on team
  • reinforces inclination of devs to want to work independently and think about team

Why should devs care?

  • furthering own goals
  • taking charge of work
  • defining “how”
  • build trust, established competence, saves management time
  • less meddling from others (the more you have a working system, the less people want to change it)

Increase Standup Effectiveness

  • Don’t try to spice it up – ex: don’t theme. That doesn’t solve underlying problem
  • Establish clear value proposition and make sure everyone knows it
  • Structure event around value proposition
  • Meeting needs to have a reason for existence beside its existence
  • Stop event once accomplished value proposition
  • Walk the Board – talk to items. Everyone responsible for item on board should be there to talk to it. Ex: go right to left so talking about items closer to finished first
  • Ask are we are on track to meet the sprint goal
  • Ask if everyone knows what doing today. Good at end for new people because need to have accomplished this
  • Make sure devs talking together and not in sequence
  • Think “war room” and not “line for immunizations”

My take

My team hasn’t done the 3 questions in many, many years because it distracted us from the priorities. I still found ideas to take back to our team. Wrote them down for next retro. The Q&A was great. Lots of opinions!

[kcdc 2025] The problems that arise when focusing on predictability instead of variability

Posted on by
Reply

Speaker: Joel Tosi

@joelstosi@mastodon.social

Deck

For more see the table of contents

General

  • Suppose a team does 5-15 days per story. What is normal?
  • Want to see variability/stop hiding it.
  • Can’t use number of story points to guarantee delivery date

Process behavior chart

  • Shewhart chart. Goal is to differentiate variation due to common causes and special causes
  • Understand variability; don’t hide this
  • If do nothing, a system with deliver results within a given range.
  • Stable system may have more variability than you would like, but is stable
  • If stretch goals outside range, won’t happen
  • Helps make better decisions
  • Two teams with same average have different stories and different problems
  • Can figure out max/min. Just because max happened once, doesn’t make it repeatable

Anti patterns

  • Always add more planning
  • Pre-planning meeting to planning
  • Tampering – make random decisions based on observable patterns without understanding why
  • Stretch goals are a lie.
  • If can’t test, adding devops doesn’t help
  • Adding points for silly activities so looks like less vulnerability – illusion of progress
  • Meetings as an attempt to fix variability. Some meetings give the illusion of control

Negative implications

  • Variability in different things compound
  • Negative feedback – pressure to do more work -> start more stuff -> more branches -> stability goes down -> quality goes down -> more work (fix quality and still do the features)
  • Gets worse – add people since too much work. If can’t ship 1 thing in a month, try for 5 things in 3 months. Plan further out, make teams think of more things.
  • When we don’t see the system, we operate with the best of intention in the worst ways

Decisions that reduce options

  • ex: Orgs want autonomous interconnected teams but make decisions that prevent it
  • Want experienced people but can’t pay
  • Get junior engineers in very different time zones
  • Now can’t meet and work together

Context

  • “It depends” – variables, context
  • Context includes company, industry, experience, people. Cumulative effect of decisions company has made to that point

Illusions of Progress

  • Stories – “story for standup because takes time”
  • Backlogs – multiple backlogs, hard to trace/see big pictures
  • Branches – one person working on multiple branches. No actual progress even though committing
  • Tests – flakey/brittle
  • Scheduling – scheduling tetris. “If that team does X by that day then that team can do ….”
  • Priorities – should be a priority
  • Not measuring impacts/wrong – need to measure what matters

Outliers

  • Be careful of perceived outliners. Could be looking at the wrong level of the system
  • If a lot of outages and each has different reasons, might be predictable if look at a different way.
  • Major releases
  • Security
  • Cost of delivery

Other notes

  • Reality is interconnected and non-linear
  • One choice is not an option. That’s not a strategy. Jerry Weinberg – rule of 3. If don’t have three options, haven’t thought about it enough.
  • Experiment early when cheap and easy. Minimize variability after decide.
  • To have zero variability, nothing can change. requirements perfect, codebase perfect, never change tech, can’t learn, can’t innovate, etc

What do

  • Stop hiding variability
  • Start measuring variability
  • You know best what to do next

https://sim.curiousduck.io – free simulator. can enter any email

My take

Good food for thought. I hadn’t hard of Shewhart charts. The answer to my question about where the max variability came from was three standard deviations from average and assumes a normal distribution.. There are alternate ways for different distributions. That’s interesting.