All of this content used to be spread over three different blogs at three different domains and it's now been merged into one. Why was it ever three? Because at the time it seemed reasonable that each of them was for a different audiences, and yet over time I've found that the lines between topic areas got blurrier and tended to overlap. So now they're all together in one place.

If you encounter things that seem broken, please let me know and I'll get them fixed.

Browse by topic area:

There's a lot here and if you're not sure where to start, here are some popular starting points. From these, you'll find crosslinks to even more topics. Enjoy!

Definitions of Ready and Done

I keep seeing heated discussions about Definition of Ready (DoR) and Definition of Done (DoD) in a Scrum team. People argue whether they’re part of Scrum and whether they’re necessary.

Code comprehension: Chunks and Beacons

We talk about making source code readable and it turns out that this isn’t just stylistic interpretation; there is actual research into this topic. As we read through the code, what we’re scanning for are chunks and beacons. Chunks and beacons are similar in that they’re both code fragments, yet they’re used differently.

Reinventing the wheel

I often find places where people have decided to re-implement some functionality that they could have just called from a library. Sometimes this is done because they honestly didn’t know the library call existed, and other times it’s because their pride insists that they could do it better.

Default Mode Network

For us to have those powerful insights or “aha” moments, we need to have a moment of brain pause. From a neuroscience perspective, that means that the Default Mode Network needs to be active.

Monkey Grassing

A common anti-pattern that I’ve seen is managers taking a highly effective team and scattering them across a larger number of teams in the hopes that they’ll take everything they know and make those new teams great. Then instead of having one great team, they’ll have many great teams.

Workplace stress and anxiety

A few days ago, I was sitting on my back deck working on the laptop. Out of the corner of my eye I saw some movement in front of me and I glanced up, expecting to see one of the many birds that are normally here. Instead I found myself staring at a young black bear that was walking across my lawn towards me.

The ugliest, nastiest, code

When teaching developers, I’ll often refer to “the ugliest, nastiest, part of your codebase that you’re all afraid to touch in case it breaks”. When I say that, everyone usually nods their heads. They know exactly what code I’m talking about because any long lived codebase has one. In fact they often even know who wrote that particular code, and its very common for that person to no longer be at the company.

Tracking metrics

Most companies I work with have a desire to track metrics for their development teams, and I support this. It’s hard to improve something we can’t see so metrics are a good first step as we seek to improve.

Why technical practices?

Most of the conversation about the agile technical practices tends to stay in the weeds. We talk about whether we should test before or after, whether we should be writing unit or acceptance tests, whether we should be mocking or not, whether PR’s are helpful or harmful. We have discussions back and forth about all of these topics and while they are good details, they sometimes obscure what’s really important.

When everything is a priority

I was asked what to do when the customer won’t prioritize the stories and insists that everything has to be done now. That brought back memories of the first time that had happened to me. This was a very long time ago and I can’t remember who had given me the idea to approach it this way.