Journal 2

Demo 2. Reflect on your learning so far. You may use the same format you used for the following assignment: student introduction

You should complete this assignment before the next lecture (March 11th). Prof. Crawley is interested to get feedback on how the class is being run (e.g. using Agile mode and XLP tool). He wants to understand if there's any significant impact (good or bad) on how you're learning. Please share with us any details. For example, Is XLP/Agile making you more or less efficient in managing your time? Has it been difficult to self-organize for sprint 2? You can also tell us about issues or roadblock you encountered when working on your second sprint.

In general, tell us how we can make the class better for your needs. Please feel free to share additional information that can help us understand if our Agile/XLP methods are helping you learn more effectively ( or less)

Ryan de Freitas Bart

Sprint 2 went a lot better than Sprint 1 as we had a better understanding of the problem we're trying to solve and the workings of Agile. Jira was especially helpful in this Sprint as it allowed us to easily create tasks which needed to be done and assign them to someone to get the task done. The one issue we faced with this framework of working by tasks is that our work for this Sprint was disjointed in many ways with each sub-group working mostly independently of the others. Although the most likely cause of the lessened communication between the groups was because each group was working to learn about and create a baseline for their system so we hadn't reached the high level yet of integrating the different pieces together to create an optimal architecture. This issue should be remedied next Sprint as although each sub-group will still have their own tasks we will also include tasks to make sure all of the work each group does feeds into the final architectural consideration. Regarding the Sprint 2 demo, it went well overall although it was difficult to see the entire story of the work we are doing and how each component feeds into the big picture. One issue with XLP is there is no logical flow to the page, there are just the different sections describing the different pieces of work that was done. At the end of the class, the work on XLP should be distilled into a final report as it is difficult to absorb all of the data on XLP to understand the final results. However, the team did a great job of coming together and delivering a product which moved us closer to our goal. Although we are still working on ironing out the details of how MIT will work on the BAA, the team did a great job of learning about and beginning an analysis for the refueling element and extensibility of the lander.

Dylan Muramoto

Sprint 2 was much less chaotic than the first. Using Jira and assigning people to specific tasks really helped streamline everyone's efforts and helped everyone understand what needed to be done in order to accomplish the bigger mission. Ryan's work in managing our whole Jira project was absolutely critical in making sure that everything got done in an organized and manageable fashion. Setting expected completion times and logging in the amount of time actually taken really helped me personally because it made sure that I didn't spend too long on a specific task. Overall, I feel like the group had a better idea of what the professors expected, so we were better able to split higher level tasks into individual tickets on Jira.

Communication was still a little bit of a problem. People working on similar tickets didn't really coordinate unless they took the additional effort to look at the documents that other people were working on. For example, I didn't know that Lydia had already done preliminary research into the ESPRIT refueling module until I looked at her working document and found the appropriate section. That work would have been repeated twice (by Lydia and me) if we did not coordinate with each other. Regarding XLP, I don't think that the platform is conducive to creating works in progress. For example, having to upload all photos before adding them to a page is very tedious and time-consuming. Additionally, the inability to update and collaborate with others in real-time is a large disadvantage. As a result, everyone types out their work on individual documents and then later adds them to the XLP, which is redundant and time-consuming. The wiki formatting (putting photos where you want them, creating tables) is also finicky and forces us to work on our tickets on traditional word document editors.

I would appreciate it if we were given a set of tools necessary to do quantitative analyses of architectures. This sprint, I feel like I really lacked the knowledge and tools to do in-depth analyses, so I had to find what I could on the Internet and publically accessible documents, which was mostly qualitative because even professional institutions like NASA are still refraining from doing quantitative analyses due to the sheer amount of uncertainties involved in creating such an architecture. If we expect to create an end-product that is useful and different than what professionals at NASA who have spent their whole careers doing systems engineering/space engineering are producing, we need to rethink the overall objective of this class and identify a truly unique and realistic end-of-class deliverable to work towards.

Eric Magliarditi

Compared to sprint 1, I thought sprint 2 ran much better. Working with Jira was a great way to assign work and to ensure that work was being completed. There was a greater sense of transparency and we were able to produce a lot of solid and interesting work. However, I still believe that the lack of understanding of a common goal to be working towards really hurt the ability to deliver come the day of the sprint. Since we took the approach of just making a ticket for every demand or task that was asked of us, we never looked at how to bridge the tasks together to make a cohesive story. This should be the primary focus of sprint 3. We need the business owners and customers to give use explicit goals so that way come the deliverable, they know what to expect. For example, the customers, Jeff and Javier, should except to see certain elements come the demo day, and if these elements are not talked about, then there was a problem in the workflow. Rather, we just worked hard to put together as much information as we could with hopes something good would come out of it.

To second Dylan's point, I also think it would be great to learn about the tools and formulas that allow us to do quantitative analysis. There are literally millions of architectures that were generated, and it is very hard to evaluate these without a proper quantifiable framework. Asking for the mass to the lunar surface, for example, is a great metric to discuss, but very difficult to actually estimate in practice. I think it would be worthwhile for Ed or Oli or Jeff to discuss the key figures of merit and how to go about calculating them from a pre-phase A standing. As an architecture gets more refined, it is easy to calculate these numbers, but at this point in the game, it seems as though we lack the understanding to provide the quantifiable analysis that is desired.

Overall, I think sprint 2 was solid, but I look forward to sprint 3. I think Ed and Oli should work with the team to develop the goals of the demo in two weeks, and planning what the demo will look like ahead of time will be a great way to get started. If we can have an outline for the demo by Monday, we can then reverse engineer the work needed to complete these goals in order to meet the requirements and needs of the stakeholders. Also, having a class period to discuss key FOM and the way to calculate them from a pre-phase A point would go a long way. Ericmagliarditi (talk) 02:51, 8 March 2019 (UTC)

Lydia Zhang

Things start to make sense in Sprint 2. Presenting in XLP format is still a bit disorienting and not smooth enough, but at least it is a way to showcase research results and somehow effective in touching all aspects of the group research. Given the extra efforts of transferring work into XLP, I realized after the demo that I had omitted a lot of research done elsewhere (ie. google doc) because I was not sure how to re-organize and present them at the right locations in XLP demo page; also was not able to transferring them in the right format to XLP in time. I agree with what others said about Jira that it is a convenient and transparent tool. However, personally, I struggled with whether or not creating new tickets for myself as the research evolved, as well as using the burndown chart and time estimate to most efficiently target my work. These are lessons learned in Sprint 2.

In terms of working on the business plans, the "business team": John, Hiro, Francisco and I had difficulties in setting up a realistic timeline and a series of technical assumptions. Given the goal in Sprint 2 was not to land on a particular architecture, we tried to also come up with some open business architectures alongside, which later proved to be very confusing for ourselves and others. Due to this, we were also unable to delve deeper into the quantitative analysis and ended up with varying scopes and topics in our different research. A similar topic to Dylan's, there were also repeated work done within the group. For this, I believe a better communication channel will start to emerge in Sprint 3 now that we are closer with each other and seem to all realize this problem. A change of workflow by first studying key concepts and tools might also help to rescope the work and set a clearer direction in this new sprint. LydiaZhang

Jeremy Stroming

I was very impressed with the volume of output from the team for Sprint 2. The team was relatively frustrated by the lack of coordination and communication for Sprint 1 and therefore delegated tasks much earlier on with clearer deliverables. However, this meant that most people ended up working independently without a clear understanding of how the pieces tied together for the demo. This was in a sense a swing too far in opposite direction from Sprint 1 where indecision led to a lack of completed work. Personally, I also struggled with a very intense two weeks outside of 16.89, and I felt frustrated that I was not able to contribute more. Additionally, the combination of Lunar w/ ISRU and NASA BAA work was difficult for our team to wrap our heads around. Specifically, the BAA, we were rather confused what work we should prioritize as our expected partnerships and deliverables seemed to shift daily. I am also still learning the JIRA system and how to track issues on the site. My main issue so far is that the project still seems to be shown as a list of dozens of small tasks and I have not been able to put together a higher “systems-level” view of deliverables on the JIRA site. Perhaps there is a way of doing this that I have not yet discovered. I also think I need to spend more time digging into the details of what each person in the class is working on and ideating what the sprint deliverables will actually look like well before the actual deadline.

As Product Owner for Sprint 3, I intent to do a better job of coordinating work to deliver a more cohesive final product. Specifically, our team’s aim for Sprint 3 is to develop quantitative models for our Figures of Merit, and tie architectures back to stakeholder needs to deliver a more definitive ranking. I’m both excited and nervous to take on this leadership role.

Julia Milton

To echo the thoughts of my classmates, I also believe that sprint 2 was much more smooth and orderly than sprint 1. After feedback and discussion with the stakeholders following sprint 1 we had a better idea of the tasks we needed to get done, and work was split more equitably among members of our team, with each person making a substantive contribution this sprint. I attribute our improvement in coordination to becoming more familiar with the project and the class expectations, but also to the use of Jira which made it easier to see who was working on what, and what specific tasks you needed to complete in order to contribute to the larger work effort. I do think we can improve somewhat on working as a cohesive team - as other people have mentioned - so that work is not duplicated or in conflict with other groups, and this is a focus of our work going forward in sprint 3. In this sprint, I worked primarily on reusability and program sustainability and as these are important considerations across the board in this project, I think it is important that others are aware of them as work is ongoing and not just when we give our sprint demo.

I still feel that XLP is not a very effective method for delivering updates or for keeping a living repository of information. In doing the demo, it is probably too much and too detailed of information to be able to give a cohesive, big picture overview of the work we have been doing. We ran into problems this past demo with going over time and because the stakeholders were not able to see how each work element fit together. I think this is one advantage of compiling an overview document (such as a powerpoint) - it allows everyone to think about how their work fits into a bigger picture and also is helpful in presenting that story to the customers.

John Hernandez

Sprint provided more time to work on the deliverables and more time for the expectations to set in for the team. I worked as part of the “business team,” which in part seemed relatively disconnected from the rest of the group. Overall, I think more integration needs to take place amongst the entire team to avoid redundant work and, at worst case, re-work. The foundational variable that needs to be addresses prior to working on Jira tickets is an overall expectation, or goal, the team as a whole is trying to achieve. In short, we need to be on the same page in terms of end-goal objective so different teams aren’t working toward different end-term goals. While the use of agile provides the benefit of working through initially ambiguous project scope and requirements, I believe a better structured approach to utilizing this framework would be beneficial for future sprints (or teams). An application of conventional project management would have been beneficial prior to launching into sprint 1 - general expectations, internal team communication architectures (e.g. who talks to who, where should information be placed, primary stakeholder interface for addressing team questions). Additionally, a more thorough stakeholder analysis could have taken place at the beginning of the project, which could have resulted in a less ambiguous project scope. I was surprised that we just built out a stakeholder list and needs matrix in sprint 2 – something that I think should have been completed in sprint 1. Agile is an attractive framework for rapid prototyping projects, but it certainly doesn’t mean we have to dive head first into a project without proper due diligence up front to minimize project uncertainty to the best of our ability. As for XLP, it seems to me as if the product was built without fully understanding customer needs (i.e. hammer/nail situation). Build a great golden hammer and then look for a nail to use it on. The problem is, there may not be a golden nail for this product's use placing it in the 'cool tool with little value add' to actual customer needs (e.g. our team). This could be my lack of understanding of how XLP functions, but again, we represent the customer here and if we're confused about it's value-add, what does that say about the product?

Becca Browder

I'm in agreement with other team members that Sprint 2 was a great improvement over Sprint 1. As they mentioned, we lacked integration and high-level coordination, but I believe we'll be able to come together this sprint to deliver a more cohesive demo. Jira is a great tool for Agile, but it does not do a good job of supporting integration, so we'll have to work around that. We started Sprint 3 by focusing on the Epics and aim to keep these in mind for our work throughout this sprint, so that they will act as guides to a more cohesive demo.

I agree with Julia that XLP is not great for presenting. From my understanding, the choice to use XLP is to document our work for future reference; if that is true, then we should still put all of our work up on XLP so that other people can find all the information. That said, I think our demo presentations should still be done with more traditional slides because it will allow us to stick to the allotted timeframe better by only highlighting the top-priority information. The XLP can hold all the data, which each customer can review in their own time for the areas they care about particularly. Bbrowder (talk) 16:14, 10 March 2019 (UTC)

Ezinne Uzo-Okoro

In Sprint 2, we had clearer defined tasks and performed them more effectively because Jira proved to be a useful tool for work assignments. However, most team members were siloed and focused on their respective tasks that three things occurred:

• (1) Our common goals appeared largely unclear because the FOM were not defined by the stakeholders and we had to estimate common goals for a few days. It would be helpful if the professors provided Sprint goals and helped with FOM definition to assist with architecture down-selects.
• (2) Most of us were also unaware of what others were doing with sufficient detail. It made my consistency check at the end of the Sprint rather futile. Was I to change what someone else did to match another person's work? Or leave as is so that our customers and stakeholders could see our thought process and contradictions before we became whole? Ultimately, I did a mixture of both.
• (3) We still used XLP as a final delivery data dump, which showed a lot of effort and work performed for the Sprint, without resulting in a structured and timely demo.

As we move on to Sprint 3, I hope we can work with better insights into the activities of each other, to encourage the delivery of a unified product, which has been succinctly defined by the professors. However, I understand that this is highly dependent on the flexibility of the agile process, volume of work to be completed, and our mandated tools. On XLP, we are still using it in ways we feel the professors did not intend. We are posting individual completed work on the platform, in a disorganized manner, that does not make for timely, polished and fun demos. Perhaps we need to review the stakeholder's definition and expectation of a demo? Since demos tend to be polished and organized final products, and the agile process is about achieving more while operating in a somewhat flexible yet chaotic environment, perhaps we, the students, needs to revise our expectations for our demos? Sse studentx (talk) 04:55, 11 March 2019 (UTC)

Andy Cummings

I feel that Sprint 2 was where the team really started to come together. There was much better attendance at the work sessions on Tuesday/Thursday, and as a team we began to divide ourselves based on expertise and ability. I guided myself towards the energy requirements for different architectures, and wrote extensive code to calculate the Delta V requirements for specific orbits. While the Delta V calculations were sufficient for Sprint 2, they will need to be refined for future sprints. For instance, I will need to discretize the different maneuvers for each path and have stronger explanations for the assumptions I make. The next Delta V requirements will be much more extensive, and will have alternate route options. Most likely, I will just fold it into a python package that will be uploaded to the Git repository.

I was also able to lend some assistance to Hiro’s work on the science motivation behind returning to the moon. I have a background in Astrobiology from work I’ve done at JPL, so I am familiar with some of the extraterrestrial motivation and objectives behind both manned and unmanned lander missions. Becca and Ferrous did a great job of taking Ed’s architectures task and refining it, and while I was able to contribute a little to that assignment, they took charge and freed me up to focus more on the Delta V.

As a team I think we finally adapted to Slack, Jira, and XLP. Slack was always active with discussions and helped us keep on track for the day to day. XLP is definitely not my favorite platform for giving presentations, but I do think it is a good way to data dump. In the 24 hours before the Sprint 2 demo we nearly doubled the work we had placed there before. I think if we were more strategic about how quickly we data dump we could filter our content a bit. However, that’s the nature of XLP, and it allows us to “show what we know” in an easy to digest way. My main gripe with XLP is that it freaks out over multiple people editing at the same time. I think for Sprint 3 there needs to be a bigger emphasis on communicating when and what is going on XLP. Jira has been a godsend for tasking; it’s super easy to track my work and see how the group as a whole is progressing. While this does force someone to be the taskmaster who tracks everything, that oversight seemed to keep the team in check and hit the deadlines that mattered. Ultimately, I think that we have come a long way from Sprint 1, and am excited for both Sprint 3 and the potential work with industry partners.

Ferrous Ward

Sprint 2 was much more well organized on our behalf. Communication between classmates was increased, and the same kind of undirected self-sorting such as that seen in sprint 1 was not necessary. Most peopole have a much deeper understanding of how exactly to utilize Jira as an organizational tool, and we have integrated Slack and XLP into our workflows. I would also like to agree with earlier statements that XLP is not optimal as a presentation format. As a documentation / changelog it performs beautifully. However, in much the same way you would not expect a notebook to be a general summary of work, XLP as as documentation platform does not shine as a presentation platform when attempting to use it as a "dual role" format. A separate "presentation" XLP page should be considered, along with the standard sprint documentation. As seen in the sprint 2 demonstration, some topical areas can be significantly more verbose than others, and time management becomes a critical issue there. One flaw I still see with our organization is that most people still do not exactly have a "do x" task, where instead their assigned task is one level of abstraction up from that. For sprint 3, we plan to mitigate this with a dedicated pre-planning and layout stage.

Francisco Jung

Jira and Slack proved to be useful tools that helped expedite and organize the tasks for Sprint 2. Both of which XLP cannot provide due to its static interface, lack of real-time collaboration capabilities, and unstructured organization. I do not mean to beat a dead horse but I believe constructive feedback will help improve XLP's functionality or scope. Currently it is hindering the team's workflow because it is neither a presentation tool nor an efficient documentation platform. In fact it contributed to the aforementioned "siloed" working conditions that left many members without a clear understanding of how the pieces tied together for the demo. The affordance of real-time collaboration is that everyone can see what others are working on and it allows a wholistic view of the sprint at hand but this is cannot be done in XLP because the "living" document only allows one user to update the document at a time. I myself wasted a considerable amount of time when I tried to save the changes I made but was met with an error and a complete wipe of my work. Another affordance that is valuable in a collaborative effort is online discussion of real-time content. Applications like Wikum that provide such discussion would have mitigated the incoherent workflow. Furthermore, many of the questions and confusion during the demo could have been preempted if the information uploaded to XLP was more structured and organized in a presentation format. XLP served as a repository of unstructured data dump with a debilitating bottleneck for uploading content.

As a team we distributed clear tasks to effective members. I wanted to address Javier's concern for a business case from a commercial standpoint so I shared my thoughts on several documents that I read pertaining to ULA's Fuel Depot + ISRU architecture. The majority agreed that it could be a viable business case and I was tasked with doing a quantitative analysis on the initial investment and the break even point. I was able to calculate the fuel price per kg by incorporating infrastructure and transport costs for lunar ISRU to L2 depot and compare it with the fuel price per kg for Earth to a LEO depot. My interactions with Lydia and John helped reinforce the business case within the scope of the sprint and Ryan provided guidance for honing in on significant figures for calculation. I feel very fortunate to be able to work with such adept team members and it truly has been an invaluable learning experience thus far.

Hiro Furufu

I did SSE-17 The Benefits of Future Science Missions to the Moon. I asked one astrobiologist who worked NASA Ames and found the benefit to look for the origin of life on Earth. I am really curious about it, but there were too many contents to discuss in the class. I feel we need to have a timekeeper or quality controller of presentation. Also, I did SSE-46 Create lifecycle costs to include cash-flow analysis of Lunar Surface ISRU for propellant use. I calculated the price of propellant on the Lunar Surface would be $26,900/kg, but Jeff said it’s too expensive. Again, we didn’t have enough time to discuss why it’s too costly so I want to have more detailed feedback.