If somebody should ask me what the most important trend in production development in the telecom industry is, I would mention the modern focus on software instead of hardware. Thanks to all the technological innovations, hardware is mainly just an eye catcher, while the real functionality of a device – for example a business IP phone multicell system or PBX system – is dependent on its software nowadays.
Therefore, consumers buy a product because of what’s inside and this requires a new approach of product development processes. While most telecom manufacturers make use of the so-called waterfall method as sequential design process for processes, including software development processes, they should rather switch to an agile method to make sure they’re ready for the future and make sure they’re able to add customer feature requirements in an early phase of the lifetime of their products.
Waterfall versus agile
The waterfall development method consists of various defined phases, like conception, analysis, design, construction, testing and implementation, and states that one may only move to the next phase after completion of the previous phase. Therefore, a new product is launched with all features included. On the other hand, during an agile development process you bring out a product as early as possible with minimal functionalities. This way, customers can use the product in an early state and provide the manufacturer with feedback very early after the first version of the product brought to market. Finally the product will be developed closed to customer needs for business success.
Flexibility at its best
In our modern software-oriented world an agile product development process has various benefits in comparison with the waterfall method, including flexibility. Development based on the waterfall method takes a lot of time before customer feedback to the product, and for programmers and developers it’s hard to implement customer oriented requirements or design adjustments in the meantime. The process is sequential, so once they’ve completed one step they can’t go back to a previous step without starting the whole project from nearly the beginning. With an agile method, programmers and developers work in small modules, allowing them to test and evaluate a product step by step and make adjustments where needed.
Earlier release, less errors
Flexibility is not the only advantage of an agile method, quality also plays an important role. Think of the waterfall method – with one testing phase at the end of product development – compared to an agile method – where you constantly implement both manual and automatic testing procedures during every development stage, including feedback from end users. The result? Earlier discovery of bugs and errors, and the possibility to incorporate customer feedback into the design as early as possible. In other words, a more flexible, efficient and faster testing procedure resulting in both an earlier software release AND less errors at the end of the product development phase. That’s what I call killing two birds with one stone.
People – your most important investment
One important, extra focus point for me during an agile product development process is the team. No matter how flexible or qualitative your process might be, without the right investments in your team you’ll never win the award for best product. That’s why you need to make sure your process matches the needs of employees. For example by integrating a feedback moment after each development stage for team members to indicate if they have the right input and technology requirements to do their jobs. And if you start with the development of a new product, it’s important that employees have the right knowledge and capabilities. One way to realize this, is by providing product demonstrations, workshops, tips from other production locations or self-training – everything to guarantee the best preparation for new product development.
Concluding my argumentation for an agile product development process in the telecom industry, I want to point out that this not only applies to software development. Although hardware development is hard to do step by step – you can’t ask end users to evaluate only half of a housing after all – there are always possibilities to integrate your hardware working method into your agile needs and the other way around. Just do it!