If you’ve been a reader of our blog, you’ll notice a common theme in a lot of our posts: Change. Whether it’s related to the company, the culture, the product, we’ve had to adapt along the way in a number of facets. Given we’re an early stage start up in the cryptocurrency space, things tend to change rapidly, even the way in which we are building our product.
When we started with our MVP for YEN, we stuck to a fairly structured Agile based framework in our Software Development Life Cycle (SDLC). Here’s a snippet from our two week life cycle that served us well when we needed to churn really quick incremental updates to our product.
Week 1 (of 2)
- Mon: Day #3 of Sprint Cycle (“SC”)
- Tue: Day #4 of SC
- Wed: Day #5 of SC
- Thurs: Day #6 of SC
- Fri: Day #7 of SC
Week 2 (of 2)
- Mon: Day #8 of SC // Sprint Planning (Plan goals for next sprint, assign tasks)
- Tue: Day #9 of SC // Business Requirements (Decide technical solutions matching business logic with engineering requirements) // Code Freeze – “
Cinderella Deploy” (changes allowed up until midnight PST)
- Wed: Day #10 of SC // Deploy to Development / Staging Branches
- Thurs: Day #1 of New SC // Master Deploy from Staging to Live // Sprint Retrospective // Goals for Next Sprint
- Fri: Day #2 of New SC
In the beginning we got really great, fast feedback from our Co Builders and we were able to turn it around in small time frames. We had a resident Agile expert on the team so it made a lot of sense to go with that. But as the product got (a lot) more complicated and the features needed more time to evolve, we made the switch from Agile to more of a Kanban approach. This was the case with Platinum Dolphin which required six months for us to rebuild.
This is a tricky balancing act because you want to allot enough time to work through build cycles but you don’t want to lose that momentum of turning out requested updates with regularity. With Dolphin we really took the time to firm up our launching pad so we’re stoked now to get back to our regularly scheduled programming. We’re still going to go with a Kanban/milestone based approach keeping rad codenames vs Sprint XX naming but these should be much shorter in scope. On the surface it may seem like we’re going back to the Agile methodology of planned development cycles but we’re going to have a little more flexibility. With Agile, we were married to two week development cycles but with the milestone approach, we could have two or three (or more) week-ish cycles. The cut off won’t be date based but feature and milestone based.
This also allows us to get back into a MVP and iterate approach as well. This is where we absolutely love our community for working with us on the process. We’re going to churn out a bunch of updates, test some assumptions, and get feedback on how we’re doing.
An example of this was the introduction of Community Groups with Platinum Dolphin. We made setting up a CG as easy as we could to see how the community would use that feature. Well turns out quite a bit because we had over 180 CG’s started on YEN in under two weeks! While we were able to validate our hypothesis that people wanted to start up groups, we also found out quickly that seeing all 180+ CG’s on one screen isn’t that great of an experience. We even made the decision to not launch with the ability to delete CG’s initially but rather focus engineering time to make it as frictionless as possible to create a CG. So while it’s easy to create a CG, it’s impossible to delete one. But we’ve heard the feedback so the ability to delete a CG along with other usability updates around GS’s are moved higher up the priority list. If you’ve got one you want to delete, hang tight it’s coming soon!