Put in an Honest Day
While I am a big believer in pair programming I don’t believe that we should do it all the time. Pairing is exhausting! After a pair programming session, I am usually wiped out because I am working hard the whole time. I have someone looking over my shoulder analyzing everything that I do. That’s great …
Continue reading “Put in an Honest Day”
Read MoreSwap Roles Frequently
Another important technique for engaging developers in pair programming is to swap roles frequently. For new pairs who are just starting to work together, I recommend swapping roles every 2 to 20 minutes. For more established pairs who’ve worked together well, I recommend swapping roles every 20 to 60 minutes, although that could become much …
Continue reading “Swap Roles Frequently”
Read MoreEngage Driver and Navigator
Pair programming is really a very simple concept. It’s about writing code in groups of two or more people. The person currently at the keyboard is called the driver. The person or people who are not at the keyboard are called the navigator or navigators. The driver’s job is to deal with the minutia of …
Continue reading “Engage Driver and Navigator”
Read MoreTry It, You’ll Like It
When I was a kid growing up in the 1970s there was a television commercial for Alka-Seltzer where one guy is giving some other guy some scary-looking food and says, “Try it, you’ll like it.” That became the catchphrase for an entire generation and it meant not to pass judgment on something until you have …
Continue reading “Try It, You’ll Like It”
Read MoreWhy Practice Four: Collaborate
Practice four from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of your software, is Collaborate. You may wonder why a technical book on agile software development practices would include a practice called Collaborate but it turns out that even though we often don’t get formal training in school on …
Continue reading “Why Practice Four: Collaborate”
Read MoreFix Broken Builds Immediately
There are good crutches and bad crutches in life. Being addicted to using heroin is a bad crutch but being addicted to using a working build is a good, healthy crutch. This is the kind of crutch that I want to encourage. A healthy, well-maintained build is the heartbeat of a project. Removing friction from …
Continue reading “Fix Broken Builds Immediately”
Read MoreKeep Test Coverage Where it is Needed
I’m not a believer in having standards for test coverage. I know teams that require 60%, 70%, or 80% test coverage for their code. I don’t like having standards like this because different code has different requirements for testing. Straightforward code like getters and setters don’t really need to be tested. However, more complex code …
Continue reading “Keep Test Coverage Where it is Needed”
Read MoreWrite Testable Code
This has become my favorite subject because it turns out that testability, above nearly every other metrics, is important to strive for in developing software. All other code qualities seem to be a reflection of testability. When I say testable code what I mean is code that can be verified programmatically and in a very …
Continue reading “Write Testable Code”
Read MoreDefine Acceptance Criteria
“You are done, finished. Time to move on.” How I long to hear those words when I’m working on a task. Specifications can be squishy and it can be difficult sometimes to determine if the task is complete or not. Software developers don’t want to gold plate. The problem is that we often don’t know …
Continue reading “Define Acceptance Criteria”
Read MoreIntegrate Continuously
I believe that continuous integration is at the very heart of Agile software development. It allows us to go fast by going small. What I mean by this is that we learn by building in small increments that it’s more straightforward to create modular software that’s independently verifiable and by building smaller it gives us …
Continue reading “Integrate Continuously”
Read MoreOne-Click Builds End-to-End
We want to automate the build so that it is easy to use. We wanted to be so brain-dead simple to use that we use it all the time and we invoke the build whenever we make even a minor change to the system. This is how we get the most value from our build–when …
Continue reading “One-Click Builds End-to-End”
Read MoreUse Version Control for Everything
Version control is an important part of file management on every software development project I’ve ever worked on in the last two decades, regardless of the methodology. I’ve used Subversion and Git and several others in the process of building software. I always find it a bit surprising that other industries don’t use version control …
Continue reading “Use Version Control for Everything”
Read MoreWhy Practice 3: Integrate Continuously
Once we define what we want and build the smallest increment, we want to integrate it into our system as soon as possible so that we can see it working and get a true measure of our progress. Continuous integration is at the very heart of every Agile project and so I wanted to introduce …
Continue reading “Why Practice 3: Integrate Continuously”
Read MoreMeasure Efficiency of Feedback Loops
All of the things that I suggest that we measure on software development teams, from these current seven blog posts as well as other things that I’ve written, are all about ways of improving the efficiency of our software development process. We measure to understand and improve. Agile is all about getting and learning from …
Continue reading “Measure Efficiency of Feedback Loops”
Read MoreMeasure Costs of Not Delivering Features
In my last blog post, called Measure Customer Value of Features, I discuss the importance of seeing the value of features from the customer’s perspective. But there is another perspective that the customer can sometimes have that is also important for us to see–the cost of not delivering a feature. Sometimes we’re in time-critical situations …
Continue reading “Measure Costs of Not Delivering Features”
Read MoreMeasure Customer Value of Features
I always say that doing the right thing is far more important than doing the thing right, if we only have to choose one of them. Of course, we don’t we can choose to do both and that’s when software development is at its best. It doesn’t matter how elegant our code is or how …
Continue reading “Measure Customer Value of Features”
Read MoreMeasure Time to Detect Defects
When I was young I read a study by TRW done in the ‘60s that measured the cost of fixing a defect that was detected at different points in the development cycle. If the developer who wrote the defect found it immediately after writing it then we can assign one unit of effort for resolving …
Continue reading “Measure Time to Detect Defects”
Read MoreMeasure Defect Density
One of the things that you’re not going to find in this seven blog posts series on measuring the software development process is measuring velocity. I hate velocity because I’ve seen it misdirect managers and team members far more often than I’ve seen it provide valuable information. Rather than spend time teaching teams about story …
Continue reading “Measure Defect Density”
Read MoreMeasure Time Spent Coding
One of the most important metrics for the effectiveness of a software development team is one that I often find managers pay little attention to. The metric is how much time developers actually spend coding. If our goal as software developers is to produce features in software then our process has to support us by …
Continue reading “Measure Time Spent Coding”
Read MoreMeasure Time-to-Value
I am especially excited to share with you the next seven blog posts, which are based on seven strategies to measure value and software from my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) Of Your Software. You can find the original post that summarizes the seven strategies here https://tobeagile.com/seven-strategies-for-measuring-value-in-software/. I’m …
Continue reading “Measure Time-to-Value”
Read MoreWhy Practice 2: Build in Small Batches
In a lot of ways, I think that Practice 2–Build in Small Batches, from Beyond Legacy Code, is the core practice that made agile and Scrum great. I was breaking down my software projects into smaller pieces as early as the 1980s. I didn’t call it agile back then. In fact, I was a bit …
Continue reading “Why Practice 2: Build in Small Batches”
Read MoreSupport Refactoring
I’d like to conclude this series of blog posts on Seven Strategies for Product Owners with a final strategy that often gets overlooked on development teams but is vitally important: support refactoring. Sometimes Product Owners resist the team’s desire to refactor because they don’t get any new features after refactoring but often times refactoring is …
Continue reading “Support Refactoring”
Read More