[2021 kcdc] a product approach to tech debt

This post is my live blog from KCDC. For more, see the 2021 KCDC live blog TOC

Speaker: Jennie Ocken


I went to another session first so only saw the second half of this talk.


  • Conway law 
  • Document debt.
  • Decide how much acceptable.
  • Project vs product thinking.
  • Short term thinking.
  • Can deliver quickly if it is less valuable or poor quality. 
  • Three horizons – majority existing market   Next new market if something new for existing market. Then both new 
  • Measure what fire fighting. We reward this culture. Have to thank senior people for working weekend to solve problem. But then juniors think have to. H
  • Hippo. Highest paid persons opinion
  • Objective truth. What are facts. 
  • Debt compounds. 

My take

I missed half, but I liked the half I saw!

[2021 kcdc] black holes and revelations

This post is my live blog from KCDC. For more, see the 2021 KCDC live blog TOC

Speaker: Sarah Harper

Twitter @sarita1119


Why work gets stuck

  • Work moves through the system until it gets stuck in a phase
  • We like to think of things as a process problem. However, often a behavioral issue (not like major HR leve problems)
  • Reasons: someone out sick, not enough people know how to do something, blame testing
  • Agile black holes!
  • Detrimenta to process and team morale
  • Not obvious what problem is
  • examples: deployment, business requirements, code review, qa
  • Biggest black hole is the backlog

Back hole theory

  • Any work status which acts as a “holding pen” for work items will eventuallly turn into a black hole
  • Once enough are blocked for same reason, all future items will becme blocked
  • It becomes acceptable for things to get blocked there
  • No work appears to be done to outside observer – unclear who working on or what it is up to


  • Queue busts – something wrong and swarm around it. Teams decides to focus on something like a customer service queue.
  • Eceeed WIP limits
  • Blocked column
  • Too much in “done” or “ready” columns
  • Long staging cycle time

Learned Helplessness

  • Exercise: everyone got a piece of paper with three anagrams and people raised their hand as solved
  • One one side, first two not soleable. One other side, first two easy. Then same third one.
  • Taught first group learned helplessness.
  • Trained to give up.
  • I tried X times to change this

Locus of control

  • Exercise: how much control do you have over weather, food you eat, comute, home, projects at wor, team member participation. (Scale of none to all)
  • Think about what under control
  • Don’t blame others for things can control
  • Be alert when someone says can’t/imposssible

Self handicapping

  • Don’t try so can’t fail
  • Fear of looking bad
  • ”give to X because X can do fastest” – setting team up for failure if that person can’t do it.
  • That person becomes busy and a black hole
  • ”You miss 100% o the shots you don’t take”

Somebody else’s problem and the bystander effect

  • Brain edits it out because someone ese’s problem
  • Everyone ignores
  • May or may not actually be someone else’s responsibity
  • Bystander effect – assume someone else will take charge

How spot black holes

  • If have to scroll in a kanan board, have a black hole
  • Not obvious

Visual principles

  • Excercise: think about your kanban board For each of these principles
  • Figure ground – foreground vs background. What see vs ignore. Showed optical illusion of face/vase. Usually digital boards have a white background so white cards disappear into background. Can make a different color to stand out. Also, if something has a date contraint or a high priority, add contrast.
  • Common region – when obects located in same region, we perceive them as being grouped together. If everything looks the same, can’t tell. Change blocked cards to a different color
  • Similarity – thinks that look the same are assumed to be the same.
  • Proximity – things close together appear to be more related than things spaced farther apart. This is more of an effect than similiarity
  • Continuity – Elements on a ine are considered more related. Lines follow the smoothest path.
  • Focal point – watever stands out visually will attract and hold our attention
  • Closure – we try to find recognizable patterns
  • Just noticeabe difference – hard to see Jira dots for how long in state
  • Idea: have blocked work in a different color, in a lane on top. So you can see status blocked in.
  • Avoid too much color

Game: https://getkanban.com/pages/free-version

Escaping back holes

  • Have team talk about problem
  • Visualize future state and take action
  • Use a physical board or customize digital board as much as can
  • FInd an influencer on team that will give good feedback and help team accept idea
  • Queue bust (swarm around problem)
  • Root cause everything

My take

I learned a lot at this session. I like how it was different than a lot of agile talks. I have a bunch of things to take back

what it was like writing a book

Last month, I got to give a ten minute speech at work about what got me to write a book and what it was like. I then gave a shorter version of it as a Toastmasters speech. The highlights seem like a good blog post. Along with a good number of more detailed points I had to omit due to time.

Getting there

  1. Over a decade ago, my teammate, Chris, asked me if I’d ever write a book. I went to a fairly animated response about there is no way I’d ever write a book because it is so time consuming. And here we are. He knew before I did. (It’s good to have a mentor that knows you better than you know yourself.)
  2. Busy people attract time consuming hobbies. After I finished grad school, I started blogging and mentoring. Moderator at CodeRanch.com. Oh, and writing lots of book reviews. Starting with Java 4, I also presented to people at work about new features in Java.
  3. My mind shifted from “no way” to “maybe someday.”
  4. I was still afraid at the time commitment, but curious about the process.When Martijn and Ben asked me to tech proof “The Well Grounded Java Developer” I said yes to learn about the process. It was interesting. I also proofed Manning’s OCA Java 7 Study Guide which was a different experience because I didn’t already know the author.  Also, getting to write tghe foreword reminded me that I did want to write a book someday.
  5. At this point I shifted from “maybe someday” to “I’d seriously consider it if the right opportunity presented itself”. I had been approached for two other books, but they weren’t the right opportunity.
  6. When Bert was looking for contributors to K&B 7, I jumped at the chance.  “Interviewing” with Bert was scary because I admired him so much. (In hindsight, I don’t think it was an interview, but I was certainly nervous enough for it to be one.) I learned a lot from Bert; he’s a great mentor. I also gained confidence because I got asked to write 1.5-2 chapters essentially half a chapter at a time. The first one felt like “taking a chance on me.” The last two groupings felt like I had earned it. I also learned my writing velocity which was huge for being able to commit to actually writing a book.
  7. My friend Erik and I talked about writing a book together. We wrote table of contents and the beginning of chapter one. Even though we didn’t proceed, it was good to have a practice run at organization. I used github to organize things. Knowing how I would so greatly happened when it came time for this book.

Previous work for Wiley

Michael Ernest asked me to tech proof his book “Java SE 7 Programming Essentials“. I didn’t get to due to, well bureaucracy in multiple places. I did learn to avoid that bureaucracy the next time the opportunity came up. Michael asked me to tech edit his next book with Wiley. I signed a contract. Then the book didn’t get written. Note that the only work I have done for Wiley at this point is sign a contract.

The right opportunity

As I sat in “I’d seriously consider to right opportunity, but not seek it out” mode, two publishers approached me. Both were big name tech publishers. One was an update of an existing book. There would have been new chapters about Java 8 that would be mine. And a lot of pruning/updating. The other was the one I choose. I did talk to a contact at both publishing houses before deciding. I also talked to the author of the previous edition (for the one I didn’t choose) and Michael Ernest for the one I did. I wanted to see why they didn’t want to do it. Just like coding, a greenfield project is often more fun and that’s what I went with on the book. I also had just finished working on Bert’s book and wanted the opportunity to have my own style.

When I spoke to Wiley on the phone, the acquisitions editor referred to “my previous work with Wiley.” That’d be the contract a signed that was later cancelled? Glad to know that shows I’m reliable. I imagine/hope that Michael vouching for me meant more than that meagre work experience.

I asked Scott to co-author with me. We had talked about writing a book together years ago and it’s always been a running joke/something that might happen one day. He was therefore my first choice as co-author.


  1. Github source control – For both example code and the book files
  2. Github tasks/issues – For managing deadlines/tasks/bugs/etc. I wrote a Spring/OAuth web service to automate this.
  3. Github wiki – For links, phone numbers, etc
  4. This blog – For announcements
  5. Jenkins/Selenium/XPath – For when Oracle changes the objectives
  6. Pomodoro Timer – To remind me both to stay focused and take breaks/look away from the computer