“Lean” is a buzzword that has been making the rounds in the startup world for a few years now. There have been numerous books written that talk about it. Some prominent ones are The Lean Startup, The Startup Owner’s Manual, The Lean Product Playbook. The spirit that this word conveys is very simple though. It essentially wants to minimize wasted efforts and resources. While being Lean is vital in the startup industry, it is a philosophy that should be leveraged everywhere. The software service industry is no exception. How many times has a software product needed to be majorly reworked or disposed of because of incoherency between the requirements and the final product? How many times have products been disliked because of the way the User Experience was designed? A lean approach to creating software for clients can mitigate such issues and bring numerous gains. Let’s understand this using the illustration below. The diagram illustrates two methods of assembling a bicycle. The Lean Method makes certain that the bike is usable in the very first stage. A customer can try using the bike and see if it does what is expected of it. And then, at every subsequent stage, improvements are made, features are added and feedback is elicited from the customer. It is possible to draw out high-quality feedback because the bicycle is usable at every stage. The General Module Driven method on the other hand does not make it possible to use the bike up until the final stage. This introduces huge risks if requirements were misunderstood or miscommunicated. The whole bicycle may need to be recreated from scratch! The following process can help keep a project lifecycle extremely lean and help mitigate any wasted effort or resources. Problem Statement Development A problem statement is the north star which holds the key to guiding the product development direction. Before getting into any details of any project, it is extremely important to understand the problem that is being solved by the product. Once the problem is clearly understood, the probability of any kind of miscommunication at any point in the project is greatly reduced. Requirement Gathering Once the problem statement is clear, the next step is to dive into the business details of the project. We want to understand the functionality, features, desired user experience and expected timelines of the prospective project. The process is iterative, i.e. we do not need the customer to worry about getting every little detail correct from the start. This process takes into consideration the fact that requirements can change at some stages of development. Prototyping Once there is some consensus on requirements, the next step is to pinpoint the user experience the client is looking for. This process begins with having a conversation about the look, feel and flow of the user interfaces. Once there is some understanding formed, a low fidelity UX prototype needs to be created. This kind of prototype is easy to create and quick to iterate on. Feedback about it will be elicited from the client, and based on this feedback changes will be made. Once there is agreement on the low fidelity UX prototype, a high fidelity UX prototype will be created and delivered to the client. On approval, we go to the next step. Feature Minimization After the UX is approved, the next step is to prioritize features based on their vitality keeping the problem statement in mind. In this step, we start eliminating features from the bottom of the priority list and come up with a set that will be contained in the next milestone. It is important to make sure that the set of selected features should come together to form a usable version of the product. Every time after these feature sets are released, it is important to get customer feedback. We need to constantly come back to this step to add additional features from the list and also make changes based on customer feedback. This method will reduce wasted effort and resources by making sure faster feedback is received on implemented features and their user experience. Milestone Release Actual development towards building a working product begins. This product will contain features decided in the feature minimization step, in addition to any features that have already been developed. Every milestone release is treated like a proper end release, with relevant documentation about the product & technical details delivered to the client. Project Delivery Once all the milestones are released, the client should be able to see and use the finished product. Additionally, training and complete documentation — technical as well as business — need to be delivered. Also published on: https://betacrew.medium.com/a-lean-approach-to-web-mobile-software-development-can-save-you-time-and-resources-when-hiring-a-f0fc7ad37e0e
