The Experiment Canvas is a simple means of planning, tracking, and responding to your experiments.
Simple Things
When I say simple, I don’t necessarily mean easy. And I certainly do not mean crude in form or incomplete. Simple indicates something that does not have superfluous parts or multiple responsibilities, is easy to understand, is as independent from the rest of the solution as possible, and meets a need as is.
Simple may not address all use cases, but it does address some use cases.
Over the past several years, as I’ve been helping teams and organizations improve their ability to deliver software products that are desirable, viable, and feasible, I have been experimenting with a Behavior Framework that has proven to be rather effective. And I’d like to share it with you in hopes that you find it useful and that you provide me feedback on your experiences with it.
My plan is to write a series of blog posts all related to the behaviors framework. Some of them will be about a specific behavior. Some of them will be about tools or techniques that help teams express one or more of the behaviors. Some of them will be my own experiences. And some will be damn near complete fiction.
I was asked to answer the Quora question, “Why is the Agile model the best”.
I’m not comfortable with the notion of “best”. Maybe “better”, “leading”, or “fit for purpose”. But most of this is so contextual and ephemeral, I tend to avoid the label “best”. That nit-pick aside…
Agility focuses on working in teams together with the customer to deliver high-quality working software in rapid cycles.
I was recently asked to engage in a debate over whether or not there are deadlines in agile. There were a few folks involved in the debate and the predominant perspective seemed to be that true agile efforts have no external deadlines - all deadlines are self-imposed by the team in the form of an iteration commitment or a scope negotiation with the Product Owner.
This is bunk.
The debate over comments in code is ongoing. At least once per year for the last 30 years, I’ve been involved in a discussion on the subject - often accidentally and reluctantly. To be honest, my perspective has changed over time. I used to comment every method, I used to comment any line of code that was “weird”, and I used to comment any blocks of code that were too complicated. Today, I rarely comment, if ever. Over time, I’ve come to realize that most comments are unnecessary.
I was recently asked to answer the somewhat vague question, “How do you interact with a large undocumented code base?”
One small step at a time.
A large code base can be overwhelming. Rather than trying to get to know the whole thing, I tend to focus on the problem at hand.
In a prior post, we talked about why we should manage WIP. We showed that we can use a future value calculation to give us an idea of how long it will take to complete multiple items.
While our future value calculation is both informative and interesting, it is not particularly useful beyond making the point that doing more at once takes more time. What we want to know is how does this materially impact our ability to make software. For that, we can look to a more simple (and useful) calculation based on Little’s Law
Having too much Work in Process, also known as Work in Progress (WIP), is a remarkably common issue. In my experience, management often encourages this behavior. I don’t know if it is the notion that we will get more done if we work on more things simultaneously. Or perhaps there is a fear we won’t get enough things done unless we work on several of them at once.
This blog post is inspired by another Quora question; “What metrics do you use to track Agile Efficiency?”
To begin with, I want to state that if I had to choose between efficient and effective, I’d choose effective. Efficiency is often about output (how many widgets per hour), whereas Effectiveness is often about outcome (was the purpose consistently met).
Agility is about responding to change. Efficiency is achieved by driving out variation. An over-focus on efficiency will lead down a path of standardization and control, making for a less agile system.
That said, given the question was specifically about agile efficiency, I’d look at a few things - Throughput, Cycle Time, Deployment Frequency, and Mean Time to Recovery.
Today’s offering is another post inspired by a question on Quora about when to refactor away duplicate code.
The specific question was, “What is the limit for duplicate code to start refactoring?”
I took this to mean, “How much duplication needs to exist before you should refactor it?”
And I’m not sure that’s really a great question. So I decided to start with clarifying what duplication needs to be cleaned up and then when might that happen.
For me, refactoring is when we change the implementation of a piece of code without changing the behavior. That’s the entire definition - Change the implementation, but not the behavior.
As a result, I will generally not refactor code unless it has a solid set of tests around it. If I see code that needs refactoring, but has insufficient tests, I will add character tests.
Now, metrics are not bad. But, they are often used in bad ways.
It might help to be aware of some of the side effects of mismanagement of metrics. From inadvertently creating behaviors that actively work against our best interest, to altering the meaning of the metric, mismanagement can do more harm than good.
Charles Goodhart is an economist and former advisor to the Bank of England. In 1975, Goodhart delivered two papers to a conference at the Reserve Bank of Australia. In those papers, Goodhart was discussing research and theory related to monetary policy and control in the United Kingdom. In the years leading up to 1975, existing monetary targets and the controls used to achieve the goals were no longer producing the results desired or expected. There had been what most considered to be evidence of a stable money demand in the United Kingdom. It was believed that the growth of money could be controlled through the setting of short-term interest rates. Higher interest rates correlated with lower money growth.
Goodhart warned, however, that policies and practices based on specific targets were flawed. Goodhart stated,
“Any statistical regularity will tend to collapse once pressure is placed upon it for control purposes.”
“Any statistical regularity will tend to collapse once pressure is placed upon it for control purposes.”
A common paraphrasing is, “When a measure becomes a target, it ceases to be a good measure.” When I talk about this, I tend to add, “And the target therefore no longer means what you think it does.”
Goodhart’s law is a critical piece of information when we think about metrics. No matter how tempting it might be, the moment we set a target for a measure, we’ve changed the system, thereby changing what the measurement means, thereby changing what the target means.
The lesson here is pretty simple. Don’t set targets for metrics. And please don’t give teams incentives towards targets if you do set them. I know. I know. Management 101 says this works. But, science says it doesn’t. Seriously. Setting targets and providing incentives for knowledge work lowers performance. Don’t do it.
Instead, provide guidelines to the teams. My favorite guideline for metrics is, “Monitor trending. Dig in when the trend changes and you aren’t absolutely certain why.”
This article is an excerpt from the book, “Escape Velocity”, available on LeanPub, Amazon, and elsewhere.
I stumbled upon a thread recently where the question was posed, “What are some common mistakes when refactoring code?”
The answers were interesting. The more I read, the more I realized that folks weren’t talking about the same thing. They were all saying “refactor”, but many were describing scenarios that sounded more like a rewrite rather than a refactor. This is not uncommon. I’ve encountered this on multiple forums, in slack discussions, in blog posts, and in actual human to human conversation (it happens).
