Cost of Delay (money lost becuase something hasn't been delivered) is a big deal, often > cost of development. It's hard to determine, tho, involving lots of guesswork. Fortunately, in an agile world, we don't need to have to have a hard number. 1/6
We can assume that the more valueable something is to our customer, the higher the relative cost of delay. "Relative" is all we need. In waterfall (and SAFe) shops, you need complex formulae (e.g. WSJF) for CoD because the timeframes are so long & dev time is a factor. E.g 2/6
If you have a small thing with a high CoD, and a large thing with a low one, do the small thing first. The time added to the long thing won't impact its CoD all that much. However, in an agile (SAFe isn't agile) shop, we can make the units of work very short. 3/6
If all stories take a day or two to implement, then that variable (the denominator in WSJF) drops out of the equation entirely, and we arrive at a simple: do the most valuable thing next. Not doing that adds cost. 4/6
I'll add to the above that Reinertsen, who came up with the notion, uses CoD for comparison purpose, but the notion applies even if you're not comparing. E.g., the delays inherent in bureaucratic overhead == lost revenue. 5/6
If you're trying to save money, a good place to start is looking at how to eliminate unnecessary delay. 6/6
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I don't believe that "bugs just happen." They are written by people. Sure, people make mistakes, so if you really want to reduce bug counts, work in a way that catches those mistakes early, 1/6
and also create a deployment system that recovers quickly and gracefully if any slip through. E.g., with mob/ensemble programming, you have multiple pairs of eyes reviewing the code as it's written (a 1-on-1 code review performed after the code is done doesn't do that). 2/6
A no-known-bugs-on-release policy helps people focus on quality. TDD introduces tests so early that bugs tend not to be in the code to begin with, and running those tests every few minutes or so makes them easy to fix when a test fails. 3/6
Some thoughts on retros (and a much longer thread than is my wont—sorry). A poll over on LinkedIn asked, "How long does it take you to prepare and create a retro?" There's an entire thread talking about the destructive implications of that question, so let's do that! 1/15
IMO, a retro is a conversation focused on improvement, maybe triggered by something not working or going wrong in the recent past. You don't plan how to converse; you converse. The conversation happens continuously as you work. It is not a meeting. 2/15
The process of continuous improvement is just that—continuous. It is not an event. 3/15
There are two approaches to making projections for business purposes. The one to avoid is estimation based on specification analysis. Unfortunately, that's what most ppl use, and it pretty much always fails because an up-front specification is invariably wong. 1/5
You need to deliver something and get feedback to validate the spec. Constant reestimation as you learn is both wasteful, and equally futile. More to the point they're useless for business projections given that they constantly change. 2/5
So, instead of making projections based on specification analysis, make projections based on flow metrics like throughput (stories completed per unit time) or lead time (time from initial idea to delivery). 3/5
People talk about mob/ensemble programming being intense and exhausting, but when I hear that, I think there may be something wrong with your process. Personally, I find mobbing relaxing. So, here are a few must-dos 👇 1/6
(1) You can't mob without psychological safety—if you feel like you can't speak up, even if nobody else has your opinion, you don't have any. Speaking up should be a stress-free activity. Mobbing should be like a relaxed dinner with friends, not a cage fight. 2/6
(2) People flow in and out of the mob constantly. If you're feeling overwhelmed, take a walk. Ofc, to do this, you can't be the only person in the mob with an essential skill, so teach others your skills! 3/6
I occasionally hear people diss mob/ensemble work on the grounds that they're "introverted." I'm a hard-core introvert. I love mobbing, as do many ppl I talk to. So maybe, the problem is in understanding what an introvert is. 1/5
I like Susan Cain's take on introversion (her book "Quiet" is worth reading). It's all about the need (or not) for stimulus. I hate large, noisy parties & restaurants. I'd rather relax over dinner with a few friends. 2/5
I don't need much stimulus, so I can focus well for long periods of time. I have no desire to bungee jump 😄. I speak in front of large groups of people all the time (I am not shy), but I recover in a quiet place, ideally with a few friends, but on my own if necessary. 3/5