Once upon a time there was a hybrid program. Starting with 2 years of business and process analyze for good preparation. Then time was slowly getting really critical because there was nothing realized at all … so the program started very quickly as a mix of agile and classical projects. The projects were organized in a classical program structure for scope and budget controlling and in parallel by a Kanban delivery alignment. At the end a kind of hybrid too. The high-level scope and budget was defined and approved by the program. The program expected high efficiency of developed components. All business function should only be created once and be reused form all other projects afterwards. The detailed processes, data and interfaces were to be developed by the projects themselves. Alignment was expected in a self-organized Kanban standup. The agile projects soon started realizing and setting standards that way for nearly everything- master data, interfaces and detail processes. There was not much documentation or process models expected while realization. How could the classical projects react on this? They quickly started the development phase after a brief conception too. There was no chance at all to check if the concepts were consistent, important pieces in the puzzle were simply not defined that time. To just start was of cause very welcome because of very high time pressure. Everyone was delivering something working inside the box and which should work together inside the context at the end of development phase. The End2End test could be started after final delivery short before golive. That’s normal in classical development. To figure out that nearly nothing was working well tougher the quality to be poor and highly fragile was of cause very frustrating discovery at this point of time. The complex software maintenance and support made bad things even worth. No real happy end for this fairy tail
Can hybrids of agile and classical be successful at all?
There are two main ways how agile and classical project can work together without negative interference.
Way 1) Classical Start: Specify the whole architecture and processes on a detail level (classical) and develop some software components agile. Benefit in relation to a full classical program? Not much – only some components could be done quicker and maybe have a higher quality. The needed time is more or less the same, the budget and scope too.
Would this approach be helpful for the described case? Not really, time was the most critical parameter. The knowledge to specify everything would have been a theoretical solution, the knowledge was not existing at that point of time.
Way 2) Specify Master Data and Interfaces hard and make sure that the modules can work independently. Speed over Efficacy. The software components must be able to work indecently on all data they need. As few as possible interfaces and interactions between the modules. This is the architecture for an agile program, only the realization in some areas is allowed to be classical. Changes on master data and Interfaces would be monitored by a very formal and highly aligned Change-Process. The benefit is speed and the disadvantage are higher cost and less efficacy cause of duplicated business logic. Would this have helped the above described program? Yes, somehow. Surprises at the end would have been less and smaller but still to be expected. Due to late testing there would have been no chance to fully avoid surpriseses.
Way full agile) What would have really helped?
Clear agile architecture of highly independent software components including master data handling and micro service architecture. This would have changed the complete system architecture. All projects would have to be run full agile and the program would have to conduct the business processes to be developed simultaneously and be tested early and continuously. The business processes would have been ranked by delivery criticality. The complete system would always run integrated. This would have had a high impact on all deployment and QA Processes. High test automation from day one would have been mandatory. Would this solution have been realistic? Unfortunately not, the agile mindset was not strong enough.