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 … Continue reading "The Purpose of an Assessment"

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 … Continue reading "Understanding the Concept of Testability: A Worthwhile Remembrance"

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 … Continue reading "A Framework for Thinking About Risk"

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 … Continue reading "TDD Makes Developers and Testers into Valued Colleagues"

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 … Continue reading "Intermediary Practices vs. Practices That Work Directly on Flow"

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 … Continue reading "TDD Provides Value to Everyone in the Development Process"

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 … Continue reading "Figuring Out the Test You Missed is Job One"

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 … Continue reading "Going Beyond Lean and Agile: Introducing FLEX (FLow for Enterprise Transformation)"

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 … Continue reading "TDD and Code Coverage"

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 … Continue reading "Using the Theory of Flow to Illustrate Impediments in Two Hours Instead of Two Weeks"