Becoming agile without permission

Archive for the ‘Undercover’ Category

Testable Increments

As part of my Think Big, Act Small philosophy of agile software development, I prefer to implement things in small units that can be easily tested. I call this unit a testable increment.


A testable increment is small. An increment can be a new method, a single change to an existing method, the shell of a new class, anything that is a small change and can be tested. A single increment should be implemented, integrated, and tested within a single day. Several, dare I say dozens, of testable increments should be completed in a single day.

By being small, testable increments can be completed quickly. By working with testable increments we can see progress towards getting the bigger things done. It feels good to get things done and with testable increments we can get many things done in a day. Instead saying, “I worked on story A yesterday and I will work on story A tomorrow”, you can say, “Yesterday I completed the get/set methods and the main processing flow of the class. Today I will complete the three exception flows and add the special case creator methods.”


A testable increment is testable. If it cannot be tested, the quality of the change cannot be validated. By testing it, I have confidence that it works and I can build more things using it. Unit tests, especially automated unit tests, are invaluable, almost indispensable, for coding in testable increments. After I am done with the current testable increment, the automated tests become part of the regression tests that I run frequently to ensure that the current testable increment I am developing does not break all the previous testable increments.

In order to test a testable increment, good unit tests need to be created; good test data needs to be accumulated; and good test harnesses need to be built. While all of these things take time when you are just starting to work in testable increments, in the long run you will save time because what you build is reusable, extendable, and can significantly reduce the amount of time spent investigating and resolving anomalous behavior. Sometimes, if not frequently, the test harnesses can become good demonstration tools, especially for backend or API driven systems.


Faster Feedback

Creating and testing small things is faster than creating and testing big things. Because of the faster times, we get much faster feedback loops, which in turn allow us to debug and improve at a faster pace.

Faster Throughput

Smaller batch sizes move through the delivery flow faster than large batch sizes.

Easier Validation

Validating and repairing a few lines of code is easier than validating and repairing hundreds of lines of code. When something is wrong, you have a smaller space in which to find the error.

Better Design

Creating things as testable increments leads to better design. In order to test these small things, they have to be built-in such a way so that they are testable. This leads to components that have well-defined interfaces, are encapsulated, and are not as cohesive with other components.

Higher Possibility of Reuse

By making things smaller, they also have a higher possibility of reuse. A function that is contained in a single testable unit can be incorporated into other functions much easier than one that is in a module with several other functions or spread across several modules.

Complexity Isolation

By creating smaller things, you can isolate the complex aspects of a function into a couple of small complex things so that you have dozens of simple things and on a couple of complex things. In most cases, something that looks complex is only complex in a very limited space within the bigger function. Breaking it down into testable increments allows you to 1) get the simple stuff coded and tested independent of the complex stuff and, 2) isolate the complexity so that it does not affect the rest of the code. You can “stub out” the complex part while one part of the team is working to solve the hard problem. The rest of the team can continue creating the rest of the solution. When the complex part is ready, It can replace the “stub” with little or no impact on the rest of the solution. This approach also allows the team to try multiple solutions without a lot of code rework on the easy stuff.

Evolutionary Development

Testable increments allow the feature to “grow” over time. Starting with the most basic needs to get a feature working and then adding small enhancements to make it better, the software evolves rather than bursts into existence. As it evolves, we can evaluate what things are more valuable than others so that we can direct our attention towards the things that provide the most value.


Focus on delivering high quality software. Check-in defect free code that gets the job done. In most cases, the time spent producing good code the first time is less than the time spent later trying to fix it. Also, be embarrassed when you deliver code with defects. You professional reputation is at stake. Take great satisfaction in delivering error product. It feels good.

In the course of your work you will discover something that is not clear, is un- or under-specified, or just plain wrong. When you bring it to the attention of the team,  have suggestions and a recommendation of what should be done to resolve the issue. You will be seen as a creative, knowledgable problem solver and not someone that leaves the hard work for others.

In the daily standup, and other meetings and work sessions, speak up. The workplace can be a noisy place. Rooms are not set up to be good acoustic rooms. Speak up. Be heard.

While working on tasks is good, the goal is to complete the story.

I am not here to deliver requirements. I am here to deliver solutions.

I do not want to know what you require. I want to know what you need. I want to know what you want to achieve. I want to know what hurts, what are your problems. I want to know what are your objectives, your goals, your dreams.

I am not here to work for you. I am here to work with you. I am here to be your partner.

I am not here to follow a process. I am here to do the right thing. I am here to work with you, to work with people on the team, to work with anyone necessary to deliver the solution. I am here to do work that creates value, that delivers solutions.

I am not here to give you my time. I am here to give you value.

I am not here just to make a buck. I am here to change our world.

How do you keep track of the things you need to do?

How do know what to do next?

How does an agile team know?

An Agile team keeps a product backlog. The items (stories) on the backlog is prioritized. The team works on the things that are at the top of the list. They keep track of the things they need to do and they know what they need to do next.

We, as individual agilists, can do the same with the use of a personal backlog. We can keep the things that we, as individuals, need to keep track of for ourselves with this backlog. We can put anything we want on the backlog. It does not need to be stories or any other single thing. If we want, we do not have to show anyone our personal backlog. It is ours to manage as we see fit. Of course we should take into account the things we need to do according to any project plan that we are working to in our professional lives. But it can also contain all those things we, as agilists, know we should be doing. By using this personal backlog we can mix the things we must do with the things we know we should do and combine and mix and prioritize so that we can produce great results.

We can also mix personal things we need to do to this list. The most important thing we might need to do is call the doctor to make an appointment to have hat sore back checked out. Self help books have been telling us for decades to keep a to do list. By keeping a personal backlog we can apply the techniques we use to organize the work of a team to keep our own work in order.

Agile AWelcome to Agile Undercover, a place where we can explore the possibilities of becoming agile when the powers that be do not. Agile works best when the members of a team are agile. You can begin the process of becoming agile well before your organization does. In the process, you will learn how to create better software, how to build software the users want, and increase your productivity.