My friends know me to be skeptical of “studies” about software development techniques. The main reason for my skepticism is that such studies are rarely undertaken by people who have any understanding of what they are studying. They combine data points from different sets of observations as a way to try and accumulate sufficient information to make charts and trend lines, but often the data points aren’t consistent enough for the aggregated data to be meaningful. I wonder whether many studies of programming techniques are based on enough observations to be meaningful, and whether the researchers’ analysis of the results is based on any direct knowledge of the subject at hand.
Month: April 2019
Doing Scrum Perfectly
Sometimes I use the phrase, “novice Scrum team,” to describe a team that’s new to Scrum, still settling into the routine of sprints, and still getting a handle on the underlying values of Scrum. Often, these teams are in the process of adopting unfamiliar technical practices like test-driven development and unfamiliar processes like continuous integration, and learning to collaborate across roles that had been sequestered in functional silos before the cross-functional Scrum team was established. They’re learning a lot of new things at the same time.
Quite a few people appear puzzled or bemused by the phrase. It occurs to me they may think of Scrum as a fixed set of rules to follow, rather than as a starting point for ongoing improvement. You either follow the rules or you don’t. There’s no concept of “novice Scrum team” because there’s no concept of ongoing improvement: When you follow the rules of Scrum, you’re doing Scrum. You either do Scrum or you don’t. That’s all there is.
TDD: Let the Tests Drive
As long as we write tests, what’s the big deal about writing them “first” rather than “last?” Let’s explore that question.
The video looks a lot better on YouTube than it does here. Try https://youtu.be/Bf89rd0o5-0.
https://youtu.be/W1-IjCbzKAs
When we’re conscientious about writing examples before production code, and we drive all our production code from executable examples, we can enjoy several benefits:
- Helps us remember details and not overlook things
- Helps us avoid over-engineering or going too far with our design
- Helps us keep the design simple
- Provides a safety net for experimenting with different implementations
- Provides a safety net for refactoring
- Gives us frequent positive feedback so we don’t feel beaten down at the end of the day
- Provides executable low-level documentation of everything the application does
- Makes it easier to locate the source of bugs; keeps us out of the debugger for the most part
- Creates a regression test suite as a side-effect of writing the examples that drive the design
- Equally useful for emergent design and up-front design, and for greenfield development as well as enhancements and bug fixes