Journal 1

Demo 1. 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 Monday's lecture. 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? Do you prefer powerpoint slides? Has it been difficult to self-organize for sprint 1? You can also tell us about issues or roadblock you encountered when working on your first 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

Overall, the first Sprint went well and I attribute most of that success to the Agile format the class is being taught in. Normally, when a class is given a large design problem it takes over a month for them to produce tangible results as that is when the midterm report is due, however using Agile with Sprints allowed our class to hit the ground running and get a preliminary product out in the first two weeks. As such, I think Agile is helping my learning process and allowing us to progress rapidly on the process. Our team has some difficulty organizing for Sprint 1, but this is expected for a new team. During Sprint 1 our team had a difficult time decided what direction to proceed in and how to accomplish the goal we decided on, these issues seemed to stem from just being a new team and from having an evolving mission statement, but the evolving mission statement was beneficial in that it allowed the team to learn to adapt. Although XLP allows us to maintain an online database of all of our work, I don't find XLP very useful right now since the work has to be done somewhere else and then imported into XLP due to the inability for multiple people to edit XLP at once. Furthermore, although XLP maintains our work for people to look at in the future, I don't think it's format will be very helpful to someone in the future trying to understand our work and a concise report detailed our final design would be more beneficial. Although I do believe XLP could be used to complement our report and add more detail, however, XLP will have too much extraneous material, which although was used to solve the problem, is not relevant for a person to understand our final architecture in the future. Regarding the demo, I understand that a powerpoint presentation is more finished and polished then is usually expected during a demo. My main concern about an actual demo is that if we jump right into showing calculations and graphs on XLP it will be difficult for our customer to understand the big picture of what we've accomplished for the Sprint and where we stand in the mission planning process. As such, for the next Sprint Demo I think we should perform our demo based on what we've done using the Kanban board and showcasing the work we've done for each of those issues.

John Hernandez

I would recommend dedicating one lecture at the beginning of the course to actively running a short sprint with assigned roles (product owner, etc) toward completing an achievable goal in the 1.5hr time block. This may reduce the initial confusion pertaining to the use of the agile framework. Even if the requirements are ill-defined, continued stakeholder interface can’t be understated. This is particularly important during the initial phases of the project. The team was initially split into three teams to cover the deliverables at my recommendation. Lesson learned here is to establish a communication architecture for the teams to ensure continued integrated and collaborative work. If the team is split into multiple teams again, I recommend establishing leads on each team who participate in a joint phone call with other leads, product owner and scrum master every other day. 15 minutes max. What’s been accomplished, what’s next, what are the foreseeable obstacles. Any continued discussion/work can be taken off-line. This ensures continued integration between each team and enables other teams to offer solutions to obstacles that other teams may be encountering that they may have already worked through. Gold plating – this can be a common occurrence if not careful. We need to keep the team on track to delivering what the customer asks for. This is something that came up during the sprint 1 demo. The customer thanked the team for the additional work and also mentioned it was not required. This is a real-world problem – this adds on additional project cost and results in scope creep. Particularly if a product isn’t built to exact specification. There may be good intentions, but the outcome could mean significant re-work.

Ezinne Uzo-Okoro

Using the agile process for a space systems Pre-Phase A architecture activity is an intriguing concept. Seeing it work in software, I am curious to see it work, for instance, for NASA SMD missions. Thus, I was enthusiastic about exploring and trying it, particularly when we learned Boeing and Airbus use this method to build large aircraft. A specific example with a 15-20 minute explanation showing precisely how these companies implement the agile process successfully would have been helpful in setting the stage for our Sprints. Sprint 1 started off with an open and dedicated team. Our team members attended to Scrum Master meeting scheduling requests promptly and showed up with a strong attendance at our evening meetings while we went through the process of forming and norming. Thankfully, most displayed "can-do" attitudes and were open and flexible. This flexibility was necessary as we put all hands on deck to ensure the Sprint 1 was completed. As we normalize for Sprint 2, we are learning that time is indeed our currency and being confused for a day is costly while asking clarifying questions (of the team or professors) is invaluable. I am still combing through our notes (with the business owner) to understand how we misunderstood his deliverable requests in our hour-long Q&A session outside of class. For future sprints, it is my intent to do my part to ensure we are better organized and communicate in a clear manner. I am uncertain, however, given the ebb and flow of life, that we will all contribute the same amount to each Sprint. It may always be the case that some contribute more to certain Sprints; I have no qualms with this approach, as long as it all evens out in the end. Moving forward, while we understand that 'agile' essentially means 'consistent change', it would be helpful for the professors to provide succinct goals/tasks/deliverables in multiple sentences from our customers at the beginning of each sprint. It is a relief to learn that upon receipt of competing expectations from multiple customers, the business owner will prioritize Sprint expectations/goals for future Sprints. As we become accustomed to our mandated and ineffective digital platform, which lacks a critical simultaneous edit feature, we may continue to opt to post results on XLP and use Jira as the working tool.

Jeremy Stroming

More than anything else, Sprint 1 was a lesson in communication. It will take a large force to overcome the inertia of any large group to get started on a complex project, but I think that this process was slowed further by the new Agile framework. This is not to say that Agile will not be more effective in the long run, it has simply required a steeper learning curve because it is an unfamiliar format to most students. The result was a lot of indecision and uncertainty over responsibility and work organization, only amplified by the fact that students get much less face-to-face time than a professional workplace. The biweekly meeting sessions outside of class certainly help with this. Nevertheless, we separated over the holiday weekend in three subgroups with somewhat unclear objectives. Though each group talked (my group had two conference calls), we were never completely on the same page as a class. Enrollment is small enough that keeping everyone in the loop and together will be a productive strategy in my opinion.

I like the overall idea of XLP, it just took me a while to understand what it is and why it had a fancy new name. Several companies I’ve worked for had an internal Wiki for documenting and I find this method to be very useful. It’s overall a good idea for the class to attempt something similar, the particular site itself seems to be a little clunky and inefficient (difficult to make edits, upload media, etc). I’m actually in favor of limited PowerPoint use (I’ve read some of the work of anti-PowerPoint evangelist Edward Tufte), but I also think that it is dependent on the content being presented. For broad architecture demonstrations with tables and images to show, slides are a good format. I look forward to working to build new methods of documenting and presenting this material.

Lydia Zhang

A lot of working session time in Sprint 1 was spent on figuring out the scope and goals of the “task”; in other words, synthesizing and prioritizing the rather loose “user stories” without the presence of key “stories users” in those sessions. It was great having our project owner Ezinne and scrum master Eric communicate with our “customers” after class, but I think it would be much helpful to have a in-class Q&A session (5-10 minute) after the business owner prioritizes user stories of each sprint, so that everyone starts the sprint with a clear scope and goal.

XLP as a documenting tool fits in the concept of Agile, where minimal deliverable product is forming as the work processing. However, its limitation in allowing multiple spontaneous input and complication in format pushed the team to Google Drive, Jira and other more efficient tools. To my mind, this is also the idea of Agile - using the best available tools instead of sticking with one. In order to minimize repetitive work and still incorporate XLP in a way, it could replace powerpoint and become the presentation platform with one person’s dedicated work of recording progress in each session. An individual XLP for each person might also be a good idea to formulate product as one works. Although a lot of us (including myself) will need to adjust to that because we are so used to powerpoint-style presentation and power-point driven work-style (work first and then make everything presentable (product) at the very end.)

In terms of contribution, I did not contribute as much as I wanted in Sprint 1 due to schedule conflict, however I can see myself working more purposefully and clearly once the team becomes more familiar with each other and once the goals in each sprint is more well defined. Looking forward to the next ones.

Eric Magliarditi

As Jeremy stated above, Sprint 1 really was all about communication and learning the expectations of the team as well as the business owners/customers moving forward. I personally enjoy the agile method; I believe in its philosophy however I think it would have been worth while to run through an example on day 1 to truly see what it means to work in an agile framework. That being said, as we continue to learn and use Jira, I am confident those logistical issues will work themselves out.

As for the Sprint itself, I thought the biggest challenge was a lack of objective/direction from the customer and business owner. It seemed almost everyday that what was requested of us was changing, which lead to confusion and an overall lack of understanding. This is why our Sprint 1 looked the way it did. We scrambled to come up with a "deliverable" simply because we were unsure what the deliverable was supposed to be. According to the agile method, there are no "deliverables", however there still needs to be a clear, well defined objective. A clear objective will enable the product owner and scrum master to create tasks, divide these tasks, and work effectively towards achieving these tasks. It is impossible to create tasks when the over-arching objective is not well defined. Moving forward, I believe the team learned a lot and will be much more prepared. That being said, clear communication amongst the business owner/customers will be very important to give us a good idea of what is requested at various stages.

Becca Browder

I like the agile infrastructure; I agree with the professors that it forced us to get to work faster than we would have if we used a traditional waterfall method. There are pain points, as to be expected with any large project, especially using agile. I stand by my previous statement that XLP forces the same kind of work that we're attempting to avoid by not using PowerPoint, namely that one person is forced to consolidate all our information and make it pretty. However, I understand that the purpose is to have a living repository of our work, so I'm amenable to using XLP for this purpose. I think the negative attitude toward slides (reminiscent of Tufte, as Jeremy mentioend) is too strong. Slides serve a useful purpose for presenting high-level ideas in a manner that tells a coherent story. The point of Tufte's (and other who are PPT-haters) that I agree with is that there should be flexibility to use other tools to show more detailed analysis work. Therefore, I'd recommend we use slides for framing our sprint demos and then switch to other tools (SpaceNet, Excel, etc.) to show detailed analysis as needed.

Based on team discussions and reading the above posts, it seems like we're all on the same page in terms of how our communication and coordination struggled in the first sprint, and our desire to do better this second sprint. We have an excellent group and I'm confident that we'll get better at this process as we move forward.

Francisco Jung

As a team we were efficacious in making high level decisions on overarching architectures and dividing up the work. John set up the morph box for everyone to collaborate and we filled out the key decisions and rationales from a commercial standpoint. I referenced the DRATS human factors evaluation of the lunar rover and the "Lunar Architecture Broad+Focused Trade Study Final Report" to extract metrics based on current capabilities and trade studies. This was used to fill in the details we were missing on the morph box and also led to subsequent revisions to our initial decisions and rationales. I updated and completed the commercial section of the morph box before the deadline we set on ourselves for uploading to XLP.

XLP is less accessible as a working tool due to the lack of real-time collaboration and is a more static than living document. If the ambition of XLP is centralizing the workflow and presentation in one platform, then it requires additional capabilities for users to efficiently collaborate and present information as clear or clearer than Powerpoint/Google slides. There is merit in consolidating information and processes but currently the bottleneck is a prohibiting factor.

Julia Milton

From my perspective, our team spent most of Sprint 1 figuring out a good framework for approaching the rest of the project and working together as a team. While this could be frustrating at times because it felt that we were not making substantive progress on the material or fully utilizing all the team members, I think it was essential and will help us greatly as we approach other sprints.

I agree with the general consensus of my teammates on XLP and the use of Powerpoint. While I do see the advantages of having a single, accessible repository for all of our work, I am not convinced that XLP works well as a living document. As others have mentioned, not having a simultaneous edit feature makes it impractical for more than one person to use, and it is difficult to work in directly for features like graphs, images, and uploaded files. Additionally, for presentations, I am not sure that scrolling through a Wiki alleviates any of the issues we are trying to avoid by not using powerpoint slides. For one, a wiki is even more text and content-heavy than slides are, and it is difficult to give a succinct update by making the customer go through all of the details of the sprint. From a traditional agile point of view, our demos are not true product demos, but rather updates on the planning we have achieved since our last meeting. Given that this is our context, I would advocate for the occasional use of slides to present big-picture updates.

I have used agile in my professional life for software development. I have found it to be really useful in projects where the requirements are uncertain and changing, so I am interested to try it in a different context for what will ultimately be a physical system and mission plan, rather than a software product. I do anticipate some difficulty with this methodology, however, because so many of the components of a physical architecture rely on the completion of another piece and therefore must be done in kind of a linear fashion rather than in parallel. This seems to go counter to the agile philosophy of "build a little, test a little". I think we will see the most success using agile if we are able to break up the project into components that can be worked on in parallel, and whose completion does not drastically hold up or affect the rest of the project.

Dylan Muramoto

At the beginning of the sprint, I personally felt that the project was pretty chaotic. We had multiple professors providing guidance, so we really didn't know what we were supposed to deliver. The beginning of every project is a little messy, but a combination of tackling a new theme (Earth-Moon-Mars), using the Agile framework, and integrating XLP into everything made the logistics and planning for the first sprint particularly confusing. Things cleared up a bit during our second work session when Oli met with us to answer our questions. After he explained his answers, the group seemed to have a better idea of what to focus efforts on and we managed to self organize by splitting into different groups, each focused on creating and examining an Earth-Moon architecture. Chaos struck again during the holiday weekend when the groups realized that we didn't know how to proceed beyond creating a few architectures, so an emergency meeting was conducted on Monday. During this meeting, I got a better idea of what we desperately needed to complete in time for the presentation, and actually felt useful for once by helping to create the presentation. It seemed like everyone was able to focus their efforts more when we were drafting the Google Slides presentation because we could all collaborate on it in real-time and we were all very comfortable with the format. During this meeting, I was able to better understand the bigger picture of what our group was trying to complete in time for the demo. By taking responsibility for the slides explaining the different architectures, I began to find out what I understood and what I needed help to complete. For example, I knew the differences between each architecture and why certain decisions were made, but I didn't know exactly how different design choices would affect the Delta V calculations, so I relied on Andy to calculate the necessary Delta V's for all architectures.

Although Ed has encouraged us to avoid Powerpoint, the Google Slides presentation we created really helped to consolidate our ideas and provide a uniform platform where we could all work on the demo at the same time. XLP is a great platform to post and view all of our finished work, but the lack of real-time collaboration and the Wiki format is not conducive to having a large group work simultaneously while also being able to incorporate changes that result from the Agile process. As I type this reflection out, I am slightly paranoid that I am preventing someone else from also adding their reflection to this page.

As we move forward to the next sprint, I have a better idea of the expectations and what I can personally do to help the team be successful. Additionally, with the help of Jira, I think this time we are focusing more on making sure that everyone does equal work. In a project-based class like this, there is no reason for anyone to get a lesser grade unless they actively try to not do work.

My background is in aeronautics, so I am dedicating this semester to branch out and learn more about space by taking this class along with the Engineering Apollo course. So far, I believe this class will be extremely useful, not just for learning more about space operations and the technical considerations for getting to the Moon/Mars, but also for learning the best methods of systems engineering and project management (the focus of my thesis research). I am excited for what is to come, and I look forward to working with this group.

Andy Cummings

I think we really struggled to understand the requirements of this class during Sprint 1. The XLP model was new to most of us, and a lack of familiarity left us wanting to return to classic group project dynamics. For instance, I struggled with adapting to the changing requirement of the Delta-V story. Each time I sought advice or asked for specifications I got a slightly different answer. Ultimately this meant I failed to deliver what was required of me, and in the end the story wasn’t even meant to be considered a deliverable. Rather, it is my understanding now that stories are paths through which to get to a demo presentation.

I think group cohesion struggled in this first sprint due to the long weekend immediately after the formation of the class. People scattered for the weekend and those of us who were able to make it through the snow to campus on the holiday made some tough calls on the direction of the demo in a way that seemed unilateral to the people who couldn’t make the meeting. We also tried to split into subgroups which ran into issues when we tried to get on the same page for each of the models we were presenting (i.e. Commercial, Apollo 17, etc.). In the next sprint, I think we could do a better job of communicating as a team and understanding exactly what is required of us beforehand.

Ferrous Ward

The main friction generator during the first stage of this project seemed to be our understanding of the usage of XLP and task management. This did eventually happen near the end, but there was not much cohesion where most people having a clear enough understanding of their expected project contributions. However, it was hammered through by the end of sprint 1, so it would seem that we are in a much better position as we go into sprint 2 and beyond. Additionally, XLP seems to be a fine system, but our orientation to it was less-than-optimal so many students were unsure as to how exactly we should implement our reporting in it. Looking forward, this could be fixed if the introductory session is less of a sales pitch on why XLP is great, but more of a 'Here is what we want to use XLP for, and here is how you do that." Besides that, there are some server side issues that essentially demand the users to communicate with each other -- since only a single individual can edit a page at one time.

As far as group dynamics go, no serious issues. People seem to work well together, and people have a tendency to self-sort and allocate / assign tasks that way. There were several iterations of "grouping" made mostly off of bad understanding of the project direction, and to the class' credit, changes were handled well and adjustments were able to be made quickly. Outside of this, I expect the remainder of the course to go much more smoothly and I am excited to see the development work that we do!

Hiro Furufu

Since each member including me was confused with how to proceed with this project, we were not satisfied with the result in terms of productive work. I feel first confusion is a kind of the characteristic of the agile method because we should do first and think later. But we need to reflect the process and sprit our tasks properly.