Journal 3

Demo 3. 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 (April 1st). 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)

Eric Magliarditi

As a team, I personally feel like we are starting to move in the right direction. However, I still think the biggest challenge is the integration component. This does not mean the integration of various people and groups within the class, but rather, how all the different questions, trades, and analysis from the top come to form one piece. We have been thrown many different concepts and ideas, all which have merit, but cause confusion for how to integrate. For example, there has been a strong push to focus on the "business case" of going to the moon. However, we are also tasked to do systems architect work where we explore the entire trade-space. These two clash. In my mind, we should have a single priority, like building a business case for going to the Moon, and see which architectures work for that and also enable science goals to be met. In summary, it just feels like we are trying to optimize over every little detail, which causes confusion as well as a lack of integration.

Moving forward, it would be great to try a new plan of attack for building architectures to Mars. Let's define assumptions and constraints on day 1, and build our demo from that. This will enable better interaction and integration, and hopefully produce a better product moving forward.

Ryan de Freitas Bart

This sprint went better than the last one and we are definitely improving with every sprint. I think we did a good job within the engineering and business teams of putting our work together, however, we didn't do a great job integrating between the engineering and business teams. We have already laid the groundwork for this integration in our model and we should be able to get to a much deeper integration next sprint as we move onto Mars. Although there is much more to be done with our Moon architecture decision process, I think that moving onto Mars will be beneficial as long as we continue to work with and improve our same model, which we are likely to do. Therefore, even though we will be moving on to Mars we will still be improving our Moon architecture decision process, so in the final sprints, we will have a great process which will determine the optimal Moon and Mars architectures. Regarding XLP, we only used it right at the end of the sprint to post our final work. As such, XLP only acts as a reference if anyone wants to look back at what we've done and doesn't actually contribute to our process of getting to our final product. I still find the XLP format difficult to navigate as there doesn't seem to be a logical flow to read through it like there is in a design document. Now for Agile, the process has got us further along then we would have been had we used the waterfall method as it requires us to have a demo every two weeks which ensures we're always making progress. Still, this same effect can be created for the waterfall approach just by requiring regular check-ins. In this sprint Jira was helpful in giving people tasks to work on, however one shortcoming with Jira is there are many tasks which are just easier to do as a group right away when we think of them instead of assigning them to one person which led us to have a smaller number of Jira tickets this sprint. The team is also working well together, with the two main sub-teams being the engineering and the business team working well so far in the respect that it has allowed us to quickly pursue both sides of the decision process, although it has led to limited integration between the two aspects. Overall, this sprint went well and we are on our way to a full mission architecture decision process.

Becca Browder

I agree with Eric and Ryan that our performance has improved with each sprint, as is normal for the agile process. I also agree that we can work on improved integration between the engineering and business teams. We've improved dramatically on this front, but there is still room for improvement. I also think our team needs to work on scoping and prioritization. There is a tendency to want every decision to be made with very high confidence, which is not sustainable. One of the great things about the agile methodology is the allowance for constant improvement; this means we can make a decision in one sprint that we can later reverse if we get more information that leads us to determine the wrong decision was made. We need to start narrowing down the number of architectures we're considering, which will require us to make decisions with some uncertainty involved.

I think our demo worked well this sprint; XLP is serving what I see as its purpose, which is to be a repository for information. We put the data on the XLP the night before our demo, and step through different parts of it as needed. Presenting from the Jupyter notebook and going to XLP as needed was a great use of our tools, showing both our code and the information to back it up. XLP may not be a great secondary tool if we demo again without Jupyter, but I liked the way it worked for this sprint.

Moving forward, I've set the goal for myself to be more involved with quantitative analysis and to learn more about the Python program being set up.

Ezinne Uzo-Okoro

As is normal with Sprints, we are improving our communications with our stakeholders and each other. We are also better at understanding our objectives and deliverables. However, the business vs engineering pulls are having an undesirable effect on our work. Is this mission architecture business-driven or is it science-driven? Does NASA design and build business-driven mission architectures? Does industry design science-driven architectures? We could absolutely try either or both. We have attempted to have it both ways so far and our results have shown that integration of both is presenting contradictory and sticky issues. It would be interesting to see if we are challenged to continue with both drivers or if our stakeholders and business owners would adjust our path. This is especially important as we transition to extensibility on Mars. Mars exploration for a science-driven purpose differs significantly from Mars exploration driven by profit incentives.

On XLP, it's great to see that the professors are flexible and allowed the use of Jupiter in presentations with XLP remaining our data consolidation site. Overall, I'm adjusting to our chaos and glad to see that we only tend to improve together with time. I am also looking forward to the direction we are given in future sprints for a technically-focused Mars mission architecture. It would be very helpful to receive our requirements on Day 1 next month.

Julia Milton

Overall, sprint 3 had a much higher level of performance and integration of all parts of the product, even though there is still room for improvement. I do see advantages of having parts of the team that are kind of specializing in a certain area (whether that be fuel considerations, cost analysis, etc), because people are becoming pretty knowledgeable and efficient in their area of work and are starting to see how it fits into the larger picture. Although this can lead to some siloing, my opinion is that the overall quality of our product has benefitted from this specialization of knowledge so far. It might be worth assessing in sprint 4 if we still feel that is the case, or whether we should mix up the groups a bit.

I agree with Ezinne’s comment about some of the difficulties that have arisen when trying to equally consider business incentives and science objectives for every architecture and mission. I think that given the nature of commercial companies having a profit incentive and a government agency having more basic research and science directives, it is important for us to have clarity in who will be the primary driver of the mission to Mars going forward, and what the ultimate objective of the mission will be. This is not to say that there will not be a financial incentive for a commercial company to be involved in a NASA-led Mars mission, it just means that the types of activities and services that NASA would likely contract out may be different than those that a commercial company would undertake alone. These requirements and general direction I think we need to receive explicitly from the stakeholders, and it will be most helpful if we are able to get them very early on in the sprint.

As the product owner for sprint 4, my goals are to help the team resolve some of these disconnects between the business and science objectives, as well as work on integrating all components of the work so that the product is a more cohesive plan for an Earth-Mars mission.

Jeremy Stroming

I am proud of the steady improvement in each sprint so far. As product owner for this iteration, I tried to make sure that each person had clearly defined tasks and understood how their work fit into the overall effort. This was fairly successful. It was great that we are starting to get into more detailed quantitative analysis, but it is true that a lot of work remains to be done to tie together different trade studies of engineering and business figures of merit. We will need to get better at defining our own scope, because the problem statement as is is still too big of a problem to tackle without setting a few limitations and priorities. Another concern I have is making sure work gets more equally distributed in future sprints. It often felt that 3-5 people were doing the vast majority of work for this sprint. I'm slightly disappointed in my performance as product owner because I feel I did not have enough time to dedicate to this class for the past two weeks. I worked with several others to make sure it was clear that the priority for this sprint was to tie together the work by both the engineering and business groups, and produce preliminary quantitative sorting of different architectures based on calculated figures of merit. It was a big task, and I often relied on others to keep me up to speed when I couldn't attend meetings personally, or make their own recommendations for actions to take, but this is also the nature of management in the real world. You can't be aware of everything all the time, you need to rely on good communication with others and trust that qualified people will make good choice and work together.

Ferrous Ward

To mirror other comments, there have been continual but substantial improvements between the sprints. Communication and task allocation has improved, as has general teamwork abilities and group cohesion. I worked with Dylan on this segment, and substantial amount of the simulations were taken and summarized from previous studies. However, in terms of the whole group, the actual focus and scope of the sprint took some time to focus down on, but significantly less than either the second or the first sprints. I agree with Jeremy that there is a sentiment that a few people are carrying the work for the sprint (even though who these people are changes between sprints), so work distribution and balancing will have to be considered for the sprints moving forward. I'll hop into the discussion with Ezinne and Julia -- even though business and science should be equally considered here, it didn't appear that deep tradeoffs were considered (at least large scale), since most of the evaluation was based on what is cost effective & makes money vs what can be done - when there are many other areas that could be explored. I think this started near the end, but this would have to be expanded on for the next sprints.

Dylan Muramoto

This sprint felt more cohesive than the others because it seemed like everyone grouped up and worked together on specific topics. I worked with Ferrous on ISRU, and it really helped us that Oli sent me a thesis from a visiting student in his lab that focused on lunar ISRU architectures and the associated Matlab code for his analysis. Although we couldn't get the code to work, the thesis gave us numbers (IMLEO) that were useful in the overall analysis for the sprint. In order to find more information that was well thought through and contributed to the project, I relied on reading papers from S.M and Ph.D students on DSpace related to lunar and even Mars ISRU. I was able to find 3 useful papers (a paper written by a post-doc, an S.M. thesis, and a Ph.D. thesis) related to lunar ISRU that gave us quantifiable predictions for potential ISRU architectures. Working with Ferrous helped significantly when we needed to upload to XLP because I was able to add my summaries of the papers and Ferrous helped save me time/effort by uploading the pictures (which is a multi-step and very tedious process). Going forward, I encourage group members to work together and possibly even try tackling topics they are not completely familiar with.

Hiro Furufu

The business team calculated the mission’s profit and loss analysis using proper WACC. The moon project contains a lot of uncertainty and risks. In that case in a real business, we tend to use higher WACC. However, we’re required to use the risk-free rate. I found that Buffett discounts the future cash flows at the 30-year U.S. Treasury Rate. https://goo.gl/s9DWQY Also, because of the enormous initial R&D cost, we should use depreciation to equalize the cost effect. Anyway, we continue to research how to calculate the uncertain project and persuade stakeholders.

Andy Cummings

I feel like the team is really starting to move together. The first few sprints took time to build up team cohesion and to realize what people were trying to get out of the class. The team subdivided into a business and a science side without any formal discussion about it, which worked well for the first sprints. We really ended sprint 3 with people feeling like owners of the final product, which I think was important. However, looking towards the next sprint I think there needs to be a bigger focus on giving everyone a chance to try out different roles. It might be time for the science team and the business team to switch, or better yet, for the teams to come together for the next sprint. I think the sprint 3 presentation felt a bit disjointed because of this separation of the teams, and going forward it would be good to eliminate that. Looking towards Mars, I think this sprint will benefit from the inertia we have built so far this semester. We know what is required of a Mars architecture in that we just completed a lunar architecture. We should look to avoid the pitfalls of the earlier sprints; we should be mindful of being to broad and too generic with our plans, and should also make an effort to read the existing literature more thoroughly before beginning our work. We were too eager on early sprints and dove into our problem without fully understanding what exactly we were trying to solve, and I think that is something to be mindful of for this next sprint. We have demonstrated that we are capable of doing the work, but I think the biggest challenge for our class is guiding that energy in a productive and cooperative way.

John Hernandez

The team worked together well during this sprint. The next sprint should focus on grafting the business and technical aspects of the project. It seems cost of mission needs to be grafted into design decisions including revenue streams and development of a viable space economy. The business team developed a first order stakeholder and DCF analysis. The stakeholder analysis was robust and captured the weighted value each stakeholder had in the architecture. The business team recognized a DCF analysis is a nice first approach, but will require a better approach given the significant uncertainty associated with this type of project. If a DCF analysis is used, the appropriate WACC will need to be evaluated.

Lydia Zhang

In this sprint, I observed improvement of workflow inside the subteam (in my case was the business team) as well as the integration process between teams. I agree with what my classmates said earlier that there is still room to improve, particularly on the integration of the two now seemingly opposite stakeholders and their needs - business and NASA. As mentioned by Ezinne, I think one of the reasons behind the current dissatisfaction of integration comes from lack of communication with stakeholder representatives, particularly communication that would have helped us figure out which stakeholder is prioritized or what compromises would have been made in trading different architectures. As we move to Mars, the same problem persists. My own goal is to engage more in those conversations to figure out the applicable stakeholder relationship for our sprint project.