Our working, living and even resting culture is constantly improved with simpler solutions, and apps play a great role in that process. We at Monterail are often amazed with some of the brilliant ideas our potential clients bring to the table, thinking – how does one come up with something like that? We like that the part before we get the spec is a wonderful mystery of each individual project, but what happens after – is our field of expertise.
When we receive a specification, we break it down into a plan, often asking you detailed questions about your product and when we are happy the shape of plan – we provide you with a rough plan of what needs to be done, estimate of time and budget and suggested team that should work on your project.
After we have a “go” from you, we dive into writing Cucumbers to have more precise understanding of the feature. (If you are wondering how a cuke looks like – please have a look at our QA team introduction.) This tool is a part of behaviour-driven development – a methodology we employ in our development. Cucumbers to app-writing business are like civil code to attorneys – it’s a book of all knowledge on the subject that we go back to whenever in doubt. First we write down each single functionality of the application in a practical, business-friendly language. We verify each Cucumber with you, taking you, quite literally, step by step in how we see a given function working. Your active participation here will be vital to the quality of your app, and all your guiding, verifying comments are gold to us. After we will have completed this wholesome documentation–we will revert to it throughout the whole project–while designing the interface, writing the code or even automatically testing the app in all production phases.
Mock-ups are a next milestone in bringing your application to life. When all cucumbers compiling to a given view are completed–our designers will prepare a mock-up or two of how this part of the app could look and work like. Mock–ups are less intricate than designs, so they are more convenient to debate and agree on preferable look before we go into more detailed, polished designs.
We are firm believers in agile Project Management, and Jira is our gospel. It shouldn’t come as a surprise that Scrum is our default project regime, however with design process we find that Kanban is more suitable approach. That is mainly because it is still a phase of discovery, where features reveal their true complexity and each should get exactly the amount of time it requires. Each feature has it’s own respective task and at this phase they are either at To Do or Design in Progress stage.
After the design work is done, the feature is moved to Design Review status, when you and the development team are giving it a final approval. If something needs correction, the feature goes back to To Do or,If it's finished, it changes status to Ready for Development and awaits it's turn in the developers backlog.
Once we reach a certain mass of completed designs, the project enters a next phase–we begin the implementation and Scrum comes into rule. What it means is that we will organize the list of our features with completed designs and cucumbers reflecting their business priority; or in our jargon: we’ll prioritize the backlog.
If Scrum puts our work routine into cycles–Backlog Refinement meeting would be the beginning of such. The team of developers gathers to break down to sub–tasks as many user stories as they can and define the workload they will require to complete. First sprint is called sprint 0 and it usually takes about a week. During this sprint, we prepare the foundation for the project–DB, environment, FE base. It’s pure “under the hood”, so you shouldn’t expect to see any deliverables at that stage.
Every other sprint however will focus around implementing user stories and is likely to take 2 weeks. Precedented with Backlog Refinement meeting, we will have a Sprint Planning meeting, when the team grabs estimated user stories from the top of the backlog. Project Manager will monitor the capacity of the team for the upcoming sprint and that the features defined by you as most important will be included first.
When the sprint reaches its end, and development team will be ready to reemerge and present you with what they have accomplished to you at the arranged Demo meeting, usually taking place over Skype or other video conference software. That is another checkpoint with you–do you like what we did and how it works? Is it what you have envisioned? Here feature can be directed to either rework or placed in the waiting line for deploy/release.
At the end of each sprint we also hold a Sprint Retrospective meeting, which gives the team an opportunity to discuss which practices work great and should be nurtured and what we’d do differently next time around. This process of iteration, where we move towards better and reduce what’s hindering us is a heart of agile development and scrum model.
If you are keen on lean product, this philosophy can also be present in your strategy of bringing your product to market. We will help you define what the MVP scope of your product is, and while developing more sophisticated features to your app we will also be able to quickly respond to your first user feedback and market traction. The process is done when you say it’s done.