Many have gone through the agony of a Scrum transformation and noticed that revolution is hard. It requires a lot from the people involved but at the same time it is mostly adapting to new surroundings, to the new way of collaborating and making work visible.

Agile methods come with the implicit expectation that you start to implement at least some XP practices if you were not doing them before. From a developers perspective the most significant is TDD,  Test-Driven Development. It is a completely different way of building software compared to the ordinary implementation driven development where the developer thinks what this system has to do and starts to implement it. TDD starts from how is this system used and what is the expected outcome.

We admit in the very beginning that we know almost nothing about the system and its expected functionality and we try not to guess and implement for the future. Instead we drive our development from the user point of view – How is this system used? What roles do we have? You start writing out your most basic assumption of the system as a test. Focus on the immediate need which is to make the current test pass. Then we continue, test by test, digging out the behavior of the system. Tests are a just a catalyst to tease out the required functionality. Conveniently another widely used moniker for TDD is Test-Driven Design.

For many developers this represents such a major shift in approaching software development that the transformation is harder than the transformation to Scrum. Moving from waterfall to Scrum causes organizational pains and some individual pain due to the loss of familiarity and for the fear of the uncertainty. Breaking the status quo always causes discomfort. But moving from conventional (yes, I think that TDD is still the non-conventional development method) to Test-Driven development causes much more pain on individual level.

You have to make the change almost all by yourself. You may benefit from a coach presence and peer encouragement and gain momentum from them but in the end, it is yourself that has to change. You have to change the way you work in order to adapt TDD as an effective development method.Thus, I have come to the conclusion that

TDD fails and succeeds on individual level.

It is good if your organization tries to make TDD the norm, but at the same time it might not be possible. Some will work more efficiently the way they have been working so far and they can still develop good quality software. Don’t tell them how to do their job. Coercion always causes resistance and resistance makes the change so much harder that it might not be worth it. TDD must be introduced as another way of developing with the intent that this could improve your way of working. TDD can be beneficial to you. Again, leading by example might be the best way to introduce TDD to other developers. Thus, I have also come to the conclusion that

You can’t force TDD, it has to be consciously and actively adopted.

Post filed under Transformation and tagged , , .

2 Comments

  1. Very nice post. I particularly like the way you put it when you said, “We admit in the very beginning that we know almost nothing about the system and its expected functionality and we try not to guess and implement for the future.”

    As someone who coaches teams and teaches TDD I agree wholeheartedly with the notion that the change involved in TDD happens at the level of the individual programmer.

    What I try to instill is that Agile is about them too. When we introduce Scrum it really isn’t about them, but when we introduce TDD it’s all about them.

  2. Thanks Adam!

    I also think that this is a very good post. As a rookie writer I managed to surprised positively myself with it :)

Leave a Reply

Your email address will not be published. Required fields are marked *