This week I worked with five other cohort members to produce a web app from a given specification. The app was a simple clone of AirBnB called MakersBnB. The GitHub repository is here.

We self-organised our days with standups in the morning and retros in the late afternoon. We used Trello and GitHub issues to keep track of tickets, and used a branch/pull request workflow to add features.

Together we identified a minimum viable product from the given spec, created user stories from this, and then produced CRC cards to model our classes and database structure. Each user story became a ticket on our Trello board, which we then implemented through TDD and pair programming.

We used retros to improve our processes over the week. During one retro we decided that we needed to do more planning of each user story to avoid overlap/duplication of work. From then on, we split each user story into tasks in a checklist on the Trello card. We categorised the tasks by model-view-controller, and distributed them based on this to avoid overlap between pairs.

We also decided that we needed to do retros better. At the start of the week, our retros were just informal discussions about what went well and what we could improve. We started using a retro board to drive discussion and allow everyone to contribute, which also meant we had concrete action items written down.

On a personal level, I think I could have improved by helping my pair partners keep up with what I was doing. Too often I glossed over things or went too quickly, which was hard to keep up with. I should try to explain myself better when pairing so that my partner can contribute.

At the end of the week, all teams demo’d their project and then we had a cohort retro. The retro allowed teams to share what worked well for them and what didn’t. One thing I liked from another team was setting up a contribution guidelines document detailing how to branch, how to pull request and how to review. I think this would have helped everyone feel more confident to contribute code.

Another good idea was identifying learning goals. In one of the teams, everyone chose a topic they wanted to learn about over the project (e.g. databases, OOP), then tasks and user stories were distributed based on these learning goals.