AFAIK building software is a collaborative event. What I mean by that is, most of the time, we learn what works better as we get into the process of building it. So, the ideal world you are expecting is not practical. Even if some work can be specified to that level of clarity and details, it is better to build a tool that takes in this structured spec and build the feature.
But, I hear your concern about working in a setup which feels ineffective. My suggestion would be to pick teams that are small (2 - 3 devs) with a well defined goal. Keep your interactions effective and short with this small group.
Standups and iteration planning meetings have value. Unfortunately many follow it as just rituals instead of seeing the real reason behind doing them and the value it provides. You don't need to call them as standup or IPM as long as what they are achieving are met in your project. That is the whole point of being agile.
I grew skeptical the moment I read "single-blind" test. So, the researchers know which group is what and that could involuntarily lead them to pick for what they are leaning to find (given it is funded by a coffee company)
The first implementation of Bahmni took place at Jan Swasthya Sahyog (JSS), a hospital that has been instrumental in pioneering this open source work. Bahmni is named after a village 70km north of the small town of Bilaspur, India where one of three village health centers of JSS hospital is located. The work being done by JSS at Bahmni village is very inspirational to us and hence the name was chosen.
True that. But the intention of building Bahmni is different. It's primary focus was to get the EMR for resource constrained (in terms of money, computer skilled people).
I was part of the team which build it for about an year and can definitely say it did change the medical eco-system in such places
