We talk to startups and investors, you get the value.
Rocket DAO ecosystem
There are plenty of various methodologies - approaches in different ways of working on IT-startups. We have already made a review of the most widespread classic and flexible methodologies. In this article, we are telling about the peculiarities of methodologies that are not quite well-known in our region of approaches.
We talk to startups and investors, you get the value.
Getting Real (GR) is a methodology which is designed especially for startups and teams-beginners. GR implies using all unique features of small projects and companies such as mobility, flexibility, pursuance of new solutions and optimizations, null bureaucracy and rude, tangled hierarchy to the maximum.
Jason Frid and David Hansson, founders of 37signals company (now it is named Basecamp — a software development company and the creator of the self-titled tool for project management), also used this methodology. In their variation, Getting Real is a simple, clear and functional system for solving real tasks.
Getting Real includes all the best approaches of flexible methodologies, which are adapted for small-scale projects with small teams.
Here are some GR work techniques:
1. Do less than competitors.
If your competitor’s product has 1000 functions, you can create 50 but they will solve the main user problems. It allows saving resources and helps to attract clients with simplicity. Other features can be developed afterwards.
2. Finance your project on your own.
When you attract money from investors, you will think about how to return it. In such a way, when you’re working on the project, you will be thinking about how to make fast money, not about how to make a good product. Set the priorities and think about what you and your co-founder can do for your product — perhaps, at first, you would deal without external specialists.
3. Follow the limits working in FFF conditions: fix time, fix budget, flex scope.
Set up two parameters and make the third one flexible — this is how 37signals made the scope open while having time and budget fixed. If you don’t cope with some work volume, try to think how important this feature is to your product and if it is important, how to optimize its development.
4. Figure out/find your enemy.
When 3 signals were developing Basecamp, they chose Ms Project as their “enemy”. The team tried to create fewer functions, having left only the most important ones, but implemented them in a way the product became more useful than MS Project.
5. Stay small.
Avoid staff expansion, extra meetings, long sprints and overly long-term goals for as long as possible. Try to get your work done so that each team member is able to work in a multitasking environment. Smaller sizes allow you to easily change directions, listen to your customers and respond to them quickly.
For our region, Crystal is a not well known family of flexible methodologies. The author of Crystal methodologies is Alistair Cockburn, one of the authors of “Manifesto for Agile Software Development”. In the Crystal approach framework, the emphasis is made on the result, not on the process itself. The main objective is achieving the required characteristics and not following the procedures. Crystal priorities are safety and development effectiveness.
Choosing a specific Crystal methodology is defined as a number of people in the team and it is described by the colour names. If a team consists of 2–8 people, then Crystal Clear methodology will suit you perfectly; if it consists of 10–20 people — Yellow; if there are from 20 to 50 people — Orange; and if there are up to 100 people in the project — Crystal Red. Crystal Maroon, Crystal Blue, Crystal Violet methodologies are more suitable for large-scale projects.
What do all Crystal methodologies have in common? All projects that are developed by this approach correspond to three indicators:
1) Fast working code delivery which is achieved by short integrations;
2) Perfection through reflection — the new version of the software is made on the basis of previous data;
3) Good team communication;
In Crystal philosophy, the development of a software is understood as a series of peculiar games (=iterations) when the team being in the situation of limited resources, invents an optimal solution for a task. Each game has two goals -to create a software (=increment) and to get ready for the next game (=iterations).
Crystal has its own custom strategies. Here are some of them:
Researching at 360°. Before starting working on the idea, the team considers the project in the following directions: business value, general requirements, required technologies, project plan, the line-up of a team, chosen methodologies. It helps to understand how useful the product is, how well-thought-out is the idea and whether it is possible to create the project with available resources and technologies.
Early win. Creating the first working feature of the future project. When the team creates this feature, it becomes their first victory so this kinda knits together the team and increases the confidence of each project participant in its successful completion.
Exposing the visual information about the project’s workflow and the achieved progress in open access. This allows keeping all team members up to date on how the project is developing and gives people the opportunity to discuss the current state of affairs.
Feature-driven development (FDD) is a development process, which is managed by functionality. The concept is that the work on the project is divided into short iterations and at the end of each iteration, a new feature (a useful function) is added to the end-product.
Apart from the majority of flexible methodologies, in FDD you pay more attention to preliminary modelling, reporting and diagrams. It is one of the main advantages of the approach: in the result, you will have a working product, as well as the full documentation of all completed processes. This means that at any moment, you can provide the full report about what has been done so far. Another advantage of the approach is that all errors are detected in time thanks to short iterations. The main goal of FDD is to develop useful and functional software in time.
The model itself formed in 1997. It was offered by Jeff De Luca when he was searching for the appropriate methodology for software development for one bank in Singapore. Back then, he masterminded an FDD prototype which consisted of five processes:
Developing a general model — the team offers several variants of task solution and then chooses the most appropriate one;
Creating a list of useful functions;
Planning and risk analysis;
Design and development;
FDD methodology perfectly suits long-term projects.
Test-driven development (TDD) or development through testing is based on repeating short development cycles. At first, the test is written and after that the code itself, then goes refactoring with a constant check of passing all the tests.
TDD is an organising process of automated testing for applications that are under development, by writing modules, integrative and functional tests, which define code requirements immediately prior to writing this very code.
Development cycle by TDD:
Create a test for new, unrealised functionality;
Conduct all the tests and make sure that the new test doesn’t function;
Write a code which will provide this functionality;
Conduct the refactoring.
Advantages of the methodology:
A well-built architecture of the applications under development
Applications work stably due to the fact that the performance of all program functions are constantly checked by tests
Developers don’t afraid of making changes in the code as in case of any mistake or error, they will be defined by testing results
BDD is a part of TDD where technical and business interests are combined. The development process goes as follows: at first, the team describes the desired result from the added functionality, then a test is written and only after that the code is written. Functionality is described as follows:
As [the role of whose business interests are satisfied] I want [a description of the functionality the way it should work] in order to [a description of the benefits].
Large-Scale Scrum (or LeSS) is a set of rules and principles that are drawn out from the Scrum methodology for increasing the organisational flexibility by simplifying its structure. In plain language, it’s when the whole company works by using scram not only the developers.
Guidelines of the methodology:
Scaled Scrum is Scrum: scrum at the organisational level is still the same scrum, not a scrum superstructure that one of the teams works on.
Whole Product Focus — the whole product is in focus, not only its parts. The whole organisation works on one product, in such a way, all employees are coordinated and cooperative.
Lean Thinking — LeSS has a lot to do with lean manufacturing (Lean at Toyota). This means that you work by the principle of continuous improvement. The introduction of a new function does not end when the function is developed and included in the project. With each iteration, it will be developed and improved. In LeSS, change is a constant phenomenon, the norm by which an organisation works. The processes of improvement, experimentation and learning are ongoing.
The methodology was born in 2005 when Kraig Larman and Bas Vodde, Agile-manifesto developers and Scrum authors, started experimenting with flexible approaches in large-scale products.
LeSS helps to avoid odd roles in the team. Often, it is hard to resist the temptation to create more specialized roles (for example, architect, release engineer, many options for mid-level managers). Assigning clear responsibilities to these roles separates people from the team. LeSS reduces the number of roles. Smaller division leads to more independent management within the team and, ultimately, to the greater flexibility of the organization.
If scrum doesn’t suit you because of too many roles and required processes, and kanban seems way too easy, you can turn to other flexible methodologies.
The Getting Real methodology is ideal for startups as this approach involves working in conditions of limited resources. What you may consider as your weakness — for example, the fact that your team has only two or three people, in this methodology fits as the standard advantage that allows you to develop a really quality product. According to the Getting Real methodology, each team member works in a multitasking environment by default, and the product is created based on the analysis of a competitor’s strengths.
Crystal Clear methodology is from the family of Crystal methodologies and it is also usually suitable for startup development. The emphasis in the methodology is on achieving specific goals. Development happens in a short iterations mode, and the team-communication must be well established. If you haven’t been able to set it up yet, the methodology offers a number of ways from which, you can choose the best one. This allows you to work without being distracted by any side tasks.
Feature-driven development is quite a well-known methodology that involves developing from “feature” to “feature”: each new iteration adds a new “feature” to your product. Each function should be given a name because this action is aimed at simplifying the process of developing and classifying software functions. In any case, keep in mind that neither the big money of investors, nor your ambitions, will not help you find a solution and create an interesting, and most importantly working product without the right methodology.
Test-driven development is finding a solution through the testing process, in other words, when the test is created first, and only then — the code itself. Among more than 10 variations of TDD, there is one that is most used, namely Behavior-driven development — this variation involves a preliminary description of future functionality in the user-language, after the description of actions — writing a test and only then the code itself.
The last but not the least, LeSS methodology, or the so-called “large-scale scrum” — assumes that “scrum” is used not only by developers but also by the whole team. This methodology has been tested at Microsoft for a decade, and now you can see the great benefits of using this method, which makes Microsoft one of the leaders in the market of technologies.