Category Archives: Conferences

[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.

[kcdc 2025] Loom is more than Virtual Threads: Structured Concurrency and Scoped Values

Posted on by
Reply

Speaker: Todd Ginsberg

Bluesky: ‪@todd.ginsberg.com‬

For more see the table of contents

Project Loom

Project charter includes;

  • easy to use
  • high throughput
  • lightweight concurrency
  • new programming models on the Java platform

Virtual Threads

  • Platform threads in JVM map to OS threads. Not useful when blocked, memory hungry, limited number by OS, etc
  • Virtual threads have nothing to do with OS. Just memory on heap.
  • When virtual threads have work, mounted to carrier thread.
  • Carrier thread uses OS thread
  • Virtual threads still java.lang.Thread, must lower memory requirements, number limited by heap memory, quick to create, better use of system resources
  • Virtual threads have ids, but not names, by default since you are supposed to use them and then throw away.
  • 2 seconds to create thousands of platform threads. 41 milliseconds to do the same for virtual threads. 368 milliseconds to create a million virtual threads
  • Little’s law: concurrency – arrival rate (aka throughput) * latency. Virtual threads increase thoroughput
  • Do not pool virtual threads. Create, use, expose. You wouldn’t pool other inexpensive objects.

Structured Concurrency

  • API change so still preview in Java 25
  • Suppose have two futures. One that takes 2 seconds and one that takes 4 seconds.
  • Want to kill one when the other fails so not wasting time.
  • While think of as parent/child threads normally, that relationship doesn’t actually exist
  • jps command gives process ids
  • To get thread dump: jcmd <main program process id> Thread.dump_to_file -format=json unstructured.json
  • Goals: promote style of concurrent programming to eliminate common risks, improve concurrency
  • Enforces children don’t outlive parents
  • Explicit relationship between tasks and subtasks, observability is easier, managing work is easier
  • join() – join point waits until all tasks are done and can then interpret results.
  • Create StructuredTaskScope.open() in try with resources which means all or nothing. Whole scope succeeds or fails
  • scope.fork(() -> doWork())
  • scope.join()
  • future.get() to get the answer now that the join is done
  • Can nest scopes

Scoped Values

  • in Java 25 (no longer in preview)
  • ThreadLocal let you set data. Problems: unconstrained mutability (anyone who can read to it can write to it), unbounded lifespan (have to clean up if reusing platform thread), expensive inheritance
  • Scoped values: Immutable, defined lifetime, cheap/free inheritance
  • Ex: static ScopedValue<String> SCOPED. and ScopedValue.where(SCOPED, obj).run(() -> …)
  • Scoped values good for passing data one way. Good when have structured sharing use cases – ex: data many layers way from where you create it
  • Can replace one way ThreadLocal as use case without structured concurrency

My take

Not the point of the talk but I like that he uses Duration.ofMillis() instead of just putting a number. This topic is like pipelines; I needed to hear it a few times from different people for it to click. Given that scope values are in the Java 25 LTS and structured concurrency is not, I was curious how to use scope values alone so nice to hear that.