For example, do you develop software and firmware only after you've developed and assembled an iteration of physical prototype hardware? Or do you develop an iteration of your software and firmware concurrently with the development and assembly of the corresponding hardware and use other methods such as simulation to stand in for the hardware until an iteration of the physical hardware is ready?
When using Agile project management techniques, it is desirable to be able to rapidly produce and demonstrate a working prototype of your technology and to rapidly iterate and refine and build on each prototype without necessarily having a perfectly engineered product ready to go at the first iteration.
When you're working with hardware, however, you need to deal with the lead time required to source components, to fabricate printed circuit boards, to have prototype layouts assembled by an external pick-and-place assembly contractor or to have custom plastics injection-moulded and so on.
What if the lead-time required for these processes is longer than the time allocated to a particular iteration or sprint? These types of external supply and manufacturing dependencies are unique to hardware, and aren't present in software development - so they present a unique challenge when trying to apply agile methods to the management of hardware projects.
While these constraints may seem like a daunting challenge to adoption of Agile in the hardware engineering industry, techniques and tools such as in-house rapid prototyping, 3D printing, CNC milling of simple PCBs and the like present part of a potential solution, allowing for rapid, agile iteration of hardware prototypes.
A prototype iteration of a hardware system doesn't have to physically involve hardware, either. Simulation and visualisation tools can play a valuable role of validating the design and performance of all the components that come together into a new product, even before a prototype is actually physically constructed. FPGAs and logic synthesis may also be valuable tools here, allowing for validation of soft cores before physical hardware is constructed.
One of the challenges for combined software and hardware development is that software can normally be developed fairly rapidly and the development broken down into smaller iterative chunks. Hardware, on the other hand, may require months to show a working component or feature, which has been implemented starting from scratch.
If the software development must wait for the hardware to be created before final testing, this can create significant testing delays. Hardware must also often follow strictly defined process models, meet compliance standards, and it can be difficult to make late changes to hardware. This means that feature creep can be difficult and expensive in hardware engineering, although Agile methods are traditionally more accepting of "feature creep" compared to traditional "waterfall" management methods.
Traditionally, the priority for embedded software, for example, would be to write the hardware drivers first, to allow evaluation of the new device and to allow testing. Testing is more complex when software must fit within a small, cheap microcontroller with limited resources in an embedded system, with timing well controlled to prevent race conditions and other timing issues. This means that at some point testing on the actual hardware is generally important.
A problem often seen when businesses who create hardware and the software that runs it face when trying to "go Agile" is that they attempt to take methods and practices developed for software (such as Scrum, an Agile project management framework), and try to use it for everything, including hardware development.
Scrum is based upon "sprints" of relatively short lengths (two weeks to 30 days), with highly defined tasks that must be completed during the sprint. The nature of software development makes this an excellent framework for rapid progress; but scrum isn’t necessarily the best framework for hardware development. If the products are in a highly regulated industry, such as medical or aviation hardware, then the documentation must follow industry requirements for specification and design, as well as normal testing and functional requirements documentation.
This makes it extremely difficult to use scrum by itself, since the processes for hardware are frequently much more rigid, defined, and design-oriented than those normally defined by scrum.
On the software side, because software must interface, communicate with, and control hardware, development issues using Agile are more complex for combined software/hardware projects, and the stories (definition of the functions for a specific feature) that the developers define for each sprint are accordingly more complex. Large projects with large amounts of hardware and software dependencies can be even more challenging.
One method of dealing with hardware that isn’t ready to test is to decouple software and hardware development, via an abstraction layer, to allow software development to continue more rapidly. Can the interfaces to the hardware module be specified, and the specifics abstracted away to allow other parts of the hardware and software development to continue around the hardware component that is behind schedule?
The challenge is to find a method that allows the rapid development of software with concurrent development of the hardware, that can best meet the requirements of each process. A good approach can be the use of different Agile techniques for hardware projects than those used in software projects. Agile techniques are not abandoned - simply implemented a little differently, with different specific Agile techniques chosen for the most effective results.
With Commitment-Based Project Management (CBPM), which has been described as an "agile without using Agile" technique with broad applicability outside the software engineering sector, the emphasis is on the delivery of at least a component or piece of the hardware that works, in the case of an embedded computing or other combined hardware-software project, in order to allow the development or testing of the software that will work on that hardware component.
This is very different from the traditional "waterfall" project management approach, where the entire hardware system needs to be built first. While the "scrum" method for software projects is based on sprints with small portions of the software completed at a time, hardware development can benefit from a different approach.
With Agile, both hardware and software features are broken down into smaller chunks - only the Agile methodology can be a bit different for each. Once software is working, it can be deployed either on any available hardware modules that are ready, or in a test or simulation environment.
This allows the early identification and fixing of race issues and bugs that arise, and reduces the amount of “fixing” and lengthy hours reworking that must occur during late integration and testing when the hardware is ready.
And that’s the goal of successful agile development – to reduce the total time required, decreasing errors, mistakes and the chances of unforseen events, which will increase the time to market for your new or revised product.
Here at the LX Group you can leverage our product development expertise and experience for your total benefit. Our consultants, engineers and experts in many fields can guide you to your goal of product success.
To get started, join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.
LX is an award-winning electronics design company based in Sydney, Australia. LX services include full turnkey design, electronics, hardware, software and firmware design. LX specialises in embedded systems and wireless technologies design.
Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.
A prototype iteration of a hardware system doesn't have to physically involve hardware, either. Simulation and visualisation tools can play a valuable role of validating the design and performance of all the components that come together into a new product, even before a prototype is actually physically constructed. FPGAs and logic synthesis may also be valuable tools here, allowing for validation of soft cores before physical hardware is constructed.
One of the challenges for combined software and hardware development is that software can normally be developed fairly rapidly and the development broken down into smaller iterative chunks. Hardware, on the other hand, may require months to show a working component or feature, which has been implemented starting from scratch.
If the software development must wait for the hardware to be created before final testing, this can create significant testing delays. Hardware must also often follow strictly defined process models, meet compliance standards, and it can be difficult to make late changes to hardware. This means that feature creep can be difficult and expensive in hardware engineering, although Agile methods are traditionally more accepting of "feature creep" compared to traditional "waterfall" management methods.
Traditionally, the priority for embedded software, for example, would be to write the hardware drivers first, to allow evaluation of the new device and to allow testing. Testing is more complex when software must fit within a small, cheap microcontroller with limited resources in an embedded system, with timing well controlled to prevent race conditions and other timing issues. This means that at some point testing on the actual hardware is generally important.
A problem often seen when businesses who create hardware and the software that runs it face when trying to "go Agile" is that they attempt to take methods and practices developed for software (such as Scrum, an Agile project management framework), and try to use it for everything, including hardware development.
Scrum is based upon "sprints" of relatively short lengths (two weeks to 30 days), with highly defined tasks that must be completed during the sprint. The nature of software development makes this an excellent framework for rapid progress; but scrum isn’t necessarily the best framework for hardware development. If the products are in a highly regulated industry, such as medical or aviation hardware, then the documentation must follow industry requirements for specification and design, as well as normal testing and functional requirements documentation.
This makes it extremely difficult to use scrum by itself, since the processes for hardware are frequently much more rigid, defined, and design-oriented than those normally defined by scrum.
On the software side, because software must interface, communicate with, and control hardware, development issues using Agile are more complex for combined software/hardware projects, and the stories (definition of the functions for a specific feature) that the developers define for each sprint are accordingly more complex. Large projects with large amounts of hardware and software dependencies can be even more challenging.
One method of dealing with hardware that isn’t ready to test is to decouple software and hardware development, via an abstraction layer, to allow software development to continue more rapidly. Can the interfaces to the hardware module be specified, and the specifics abstracted away to allow other parts of the hardware and software development to continue around the hardware component that is behind schedule?
The challenge is to find a method that allows the rapid development of software with concurrent development of the hardware, that can best meet the requirements of each process. A good approach can be the use of different Agile techniques for hardware projects than those used in software projects. Agile techniques are not abandoned - simply implemented a little differently, with different specific Agile techniques chosen for the most effective results.
With Commitment-Based Project Management (CBPM), which has been described as an "agile without using Agile" technique with broad applicability outside the software engineering sector, the emphasis is on the delivery of at least a component or piece of the hardware that works, in the case of an embedded computing or other combined hardware-software project, in order to allow the development or testing of the software that will work on that hardware component.
This is very different from the traditional "waterfall" project management approach, where the entire hardware system needs to be built first. While the "scrum" method for software projects is based on sprints with small portions of the software completed at a time, hardware development can benefit from a different approach.
With Agile, both hardware and software features are broken down into smaller chunks - only the Agile methodology can be a bit different for each. Once software is working, it can be deployed either on any available hardware modules that are ready, or in a test or simulation environment.
This allows the early identification and fixing of race issues and bugs that arise, and reduces the amount of “fixing” and lengthy hours reworking that must occur during late integration and testing when the hardware is ready.
And that’s the goal of successful agile development – to reduce the total time required, decreasing errors, mistakes and the chances of unforseen events, which will increase the time to market for your new or revised product.
Here at the LX Group you can leverage our product development expertise and experience for your total benefit. Our consultants, engineers and experts in many fields can guide you to your goal of product success.
To get started, join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.
LX is an award-winning electronics design company based in Sydney, Australia. LX services include full turnkey design, electronics, hardware, software and firmware design. LX specialises in embedded systems and wireless technologies design.
Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.
Thanks for the post about product development process. You should take part in a contest for one of the best blogs on the web. I will recommend this site!
ReplyDelete