Creating Our Method
Ever since we began operations a little more than two years ago, our endeavors have been dedicated to realizing the idea of @marcus_lindblom – the source behind the Strife initiative. We made the decision early on to take things slow and steady, instead of bringing in investors right away and going full throttle. So to keep the lights on and fuel our efforts, we decided to combine the development with offering our services to others part-time.
This definitely presented us with some challenges, like figuring out how to keep our focus while juggling multiple tasks. And therefore we had to come up with a way of work that is fast and flexible yet thorough enough to ensure high quality in our product. And we find it hard to believe that we are the only ones facing this kind of challenge so we thought we would share our method with you all.
Development cycles
When starting a development cycle we want nothing but the best conditions for our team. We want the team to be able to create momentum and focus on the important tasks ahead. This is hard. Life is busy. But we try to cancel as many unrelated meetings as possible and make sure everyone is finished with any previous work and obligations before starting the cycle. After each cycle, there is a cool-down period where team members have the time to catch up with other work.
We also don't set a fixed amount of days in each cycle. We scope work for a 1-2 weeks period depending on how busy our current schedule is but we are always aiming for finished and shippable work before ending the cycle. All because we have a strong belief that task switching and leaving work unfinished is bad for both your stress level and our product's progress.
Each cycle follows the same routines. We're not a big fan of long meetings, although we could talk for hours if given the opportunity, but we do need to do some proper planning before jumping straight into the code. Therefore we have a few cycle routines that we try to follow in order to get the work done in the most efficient way:
Think it!
Sketch it!
Engineer it!
Build it!
Ship it!
1. Think it!
The Briefing – We always start with a short briefing to bring everyone up to speed, setting the scope and ensuring that everyone on the team has a basic understanding of the feature. Don't linger but take the time to make all necessary preparations and break down tasks to a reasonable size.
2. Sketch it!
At the drawing board – In order to make sure everyone has the same idea of what to expect from a feature we need to create some kind of visualization. Regardless if it's a full-blown design, mockup prototype, or just a few lines drawn to a piece of paper it will help create an alignment in the team. A few things may very well change along the way. You should probably count on it. But it's not that big of a deal, the most important thing is that we are all on the same launch pad when it's time for blastoff.
3. Engineer it!
The Blueprint – Once we know the WHAT it's time to decide the HOW. By creating a very rough technical blueprint of the feature we agree on how things will work, what techniques to use and what unknowns that must be further investigated. It's also important to consider what other parts of the application may be affected or could be utilized. The most important thing when creating this blueprint is to spark team collaboration and benefit from the combined team experience and expertise before writing the first lines of code.
4. Build it!
In the workshop – While developing we don't want to waste any time getting the feature out to our users. User feedback is crucial and let us know if we're on the right track. So we want to maintain a good speed and avoid getting stuck on details. Therefore we follow these, perhaps familiar to some of you, principles when developing a feature; Make it work, Make it fast and Make it beautiful.
Each principle defines a milestone that should have a shippable outcome and we always aim to include all three principles in the same cycle but depending on the feature's size we may have to revisit the feature later on to fulfill the rest of the principles. The feature is never considered done before we have worked through all three principles.
Make it work
With this principle in mind, we expect a shippable feature that is robust, gets the job done, and checks all the criteria of the feature spec. It may not be the fastest version of itself, the code could still use some cleanup and there could still be some details or cosmetics missing. But at the end of the day, we should be able to introduce the new feature to our users.
Make it fast
Performance is important. Really important. And with this principle in mind we try to optimize the feature for speed. We want a lightweight impact on the application and a feature that feels natural and easy on the user. Lightning fast. No spinners. No waiting.
Make it beautiful
We want a feature to feel almost magical. We always try to walk that extra mile and surprise the user with super smart features that will make their work fun, easy and powerful. We also want clean code, a clean interface, and not too many WTFs on the code review.
5. Ship it!
Make the world know – The most exciting part of our work is when we are able to release new features or improvements to our users! We try to automate as much as possible of the deployment to make things run smoothly and without hassle. This way we can deploy often and easily roll back if something went wrong. Since we aim to release every cycle some features may not be 100% done, in those cases we use feature toggles to try out the feature only on a small group of users. During this phase, we also create a change log and update the documentation for everyone to see. It's also a great opportunity for us to share any insights and gather ideas for future blog posts.
Summing it up
We believe that using this method allows us to maintain a balance of speed and structure. It helps us to focus on what is important without losing sight of the bigger picture. Additionally, we use roadmaps for long-term planning and a triage system for managing ideas, perhaps I may delve deeper into these topics in a future blog post.
I hope you found this blog post interesting and perhaps even sparked some new ideas for you. If you have any questions or would like more information, please do not hesitate to reach out to us. We are always delighted to share our insights and ideas with our readers.