Preparing for a podcast interview
Next week I will be speaking about #noEstimates on the great Scrum Master Toolbox Podcast. Even before the actual recording this has been a great experience already: Even though the spotlight was on me initially we managed to spin this into a team exercise. Just as it is in our daily work. We had some interesting reflections on what had happened during the last half year. Sometimes it’s good to stop and look back at what you have achieved.
I was confronted with how I want to present me and my work in public, how we can both have interesting and inspiring conversations with tweetable quotes while staying true to the facts and my values.
Technical debt board
One of my colleagues proactively started a technical debt board. He set up a physical board where we keep track of our impediments. We organise topics on a pain / effort scale and we also have a backlog for topics where the real impact is not yet clear.
I like how this board helps in keeping track of problems during a sprint. Often times we are quick to forget them as we resume the task. By writing down our issues we instead can find the most painful issues over time. I think the 4 quadrants of technical debt are another great way to categorise technical debt: You have deliberate/accidental and reckless/prudent.
- Deliberate + reckless: We don’t have time for design
- Accidental + reckless: What’s Single Table Inheritance?
- Deliberate + prudent: Ship now, deal with the fallout later
- Accidental + prudent: Now we know how we can do it better
User interview observations
I am still reading The Mom Test book and trying to apply these practices. This week I joined my first real user interview. Here are some of my observations and learnings. Open ended questions reveal some unexpected opinions and thoughts of users. It was nice to how to talk to the user without biasing them. Questions from the user like “how is this supposed to work?” were answered with “How would you expect it to work?”
Another thing I observed was the inherent need for users to “do it right”. I saw how important it is at that point that the interviewer reassures that there is no right or wrong.
Sometimes the answers are a bit harder to interpret. When you get a reassuring answer like “yes, the information displayed is enough” followed by a “because XY is not that important” it raised a slight doubt. Why did the interviewee specifically mention this field X? It might have been a hint that they were just too afraid to object directly.