Almost all the software projects go wrong. Ok, this is a fact. Forty years of software engineering exists to tell us that making reliable software that meets the customer needs is a very hard work. And it’s pretty clear that the customers have the mainly role on the process, maybe what we didn’t get yet is how to make them play it right.
For the last decades a more fertile ground of software design, called User-centered Design, is trying to address more properly the mentioned problem above. UCD is related to Human-computer Interaction and Usability, a term that includes ease of use, efficiency and satisfaction of customer. To look for usability leads beyond than graphical (or whatever else) user interface and the usability engineer should be asking for user requirements in order to understand: conscious, unconscious and dream of requirements.
And there came the Agile methodologies, many of them, with the promise that it would fix your problems. The agiles say that the traditional way of doing software is wrong and lead to many mistakes that are responsible for the current bad panorama in software production. These methodologies are much more focused on delivering value to the customers and, which is the same, meeting their needs doing very short iterative cycles where customer feedback is asked to its maximum.
Extreme Programming (XP) is one of these “methodologies”. An iterative cycle in XP lasts one week (it is called weekly cycle), and the whole process of going from user requirements gathering to implementations and validation is doing within this cycle. In the beginning of the week the whole team, it means developers, customers and manager, meets to the Planning Game where User Stories are created, prioritized, sorted, dropped and so on, at the end of this meet the team would have a clear set of functionalities that must be done in this week and how to test them (Acceptance tests).
User Stories are express customer verbalized requirement. It usually have the following sentence: “I want to…”. The intention is make the customer feels like signing a check, more she wrote down new stories, more she will pay for it. This practice favors one of the values of XP: Communication. It becomes very clear to the team what they have to do in which time and also becomes clear to the customer for what he will be paying for.
Ok. But in UCD we see that to ask user for their requirements is one of the weakest ways to obtain their real needs. More often than it should be, the users barely know what they want, and sometimes they don’t even know at all. When traditional software development spend almost six months until the client sees something running on her machine, make sense to try do it worthwhile by covering as many aspects as you can using techniques like ethnography and alike.
And in the context of doing XP, the user stories only catch conscious requirements, leaving behind unconscious and dream of requirement which is, commonly, the bigger part of the issue. Even showing to the user working code every week, she cannot say much more than that she already knew. Of course that the user learns more when using the program, but there are many issues that can go through her unnoticed. Making her pay for learning something that could be done early in the project if usability engineering was done seems like unfair to many of agile skeptics.
But much was already done in this area, and we are just in the beginning of this trial. Could XP meet the usability issue in long-term? Is it cost-worthy? In which cases it is and in which cases it is not? And how can we mix UCD practices within XP context to take off advantage of both?
These are the questions that I want to address during the next steps that I will be posting here. Please, I would be glad if you give any comments about this post and the next ones.