Here's some notes from our first retrospectve. Come visit our slack for the latest news and updates, but thought I'd cross post here in case it's of interest. For clarity even though it says it's from me, all of the following is actually an update from Daniel.

I just wanted to sum up the retrospective meeting from Friday for everyone that was not able to attend and to serve as a reminder to everyone that was able to attend. It was so great to hear everyone's input and once again it was great to see that everyone is on the same page with both, the things that went well and the things that didn’t work so well. There is a lot of items that really stuck out to me during this meeting:

Let's start with all the elements that we feel worked for this project:

Teamwork

We are a GLOBAL open source team. We have had over 700 people look into this project (not everyone was able to contribute). I think that we should take a moment and understand that what we have accomplished (and are continuing to accomplish) is truly incredible. We have an incredibly diverse team with a variety of different schedules. To push out an app with this much functionality in just a few months is not something that most open source projects could achieve.

The ability to organize chaos

At the beginning of this project it was complete chaos with absolutely zero structure (as it is at the start of most projects). What made this one different is everyone here is at a completely different skill level, everyone has their own professional experiences that they wanted to incorporate, everyone wants to contribute as much as they can, and we tried our best to have zero hierarchy. With all of the obstacles that stood in front of us we were able to get this team organized and working with excellent flow.

The resilience of the team

Resilience is not only a fantastic title of the application, but it is a perfect word to describe this team. Through my short 2 and a half month span there have been multiple people that have come and gone. Some contributed more than others but we never struggle to pick up the slack (No pun intended). We have lost organizations, we have changed our scope, we have on-boarded multiple people, we have changed our tools more times than I can count, and the world keeps testing our durability with outside stresses. We never broke down, we never gave up, and we always kept striving to attain our goals. That speaks volumes on the passion and drive of this group and it is something that I am honored to be a part of.

Figma as a tool 

A common theme was that a lot of the designers seemed very impressed with the figma tool. From what I could see the tool was a game changer. As Miles pointed out, not a lot of open source teams such a strong design focus, but we do and I think that we can thank Figma and our amazing designers for that incorporation.

On the flip side there were quite a few things that we felt needed to improve.

Communication

Throughout the project communication was a little chaotic. Not only on Slack but with the tools that we were using. The gap in communication on Airtable came from having a lot of hands on the board. Sometimes a ticket would be moved to the wrong swimlane and other times the ticket wouldn’t get moved at all. The lack of ticket organization would lead to duplicate tickets and tickets being lost or unaccounted for. On Slack the big issue is having multiple conversations with multiple people. Information is not being relayed or discussed by the group and it would cause confusion amongst everyone working that part of the application. Since the release of the pilot application we have not been having enough stand-ups (Completely my fault) and that has led to a break in communication.

To fix these issues we have already started to implement Zenhub. Zenhub will limit the number of hands on the kanban board and encourage more communication about each individual issue that is created. We are hoping that limiting the hands on the board will keep each issue in its rightful place on the boards, providing better organization, and less confusion. Karen suggested that we look into a tool called Twist which emphasizes thread conversation. In the meantime a few things that we can do to keep communication organized on Slack would be to respond to others messages on a thread instead of replying directly on the channel. It is all of our responsibility to keep people in the loop of our decisions. If we are a part of a DM message that attains to others we need to do our best to inform them. Now that the pilot is released we will be breaking up the three teams that we created, and I will also be starting the daily stand ups again. Stand-up will begin next week and will be held every M-F at 5 pm EST. Having these daily stand-up will also help keep everyone updated on the progress of the resilience project.

Dev and Design teams working on same issues simultaneously

A big part of all the pandemonium stemmed from both the design team and the development team working on the same feature at the same time. This has caused some serious destraction and has been very counterproductive. It is hard for the developers to create a feature without having a design to reference, and on the other hand it is hard for the designers to create a mockup if the feature is already being worked on.

To fix this we need to get the designers at least one week ahead of the developers. We need to figure out what direction we are going so we can start getting the designs ready for creation. Right now the Developers are in the process of cleaning and refactoring the code, it would be a great time get these designers ahead of the curb.

On-boarding process and documentation

On-boarding has been a struggle out of the gate. Part of that is because we have had a few waves of a lot of volunteers while we are simultaneously modifying our processes. It has been a real struggle getting newcomers involved, and keeping them involved.

To fix this issue we have been updating all of our documentation. We are providing step by step directions on how to use Zenhub and we will be grooming our user stories to provide tickets of every difficulty. So when we have a newcomer they should be able to introduce themselves and be directed towards the GitBook and look at the GitHub ReadMe for directions. Of course, if there are any questions we will be able to easily point them in the right direction or assign them to a ‘good first issue’ to help them get familiar. Documentation is a key factor in providing a speedy on-boarding process.

Ticket Writing and backlog grooming

Ticket writing has been confusing for a lot of volunteers. For designers the user stories are a great size, and for the developers the user stories are too big and need to be broken down into smaller tasks. For developers we have not been holding consistent backlog grooming sessions so these oversized issues are not being addressed. 

Through Zenhub we have created a process that will help provide the user stories for the designers and when the design is complete the user story will be moved to the developers backlog for refinement and subtask creation. I think that it would be extremely beneficial for the devs to have bi-weekly backlog grooming sessions to keep creating subtasks. The more subtasks that are created the more ‘good first issue’ tasks that will be provided, the more ‘good first issue’ tasks that we have the easier it will be to keep newcomers involved.

I will be holding 2 separate meetings this week to walk through our Zenhub process. One with the designers, and one with the developers (feel free to attend both if you want). During these meetings I will walk you through the life cycle of an issue, and I will be able to answer any questions that you have or take in any suggestions that you have.