I have added all of the Generic Support Team together with Nigel John - Feel free to add or remove your name. It is currently in alphabetical ordering but it is up to discussion.

It feels as though you are trying to comment on agile vs waterfall here. Is "AGILE VIS Development" really the focus? Is this documented somewhere? Most of the VIS design methods I try to draw upon are pretty (though not explicitly) agile - ADR, Creativity workshops etc. I think it would be great to really try to pin down the documented concept that you used and are effectively testing in this notebook.

There are useful things to say in here, but I think this is probably about AGILE VIS Software Development, and it would work best if you were able to reframe around that: what is it, what aspects worked, what have you learned about it through this project etc. I hope you can move it in that direction. Can you try to add some colour! Screenshots to show what was achieved. Do you have screenshots of the development process that can help explain how it worked: burndown charts, commit records, prototypes as they develop? Try to interest and inform the reader so that they can see what happened.

I guess that Agile is one of the most important fact. The waterfall appraoch is slow and risky as the waterfall aims to get everything correct in each step moving forward. We have to use an agile approach as it was difficult to get everything correct in every step. We tried to be quick for deploying a system to support the SCRC. This is the spirit of emnergency response. The second fact is the training of industrial developments. If I am correct, Alfie, Saiful, and Phong are the three people who had received a good amount of training in industrial environment. They understand the need for deployable software and know how to achieve that. We were and are very lucky to have them in RAMPVIS. We can write more about how the VIS server became deplayble within 3 months, and how we update it in an agile manner, while keeping it always deployable.

There have been no updates since my initial comments on reframing on Aug 27. Min has added a couple of comments indicating that these suggestions might be useful and acted upon, but the content is not there. There are promises to write more - see above - which are helpful, but the deadline for reflection was 5 days ago and we have to write the paper now. So please tidy this up, address the comments, re-frame and do some more thinking, but don’t change section 7 - I will only go with what we have there now (and it’s a bit underdeveloped - see comments - and hard to interpret given what preceded it - again, see comments for some feedback on how you might address this). Original comments still apply - do try to address these issues to help generate a coherent evidence base for the paper.

A User Story would be great - particularly as this is about agile software development! 😉

Maybe ... As a visualization developer I want to design and deploy a visualization infrastructure rapidly To support domain experts in accessing and assessing a range of dynamically changing data sets ?

Yes. The team can write some text on this topic. Two facts remain important: the written knowledge as well as the "mind" to implement the written knowledge. Without Alfie, Saiful, and Phong, we might not aim for creating a server in an agile manner.

Are we likely to get any more information than this? The results are impressive, but it would be great (informative, persuasive) to hear how the concept was used and developed.

It will be interesting to find out how many VIS systems in the literature is still alive.

If long persistence and reliability are important aspects of the design - add them to the user story! I can't write this for you, but maybe it is something like: As the developer of a flexible visualization system I want to design and deploy a reliable and persistent visualization infrastructure rapidly To support domain experts in accessing and assessing a range of dynamically changing data sets now and into the future Then it's about describing the agile approach, how you used it, how you adapted it, what you learned in doing so, and what you would do (and recommend others may consider doing if they find themselves in similar situations) in the future given this experience.

This is very positive and impressive. The more you can say about why things worked well and what was different from other projects - and what the costs were ... the better for our thinking in the paper.

This really seems to be about AGILE Software Development for VIS. Can you reframe this somehow?

OK - some of this fits quite nicely into "6. Description" - it's about what yo did rather than what you learned. It would be great if you could split things up a little and really think hard about what you learned about agile and what is specific to or interesting about (combinations of) VIS, SCRC and emergency!