Over the last couple of months, we have shared our journey to develop and implement a more flexible approach to project management. We have shared how a combination of Agile and Waterfall allowed us to overcome the challenge of our business environment. We have shown how we were able to drive adoption through the definition of critical success factors, and we have explained how active portfolio management will ensure the health of all our in-flight projects.
Now, as we stand at the finish line, we are already looking on to the future. Having implemented our new solution, our drive for continuous improvement kicks in once more. As we finish refining one area, another becomes a candidate for improvement. Are there any elements that have the potential to grow? Are there any areas that still need refining?
When we began the process of developing our new approach we were certain of one thing, we wanted some degree of agility.
For this initial improvement phase, we maintained an emphasis on continuing to use Waterfall but with the addition of Agile elements. This meant we would continue to view systems as a whole, planning the entire development upfront and working through to verification and validation. Maintaining this element of rigidity and preemptive planning helps ensure the traceability required for systems that require a safety case.
Though the adoption of certain ceremonies has allowed us to become more Agile, the agile movement has a lot more to offer than we are currently using. Our desire to become more agile challenges us to deliver value, that is in terms of working software, to customers as early as possible. It questions the approach of specifying everything upfront, building large chunks of software, testing it all upfront and taking a long time to do it.
Would we be able to determine an alternative, agile process that could be applied to particular project types? Could we still develop robust, safety-critical systems if we were to develop them as a series of ‘features’, i.e. slices of working software? If proven to be possible, we would be delivering features to customers for them to view and test earlier, rather than having them wait longer-term for whole components to be developed and integrated.
Continuing in the same vein, we may attain greater value in embracing more DevOps principles in order to reduce cycle time.
One aspect of DevOps that we have an interest in adopting is that of Continuous Integration and Continuous Deployment. Where newly developed code is regularly merged into a central store and automated builds and tests are run and deployed in either a testing or production environment. If implemented correctly, the team will always have a deployment-ready item that has successfully passed through a standardised testing process.
Would we be able to implement a process that allows us to integrate and deploy our software at more regular intervals, and allow our clients to see functional software more frequently? However, we are already aware of a few potential challenges. For example, how could this process be applied when working with embedded systems, where software has to be flashed to devices?
As we said in our article covering our use of critical success factors, we decided to limit the quantity of our initial factor set to ensure a successful change. Through continuous consolidation, their application has now become second nature for all of our engineers.
Having reached this point of consistency, we can begin the introduction of the additional factors in a continuous cycle, constantly running through the process of identifying an area for improvement, implementing and embedding the change to reach a point of consolidated consistency before looking on to the next thing.
Following the success of this initial improvement process, we are keen to keep the momentum going and push for even more. However, we will have to take care to strike the right balance between improving the process and just following it, recognising that it is “good enough”.