The Core Four

If you are having trouble with your agile software development process, here’s something to consider. I would like to introduce The Core Four. These are the four most basic practices of an agile software development team. These practices have proven to work well together to form a solid agile software engineering practice. It has also become evident that it is difficult to maintain a sustainable agile practice without them. Having these four practices in place gives you a return on your investment in agile software development and a solid foundation for other valuable and important agile practices.

I think that I first saw these practices together in a graphical representation of Extreme Programming by Ron Jefferies in his article: “What is Extreme Programming?” I didn’t realize how important it would become later, though. Extreme Programming recommends a lot more practices than four and they are all great, but I could sense from my own experience that I didn’t have to start with all of the practices in order to get some of the benefits. It was also pretty obvious that I couldn’t be successful if I left some of them behind. It wasn’t until Uncle Bob Martin explained in his video: “Agile Programming, Clean Code, Episode 49” that Jefferies had documented an inner circle of practices in his illustration Martin called: “The Agile Circle of Life”. What we, as agile practitioners are discovering is that without these central practices, it’s very difficult, if not impossible, to sustainably support the others, yet these are the very practices that are being overlooked by many teams that call themselves “agile.”

What are the Core Four? They are:

  • Test Driven Development
  • Refactoring
  • Simple Design
  • Pair Programming

Let’s take a quick tour of the benefits of these practices.

Test Driven Development

There has been a great deal of debate about Test Driven Development over the years. Some very smart people are actually against the practice. Even so, the practice is still the basis for good software engineering to many experienced developers like myself. I have not been able to find an adequate replacement for it. It solves so many of software development’s most challenging problems.

One of software’s biggest problems is ambiguous requirements. Test driven development helps to remove this ambiguity early by forcing the requirements to be testable. Is your team having trouble getting the requirements? Is your team building the wrong thing? TDD could create a huge improvement in this area.

TDD is also a way of permanently documenting your software requirements. Unlike classical written requirements documents, tests are executable and must stay accurate. Are your requirements documents useful? Do they represent the system that is actually in place? TDD makes a big difference here.

Test Driven Development also stops your software from leaking requirements. That’s when an “upgrade” removes or corrupts previously enjoyed features. How many times have you upgraded an app only to find that you lost a feature you really liked. It’s happened a lot to me and it really makes you feel like the developers don’t care. It also makes it seem like someone lied to you when they said they had an “upgrade” available. We don’t want to be doing that to our users and a complete, working set of tests helps to stop feature leaks between releases.

If you want to learn more about TDD from the one who brought the practice to light, check out my affiliate link to: “Test-Driven Development By Example” by Kent Beck.


I think of refactoring as “agile architecture” that’s because I think that the most productive architect is one that makes architecture for a product that will be used. When you refactor, you are developing architecture based on code that is already being used.

In my practice, I discovered that about 90% of refactoring is merely an attempt to remove code duplication. It was one of the biggest surprises in my career. By merely trying to remove duplication, I forced myself into using well-known and loved patterns. The main difference between just employing patterns and refactoring to them, was that these patterns were actually proven to be necessary. Back in the 1990’s, during the days of patternmania, we tended to use patterns whether we needed them or not. The move to agile development, primarily by way of Extreme Programming, lead to a more practical use of patterns and refactoring was an underlying hero.

Refactoring can also be considered to be the software fountain of youth. Teams that are vigilant at the practice, have code that looks very new. It appears that the code was just typed out in a few minutes yesterday, even if it is many years old! This is something you almost need to experience to believe. A big contributor to this, other than the removal of duplication, is the basic effort to rename things. As understanding of the system matures, old names are no longer relevant and can be replaced with the more obviously fitting ones. Another big benefit is that refactoring makes the next core practice possible.

If you want to learn more about refactoring, make sure you check out the definitive work by Martin Fowler. Here’s my affiliate link to it: “Refactoring” by Martin Fowler.

Simple Design

A simple design is one that developers who read the code think is obvious. Simple designs like these are not easy to achieve, though. Rarely are our first designs adequate because we have so much to learn about what the system will have to do. A fundamental element of agile software design is to make the system as simple as possible and that usually means that we don’t do things like add code that we think we might need in the future. Because we refactor the system frequently, we don’t need to do that. We can just add the code we need when we need it and not sooner.

The opposite is also true. When code is no longer needed, we should just remove it. We shouldn’t leave code hanging around just because we might need to add it back in again. We need to rely on our version control systems in order to retrieve old code and keep our code simple.

Usually, removing duplication makes code simpler, but it’s also good to remember that there is a time to duplicate. You can imagine how ridiculous it would be to try to limit the letter “s” to as few places in a sentence as possible. You could try to write your sentences using a crossword style, but that would be harder to read, not easier. When it comes to communication, duplication can actually be a helpful thing. If duplication makes the system easier to read and understand, then it overrides the “don’t repeat yourself” rule.

Simple design is pretty subjective. What seems simple to me may seem pretty difficult to you and vice versa. I may also miss an opportunity to refactor. In fact, it’s pretty easy to make an important and costly mistake anywhere in the agile process. That’s one thing that makes the next core practice so important.

Pair Programming

This may be one of the most difficult agile software development practices to start but without it, it’s difficult to consider yourself to be a truly agile development team. How do you know you really are an agile development team if you don’t know whether or not your team members are using agile practices? Worse that that, how can you really be a team if you don’t ever work together on things? How can you teach a new member of the team what they need to know in order to be a good contributor to the project?

I think that the main reason that Extreme Programming became so popular so quickly, was because pair programming was a fundamental practice of the method. It tends to spread and balance out the knowledge on the team. There will still be experts, but there will also be those who will learn from those experts.

An important part of having an agile process is the ability to be predictable. The stakeholders begin to rely on the team’s velocity. It’s pretty obvious that this consistency depends on developers, but what if the developer of a key part of the code is sick or on vacation? An agile team should be able to continue to go at the same velocity even when a developer isn’t available for part of the iteration or sprint. When the developers work together, expertise is spread around. Even if the best person for the job isn’t available, someone else knows enough to get through it. Pair programming makes the team stronger by reducing the single points of failure caused by programmers working alone.

Pair programming ensures that all code is reviewed. Studies have shown that peer review processes reduce error. Other studies have shown that error produces late projects. Even though it seems like you will go slower when two programmers work on the same thing, it is logical to assume that this is not the case. When errors are reduced, software gets done faster. Even non-agile developers have learned to do peer-reviews. Pair programming makes the practice efficient by keeping the team involved in the code on a day-to-day basis. Errors are found quickly and are less likely to be missed and found later when they are more expensive to fix.

If you want to do a deep dive into this important practice, here’s my affiliate link to a book I highly recommend: “Pair Programming Illuminated” by Laurie Williams and Robert Kessler.

Returning to the Core

It’s one thing to write and talk about these practices, and quite another to actually do them. That’s my challenge to you as a professing agile practitioner. These practices are far from new. They’ve been proven over and over in my experience and in the experience of many other developers over the last 20 years or so. Don’t be satisfied with an inadequate trial of agile software development. Make sure that you give The Core Four a try before assuming that you have failed. I think you will be very happy you did.

Choosing Software Engineers as Scrum Masters

One of the surprising things that I have discovered recently, is that some companies that are trying to hire Scrum Masters without software engineering experience.  This is not an advisable move according to Scrum’s creators.

Ken Schwaber, one of the creators of the Scrum process, addressed this problem in the first book on Scrum.  Here’s what he says along with his co-author:

“As Scrum Master, I make judgments on a team’s engineering practices (or lack of practices). The best Scrum Masters are also good engineers. The Scrum Master helps the team improve its engineering practices, just as a coach teaches a team to play better.”

Ken Schwaber, Mike Beedle, “Agile Software Development with Scrum“, Chapter 4, Section 4.1.3

Because of this coaching responsibility that Scrum Masters naturally have, it’s important that they are aware of good engineering principles.  Without this knowledge, a good Scrum management team could still fail to produce quality software on time.  In this same book, the authors explain that Scrum is just a wrapper around good software engineering:

“If engineering practices are candy bars, then Scrum is a candy bar wrapper.  That is to say that Scrum is superimposed on and encapsulates whatever engineering practices already exist.”

Ken Schwaber, Mike Beedle, “Agile Software Development with Scrum“, Chapter 4, Section 4.1

It’s also good to note that you don’t have to be an engineer to be a good Scrum Master.  It is possible to find the engineering help you need to coach an engineering team with their internal processes.  The main problem is when a non-engineer starts directing the behavior of engineers without any training.  They are prone to make the same mistakes the industry made that lead to the creation of agile methods.  Although it is possible to recover from bad advice using Scrum, it could be a significant waste and one that could be avoided by having a knowledgeable person coaching the engineering team.

There are dangers in hiring the wrong engineers as a Scrum Masters too.  If the engineers are not an good communicators, they may not be able to communicate their knowledge to the team or to project stakeholders.  The Scrum Master position is a coaching position.  The engineer who takes this position must not only be a good engineer, but also a good teacher.

It’s also important that the engineers who take on the Scrum Master role be good at separating themselves from the team during a sprint.  If the team is to be self-directed, good Scrum Masters must know the difference between coaching and control.  The team must still be given the freedom to be self-directed during the course of a sprint.

If you are doing “Scrum” but it isn’t working very well, make sure that your engineering team is following good agile engineering practices.  It may be that that the Scrum process is not to blame at all. It’s important to understand that good Scrum management must also be able to coach an engineering team about good engineering practices that work with Scrum.