Makers Academy — Week 6

🔧Building MVP (MakersBnB) in a group 🔨

This post is going to be looking into XP values instead of the coding skills we’ve learned or revisited in Week 6

As an extrovert, I always have enjoyed working in a group. Coming from a technical project management background and certified as AgilePM practitioner, I thought this week will be a breeze and my assumption was far from the reality 😅

From design to completing the build, it took more than just application design and coding skills to get there. Our group set up the project goals for the week mainly to learn and enforcing XP (Extreme Programming) values and here’s the score we have assigned on each value with at the end of the MVP build.

👥 Communication = 3/5

We gave ourselves 3 out of 5 in communication because despite we were constantly communicate, it lacked structure. Whilst impromptu meetings were great for instant feedbacks, we favoured them and neglected the retrospects and morning stand up to discuss anything beyond the feature building and testing. It led us to the dilemma outlined below:

During design, two ideas were presented for implementation of a feature and we didn’t come to a decision at the end of design phase. The implementation was left in the backlog until almost the end of the project. The feature was assigned to team members but the assignees didn’t understand how to proceed for quite some time.

Upon our reflection on it, both implementation ideas were presented only verbally, and each opposite side didn’t actually understand their opponent’s idea at all hence it wasn’t able to be resolved in a timely manner.

Diagramming 📐 would’ve been a great tool in presenting ideas (conceptual or implementation) to the group. Going forward, we will have diagramming as one of our most essential tools in building a MVP.

👍 Simplicity = 3/5

We gave ourselves 3 out of 5 on simplicity due to the lack of time of refactoring the code and the lack of research we took during the design phase. Whilst we maintained on keeping the code clean for the individual features delivered, we didn’t spend much time to look into various methods to keep the overall implementation simple and modular.

Dan, our coach gave us some great tips such as keeping our controller light by using facade pattern, and assign heavy lifting along with some DataMapper configuration to consider as well.

The main takeaway for me, is that design techniques investigation session 🕵 ️could’ve been very useful to ensure design is well thought out for the MVP. As Sandi Metz said, the first way design fails is due to the lack of it.

💪 Courage = 4/5

We gave us a higher score for courage, as we took a more unconventional approach in working together. We spent more than 1 and a half day coding and configuring the setup together in a group of four. That certainly was the secret sauce for our success in having almost no merge conflict, and having a fully built working MVP in just five days. The courage from the pair which raised their hand and ask for help within the group is a quality I greatly admire as well.

🗣 ️Feedback = 4/5

We also gave us a much higher score for feedback because due to the incredible feedback on the pull request on each feature, we reach almost 100% test coverage for our MVP. Beside that, the group was constantly discussing the production code quality during code review. From that, we learn from each other on writing cleaner code and getting the balance right with refactoring and picking the next feature to build.

🙏 Respect = 5/5

We were immensely proud that everyone agreed that our team was very respectful towards each other. Everyone contributed and difficult discussions happened in a constructive manner. We came out of the process not only gained knowledge in learning to build an MVP, but learning from each other on all of the XP values.

Thank you Byte 2 for an amazing week!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.