The first post in the series on hybrid software development talked about general problems many software development companies have during their customer relationship. Contracts are very often based on a linear process as shown below:
In addition, user departments responsible for the requirements and the software may have the need to change the requirements even after they have been finalized or contractually agreed due to several reasons. Some of them are:
- A change in another process requires a change of the requirement
- Some requirements have been forgotten
- A change due to e.g. legal reasons need to be included
Based on the number of required changes projects need to be shifted, deployment dates need to be moved or projects already started need to be cancelled.
In the last decade agile development tried to get rid of some of the challenges mentioned above. Based on the “Agile Manifest” a lot of development processes have been designed that try to solve the problems mentioned above. As a result, requirements are created at a rougher level at the beginning and later on detailed during development at the time when they are really developed. In recent years several of these process models have been designed, namely Scrum, FDD and others.
In recent years it has been seen that even those approaches have raised questions and concerns. Some of them are:
- They do not follow enterprise processes (as enterprises are very often stick to linear processes where there’s a contract required with a fixed price offer based on a detailed specification)
- Very rough requirements at the beginning might cause legal intervention in case of later delays not non-wanted results
- Customers (and requirement engineers) need to be more involved during the complete development process.
- Processes like scrum or other agile methods tend to deliver software in more frequent deployments (to reduce time to market). A software delivery with intermediate (and therefore changing) features need a high amount of change management. This becomes heavy if you use a complex software on a high user base.
- Team building is a more complex process as agile teams with a given velocity tend to react negative to changes in stuffing.
We have designed a hybrid process which tries to overcome (most of) the concerns described above and create a model combining the best out of the two worlds (classic and agile).
The hybrid process will change each of the process steps above in a way to achieve a possibility to create flexibility during development for a fixed price project:
- Requirements: Allow fuzzy requirements that remain estimatable
- Contract: Enhance the contract process to recognize fuzzyness and allow reserves
- Develop: Agile (e.g. Scrum) and allow refinements
- Deployment: (Usually) only one deployment towards the customer
- Acceptance: Acceptance based on requirements and refinements
This process has been established now for medium to large projects for at least three years with increasing success.
Further posts will discuss details on every process step and will provide more in-depth guidance.