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

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

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

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

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

A periodic reminder that the vast majority of metrics are our destruction, not our salvation. Let's start with Deming:

“You can only measure three percent of what matters” (Deming, quoted by Peter Senge) 1/8 "It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.” (Deming [The New Economics])` 2/8

That made-up Henry Ford quip, “If I had asked people what they wanted, they would have said faster horses” (no, he didn't say it), is usually interpreted as "I know more about what customers want than they do." That's ridiculous. 1/4 However, you may be better positioned to come up with better solutions to their problems than they are. That is (or at least should be) our area of expertise. 2/4

1/4 Just a reminder that I have a series of 3 classes coming up in January that cover the gamut of agility, all described at holub.com/classes. They are: 2/4 (1) A short seminar that covers my holub.com/heu heuristics and other rules of thumb for building effective software organizations. This one is for everybody, including managers.

Let's talk about team stability. Stable teams have obvious advantages. They're easy to budget, and a gelled team works like a well-oiled machine. But balancing that notion is the Lean idea of people moving around to meet demand. 1/7 (Note that I said "people moving," not "moving people." This is something that self-organizing teams do on their own. It's not Soviet-style controlled-economy management moving people around like chess pieces.) 2/7

This is a great question. I start by adding a test that proves that the code works as expected right now. It should pass. I then modify the code to break the test to prove that the test works. 1/4

https://twitter.com/vijaytnc/status/1608571122454519809

Alternatively, if I'm adding a completely new feature, I augment that first test with a second one that fails because the new feature doesn't exist. In both cases, I'm starting with a red test that focuses on a single small subset of the behavior I want to add. 2/4

The whole notion of "SDLC" is a waterfall notion. Software built in an agile way doesn't really have a "life cycle" where it moves through study, design, implementation, test, deployment, and support. We do all of those things in parallel—continuously. 1/4 Secondly, only in-agile or fake-agile processes have "ceremonies." We're agile. We meet when we need to. (That may be on a regular cadence, but it's not a ceremony. It's a working session.) I'd also reconsider the whole notion of a Sprint. 2/4

How does Scrum-as-usually-implemented violate the Agile Manifesto? Let's start with "Individuals and interactions over processes and tools." 1/15

https://twitter.com/scrumtuous/status/1598663971824967683

Scrum is treated as a rigid process with mandatory tools like Jira and Story Points and all those required meetings where nothing is accomplished. 2/15

ISTM, a significant objection to going back to the office is that the office is an open-plan hellhole built without humans in mind. If companies really want people to come back, they need to rethink what an "office" is and redesign it around human needs. 1/4 Moreover, they need to think deeply about whether a single ginormous office meets those needs. What's the point (other than a show of power and surveillance stemming from no trust) to put people who rarely interact into one big building? 2/4

Look. I don't want to be a naysayer, but I keep hearing about how WFH is the future and how awful orgs that don't allow it are the spawns of Satan, but the fact is that many existing orgs will _never_ allow it. 1/6 Those orgs will not magically start caring about their employees or your work environment. They put up with WFH for a while, but they're now reasserting their authority through control. 2/6

I don't see how you can design a complete architecture before you start building. The simplicity principle is at play here. At any given moment, the system has exactly enough architecture to implement the current set of stories. 1/5 The architecture evolves incrementally as the system grows. Any up-front architecture based on guesswork will be bloated & overcomplex. That unnecessary complexity adds expense—everything takes longer, and you need to maintain things you don't need. 2/5

I've been using @Readdle's Spark email on my phone for years, but they've just lost me with the new big-bang release. Many many changes. Many new features. Utterly incomprehensible. Not as usable. 1/4 This is a great example of why the agile approach of incremental small changes is better than huge releases. Changes come gradually, one at a time, so they're easy to absorb. 2/4

In a blinding flash, I've had a revelation about many of the people who complain bitterly about mobbing, usually because they identify as "introverts" or as someone with ADHD or on the spectrum. Those are actually not the core issues! Putting aside the fact that many neurodiverse or introverted ppl & ADHD sufferers enjoy mobbing, it occurs to me that the _real_ problem is they work in a command/control org w/o psych safety, and they can't leave the team. They believe they'll be forced to mob!

The QT is actually a big question. UX and (UI) design are both handled by having UX skills on the team. You "research" by building small, delivering, & getting feedback. Architecture (which is also design) is done incrementally by the team as it writes the code. 1/4

https://twitter.com/_/status/1591473201112121347

Align with other teams using something like Spotify's guild system (e.g. UX and Architecture guilds). A single Architect or UI/UX expert who works with multiple teams can also help. 2/4

1/ Was asked "what do you mean by 'thin slicing'"? I work from stories. A "story" is a description of a user's problem. It describes the user's work, not ours. We come up with a solution as we implement it and get feedback from them. 2/ A full-blown solution is often way too big to implement in an Agile way, however (i.e. 1 or 2 days max). We need feedback and can get it only when we work small. So we "narrow" or "slice" the story to make it smaller.

One of the problems with PR-triggered code review is that you can go for days (or weeks) w/o getting feedback. 1/4 Since the rest of the code is evolving during that time, merges are difficult, & rolling back work or fixing problems can be a massive effort—much more so than it took to write the code. 2/4

So, let's talk about secure hashes and passwords (Based on an earlier convo, they are not well understood). A hash is a fixed-width number that you generate by feeding characters into an algorithm. 1/9 The width of the hash is the same (typically 32-64 bits == ~8 bytes, but they can be as large as 512 bits, depending on the algorithm) regardless of the number of characters you feed in. Passwords of any length create the same-width hash. 2/9