When TDD was first suggested, there were many who were dubious about the wisdom of having developers write tests of their own code. Among the objections raised was that developers will slow down if you burden them with new tasks, namely writing the tests as well as the code.
This seems logical. Give someone more to do, and they will take longer to do it. But the truth is that TDD actually increases velocity once the team gets over the initial learning curve.
How can this be? This is true for three reasons. Continue reading “TDD Yields Velocity”
TDD is a process that provides constant confirmation to the development team.
Writing the tests up-front confirms that there is sufficient understanding of requirements so that they can be expressed in the rigorous form of a unit test. Alternately, it reveals that this understanding has gaps and reveals questions that need to be answered.
The quality of the test mirrors the quality of the system, and so if “good” tests (as I have defined them) can be written, this is confirmation of a good design. Continue reading “TDD Yields Confidence”
This was originally published in June, 2014
|I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contrivings as constituting the only means for solving a given problem. Buckminster Fuller
Continue reading “The Real Reason the “Agile Wars” Are Destructive – It’s Not What You Think”
This was originally published May, 2017
Note: This blog assumes the reader understands the basic roles and practices of Scrum.
Scrum suggests that the way to improve a team’s workflow and the organization within which it works is to remove impediments to its core roles (product owner, team, Scrum Master) and practices (cross-functional teams, daily standups, and using time-boxing for work, demos and building backlogs). It takes an inspect and adapt approach that requires little understanding of the underlying laws of software development other than an acknowledgement that reducing the time for feedback is essential and that small batches are better than large ones.
Continue reading “Why Shu Ha Ri and Scrum Can Make for a Dangerous Combination”
I had hoped they’d fix the underlying flaws of SAFe but am now convinced that will not happen. Here’s why we only help folks doing SAFe but don’t train it anymore:
1) SAFe’s based on levels & not on the value stream. All companies need the concepts in the top levels (e.g., strategies) but these are overly complex due to factors described in the rest of this list so SAFe’s method to achieve them is unusable for many organizations
2) SAFe has tacked concepts together by focusing on roles & artifacts while misusing/redefining previously useful terms
3) SAFe does not have a concise, well-defined concept of the smallest increment of value used to extend an existing product. MVPs are for new products & epics are too large. This makes prioritization across teams difficult
4) there is no simple way to have the org align around value
5) the Lean principles mentioned are used in a superficial way
The result is a pre-defined, over-complicated solution. SAFe can be a massive improvement for companies whose development group is blocked & it provides low cost training materials. But it will not help achieve true agility except when guided by a real expert who goes SAFe to achieve that. SAFe is often used to gain consistency not agility.
These are not idle comments. If you are using SAFe and finding value at the program level but want to improve its higher levels, you will find value in Part IV: Using FLEX to both enhance and simplify SAFe