A program or software can be created by anybody, but what sets it apart is the capability coupled with maturity to understand and create one that focuses and solves real customer problems delivering a seamless experience. A successful software is not just a line of codes that are written but the pain that it aims to alleviate through those codes. Eventually, software development is just a tool to solve real business issues since that’s exactly what a customer pays for.
At FieldAssist, we strongly believe in solving problems as opposed to just features and as a practice, we have ingrained this philosophy in our day to day work that equally reflects in our processes that we follow to build a better SFA app.
Business First Approach (DDD)
Domain Driven Design is the core of our development process. It allows us to center our thinking in terms of business problems first followed by implementation challenges. DDD is about trying to make your software a model of a real-world system or process. Following this approach, we first start with a domain expert to model the real-world problem in a language that everyone understands.Our development team then starts working on the software using this model.
DDD approach gives you a client’s perspective while developing a new product or adding a new feature to the existing product. This keeps us aligned with the business strategies of our customers. It adds the domain experts to the team of the product development and thus prevents any scenario of ending up with a product that is practically useless . An important aspect of DDD is the way communication takes place between the Developer and Domain Expert.
A system of common language is created so that the communication flows between the domain expert and development team in a language common to both. Confusions and misinterpretations are prevented during the project period hence improving our productivity and the quality of deliveries. Simultaneously, this makes it simple for everyone including the stakeholders to keep track of requirement implementation all the time.
Iterative Design/feedback based development
Today, it is quite common for big projects to get delayed or even fail completely. To make matters worse, most of the times, it is quite acceptable and usually seen without any frown. The reason for the same is trying to anticipate every problem in advance when the dynamics are changing rapidly. By the time the project ends, it is already obsolete.
At FieldAssist, we understand the ever changing nature of our environment and take an iterative approach that allows us to deliver with high standards and significantly less chances of failure. In Iterative design, as the name implies, Instead of specifying the entire application before-hand, a part of it is planned, designed and tested in the real world scenario. The feedback is collected in the process that is further used as a basis for future developments. This ensures that any deviation is detected early in the process and losses are minimized due to wrong understanding of requirements.
With iterative design approach, we are able to deliver a robust product at a significantly less cost and time. Other benefits include early detection of serious misunderstandings and inconsistencies among requirements saving a lot of effort and frustration. The continuous user feedback allows us to focus on critical tasks and let them prioritise over non-critical issues at a point in time. This opens up the possibility of an objective assessment of the project’s progress to the stakeholders throughout its lifecycle.
How we achieve this:
Agile Process/Scrum:
At FieldAssist we follow Agile principles to achieve the above. Agile software development professes the MVP mode of development by ensuring a short development cycle, continuous feedback system scope readjustments.
Scrum is our toolset to implement it. It is a lightweight process framework for agile development, and the most widely-used successful software companies like Google and Microsoft. Scrum uses Sprint for its Iterative and incremental development process implementation.
This allows our developers not just to be concerned about writing code for adding a feature but commit themselves in understanding and solving the problems of Customer for which a particular line of code has to be written. There are many systematic approaches which could help any team achieve those goals and Sprint is one of them.
Sprint Planning
Sprint is a set period of time during which specific work has to be completed and kept ready for review. A Sprint Meeting is organised based on the plans of product team (product owner) for the next fortnight. All the problems of the clients which are to be resolved in next 2 weeks are discussed in a 2-4 hour meeting every week. Product owner shares all the issues which they have gathered and prioritised based on discussions with client, Customer Success team and Sales team, in the form of user stories with the tech team. Along with the user stories product owner also puts an acceptance criteria which contains precise expectation of the solution to the problem described in the user story.
The solution is discussed in details with the tech team and they come up with a technical feasibility scope along with resource requirement in form of story points (estimated effort) for taking the backlog item in the sprint. If all goes well then the task is added to the Sprint. The development team has the final say when it comes to determining how much work can realistically be accomplished during the sprint, and the product owner has the final say on what criteria need to be met for the work to be approved and accepted.
Daily Scrum
After a sprint begins, the product owner steps back and lets the team do their work. During the sprint, the development team holds stand up meetings (scrum meeting) daily to discuss the progress and to brainstorm solutions to challenges. The product owner may not make requests for changes during a sprint and only the scrum master or the project manager has the power to interrupt or stop the sprint. The 2-5 minute stand-up meeting is done everyday at 5 pm to discuss days work and next days plan. All impediments and interteam dependency issues are resolved here.
Sprint review and retrospection
At the end of the sprint, the development team presents its completed work to the product owner who uses the acceptance criteria established at the sprint planning meeting to either accept the work or suggest improvisations from the User Acceptance Testing (UAT) done during and after the sprint period. Once UAT is completed the feature is handed over to the product team to release it further in steps.
Backed with experience, we firmly believe that a product development and enhancement centric approach where all stakeholders are included right from the idea inception stages is bound to be successful. At FieldAssist, we put in a lot of effort in updating ourselves with the latest developments around us. The essence of our solution lies in the fact that we focus on the relevance of a product while developing one and not build something with multiple features that may appear great on the surface but doesn’t bring in any business value to our stakeholders. DDD, Agile and other methodologies therefore, keep our processes in constant check to be relevant to our clients and to our market.
About Post Author
