“Change is the law of life. And those who look only to the past or present are certain to miss the future”
J. F. Kennedy
This observation also works for software development, as product requirements can and do change. That is why XP programming, the agile approach, Scrum and all the rest were created: earlier models were inefficient in dealing with change.
The Horizon of Predictability
You can’t reliably predict the future. And the further you try to move on the time scale, the worse you end up in this endeavor. Beyond some point, it is simply impossible. In addition, you can’t assume that the client will know what he really wants, even if he is trying. And you can’t even assume he will try. Just deal with that. I know the feeling of building a beautiful and clean model and then watching it falling apart, piece by piece, after several changes to the original notion of what we were planning to build. Of course, you need to have some idea to start with, but it will change and there is nothing you can do about that aside from adapting.
There are people and organizations who desperately cling to “the old ways”, resist change and build fences around “their” playgrounds. The main reason is that change is hard. Change is painful and risky. It’s risky because the organization and the environment are not built around dealing with change. Enter the idea of Continuous Integration and Deployment. You should strive to shape your system and environment to be able to deploy to production at the push of the button as often as you want to. If it’s easy, it won’t be painful or scary. Don’t tolerate grand releases of piles of features everyone is scared to death of. Getting rid of them usually requires an initial commitment of time and money as well as deep shifts in the mindset of some people and usually, these people are “higher up” than you. Also, in order to respond to changes quickly at the code level, you need to take care of the technical debt. Unattended, it will slowly turn your sprint into a crawl. This is dangerous because it won’t happen overnight. It will creep in slowly, week by week, month by month and choke you gradually.
If change is painful, try to bend your organization to make it easy. If you can’t, and you don’t like it, consider leaving. Don’t tilt at windmills, you did your part.
What about changing (read: extending) sprint content then? What if a manager storms into your room two days before the end of a sprint and wants you to include something special, something more in the release? You look at the change and you know it’s too risky to do. Everything is almost done; the last finishing touches are underway, and now you are being asked to dig back in, break stuff, and you doubt you can even code it in time, let alone test it functionally in any decent way. You say all that and the manager responds “what about embracing the change that you talk about so much?”.
Well, regular sprints are there for a reason. Because they are effective in the long run. Sure, a Product Owner can decide to terminate the sprint and start planning a new one, but this should be an emergency, not a habit. If your company happens to earn twice its usual yearly income provided you release the feature in two days, it might be worth putting in the additional effort, staying late, ordering pizza, getting in a lot of energy drinks, thinking hard and generally taking the bull by the horns – even entirely screwing Scrum for the moment. And this comes from me, someone near a Scrum evangelist.
Remember, rules should be used to help you. If you get good at stuff, you can bend the rules. If you get even better, you can break the rules to your advantage. Think of a novice driver and race driver. A novice driver goes by the rules on how to work with the pedals, a manual transmission, how to keep their hands on the wheel and how to use handbrake (for parking). A race driver will use the handbrake to drift through the corner faster, but if a novice were to do that, he would likely end up in the nearest tree. The same goes for Scrum, you can use the handbrake to cut corners if you know what you are doing. Just make sure you do, and I don’t mean learning The Scrum Guide by heart.
Tracking vs Exaggerated Control
Finally, some people confuse change tracking with change control. Usually, those are the people who are in charge and who feel that power is gradually being taken away from them. Modern software development is constantly shifting towards decentralization and empowering individual developers. Your manager is no longer the person who tells you exactly what to do, like in a factory. Your manager should be a person who trusts you to know what to do in order to achieve goals defined by a higher level; a person who helps you do just that by removing the obstacles in your way. Your workstation doesn’t have enough memory and the local builds are slow? Your manager should be there to get you that memory, which is worth a fraction of your monthly pay anyway. If your manager focuses more on controlling you then on helping you, it’s simply bad management.
Information is power. You want to know who changed what and why in order to quickly know how to fix things if they fail. That’s change tracking. You don’t want overly formal change approval under intense scrutiny and micromanagement from your boss. That’s exaggerated control. Make sure your boss understands good developers are professionals who know what they are doing, that they are responsible for what they are doing and that they don’t like when someone constantly gets in their way with meaningless formalism, needs to satisfy an Excel file and their ego.
Trust me. I’m an engineer.