Entrepeneurship, Innovation, IT is business

Have you already tried to buy software per sprint?

June 28, 2019

Lack of understanding of business by IT and of IT by businesses may still be one of the main issues when building software. 

Main issues on buying fixed scope/price software

The main common thoughts when somebody starts to think about creating some software is that it will be something similar to any other stuff we buy. How much will it cost? And how many time will it take to be done?

I’m trying to demystify the bad comparison between building a house and building software that commonly takes places during these conversations.

Software is a baby

We tend to think that building software is similar to building a house or a tower. But this parallel/analogy is impossible nowadays. For centuries, houses have been built and the process has reached a maturity that it’s possible to put all the information in 2 or 10 blueprints, and everything the buyer said he wants will be there well described.

Softwares have been created for less than 100 years (since the 1950s) and until today there is no way to put all the information on a document that can be followed from the very beginning to the end. Invariably, the documents have a macro vision of what is wanted with the pages described. But, as an example, what should happen when I hit the button “notify user”? Does it send an email to one user? Or does it triggers a background processing involving AI looking for all the users that match the current data and send them a push notification on their phones?

PMI addresses this scenario writing huge documentations with plenty of details following the PMBOK. But only some software have this level of detail. For the entire rest (the biggest majority I’ve seen during 10 years on IT) companies can’t afford the investment for having this level of detail.

Different complexities

Back to the analogy of houses. When you are building a house, the level you reach when designing the architecture (similar to the requirements document in software) will be the walls, plumbing, electricity, network and etc. But at that level, you don’t describe how the house will be decorated (the UI on software). How many paintings will be there? Which will be your sofa? How many inches will have your TV? Your kid’s room will be Superman or Batman’s?

Obviously, this is not described because people will have different opinions on how to decorate the house. And these opinions change from time to time. When talking about software, sometimes these UI behaviors are just not described at the level they should be.

The migration to agile

Given the scenario above and after severe issues developing software, eventually, companies start the migration to agile. Currently agile is the fastest approach to address the issues that come when a scope is not clear/detailed enough. Gartner (ID #G00325642) says that the main barriers for the change from fixed scope / fixed price to agile are:

  1. Sourcing and finance:
    • Sourcing: It’s hard to tell how much the software will cost. In organizations structured like having a hard sourcing process, this will be one of the main challenges.
    • Finance: the organizations have their financial operations structured as price per project. Budgeting for treating the software as a product instead of a project can be complex in some organizations;
  2. People’s routine adaptability / culture / mindset:
    • Be prepared to face challenges on people behavior when migrating to agile. It’s a new way to work, and everything new creates resistance.
    • As one of the key features of agile development, the ability to adapt your software alongside its development is essential. When applied to organizations changing, some issues will arise:
      • Since the scope can be changed at any time, people may fall on the trap of keep trying to reach perfection on some requirement and spend too much time on it, instead of moving to next requirements, making the entire cycle slower.
      • In some times, it’s easy to lose the UX pattern, as the features that have already been delivered may have functional or design differences from the next ones;
      • Managing people will have different KPIs to measure performance and quality. Finding the right ones to your project won’t be quick;A

A hybrid approach

The more flexible the scope is, the bigger the risk is for the client. The more fixed the scope is, the bigger is the risk for the vendor.

A good hybrid model between fixed scope and 100% agile can be the purchase per sprint/phase (Gartner, 2017 – ID #G00325642). You will need a big picture of the project to use this model. Starting from an initial internal estimate of price and time, the client will be able to go for the market and call vendors to produce the software. The software production will be done sprint per sprint. Every new sprint beginning has a new deal. What will be inside this deal is:

Anatomy of a per sprint deal:

  • Start and end dates (2, 3 or 4 weeks are good to start);
  • Price for the sprint;
  • The stories to be delivered;
    • Every story must have a clear DoD (Definition of Done);
    • Every story must be detailed enough for the team to work on without blocks.

For this model to work, the product owner has to have the autonomy to sign. This cannot involve an entire cycle of procurement.

The benefits

Developing projects per sprint puts the risk balance somewhere closer to the center. And here I list some key important outcomes of the change: 

  • For the client:
    • They can stop the work whenever they want without long term contractual strings;
    • The client will be able to apply new business decisions whenever he wants;
    • The client will be able to respond quickly to market and competitors changes, without having to wait for the current project to finish and then start an entire negotiation once again;
    • If something is delayed from one sprint, it will be the vendor’s responsibility to solve without generating new costs;
  • For the product (software):
    • One of the key benefits of flexibility is the possibility to involve more people that are experts in some specific process. Then the product will fit better what the users want, and not what a group of people (like the old project manager and system analysts) think they want;
    • The product will be flexible to respond fast to business decisions and users feedbacks;
    • Practices focused on finding innovation can be turned into a routine. Running design sprints, inceptions, usability testing, and user interviews are some key practices that would be done without affecting the project continuation;
  • For the vendor:
    • The vendor will have clearer information to work with. Less double understanding of requirements will happen;
    • The vendor will have more flexibility to turn into more like a consultant, bringing knowledge from many different projects. Both technical practices and business decisions will benefit;

You Might Also Like

No Comments

Leave a Reply