📬 The Backlog #189

Why Definitions of Ready are wasteful illusions, how a sustainable pace isn’t just a Developer affair, and which things will help you speak better - of yourself.

1. Instead of focusing on a Definition of Ready, put your energy towards a Definition of Done. The former won’t help you when you’ve actually started doing the work; the latter will, and that’s because finishing something matters more than starting it: after all, only when you finish something, will you be able to examine if you achieved an outcome you were aiming for.
   
   I routinely encounter (software-engineering) teams that note the absence of a Definition of Ready and believe that having one will bring order to their work. Incidentally, none of those teams have (or adhere to) a Definition of Done. It usually takes me a little while to open up the conversation around this topic - let alone to finish it, natch.
   
   Next time you or I find ourselves in a situation with an opportunity to discuss why (and in which circumstances) a DoD may serve a team, quickly refer to Chee-Hong Hsia’s beautifully succinct comments in this LinkedIn thread responding to a Definition of Ready video by Daryl Chen.
   
   Chen’s video echoes what I think may endear the concept of a DoR to teams; setting the stage so you don’t have to think anymore. But that overlooks the problem that doing the thinking only comes when starting the work, as Chee-Hong Hsia explains:
   
   “DoR works well in a simple (everything is known) and complicated (more known than unknown) environment. When you find yourself in a complex environment (more unknown than known) be aware that the DoR does not become the foe of empiricism.
   
   […]by focusing too much on getting it “first-time right”. In a complex environment (definition: more unknown than known) it’s an illusion that we can get the specs complete, clear and ready. If you’re not careful, you’ll be potentially promoting a waterfall way of working. Empiricism asserts that knowledge comes from experience. This is the reason why the Agile manifesto talks about “working software over comprehensive documentation”.
   
   “The key difference here is complicated vs. complex. Thinking you can manage the unknown, uncertainty and risks beforehand (through a DoR) is a bad idea. Continuously inspecting and adapting to make this DoR complete is a waste of time because of the high variability per item”
   
   (I reproduced these comments here entirely on the off-chance you don’t have a LinkedIn account and would get stuck behind LI’s garden wall.)
   
   
   

2. Blake McMillan is writing a series of articles on the principles of agility. His recent entry Sustainable Pace for All touches a topic dear to my Scrum Master’s heart, feedback loops - from the perspective of doing/making things better a little bit at a time.
   
   Doing that is associated with achieving and maintaining a sustainable pace - of work, of development, of delivery. And it’s usually discussed with or by the developers.
   
   Rightly so, because “when people are pressured to work at an unsustainable pace, inevitably quality will suffer. When we feel like we are trapped in a situation where we are unable to produce work meeting our quality standards it will lower our morale. If our morale is low, it can lead to dissatisfaction which leads to undesirable attrition,” as McMillan says it.
   
   His article is valuable, though, because it explicitly deals with sustainable pace for two other groups: Sponsors (like stakeholders) and Users - each of whom have different engagement needs and frequencies. So include those groups, too, when examining what pace may be sustainable for your work.
   
   
   

3. “To tell your story well, help people understand not just what you are, but why you are the way you are. What are your motivations and passions?”
   
   I wish I’d read Julie Zhuo’s excellent article How to Talk about Yourself in the Best Possible Way before I appeared on the Scrum Master Toolbox Podcast a while back.
   
   Zhuo explains how she had to overcome tendencies to be overly humble in talking about herself, when she’d written a book and she needed to establish herself unequivocally as an expert in her field. I believe her advice and examples are useful to anyone updating their vanity website, writing a speaker bio, or preparing for a job interview.
   
   Because even if there’s a whole PR department behind you (and how many of us have that?), you still have to feed them the interesting bits, yourself.
   
   
   

Have a self-assured week and Scrum on,
Thomas van Zuijlen