Making an app that replaces daily stand ups

Daily stand ups are done in nearly every single technical field and engineering job. They are important for managers to know what they’re employees plan to work on for the day and give the employees a chance to voice anything that may be blocking them to their peers. The problem with stand ups, is that they take up valuable time that could be used to fix problems and otherwise get work done. While communication is important, so is coding and designing. Some products try to get around this with automated stand up messages like GeekBot so they can be answered quickly, and everyone has the ability to read responses at their leisure. An issue, though, is that automated responses can be easily ignored or forgotten. That’s where Apollo comes in. Apollo combines the two of these systems by giving team members easy access to the surveys and questions that the team lead needs answered while also making it more personal by making it so the lead needs to manually send out these surveys while having the ability to customize the daily questions based on what is required for the day.

Replacing a staple is really hard as it turns out

When you are trying to directly replace an option, the product you are creating must provide significant improvement to the old way. If it’s not an improvement, why use the new way? Well as it turns out, stand ups are more complicated than they appear. There are different teams, owners of those teams, and every day needs a new stand up that could have new circumstances and new questions that need to be asked and answered. As well, there is a need for possible immediate feedback to how a team member responds to a question. This leads to something a lot of develops may have encountered over the years, a dense data structure. With how dense our data structure was, our backend had to deal with a lot of complexities to allow our frontend, including us as iOS folks, to get the needed data. Then once it was set up, it required a lot of hoops to jump through in order to actually use this data.

Getting it right in the future

Our current product has been plagued by data model issue after data model issue. Every time we thought we would have structured, an important change would surface itself at the last moment. Once we were able to sit down and talk with our backend, we were able to finally get a structure that will sit in place for long enough to do lasting work, but this talk should have happened much sooner. We were able to get the wizard for topic completion done during this time however. Not all work was lost and non-permanent.

We still need to look into finishing joining topics and then sending out survey requests from the topics but we are on a good track. I can foresee some structuring issues popping up more as our data model is very deep and complex. I’m excited about his project though because I have never done more custom decoding before and it has given me a great chance to try out complex solutions and realize how strong of a tool it is.