During the last years, at Kokoen, we have specialized in creating mobile applications while reducing to the minimum time and costs of the development. Here is an overview of how we have achieved it.
Understanding the client needs
After receiving a client request, the first thing we want to define is what the client really needs to build. This may be very different from what he wants to create, and it is for sure, very, very different from what he says he wants to create.
Copyright © www.projectcartoon.com under the Creative Commons Attribution 3.0 Unported License
The best thing here is not to waste time with non-ending conversations and documents with a lot of technical specifications. Writing the requirements is a good idea, but mostly only to define the "big picture" of what the app should be able to do and some specific desires that should figure on the contract. However, writing all minor technical details in a paper is inefficient since it is impossible to estimate all needs, questions, and problems that developers may have just imagining how the app should be.
Instead, we try to build a click dummy to help the customer and our self visualize what we are trying to do and specify all technical details and requirements working on this click-dummy in an on-going way.
Building a click dummy will help define the requirements better and discover problems or questions that, without a click-dummy, would have remained hidden.
Working Agile – Defining the Increments
Requirements may change and will undoubtedly change. So, why to focus now on elements that may never be coded or, even worse, that may be recoded soon? That's why we prefer to work agile!
Copyright © Andrews McMeel Syndication - dilbert.com
Agile's concept turns the traditional way of working of a company entirely upside down - in the most real sense of the word. Agile companies distribute responsibility away from management to the developer teams. Those teams take responsibility for their own actions. The management gets a completely different role. Control and guidance become support and encouragement for employees (keyword: Servant Leadership). The pyramid is reversed, what is now needed is a broad platform supported from below on which employees can work successfully. Clear goals and guidelines replace small-scale planning, enabling a rapid response to changes and unexpected events.
The control function is taken over by the team itself. Not only does the team monitor the work progress, but it also continually tries to improve, remove obstacles, and distribute tasks sensibly. This is successful when all team members know the goals or visions they are working towards. Ideally, they have even participated in the formulation of these goals or visions.
Three steps quickly lead to more agility:
1. Organize subprojects:
The overall project is divided into sub-projects, each of which generates added value for the customer. It is important that the sub-projects do not overlap so that they can be pursued independently. Each sub-project must be broken down into concrete tasks before it can be processed.
2. Short-term planning:
Only the next and the subsequent subproject is planned since these are the only subprojects for which the necessary details are usually available. For future sub-projects, the available information is often too imprecise; the risk of changes and replanning is high.
3. Take the customer's view:
The partial and overall project result is formulated from the customer's point of view. This way, all team members do not lose sight of the goal and can react independently in the customer's mind if problems arise, whereby customers can be external or internal.
The sum of all completed tasks at the end of a chosen time period (the so-called sprint) is called the Done Increment. The increment is the integration of the currently completed tasks with all tasks completed in previous sprints . We prefer to work with weekly increments. In a new project, there are usually still many uncertainties and unsolved problems/questions. These represent risks for the development because the effort of individual requirements can be estimated only with difficulty. Therefore, it is obvious to work in the smallest possible units, especially if the project is still in an early phase. Do you wonder what the advantages of this way of working are? Here they come:
- Regular reflection of the development process
- Use software productively as early as possible and then expand incrementally
- Present regularly running software to stakeholders
Reducing risks with MVPs
These advantages are also the reason why we work with the so-called "Minimum Viable Product" (MVP), a product with the minimum requirements and characteristics that still makes the product worth using. When developing an MVP, the basic idea is to create a product as quickly as possible, with only the most necessary features. This is then published immediately, and feedback is first sought from (potential) customers. This feedback is used in the following to expand and improve the MVP.
Copyright © Henrik Kniberg - Making sense of MVP (Minimum Viable Product)
Any further functions should be left out of the MVP. Only those functions that are necessary to enable the actual purpose of the product will be included. This saves a lot of time, work, and money.
The main reason for developing an MVP is to minimize risk. If you choose the path of developing and releasing a complete product, many problems can arise.
For example, developing such a full-fledged product takes a lot of time and money. Far more than it would be with the development of an MVP.
Another risk is the development of ignoring the real market and customer needs. If months of development are invested in a product, but nobody wants to have it after release, everyone has just wasted its time and money on building something no one needs.
The development of an MVP, on the other hand, reduces the risk for companies by developing only a prototype with the most necessary functions and initially saves the company a lot of time and money. Besides, early market entry quickly evaluates whether the idea and the product have any chance at all on the market.
Using the best-fitting technologies
Before we start developing, we spent a lot of time discussing which technologies we should use and how the application should be developed - entirely in the spirit of "Weeks of coding can save you hours of planning." The fundamental question in app development is, of course, the requirements and the desired platforms. Combined with the available budget, this simple calculation results in the final development strategy.
There are nowadays different ways of coding an app: Native, Hybrid, Compiled, and PWA. Each of them has its advantages and disadvantages, and choosing the correct one can make you save tons of money and time. You can read more about this here: Overview of App Development Options
Of course, it is not possible to make a generally valid assessment for individual projects. Simple requirements can indeed be implemented web-based and distributed in the app stores via a native framework. Often, however, the current technological limitations push the project to its limits. In this case, a hybrid solution is usually an excellent alternative from a cost/benefit point of view. However, if the requirements are too complicated or elaborate or if you enter the terrain of game development, you can hardly avoid a native development.
Do you have any questions or need consultancy about transforming your idea into an app? Do not hesitate to contact me.
Top comments (0)