Month: February 2019

TDD and Encapsulation

The type and nature of the tests that you write in TDD helps you to understand how strongly your system is encapsulated.

Everything the system must do, and yet might not, needs a test. Here, “must do” comes from your stakeholders’ requirements, and is therefore connected to business value. The more your tests are about these issues, the clearer your specification will be.

Everything the system must not do, and yet might, needs a test. Here, “might” means that the unwanted behavior is possible, that it cannot not prevented in some way. Anything that the compiler, linker, etc will catch and report is prevented and does not require a test. If such tests were written, it would be impossible for them to fail. Continue reading “TDD and Encapsulation”

TDD and the Single Responsibility Principle

I mentioned earlier that TDD offers qualitative measurements about production code, namely that a large average fixture size can be used to measure relative coupling in a system. Similarly, tests can reveal whether, and to the extent, that the Single Responsibility Principle has been adhered to.

The Single Responsibility Principle states that every class in a design should have a single responsibility. It is an aspect of cohesion in design. The reason that tests will reveal when this principle has been violated has to do with the number of tests needed for that class’ behavior. Continue reading “TDD and the Single Responsibility Principle”

The Purpose of an Assessment

Assessments are not about where you are. They are about where you want to go. By seeing where you are and what challenges you are having a roadmap for improvement can be made more effectively.

Assessing can be done in several ways. The most popular Agile method is to see how well the company is doing from the perspective of the approach they are taking. For example, a common assessment for Scrum is the Nokia test which specifies how well teams are doing Scrum. SAFe® has its own assessments. But consider these as assessments in how well a framework is being adopted, not how well the company is delivering value. We have found that focusing on the work, not the framework, is a better approach.

Because FLEX is based on a model of flow, it can be used to see where an organization is having troubles with achieving flow; that is, performing its work with few hand-offs, turmoil, delays, and rework. Reducing these helps achieve business agility. It is more effective to attend to how work is being delayed or how extra work is being created than how well a practice is being followed. Therefore, an assessment should focus on the value stream and what is impeding it.


For more, see Using FLEX to Perform an Assessment for Small-Scale Organizations

Understanding the Concept of Testability: A Worthwhile Remembrance

I was first introduced to XP in 1999. I remember getting into an avid discussion on the XP user group about TDD. I could never remember what it stood for, often calling it “Test-Driven Design” because I recognized that TDD helped people design their code when using it. This was consistent with the first mantra of design patterns, “Design to the behavior of objects.” Focusing on behavior informed design.

I also remember getting some flack for it. People said things like, “tests couldn’t possibly inform design.” My opinion was, and is, that they not only could they, but they should. Continue reading “Understanding the Concept of Testability: A Worthwhile Remembrance”

A Framework for Thinking About Risk

In TDD, there are always more potential scenarios to test, other than the “happy path” of desirable behavior. We need a way to decide how far to go.

This is often a question of risk assessment. Having a framework for thinking about risk can be useful. Consider this framework that has two dimensions: Likelihood and severity. Crossing these produces a four-quadrant matrix. Continue reading “A Framework for Thinking About Risk”

TDD Makes Developers and Testers into Valued Colleagues

In many large organizations there is a kind of wall between development and testing. Developers do their work and “throw it over the wall” to be tested. This can create negative attitudes on both sides.

Developers see testers either as a source of no information (“it works? Yeah we knew that”) or bad news (“there are bugs to find and fix, ugh”). Testers are adversaries to overcome before developers can be said to have succeeded.

Testers see developers as a source of hard work, and code that must be wrestled with. Often testing lags hopelessly behind development and because of this testers see developers as a source of a never-ending avalanche of work.
Continue reading “TDD Makes Developers and Testers into Valued Colleagues”

Intermediary Practices vs. Practices That Work Directly on Flow

An intermediary practice is a practice that works indirectly on what you are trying to achieve. Before discussing examples and the risks of intermediary patterns, let’s look at some of the things needed to achieve flow (realizing value without delay):

  • Removing delays in workflow (hand-offs and waiting for others), feedback, learning, and between getting and using information
  • Manual testing
  • Interruptions
  • Technical debt

By working directly on these, here is what you would have. Continue reading “Intermediary Practices vs. Practices That Work Directly on Flow”

TDD Provides Value to Everyone in the Development Process

Project Managers and Product Owners are sometimes dubious about the development team doing TDD. They are concerned that the team will slow down because they’ve been burdened with additional work, and that developers might “game” the system with bogus tests to satisfy the process. Also, it seems like a nonsensical idea to write a test for something before that thing exists.

All of these concerns are addressed by the observation that, despite its name, TDD is not really a testing activity. The “tests” that are written in TDD are actually the specification of the system.

The effects of this shift in thinking are profound. Continue reading “TDD Provides Value to Everyone in the Development Process”

Figuring Out the Test You Missed is Job One

Defects can either be prevented or detected.

Let’s say you write a method in C# that takes, as its parameter, one of the nine players on a baseball team.

If you decide to make that parameter an integer (1 is the pitcher, 2 is the catcher, and so forth), then the code will still compile if a number greater than 9, or less than 1, is passed into the method. You will have to take some action in the code if that happens: correct the data, throw an exception, something along those lines. This code would be written to “detect” the defect, and would be driven from a failing test in TDD.

On the other hand, we would not have to allow for the possibility that someone will pass a non-integer, like 1.5, into the method, because the compiler will not allow this. Anything the compiler, linker, IDE, etc. will not allow is considered a “prevented” defect. Continue reading “Figuring Out the Test You Missed is Job One”

Going Beyond Lean and Agile: Introducing FLEX (FLow for Enterprise Transformation)

I’ve created a new design for my book and am pretty excited about it. There are five parts to it:

  • Part 1: Workbook: understanding what’s required for flow in your organization
  • Part 2: Workbook: Using FLEX to transform your organization
  • Part 3: Topics in depth
  • Part 4: Using FLEX w/SAFe
  • Part 5: Resources on the Net Objectives Portal

The first two parts cover the basics of FLEX. They present what the effective enterprise of the future looks like, giving a vision for the transformation. They are designed as workbooks to guide readers via a way to learn by doing. They are also relatively short so they represent a quick overview of the entire approach.

Part 3 provides an in-depth explanation of the topics used in the first parts. Part 4 discusses how to take advantage of FLEX’s Lean portfolio & prod management approach for those using SAFe.

The last part of the book is online, providing the latest ideas and practices we are coming up with.

If you are looking for a more effective approach than either SAFe or LeSS, I invite you both to look at the book as it is uploaded. If you are interested in using it to help with your own adoption, let me know as I am looking to work with a few people while it is being written


To see the book, go to Going Beyond Lean and Agile: Introducing FLEX (FLow for Enterprise Transformation) (online book)