The notion of pulling multiple stories into a Sprint is, AFAICT, based entirely on the notion that you’ll divvy up the stories between team members and work on them in parallel. 1/5
IMO, it’s much better for the whole team to work on each story in sequence using a collaborative technique like mob/ensemble programming. 2/5
If you do that, then it’s actually contraindicated to pull more than a single story because, if you do, you’re preventing other teams from working on the stories in your Sprint backlog. That guarantees that low value work is taking precedence over high-value work. 3/5
Of course, once you start working collaboratively on stories in sequence, the whole notion of a Sprint becomes far less interesting. 4/5
Shrinking the entire Sprint to a couple days (for one story) increases your meeting:work ratio entirely too much, and what’s the point of delaying reviews and retros until you complete a block of stories? 5/5
• • •
Missing some Tweet in this thread? You can try to
force a refresh
A few more out-of-context quotes from Kretzman, but he’s provided another good list of fallacies to examine, so let’s do that!
Paper prototyping is indeed a waste of time if it’s an up-front design process. 1/6
IMO, you don’t start getting useful feedback until you release something, so build very small and get feedback as you’re building. I’ve seen horrific failed UIs that were developed using extensive paper prototyping. Paper can’t replace the real thing in your customer’s hands. 2/6
I have no idea where he got the "goal driven" quote from, but it links into the "roadmap" thing. I’m not a fan of traditional roadmaps, particularly the corporate quarterly thing. 3/6
I have Peter blocked, so can’t quote him directly and won’t respond if he injects himself into this thread (he usually takes my tweets out of context and quickly resorts to personal attacks), but his tweet (see screen shot) is an interesting list, so lets’ go through them: 1/11
"Dispense with measurements…" In general, when I go into an org, measurements won’t help with things that are most wrong. Things like no psychological safety, a culture of competition vs. collaboration, a culture that puts process over people. 2/11
Measurements are useful for tweaking things once the worst problems are addressed, but most orgs never get to the point where the worst problems are addressed, so there’s not much value in measuring. 3/11
IMO, production testing and "exploratory" testing are complementary, but incompatible activities. Production testing is the thing that a few people in the community denigrate as "checking," as they turn up their noses and deprecatingly sniff. 1/9
That’s the thing that tells you that the program actually works and is shippable. IMO, that process must be fully automated and integrated into your CI/CD pipeline. 2/9
It must be possible to check-in-test-and-release with an automated, and very fast, indivisible process that in no way involves human hands. IMO, production tests of this sort are created by the dev team, ideally as part of the TDD process, & checked in along with the code. 3/9
Dan Pink’s "Drive" (and his Autonomy, Mastery, & Purpose) is a great book, but he’s just a popularizer of other’s work, primarily that of Ryan and Deci, who’s life work (and vast research) went into their Self-Determination Theory. 1/5
They have many long books, but there’s a reasonable (tho simplistic) summary here: [tinyurl.com/y6ur7dks]. Self-Determination Theory identifies three factors: competence (Pink’s "mastery"), connection (or "relatedness"), and autonomy. 2/5
I’m much more trusting of people like R&D, who spent their lives doing peer-reviewed research, than a popularizer like Pink, so I’ll stick with those three characteristics as primary. Don’t know why Pink left out connection, but it seems critical to me. 3/5
Asked "how do you manage your backlog?" First, my backlog is entirely user stories—no PBIs. Any tech work that does not make your customer’s work in the domain easier probably does not need to be done. 1/9
I put essential overhead (e.g. updating key frameworks) on a separate kanban board, not the backlog. Allocate a fixed percentage of your time to to overhead—say one day a week max—so that it doesn’t overwhelm real work. 2/9
Next, Make the stories small—something you can implement in a day or two. You can’t reliably estimate stories larger than that, so there’s no point in pretending you can. 3/9
Recently, @GeePawHill tweeted about this very issue & I’m very much aligned with his thinking. For a long time, I avoided politics (and still resist most of impulses). The constant walking on eggshells was eating away at me, tho. You cannot separate the code from the person. →
@GeePawHill If I lose followers because they don’t like me as a person, I’m truly sorry to see you go, but I am who I am. I’d argue, in fact, that my thoughts about software dev and everything else are not separable. One follows from the other. →
@GeePawHill I believe what I believe, both about software & life, because I am who I am. One of the things I believe is that people should respect and watch out for one another. People who will happily kill people by spreading contagion are not good people in my mind. →