Collaborate

Engage 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 …

Read More
Collaborate

Try 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 …

Read More
Collaborate

Why 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 …

Read More
Integrate Continuously

Fix 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 …

Read More
Integrate Continuously

Keep 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 …

Read More
Integrate Continuously

Write 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 …

Read More
Integrate Continuously

Define 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 …

Read More
Integrate Continuously

Integrate 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 …

Read More
Integrate Continuously

One-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 …

Read More
Integrate Continuously

Use 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 …

Read More
Integrate Continuously

Why 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 …

Read More
Build in Small Batches

Measure 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 …

Read More
Build in Small Batches

Measure 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 …

Read More
Build in Small Batches

Measure 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 …

Read More
Build in Small Batches

Measure 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 …

Read More
Build in Small Batches

Measure 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 …

Read More
Build in Small Batches

Measure 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 …

Read More
Build in Small Batches

Measure 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 …

Read More
Build in Small Batches

Why 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 …

Read More
Say What, Why, and for Whom Before How

Support 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 …

Read More
Say What, Why, and for Whom Before How

Remove Dependencies

One key characteristic of great Product Owners is that they help remove dependencies whenever the team encounters them. Dependencies can show up in many different forms. Our team may need some code from another team in our company, but the other team hasn’t yet built it for us. Or one feature that we may have …

Read More
Say What, Why, and for Whom Before How

Answer Questions Quickly

One of the most important skills for a Product Owner is to answer questions quickly, which means that they have to really know their product and understand WHY it’s needed, WHAT’s needed, and WHO it’s for. Developers have to dive deep when they’re writing software and they come up with questions that non-developers may never …

Read More