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.
Why we branch the code
Branching is a great workaround for problems elsewhere in the system that we are unable or unwilling to fix.
Outcome bias (Resulting)
When I first read How to Decide: Simple Tools for Making Better Choices by Annie Duke, one of my biggest aha moments was from what she calls Resulting and is more formally known as Outcome Bias.
Flow Efficiency
Flow efficiency (sometimes called Cycle Efficiency) is a metric that gives us a sense of how much time work is waiting. A flow efficiency of 100% would indicate that we are adding value to the work item for the entire time it’s in progress. 50% would imply that half the time we’re working on it and half the time the work is just waiting.
Rapid feedback
One of the key things we’re trying to get with Agile is faster and more effective feedback so that we can make better decisions. This extends into to the technical practices just as much as it does in our meetings and processes.