Agile Otter Blog

Code degrades because it is strongly anchored to the past. Instead of updating, refactoring, reorganising, and rearchitecting the code as we learn over the years, a system tends to keep its original shape, as developers shoehorn new features in with If/else statements. Imagine you are one of N people working individually in the codebase, each of you on a personally assigned task, not in groups. Any change one of you makes has a non-zero chance of causing a merge conflict for someone else. The larger the change, the greater the chance that some part of it will conflict. Multiply that by the number of people making changes. Remember: when separately-made changes conflict, the first person to merge sees no problems, but the second person to merge has to resolve the conflict.  People hate resolving merge conflicts. It is tedious and exacting work. You have to understand not only your own change, but the other person's, and figure out how to harmonise them. If you get on...

When I said  tickets have almost nothing to do with agile software development,   I was greeted with some very odd looks and incredulous "huh?" sounds.   So... Agile and stories In the beginning, the processes that were to eventually become agile were focused on delivering early and often, getting frequent feedback, and applying what they learned to the codebase so that they can continue developing early and often. To do this sustainably, it was necessary to use taste, judgment, and good craft so that the code remains ready to take on new knowledge and new functionality. To support that, XP chose to always work in groups (pairs, generally) and to have lot of tests to support refactoring, and lots of refactoring. So how does one keep track of what needs to be done - what customers have asked for? For this we had user stories (likely no relation to what you've seen called 'user stories'). The user stories were typically written on a sticky note or a card, since team...