Startup Jedi
We talk to startups and investors, you get the value.
Become an author
Settings
Sign Out
When you decide to launch a tech startup, sooner or later you will be faced with the choice: how to create a product. Is it worth planning all stages thoroughly and carrying out them step by step? Or is it better to work with short iterations so that you can track your performance and make timely corrections to the future prototype? Or split the work into several independent parts, and allocate a separate team for each of them? The answer lies in choosing the right product development model or methodology. There exist dozens of different models, and each of them has its advantages and disadvantages. In this article we are considering the most popular of them.
Startup Jedi
We talk to startups and investors, you get the value.
A product development model covers all the phases of product creation and involves everything that happens at each of these stages. For example, in the case of software development, the project usually goes through six major phases. They are:
Planning. We define what we are going to do and what problems we will solve. We set goals, find out what resources we need to implement the project. We study the market and competitors, and work out alternative variants of product development.
System analysis. We determine and document end user’s requirements. What expectations do our customers have and how can we fulfill them, if ever?
Design. We define the system elements, its components, security level, architecture, interfaces, data types. We design and discuss.
Development and implementation. By the beginning of this stage, the design has been already agreed, the development stage is coming. We complete coding, configure the system according to the requirements and functions. The system is ready to be installed and launched by the end of this phase.
Testing. In the end we determine whether the product functions as designed or the results turned out to be different. System testing is performed automatically, as well as is undertaken by a team of experts. We also offer potential users to test the software. We identify defects and detect bugs in the program and eventually rectify them.
System maintenance. We prepare and release system upgrades, evaluate system performance, remove/deactivate obsolete components.
This scheme is typical and varies depending on the way the development goes, on the specifics of teamwork, budget and product features. It is here where you should choose the suitable development approach, which is generally divided into classical and flexible.
Here is the list of traditional development models:
Code and Fix often known as Cowboy coding (coding, checking and fixing errors),
Waterfall (the project flows through all phases consistently),
V-Model (system testing is conducted simultaneously with a development stage),
Incremental model (the project is broken down into multiple components, the team prepares each of them successively and produces a final total system),
Spiral model (implies a thorough study of risks),
Iterative model (first the core model of the project is implemented, then iterations on its improvement follow),
RAD-Model is Rapid Application Development model (high-speed product development).
Traditional models assume an emphasis on sequence, timing, and final product requirements.
As for flexible models, we use the well-known Agile methodology. When we prepare a product using a flexible model, our project and requirements can change during each iteration (flexible model, when the project adapts to each iteration), and there are no timelines, the work can be carried out endlessly — you have an opportunity to constantly improve the product and add new functionality to it.
Finally, development methodology is applying a model in practice. Thus, Agile has a range of widespread methodologies: from nimble Kanban (when a team works with a task board) to rough Scrum and XP.
Now let’s look at more detailed characteristics of each of the above mentioned models.
...
It’s one of the oldest development models: it’s very simple and will fit startups with a small team and no special conflicts of interest, with a clear view of goals and understanding how to achieve them.
How does Code-and-Fix work? We know exactly what we want to do. We start programming, then we see the results. We find all software bugs, fix them and repeat checking until the program starts working properly.
Advantages of Code-and-Fix: you do not need to waste time on product planning, documentation, meetings.
Disadvantages: sometimes fixing a single error causes breakdown of the whole system. As a result, you have to rework it again and again. That’s why long ago programmers who were tormented with this development model decided to move away from its ostensible simplicity and invent a new model.
...
Waterfall or cascade development model became one of the first appropriate options. It is a traditional rigid and highly controlled model: you have a plan, budget and you follow through all phases in strict linear order.
The process of product development goes step by step: you study the requirements, design the product, develop it, test it and then maintain it. A new stage can’t begin until the previous one has been completed. The biggest problem of this model is that errors made during the requirements and design phases are very difficult to correct — both financially and technically.
Waterfall model is good at developing a product that is very similar to any other: you have a prepared sample and you just copy it. Thus the cascade model is suitable for startups that don’t develop an absolutely new product, but create an improved version of the existing solution. The main thing is to avoid mistakes in calculations.
This model is used in the development of programs for construction, medicine, work with government contracts. In terms of non-software products, the cascade model is used for construction of large objects.
Chuck Cobb, the author of books on project management, described this method succinctly:
If you were building a bridge across a river, it would be ridiculous to say, “We’ll build the first span, see how it comes out, and then decide how to finish the remaining spans!
Indeed, such objects must have a pre-approved plan, layout, prototype, and normally changes are not envisaged.
The Cascade model was applied by the Cisco company to develop security systems, IBM, Microsoft IT and even Toyota.
...
V-Model is an improved version of the Waterfall model. Unlike the latter, V-model focuses on thorough product verification and testing already at the early stages of its development. In this case, both processes run in parallel. Prior to moving to the next stage, everything that was done previously is being verified. All found errors are eliminated and only then a new phase of work on the product follows.
Testing begins at the stage of requirements gathering, for each corresponding development phase there is a directly associated testing activity. Besides, the development of testing strategy for the next level goes in parallel with the testing of the current one. When creating tests, the expected test results are defined and the entry and exit criteria for each stage of product development are specified.
You also need planning here and a clear requirement analysis. What’s more, there must be software testers in your team — the model will not work without them.
...
Using this development model, you decompose a product into a number of separate components — increments. Each part represents a finished fragment of the final product, which ideally is not altered.
We get several development versions — a kind of “multi-waterfall” cycle. Each version is divided up into smaller modules, each module is divided into phases: requirements gathering and specification, designing, coding, implementation, testing.
This model allows you to manage risks and to get a product to the market early even when all the planned functionality may be still at the design stage. Startups use the incremental model if they have a common understanding of what their end product should look like.
...
This model is similar to the incremental model, but has one significant difference — risk handling. The spiral model is used for large high-risk projects, where failure may lead to company’s closure.
According to the spiral model to develop the product special scientific research and evaluation is often carried out.
The spiral model has four phases: planning, risk analysis, design, evaluation of results.
This model is quite expensive and comprehensive for small projects, but it can be used for medium and large projects, especially if you are afraid of going bust.
The spiral model is best used in startups with unclear and complex requirements. So working iteratively and managing unknown risks through each phase of this development model, you can safely release the product to the market and then gradually refine it.
GanttPRO Case. GanttPRO is an application for project and task management. Its development was based on the principles of the spiral model and also the Agile — Scrum framework, which is described below.
The developers have chosen rather short two-week delivery periods in order to be able to get more frequent feedback. A detailed plan describing what to develop for the first iteration and how to assess risks was created. For example, before the first iteration, each developer commented on what might not be implemented and why. In addition, the team focused on reducing risks caused by quick adaptation to the needs of the users and the market.
...
You don’t need to have a full specification of the requirements to start working with this model. To develop the product you, first of all, create a basic working functionality. Thereafter at each iteration you improve the product by adding new modifications.
An iterative model can be compared to the picture when we draw a sketch, from which you can see what will be depicted. With each step we add new colors and transitions. In the end we get a finished picture. And in the case of a startup, it’s a final product.
The model is suitable for startups that want to enter the market and attract customers with rapid turnaround.
“Scooter” Case.The iterative model in the figurative sense can be illustrated by an example of vehicle development. The result of the first iteration can be a scooter. This is an example of transport, though as simple as possible. The result of the second iteration can be a scooter with an electric motor, the third iteration — an electric bike, the fourth one — a motorcycle. Thus, at each iteration, the functionality of the product bolsters.
Let’s compare the development of the same vehicle in accordance with the waterfall model: we will get the transport at the very end, after all stages of the project have been completed.
...
It is a type of incremental model. It appeared in the late 80s and became one of the attempts to create a flexible development process.
A customer is involved in the process at the earliest stages — he participates in the development and evaluation phases. The main feature of the RAD model is that the project could be easily divided into a series of smaller parts that can be developed in parallel by several teams if necessary.
The main pro of this development model is speed and the con — financing.
...
Agile is the most frequently used flexible development model in IT world today. It promotes continuous iteration so that you can discuss product functionality with the users and in accordance with their feedback you can make changes to the original product vision almost at any moment of work.
The minus of such a model is that due to the constant improvements and additions the project budget may end and the finished product may never enter the market. The benefit of this model is that there’s no detailed planning and clarity of the end user’s requirements. Besides, you don’t need to have a complete budget and calculate all the risks.
Agile has many variations and frameworks. Among the most well-known are Scrum, Kanban, Extreme Programming (XP), Lean.
...
It is one of the Agile methodologies. The Kanban method relies on the principles of lean manufacturing, based on the desire to eliminate all losses — losses of time, production, logistics, and quality.
The backbone of Kanban lies in just-in-time delivery of functionality and equal distribution of the load between the team members.
In practice, each project task is written on a separate card and added to the board — virtual or real. The card and the board are integral elements of Kanban. All the tasks to be done are collected in a special column, it can be called “to do” column. An executor chooses the task and moves it to the “in progress” column. When the task is implemented, it is placed to the next corresponding column “done”.
There may be much more than three columns, for example, columns on the board can look like this: “a list of work” (backlog), “already agreed” (ready), “coding”, “testing”, “approval” and “done”.
There are a lot of tools to improve team’s productivity and workflow efficiency in accordance with the Kanban method. Some of them can be read in the article “Collaboration tools for startups.”
Toyota Case. Kanban methodology was introduced at Toyota. Managers of workshops listed the works that were being accomplished on paper and hung it in a prominent place. Thus a Kanban board (one of the main elements of this methodology) appeared.
An annual car production and sales plan has become the main pillar of the Toyota production system. It is used to make monthly and operational plans for the average daily production at each site. These calculations in turn depend on forecasts of customer demand.
The methodology is built upon the “just-in-time” principle. It allows us to adhere to precise timing of tasks and eliminate production defects in a timely manner. For example, daily checks of inventory stock reveal faults or downtime.
...
It is one of the most popular Agile methodologies. Unlike Kanban, Scrum consists of much more elements — different meetings (from daily five-minute meetings to sprint planning, demo), a clear division by role. In addition, the development is divided into sprints — which last from a week to four weeks and end with the release of part of the product.
In English, scrum also has a meaning of “a fight” or “a crash”. The term came from Rugby and refers to a specific game situation in which the ball is introduced into the game after the violation of the rules and team members all push together in a circle, with their heads down, and try to get the ball; the task of players is to win through the team’s joint efforts.
Almost the same process is applied to Scrum methodology in software development: a team of cross-functional specialists jointly implements the project. These professionals should be highly motivated, proactive and ready to make changes both in the execution of the project and in the product.
Let’s review how to use Scrum in a practical case:
During the product development phase, you and the team decide which member will become the product owner — a person responsible for communication with the consumer and investors (if your investors are interested in the progress of product development).
A product owner creates a wish list for the product, collects primary information from possible users and then generates a product backlog — a list of tasks that will eventually lead you to market entry.
Your team defines the length of the sprint (a timebox at the end of which you should make some working piece of product) and selects the tasks for the first sprint from the backlog.
During the first sprint, you monitor the quality and quantity of your work. Daily short (5–10 minutes) meetings form an integral part of Scrum. In these meetings team members tell what they are planning to do in a day, share the emerging difficulties or, conversely, the successes.
The progress of the tasks is displayed on a scrum board, where all tasks move from the conditional position “needs to be done” to “accomplished”.
At the end of the sprint, you demonstrate the delivered part of work and collect feedback from the team members, clients, including potential ones.
The sprint cycle repeats until the product is completely finished.
...
Extreme Programming (or XP) is one of the agile development methodologies that emerged in the late 90s. The authors took “best practices” of software engineering to extreme levels — hence the word “extreme” appeared in the name of this methodology.
Unlike Kanban and Scrum, which can be used in different startups and businesses, as well as in personal activities, XP is applicable exclusively to software development. Within extreme programming 4 basic activities of a project are distinguished: coding, testing, designing, listening. This methodology is mainly characterized by efficiency, high quality, and teamwork.
At its core, XP suggests using several practices. The most famous among them is called Pair Programming. Its essence requires two developers work jointly on the same code: the first programmer (the driver) writes and the second one (the observer) reviews code and fixes mistakes along the way, then they switch roles. Thus, there are two alternative solutions in the process of code creation; the best one is selected at each stage. Pair programming operates on the principle: two heads are better than one.
Another distinctive feature of XP is that you write tests first, before you create the code. Meanwhile, the tests are written by the programmers themselves. Testing allows you to correct most errors at the stage of code generation.
The third feature is collective code ownership: each programmer in the team has access to the product code and can make changes to it. In case the changes lead to the system crash, the programmer who made these changes must fix everything.
XP also involves the delivery of the software via small releases, which may range from one day to one month. In this regard, the shorter the release is — the better the product quality.
Finally, the integration of new parts into the system is as fast as possible. Once the tests have shown that the function works correctly, it is integrated into the system.
...
As we can see, even if you think that you are working “no muss, no fuss” without using any methodologies (in fact, this is spelled out in theory), most likely, you are working according to the Code-and-Fix model and probably will soon encounter all its drawbacks. To avoid them, it is important to analyze the product before starting to work on it and together with the team to decide on the phases of its development. To choose the sweet spot, you should consider the following questions: whether you have already formed specific requirements for your product or you are planning to improve the product while working, what budget you have and how cross-functional your team is, how long the project is running and how much funds are left.
There is no ideal model and no ideal methodology, but you can choose the one that will allow you to maximize the chances of successful work and eventually bring the product to market.
Facebook: facebook.com/StartupJedi/
Telegram: t.me/Startup_Jedi
Twitter: twitter.com/startup_jedi
Comments