This blog post belongs to a couple of (yet to be written) posts about hybrid software development processes. please follow the blog to get updated with the latest blog posts.
At the time we’ve started our company some 10 years ago agile methodologies had not reached the development mainstream at software development companies or IT departments. At that time we decided to go the “classic” way by using an iterative waterfall (see here pg. 329f – fig. 4) approach.
Learning about agile development and new team members made us moving towards Scrum in 2009. The agile approach gave us the flexibility we’ve looked for and we liked the innovative chances of this new process.
We ran a couple of projects with Scrum, some went well, some did not. We learned a lot about success factors, advantages and disadvantages.
Analyzing the project results we had seen there were a lot of cases where we had a clash between the classic “request” > “offer” > “order” > “produce” > “accept” way of handling projects towards the customer and the agile process. We learned that it is difficult to apply the Scrum process all the way to the customer. Customers often prefer the classic approach, especially when it comes to timing, outlines and the commercial aspects of a project. On the other hand late changes in a development project are often requested.
With the waterfall process late changes are difficult to cover, with Scrum they are easily implemented but do have negative impact on time and budget. This negatively impacts customer satisfaction and causes uncovered expenses and delays.
We thus tried to merge the advantages of the waterfall and the scrum process and created our own hybrid process using parts of both methodologies:
- Towards the customer we stick on a classic linear process (iterative waterfall) to have a known and established way of communication towards our (mainly) enterprise customers and
- internally use Scrum as the development method to allow flexibility in respect of work package building and
continuous evolving of requirements into stories and tasks
This process even allows the customer to incorporate late changes as long as
- the requested requirement to be changed has not been developed already and
- the change fits into budget, time and quality constraints.
There’re some other constraints but basically these are the rules.
If one of the above rules are not matched, even then the change might be accepted but in this case we have to come back to the customer and explain him that this change will have side effects (budget, time, …) and the outlines (schedule, price, etc.) of the project need to be changed However many of the smaller changes that occur in almost every project can be covered without any commercial change.
The next blog post will discuss the overall process followed by blog posts related to specific parts / topics related to the process itself.