Usually our team achieves 20 +/- 2 points in one two week sprint. The sprint we finished yesterday showed some amazing figures. We completed 37 story points. When we arrived at our retrospective we did not have a clear agenda so the retro was used to think why we had so successful sprint. Our scrum master used root cause analysis as a facilitation method. We came up with the following reasoning. Note, we run out of time, thus we did not get clear enough goals. I know that a retro should take all the time it needs but we are expecting some turbulence in our team composition so we decided to postpone some of the discussion to calmer times.
Here is the main content and questions answered during our retro.
Why do we normally not perform this well?
In this sprint we had no legacy code. Thus, we didn’t have any burdensome integration or system testing either. We were not afraid of breaking any existing code bases.
Why are afraid of breaking the existing code base?
It is too easy! Hard to maintain.
Why the code base is easy break and hard to maintain?
We build all new features on top of the old implementation. We have not done refactoring.
Why are we not refactoring?
It is too difficult to refactor. No internal documentation and not enough automated tests covering regression.
Why there is no internal documentation/automated regression tests?
There is no time. Documenting legacy software is also deemed as a boring task.
The most significant thing here is fear. The team is afraid to make changes. It is an obvious sign telling us that we should start putting more time into refactoring the legacy code base and writing more automated regression test suites. At least on the parts that we expect to change in the future. We are building our CI environment in all the time we can squeeze out of our sprints but as it turns out it is not enough.
In the last sprint we didn’t fear anything. We were extremely productive. Lesson learned: Get rid of fear.