How might the Dreyfus Model of Skills Acquisition apply to pair programming? Is it better to pair a novice and proficient or a novice and expert? Does novice to novice pairing make any sense at all? Doc explores these and other questions.
Metrics and Scrum
So there we were, at an agile conference. Well, not at the conference exactly. But at a bar very near to an agile conference.
A few patrons were talking agile stuff - like they do. And someone, as evidence in support of their stance that all metrics are evil, used the “But the Scrum Guide”, defense.
“But the Scrum Guide doesn’t prescribe any metrics. As a matter of fact, the word metric is not in the Scrum Guide. Not once.”
I found this claim dubious, so I checked it out.
All agile stand-up meetings must...
Refactoring: Introduce Parameter Object
A cluster of parameters often indicates an object in hiding. By creating a Parameter Object, you are making the code more flexible and you may discover a new object that was hiding in plain sight. In many cases, not only will you end up moving the parameters into a class, but you very well may discover that some of your code will move into the class as well. In this way, parameter clusters can be an indication we have a Single Responsibility Problem.
Agile is "the best"!
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.
Deadlines and Agility
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.
Comments rarely improve code
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.
Shippable Stories
Dealing with a large, undocumented codebase
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.
WIP, Throughput, and Little’s Law
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
Why Manage WIP?
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.
Measuring Agile Efficiency
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.