February 2019 – Net Objectives Thoughts

TDD and Code Coverage

It’s not unusual these days for development organizations to adopt a code coverage requirement. This is usually expressed as a percentage: at least X% of all code developed must be covered by tests.

Measurement tools are used as a process gate, where the team must achieve this minimum coverage level before code can be checked in. This is pointless and may be dangerously misleading. Code coverage tools can only measure how many lines of code are executed by tests, but not what the test do with the results of that execution. Continue reading “TDD and Code Coverage”

Using the Theory of Flow to Illustrate Impediments in Two Hours Instead of Two Weeks

Simply put, the Theory of Flow focuses on two areas:

The steps it takes from conception of an idea until value is realized from it
Reducing the Cost of Delay, the revenue or opportunity lost because of delays in realizing value

Reducing Cost of Delay (CoD) is essential to the goal of business agility, the quick realization of value predictably, sustainably and with high quality. Continue reading “Using the Theory of Flow to Illustrate Impediments in Two Hours Instead of Two Weeks”

TDD Tells Us What is not Known

You cannot meaningfully test that which you do not adequately understand. The time to find that out is before you start development. TDD tells us what we do not know. Sometimes, it tells us what our stakeholders don’t realize they also don’t know.

Imagine you are developing the software for a casino’s poker slot machine (loosely based on a real case). Part of the behavior needed is to shuffle the “cards”, mixing them up into a new order. That would be the stated requirement. If we try to write a test about this, we realize that this is not nearly detailed enough. What is meant by a “new order”? How new? How will we know when the shuffling is adequate? Are there any regulatory requirements about this? Industry standards? Not being casino experts, the developers probably don’t know and would ask the customer. The customer might realize that they aren’t clear themselves.

Testing something requires far more rigor than most people apply to their businesses, and that means the development team that does TDD not only finds good questions to ask, but can also help the customer to more fully understand their own business domain. At times, this leads them to realize even more business value than they knew they wanted.

How Much Testing is Enough?

A typical question those adopting TDD ask is: How much testing is enough? Or, put another way, does everything really need to be tested? How do you decide what to test and what not to test?

It’s an interesting question, but I prefer to address it this way: everything will be tested. The real question is, by whom? Will it be you, or someone else? Continue reading “How Much Testing is Enough?”

What I Think About Scrum

First of all, I like Scrum. I think it can be a great framework when used in the right place. But I also think it must be taught as a tool in your toolbox, not an end in and of itself. This means initial training of Scrum should include more of the flow model (eliminating delays in workflow, feedback and using information) on which it is based. Test-first methods should also be incorporated into this training. This combination allows for teams to avoid most of the pitfalls teams new to Scrum face. I also believe one should look to see if Scrum or Kanban is better for a particular team (or something in between). See first comment for how I do this.

See Why Agile Coaches Need to Know Both Scrum and Kanban.

Continue reading “What I Think About Scrum”

Why Being Explicit in Workflow is Useful: Case Study, Scrum Based on Lean Flow

Scrum is a lightweight framework that encourages correct action through performing its ceremonies and practices. While that is great in theory, the lack of the “why” of the ceremonies often has them be not followed.

Consider the “sprint” in Scrum. According to the Scrum Guide, “The heart of Scrum is a Sprint, a time-box of one month or less during which a ‘Done,’ usable, and potentially releasable product increment is created.”

It implies the need to start and finish stories in the same iteration. In other words, one of its objectives is to have a short time between the beginning of a story until it is completed. Here is what this provides. Continue reading “Why Being Explicit in Workflow is Useful: Case Study, Scrum Based on Lean Flow”

The Multiple Values of Doing TDD

Tests pay you back for your effort:

When you are writing them. They help you to understand the problem you are attempting to solve, they reveal gaps in your knowledge, and lead you to useful questions.
When they fail. They inform you of a defect, and if written well, specifically where that defect is.
When they pass. When you are enhancing or refactoring the system, tests passing confirms that you are only making the changes you intend to make.
When you read them later. Tests capture knowledge that might otherwise be lost. And their accuracy can be instantly confirmed at any time in the future, by running them.

TDD does not cause extra work. It is just the opposite; it is one effort that provides value in multiple ways.

Time to Say Goodbye to Empirical Process Control

Creating software has several aspects to it.

Deciding what to create
How creating new software affects existing software
How people work with each other
The process being used to build it

Although all of this creates a very complex process, only the first three are fairly unpredictable, the fourth is not.

Continue reading “Time to Say Goodbye to Empirical Process Control”

Types of Processes (by Don Reinertsen)

Note: This was originally published on the Net Objectives blog on October 6, 2009.

In May 2009, there were some discussions on the Kanban Dev group about types of processes. The dialog that resulted is an important part of the Lean thought process. It is helpful to reproduce it here. The discussion on the thread about quality and pressure helped me to thinking more deeply on what I consider an important issue: Can effective software development be defined.
Continue reading “Types of Processes (by Don Reinertsen)”

Tests are Reactive: They Pass or They Fail

A test reacts to everything currently in scope that it does not control. Ideally, that should be only one thing. Everything else in scope must be controlled by the test, or it may react to the wrong thing and give misleading results.

For example, if a production entity uses a service call as part of its implementation, and the service being called is not what the test is testing, then that call must be controlled by the test because it is in scope.

This is a major reason to use a mock object.