Retrospectives - SRA-18F-GSA-Agile-Services/checkFDA GitHub Wiki

What went well?

  1. The pizza for lunch was good

  2. Development team has been focused from the get go. Did not break and kept momentum going.

  3. Good practices with pair programing and pull requests. Fixing problems now before they happen and not getting bogged down the road in these issues.

  4. Being located in the same room has been a benefit for the Development team. “Too real time for chat app”

  5. Using everyone’s strengths to round out our development team. Combining each other’s expertise and knowledge. Learning about frameworks and easier solutions that one might not have known that existed before. Over all becoming better developers.

  6. From a UX side: using webEx and Balsamiq to describe ideas. It has helped visualize ideas and show others.

  7. Getting better about staying on topic and talking about what really matters for our projects and with our time constraints. (Thanks remote team members!)

  8. Communication has been one of our strengths.

  9. Because we were remote we are committed to our GitHub posts and other forms of documentation

What could have gone better? How can we work better as a team?

  1. Achieved our stride for our remote teams faster. Finding better ways to describe and show our ideas from the get go would have helped maximize our short amount of time. Wish we had more experience with hackathons beforehand.

  2. Keeping active mindset for what specific tasks need to get done in a certain time frame.

  3. Process feels slightly artificial at times. For example logging an issue rather than just talking to the developer right next to you who wrote the content (do both). We all do agile in some way shape or form but not completely.

  4. Understanding the process and the other side of the team. Development vs UX and how they work together in this idea. This differs in every time frame, Ex 2 year project vs 1 week vs today.

  5. We all want a great product but what we have to know is that on both sides there are tradeoffs with the time frame given. We do not want to be left with an app with all the feature halfway finished

  6. Keep in mind that some of these processes can seem nebulous at times but it is important that we do them because they are valuable for the long term and if we were a real team that is distributed across the country.

  7. From the get go we should have very clearly defined roles and responsibility. This would clear up the process, speed us up, and allow us to produce a better product.

  8. Knowing peoples strengths ahead of time and all working locally rather than so many members working remotely. Communication is always an overhead.

  9. Because we tried to do such a small task so fast we ran into dependency issues that did not allow us to work as efficiently as possible. Now that we are past that we can iterate on the application more easily

  10. Talk about requirements of the RFQ so that we can confirm we are hitting all the requirements.

Shout Outs

  • Thanks Drew for the pizza and for working on the charge code

  • Thanks Scott and Eric for working through a crazy test case (do smaller test cases haha)

  • Thanks Brian and Jenny for keeping us organized

  • Thanks Andy for jumping in right away

  • Thanks Holly for keeping design aspect organized and online with all of our expectations of speed and quality.

  • Shout out to Caroline for organizing the data requirements helping understand what exactly is possible

  • Thanks Graham for knowing how to type/take notes and take pictures