This is an except from Al Shalloway’s upcoming book: Going Beyond Lean and Agile: Introducing FLEX – FLow for Enterprise Transformation. It is from a particularly important section called Teaching and Adoption.
I have never liked the common Scrum/SAFe approach of teaching select practices that are expected to be used as is. Their justification is that you need to understand how to use these practices before going beyond them. I have observed that while people need a set starting point they also need to understand why things are working. This creates learning opportunities from the start and enables a gradual improvement, or even, the transcendence of the practice.
Continue reading “The need to teach the principles that drive practices with the practices”
Specifying a workflow in #TDD means writing a test that says, “When entity A is called upon to accomplish a task, it must interact with entity B is the following way.” This is done when the interaction in question is part of a required workflow, and not simply an implementation decision that should be changeable.
The best way to accomplish this is to create a mock of entity B. Such a mock would “log” how it is used by entity A at test time, and then allow the test to examine the log and compare it to what should have happened. There are many ways to accomplish this. Continue reading “Specifying Workflows in TDD, Part 2: How”
The term “workflow” in this sense is meant to indicate the way two system elements interact when performing a task. Often these interactions themselves are not exposed outside the system, and so only their resulting behavior should be tested. This is as true in TDD as it is in traditional testing.
Most workflows are implementation details that developers should be able to change so long as the right behavior is still achieved. If the developers have a better idea, or technology improves, these changes should not break tests. Continue reading “Specifying Workflows in TDD, Part 1: Why”
Recently I wrote about the necessity in TDD of specifying both sides of a behavioral boundary, and its epsilon. This is important because we want a complete, detailed record of the critical business rules and other values in the system.
But there is another reason that this is important. It has to do with the notion of “a specification.” Continue reading “Specifying Boundaries in TDD: Part 2”
An excerpt from the preface of my book.
One important aspect of systems-thinking is that a system is not its components but is defined by the way these interact in a way that creates the behavior.
But the nature of these interactions are very complex – meaning that they can’t be predicted. Unforeseen events & interactions occur. And sometimes small mis-understandings cause huge side effects. This is a reflection that product development is both complex (unknowable in advance) and chaotic (small things can have big effects).
While I believe a deep understanding of complexity can be useful, very little is needed to attend to it. In the same way engineers were quite effective in building magnificent edifices (e.g., the Pyramids) without a full understanding of the science underneath them, it is possible to adjust the behavior of complex systems without understanding the exact results of proposed changes.
We mostly need is to know that 1) our changes may produce unexpected behavior and 2) we are embedded in a system where small errors can cause big changes. This requires quick feedback both about the actions we take and process improvements we try. Both agility of development and improvement of our methods is required.
Often a given behavior will change due to a certain condition: sometimes the system will behave one way, sometimes another. We call this kind of behavioral change a “boundary” and it should be specified as such in TDD.
For example, let’s say there is a business rule that dictates how a passed-in value should be handled. If the value is greater than 100, we decrease it by 10%; a kind of quantity discount. Continue reading “Specifying Boundaries in TDD: Part 1”
TDD is different from QA in many respects. Part of this involves the tests we choose to write. A case in point is the specification of public constants. Continue reading “Specifying Constants in TDD”
Flow-thinking is my latest thing. It’s looking at how to achieve value in the quickest way. This is not necessarily going faster – but mostly avoiding delays. I have observed that when I consult with clients I look for the following:
- hand offs (these delay value because they typically cause a degradation in understanding)
- delays in workflow (i.e., waiting for someone)
- interruptions to workflow (often caused by working on too many things)
- delays in feedback – a symptom is when work goes upstream (e.g., dev back to product owners)
- doing less valuable work than what could be worked on
- doing work manually that could be automated
As you minimize these you almost certainly will improve your value delivery. Quality typically goes up as well.
Because TDD is “test” driven development, people tend to think of TDD as “writing tests first.” In fact, TDD is not a testing activity per se. It is the creation of an executable specification prior to the creation of each system element. Unit tests are a very useful by-product of this process.
Because of this point of view, TDD dictates that different tests be written, or written differently than the QA point of view would lead us to do. There are points of overlap, but there are distinct differences, and this means that those new to TDD often miss certain important tests. Continue reading “Commonly Missing Tests in TDD”
Design patterns in software came from the work of the Gang of Four in the mid-1990’s. Similarly, TDD was first promoted around the same time in history as part of eXtreme Programming. Some have suggested that these two points of view stand in opposition to each other, saying
Design patterns are about up-front design, while TDD is about emerging design through the test-first process.
In truth, TDD and design patterns are highly synergistic. Understanding each of them contributes to your understanding of the other. Continue reading “TDD and Design Patterns”