Do you think about building a reliable product with the smallest risk and reasonable budget at the same time? Wondering if it’s even possible? In this article you will find the answer on how to achieve this goal.
Through nine years of developing projects for our customers, we’ve determined several effective processes that meet the requirements mentioned above. Our operating model is based on the Agile Methodology and by applying its premises we were able to develop software in the way that provides flexibility and supports partnership during the whole process.
At Future Mind we use Time & Materials pricing model, so our customers can be sure what they are paying for. We calculate our costs basing them on the number of hours put into the project and tangible effects of our work. We believe that in the process of delivering innovative products other existing methods of collaboration don’t deliver expected results as well as those implemented by our team. In the following you will find out why.
Agile approach is based on the following assumptions:
People and interactions more than processes and tools used,
Up and running software more than detailed documentation,
Customer collaboration more than contract negotiation,
Responding to changes more than project implementation plan.
These assumptions, which are included in the Agile manifesto, accurately reflect how this approach could be used in the software development process..
Project implementation based on the Agile Methodology is divided into sprints. A sprint is a short period of time (usually two weeks) during which a planned scope of work is done. Each sprint begins with the analysis and creating the so-called sprint backlog, which is a list of features or scenarios that need to be completed during the sprint.
Then it’s time for the designing, programming and testing process. To make the work smooth, the team organises daily stand-ups, which are short meetings designed to inform everyone about what’s currently going on. Each team member is trying to answer the following questions: What did I do yesterday? What will I work on today? Am I blocked by anything?
The result of two weeks of work is a new version of a tested and working product. Each iteration ends with so-called sprint review, during which the project manager presents the results to the client and then they discuss them together.
When you work in the waterfall model the project is implemented in successive stages. This means that each subsequent stage can be pursued only after completing the previous one. The following outline shows the differences between the agile and the waterfall approach.
The pricing method will also vary depending on what kind of project management models you choose. The Agile Method comes with the Time & Materials model, which means there’s no fixed price and detailed specification in the contract. You pay only for the hours spent on the project and for the real effects. Of course, we’ll stick to your budget and help you with estimating it.
On the other hand, the waterfall methodology comes with the fixed price model, which means the total price and specification are unchangeable, no matter how much time the project actually takes.
The Agile method sounds interesting, but you’re still not sure if it works for you? Most of our clients had the same feeling before our joint journey with the Time & Materials model. And we bet your concerns are quite alike. Bellow you’ll find a list of the most common doubts encountered by us:
Our work is based on agile approach, which doesn’t mean that we don’t make development and financial plans or don’t manage the risk. The main difference is that the budget is defined as the value that “shouldn’t be exceeded.” When Using Agile it’s possible to verify whether this assumption was accurate right after the first sprint. So, if necessary, it’s easier to make changes in the project, modify the way of implementation, project complexity, priority, or even planned scope.
You can track the time developers spent on their tasks with 15-minute accuracy. The time report, which shows the number of hours spent on development, allows you to fully control the resources used in the project. What’s more, we jointly define the exact scope of work to be done and estimate it before each sprint. This means that you have full control over the project and get the expected results for a fixed price.
We’d rather not set a rigid total price because valuing new digital products is very difficult due to their innovatory nature, specific requirements and unpredictability. Thus, the valuation process includes estimations which are only predictions for feature creation time. In fixed price model the contract budget is always just an estimation. This means that agencies add extra budget to mitigate possible risks and make their project affordable. This financial cushion could range from 20% to 100% of the real value.
Let’s dig deeper into the valuation process and imagine the following situation:
Let’s say that the software house’s estimated budget for the project is $100,000. Do you know what’s behind this price? In fact, the real value of the project could be $90,000 or $110,000. That means you can either lose $10,000 or major software features. Which one is worse?
Believe us, you would rather choose to lose money than get an application that lacks necessary features. But how does it even happen that customers receive defective products?
When an IT company notices that the project exceeds its budget it tries to reduce costs and finish the project earlier than previously planned. In this scenario, you can forget about high code quality, testing process or bug-fixing. You can even be sure that your project will be finished by junior developers or interns.
Note that creating a product usually comes with development work planned for after the product launch. When customers underestimate developers’ time it’s only natural that the latter offer them higher prices for subsequent things to make their work worthwhile. Do you feel a bit uncomfortable now?
There’s no question that you should pay only for the hours effectively spent on your project. And it’s possible in T&M model.
You have control over the entire process so you know exactly what you’re paying for. What’s important, you’re sure that each sprint comes with the design work, development and testing process. In result, you can rest assured that you’ll get a fully reliable product every two weeks.
When you sign a contract with the predetermined scope of work, you must create an entire specification before starting the project (and it may be time-consuming). In practice, you’re writing down all the features that spring to your mind.
There’s, of course, nothing wrong with this approach. Yet, you can’t be sure if you need all these features or you can come up with new ideas during the project. From our experience, we can see that it’s a typical situation and when clients choose a Fixed Price Model, they see some bumps on the road when they want to change the scope of the project.
Keep in mind that you can end up with a product that has many “nice” features but lacks useful components. It usually comes with the need of modifications which require contract and price changes.
In Time & Materials model you don’t have a strictly written specification in the contract, so you can add new features in every sprint. How is this possible? The product is being built in an iterative way, which means valuable work is finished even after the first sprint.
Product features are added during every set period, not all at once. But the product still fulfils its assumed role. The entire process is split between various stages and you can start using the product after each iteration. This means you can regularly show it to your board members, investors or clients and get their feedback.
Everyone knows that the best ideas come to mind when you assume the role of the end-user. It’s easier to test the features and find a way to make everything work better. You can change the initial requirements or project priorities, improve some elements on the go and simply add new ideas to the backlog without renegotiating the contract and wasting your time.
The following pictures accurately illustrate the difference between agile and waterfall approach..
As you can see iterative approach gives you the opportunity to see the big picture as early as the beginning of the project. In the waterfall model it’s not that easy to guess whether the work is going in the right direction because you only see a part of it.
Product creation based on the Time and Materials model comes with reducing the risk to the absolute minimum. You may be sure that you won’t pay for the mark-up caused by inaccurate estimation.n.
To make it clear, the difference between the client and the software house can be illustrated when compared to a soccer game. When you sign the contract with fixed price you both play on opposite teams — the agency tries to do just as much as needed to make a product with certain features. You, on the other hand, require the best possible quality within agreed budget. Yours and the agency’s priorities are completely different, so it’s not that easy to build a valuable product (or score a goal).
In the T&M model our common goal is to create the best software that will not exceed certain budget assumptions. We monitor each team member so you can control your budget in real-time. When, for some reason, your priorities change, we can simply reduce the costs and finish the project within two sprints. You’ll then get a 100% tested and functional product without any additional penalties.
Now, let’s assume that the work is based on a Fixed price model and the budget is reduced by 35%. What’s the result? In this case, the work is finished at the end of the programming phase, when no function has been tested yet. You’ll receive a useless product because the code is built upon code at each stage.
Waterfall model lets you earn money on the product only if it’s fully implemented. This means you need to spend the entire budget. A huge flaw is that you’re able to start collecting customers’ feedback only after receiving the finished product. Too late, don’t you think?
IT projects also come with high technical risk. When one is using the agile approach the product is tested in every sprint. That’s why it’s easier to fix any errors, make changes to the project, modify the way of implementation, project complexity, priorities, or even planned scope.
Remember that projects can take months or even longer than a year. It’s obvious that during this time new and better software development technologies may appear on the market. The agile approach allows us to change the specifications and implement newer technologies to make the most effective and functional product.
One of the principles we follow to create products is trust.
After 2 weeks of our cooperation you can give up on the project and decide that you don’t want to pay the hourly rate of a specific developer or even quit all of them. As a result you end up with no product at all, but it can help you avoid any financial risks.
When you decide to continue the work after the first sprint you can still break the project after a 4-week notice period (equal to 2 sprints). Our cooperation with clients is based on the Agile Methodology, which we also use to manage our company. We believe that potential non-payment for two weeks of work is less risky than incorrect evaluation of an innovative product.
Want to ask us something? Don’t hesitate to drop us a message at firstname.lastname@example.org