SEPTEMBER 4, 2018
3 min

Why we don't use a fixed scope

article7

In everyday life, buying products and services is often a clear cut process. You know what is being offered, you know how much it will cost and the exchange can be made relatively simply.

Software development should be treated differently, but it’s still perceived in the same way as buying a fridge or cable TV subscription. We’ve built a lot of tech products, and here are some common questions we get:

  • How long will it take to build the product?
  • How much will all these features cost?
  • What features will be built in the next 6 months?
  • Can we agree a 12-month roadmap?

We try to educate our Founders and partners about a better way to build software. We do this because all the questions above revolve around the common misunderstanding that having a fixed scope is less risky than paying for development time.

Here are some reasons why we don’t commit to fixed scopes and always recommend early-stage start-ups to find a tech partner that offers a full-time Agile development team rather than fixed feature delivery:

 

Start-ups need to stay agile


Y
ou need to be able to change your mind about how something works, or what your product does. You will talk to potential users and your team, you will learn from other products, you will have ideas. If you are signed up to an agreed scope then you will not be able to change what is being delivered without bureaucratic change request processes and re-estimations. If you are paying for a team, then their priorities can be changed almost instantly if that’s the right thing to do.

You are more likely to get the product you expect


If you are agreeing on a fixed scope, then you need to decide, design and finalise every aspect of your product upfront before any development starts. This is very difficult to do as there are too many unknowns at the start of any project. With a fixed scope, you will have to wait and hope the final product gets delivered working and looking as you imagined months earlier. With Agile development, you can check in regularly and course-correct often, so expectations on both sides are continuously aligned.


You can get essential feedback earlier


With Agile development, your team will constantly be working to deliver value in small incremental chunks. This means that within a few days or weeks you can have real, working software that lets you complete some flows within your product. It might not be the final version, but even the simplest flow can be put into the hands of potential user to test if the value you expected is being offered and if your product is usable, desirable etc. Any feedback you get can be put back into the team immediately so they can adapt and change things while working on the next version. The alternative is waiting for months before getting the whole product delivered and hoping that users respond well to it when they see it. If you need to make changes after the whole product is built then everything becomes harder, slower and more expensive.


It’s more efficient


Software estimates are infamous for being inaccurate. This is perceived as developers covering their backs or agencies trying to win contracts or squeeze more money out of clients. However, as building tech products usually involves creating something new, it is very difficult to accurately estimate and predict what might happen in the future once work starts. The only way to accurately estimate how long software will take to create is to basically write out the logic and code… this is very time-consuming. At Founder + Lightning, we would rather your team’s time was spent building a product and dealing with any unknowns that come up, instead of spending days trying to provide detailed estimates that will more than likely change once more information is available.


It encourages you to prioritise what is important to your business


As mentioned in point 3, a good Agile team will break down a product scope into layers of value and work on delivering working, valuable user flows in increments. This means that you can decide what is most important to your users and business and work on this first. Doing this means it can be delivered sooner and tested. If you have agreed to a fixed scope and delivery, then the team can decide to work on whatever part of the product is best for them first and fill in the rest later. Agile development forces the whole team to work on what is best for the users first. The great result of this is that you can keep re-prioritising the things that are best for your business and users, and it doesn’t matter if the low priority things never get done because your product is always working and always delivering more value.

Those are just a few reasons why we believe you should work with a tech partner who offers you a team rather than a fixed scope. The only stumbling block is that for time-based development to work, you need to fully trust the team is always working towards the correct goals and are pushing to deliver the maximum value to your product.

We’ve found the best way to guarantee trust is by being 100% transparent with what we are doing and why. This means exposing our development tasks to Founders, sharing our work every day, never hiding any of our code and putting full-time people on all our products.

Sign up to our

Newsletter

Subscribe to get articles, guides, templates and event invites direct to your inbox once a month.

Top