Embrace Change! Yes, but…

I found myself asking for written specifications from our major customer the other day, and it made me shiver… What on Earth was wrong with me? Wasn’t I able to cope with fuzzy requirements anymore?

The answer is YES.. BUT…

The goal of the “Embrace Change” motto (this is the subtitle of “eXtreme Programming Explained 2nd. Ed”) is to account for the fact that the cost of changing a system may not grow exponentially as is commonly thought, and that changes are always for the better. As a matter of fact, changes are requested at a time when users/customers know better what the system should do (because they have had the chance to play with pre-releases and think about the system some more… or because their understanding of the market has evolved), and developers’ ability to design and implement features is also better (because they have learned to work together and learned the tools and technologies).


It doesn’t mean that users/customers should not think about what they want, explore their options, and keep track of their discussions/reflections. It just means that they should do so with the expectation that they will probably have even better ideas later on… and that those changes will still be easy to implement by their Agile developers (just change a few tests here and there, think about how to fix them, and then fix them!).

Also, documents serve a purpose: they prompt thinking.

In our case, requirements must be run by multiple parties, who cannot always sit in the same room at the same time to validate their shared understanding about what the system should do. Documents alone are far from the best way to communicate requirements, but they are better than nothing. In particular, they are better than having developers guess requirements, write tests and code, then deploy and ask for feedback, then do it all again until all parties finally realize they should sit together. The process of identifying all stakeholders is a very important step in the  PMBOK® Guide, and one that is not covered by XP or, for simplicity’s sake, Scrum.  Skipping the stakeholder identification step will always generate unnecessary changes and waste.

Embrace Change: yes! Invite Change… Not sure!


About this entry