All posts tagged: agile

Even though the design and development of electronic systems, and firmware in embedded systems, differs from conventional software application development in many ways – there is an increasing awareness in the hardware and embedded engineering fields today about Agile development methods.

The accelerating rate of technological change for electronic products requires rapid market responsiveness to maintain a competitive edge, and this is especially true in today’s world of ubiquitous mobile connected devices and Internet-of-Things technologies.

In one recent survey, 76% of software developers today see electronic hardware as a key element in turning many software ideas into products ready for market. This highlights a need for product innovators – growth of new markets like the Internet of Things demand practical tools to make physical design more efficient without sacrificing product quality, and Agile methods are one of the tools that can potentially play a role here.

Hardware is different from software, so rather than attempt to transfer Agile practices directly to hardware development, some careful consideration about what the differences are, what is really relevant and what is not most relevant, will allow the most effective adoption of Agile management techniques in the electronic design and embedded systems industry.

Agile project management methods can be used effectively in a hardware environment, by mechanical or electronic development teams, but some adaptations might be needed on a case-specific basis. However, this is already the best practice recommended in an Agile environment for software development teams.

Many large companies use Agile techniques in their development today, including Yahoo, Microsoft, Google and many others. The WikiSpeed startup employs heavy use of Agile management techniques in their mechanical engineering projects, delivering a novel car built from composite materials that offers extremely high fuel efficiency while also being safe and road-legal – designed and built from scratch in only 3 months using crowd funding, made viable thanks to the cost-effectiveness of their Agile practices.

However, some companies prefer the perceived stability and predictability of a traditional development process. Traditional use of comprehensive documentation and contracts is viewed as protecting them from risk and having one team follow the work of another.

There are also special hurdles when you’re combining hardware and software in one product, and most Agile experts, even with extensive software project experience, are not yet used to working with these issues. Some common challenges and concerns that are raised against the use of Agile methods are that more revisions and versions mean more data to manage, and that changing procedures and tools means added costs. There is the view that fewer contracts and specifications could mean higher risk, and that effective, useful communication and coordination is more complicated in an Agile environment.

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 chunks with more rapid iteration. Hardware, on the other hand, may require many months to show a working component or feature.

If the software must wait for the hardware to be created for final testing, this can create testing delays. Use of rapid prototyping technologies such as 3D printing can be valuable here for mechanical and plastics design, as can the use of modular electronic design, with smaller subsystems that can be iterated more rapidly, demonstrated, and tested independently of the whole system.

Writing user stories that span hardware and software allows for the interdependencies to be understood. There might be some software that the hardware team needs to test their first prototype; the teams can ensure that the required stories are correctly prioritised to support this. Similarly there may be software that is most efficiently developed once hardware is available (perhaps low-level interface drivers); these can be prioritised based on the hardware delivery schedules.

Because hardware often isn’t available until near the end of a project for actual deployment and testing, virtual versions of the hardware such as mock-ups, simulations and emulations are often an important part of hardware development using Agile techniques.

Modelling and simulation allow testing and integration to begin as soon as the design work begins, which eliminates the delays that might be experienced if the hardware isn’t yet available. It can save significant investment in unnecessary early prototyping of architectures that aren’t viable.

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. The challenge is to find a method that allows the rapid development of software and concurrent development of the hardware in a way that can best meet the requirements of each process.

Hardware abstraction layers enable concurrent hardware and software engineering by allowing software development and testing to start prior to hardware availability. This valuable practice can also provide input into the hardware requirements and help most efficiently refine the boundary between hardware and software.

Therein lies the challenge of embedded hardware design using Agile methodologies – software and hardware teams need to be challenged to work together for the desired outcome in the available amount of time. And as a leading developer of embedded hardware, products and services from design through to product manufacturing and support – here at the LX Group we have the team, experience and technology to bring your ideas to life.

Getting started is easy – 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.

When an organisation or team decides to adopt Agile methodology for their projects, not “staying agile” can potentially lead to problems. Although Agile itself is very broadly defined in the general principles of the Agile Manifesto, and there are many different ways to implement these principles, “staying agile when using agile” is important and straying too far from the underlying principles can potentially lead to pitfalls.

So, how can we keep Agile development agile and avoid common pitfalls when adopting Agile project management techniques?

One of the important things to know about Agile methods is that if they are limited to one development team churning out code, the outcome won’t be truly Agile. It takes a whole organisation to truly be agile, with agile methods supported by management and other staff within your organisation – not just one team without any support for agile in the organisation.

There are several other key success strategies for organisations when adopting Agile methods, such as looking beyond the application “construction” stage and considering the life-cycle context of the application. If organisations only change the way they construct software, without downstream or upstream business changes, this is unlikely to lead to the most effective outcomes with Agile.

It’s important to not be “Agile zombies”, with the inaccurate assumption that just attending a class or seminar about Agile methods and implementing some of the points learned leads to “being agile”. Every organisation is different and is constantly evolving. Continuous learning and improvement is at the core of Agile, and Agile isn’t a strictly defined “one size fits all” recipe.

The methodology itself isn’t a prescribed process or set of practices; it’s a philosophy that can be supported by practices, and no two agile approaches are exactly the same. No one single methodology exists that meets the needs of everyone.

It’s also important for organisations to decide if and where agile adoption is most beneficial for their business, to plan carefully for adoption, and to not adopt “Agile just because it’s Agile”. Organisations should ask questions such as why they want to be agile, what benefits it will provide, and how agility will be achieved and measured. Organisations should ask what cultural or other barriers exist to their adoption of Agile techniques and how they can be overcome.

Without a plan that clearly shapes the initiative, addresses and resolves constraints to agility (for example, removing waterfall process checkpoints or getting support from other required entities), it is more difficult to shape the Agile initiative, staff it, fund it, manage blockers and maintain support from executives.

It’s valuable to ensure that the entire organisation is included in Agile project management – including areas of the organisation that may be overlooked such as marketing or accounting staff. It’s faster and less painless, of course, just to launch an Agile initiative with one team, but this is not most effective.

A single team may gain some benefit from agile, but to be most successful you need to look at the whole process around solution delivery and the numerous people involved. Agile, ideally, should be a change in culture for the entire organisation.

It’s important to find supporters for Agile adoption not only among developers and IT teams, but across all parts of the business unit. In particular it is desirable to try and get somebody from senior management directly involved in Agile adoption, with as much support as you can find from executive management.

Effective agile adoption requires executive sponsorship at the highest level, because these are the people who control resources and can move them as needed to deliver results most efficiently.

Successful adoption of Agile means a shift in the way business views technology, and for most effective results we should recognise that developers don’t like change and many people like working in their own world. As with any cultural shift like this, coaching can be valuable.

Business users will need to learn to work differently with development teams as well. That’s why a coach – either a professional or a designated employee with strong communication and motivation skills – can be an effective part of a new agile team, to help everyone learn to work together most effectively.

Training is also important for success with Agile. Some organisations tend to skimp on training, but Agile is one area where it can be particularly valuable. Managers may only send a few key people to training, in the hopes that they can train the rest of the organisation to implement the new approach for free.

This is unlikely to yield the best results, since Agile is a game-changing initiative, and everyone across the organisation needs to understand it for best results. Continuous improvement is a key principle of Agile development, including continuous development of the team and their skills.

Once again we enjoy illustrating that Agile methodologies can be used effectively with embedded (and other) hardware development if all members of the team embrace the methodology. And that includes the engineering team here at the LX Group – who can bring your ideas to life.

Getting started is easy – 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.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Although the Scrum agile methodology was originally formalised for software development projects, as with other agile frameworks it can be applied well to any complex, innovative project that a team works on.

Scrum is a way for teams to work together to develop a product where product development occurs in small pieces, with each piece building upon previously created pieces. Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly what is needed using a most efficient manner.

Furthermore it’s a simple framework for effective team collaboration on complex projects that provide a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge.

So let’s have a look at how scrum methodology can be applied, and its potential benefits and challenges, when applied to embedded systems and hardware projects. Building complex products for customers is an inherently difficult task, even more so for projects that have a hardware component, and Scrum provides structure to allow teams to deal with that difficulty.

However, the fundamental Scrum process is quite simple and at its core it is governed by a few core roles on the project team. Product owners determine what needs to be built during a “sprint” interval of 1 to 4 weeks and the development team does the technical work to design and build what is needed during this interval, followed by demonstration of what they have built.

Based on this demonstration, the product owner determines what to build next. The Scrum master ensures this process happens as smoothly as possible and continually helps to improve the process.

A key principle of Scrum that differentiates it from traditional project management philosophies is its recognition that during a project the customers can change their minds about what they need or want, and that unpredictable challenges cannot be easily addressed in a traditional predictive or planned manner.

As such, scrum methodology adopts an empirical approach, accepting that the project cannot be perfectly understood or defined in advance and instead the team focuses on maximising its ability to deliver small iterations of progress quickly and to respond to changing or emerging requirements as the project proceeds.

As the team proceeds through the “backlog” of tasks during a scrum project, it is accepted that changes can and will happen – the team may learn about new market opportunities to take advantage of, competitor threats that may arise, or customer feedback may change the way the product is supposed to work.

When it comes to hardware projects, the time constraints involved in fabrication of printed circuit boards, the ordering of components, hardware assembly or other external manufacturing dependencies and the commitment to a particular hardware prototype design once it has been sent for manufacturing can potentially make it much more difficult to respond to new or changing customer specifications or requirements within the fixed timeframe of a given sprint.

If these kinds of factors in ordering or manufacturing hardware devices exceed the time allocated for a sprint, these manufacturing issues can present a unique challenge when trying to apply agile methods to hardware development.

The “sprint” is the basic unit of development effort in a Scrum project, a period of typically 1 to 4 weeks in which development occurs on a set of “backlog” items that the team has committed to, restricted to a specific time duration which is fixed in advance for each sprint.

Over the course of a sprint the project team has a physical, co-located, “stand-up” meeting every day to communicate between the team and assess its work, while the scrum master keeps the team focused on its goal along the way.

For hardware projects, increasingly popular and accessible tools and technologies such as small-scale CNC milling, 3D printing, and laser cutting are becoming more important for rapid prototyping and agile hardware development, allowing components such as custom plastics or simple PCBs to be rapidly prototyped, demonstrated to the product owner and evaluated within a sprint.

A prototype iteration of a hardware system doesn’t have to physically involve hardware. Simulation and visualisation tools, such as SPICE for electronic engineering, 3D rendering of mechanical components and PCB component dimensions, and thermal modelling for predicting heat transport with a device enclosure, for example, can all play an important role in assuring the quality, interoperability, industrial design, electrical and thermal performance and the “look and feel” of all the components that come together into a new product even before a prototype is actually physically constructed.

These tools and techniques can also be valuable to demonstrate hardware design and engineering progress relatively quickly, within the finite timeframe of a sprint, if the manufacturing of physical prototype hardware will take longer.

Once again this shows that agile can be used effectively with embedded (and other) hardware development if all members of the team embrace the methodology. And that includes the engineering team here at the LX Group – who can bring your ideas to life.

Getting started is easy – 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.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

The Agile Manifesto is based around twelve principles, guiding concepts which build upon the four core values of Agile and support project teams in implementing Agile management methods, helping to lead to better project outcomes, better engineering and better customer satisfaction.

Let’s review these twelve principles of Agile project management and the relevance that they have to project management, particularly in the context of embedded computing, electronic engineering and product design projects.

The first principle is that it is the highest priority of an Agile project team to satisfy the customer through early and continuous delivery of valuable technology – and this remains true whether the product is software or hardware, embedded firmware, or any type of industrial design or engineering product.

Valuable engineering that is delivered to the customer early and continuously may not be the final product, but it might consist of rapid design iterations, demonstrations of certain subsystems or modules, proof-of-concept engineering, or prototypes constructed for demonstration using rapid manufacturing and rapid prototyping techniques such as 3D printing or digital logic synthesis in an FPGA.

The second of the core principles of Agile project management is that changing requirements should be welcomed, even late in development. This means that the customer should not be expected to provide a complete and concrete specification of all project requirements at the start of the project and never change or add to it.

Change should be welcomed, and Agile processes harness change for the customer’s competitive advantage. This principle applies equally for embedded design and hardware projects as it does for the management of software projects, however obviously there can be challenges when incorporating new requirements from the customer into a hardware project late in development.

For example, it may be difficult to incorporate new or different requirements into an existing PCB design and layout, requiring increased time and cost to design and fabricate a new PCB. In some cases, depending on size and mechanical requirements, using multiple modules and interconnected boards within a hardware system can allow for easier changes or the addition of new functionality without “wasting” existing hardware and its embodied time and money if a new iteration is required.

The use of programmable logic devices or FPGAs, or microcontrollers with their functionality reconfigurable in firmware, can also be useful in this regard – although this may increase cost or power consumption compared to a hardware system with application-specific, fixed functionality.

The third of the core principles of Agile management is to deliver working technology frequently, over a timescale of a couple of weeks to a couple of months, with a preference towards keeping this timescale as short as possible.

Like the other principles we have discussed, this principle is also useful and applicable towards hardware projects. Although there may be insurmountable time constraints, such as lead time for components, PCB manufacturing or assembly, the rapid delivery of working iterations of hardware, even if it is just for a subsystem or a prototype that validates part of the overall system design, is a valuable goal and it is practical to achieve in most cases in a typical hardware project.

Another of the twelve principles of Agile is that working engineering that can be demonstrated, even if it is just a subsystem, a component, an experiment or prototype and not the “final” deliverable product, is the primary measure of project progress. Other metrics that might be applied to gauge project progress are of secondary value compared to the actual technology created.

Further core principles of Agile are that business people and customer representatives should work together intimately with developers and engineers throughout the project, with close contact and communication between them during project development, preferably every day, and that project teams should be built around motivated individuals on the development or engineering teams who are given the support and environment that they need to get the job done, as well as given the trust that they will get the job done without micromanagement.

Among the other core principles of Agile project management are the principles that the most efficient and effective method of conveying information to and within a development team is face-to-face conversation, and the belief that Agile processes promote sustainable development and a sustainable use of the human resources of the team, where the sponsors, developers, engineers and users making up a project team should be able to maintain a constant pace of work indefinitely.

The remaining principles are that continuous attention to technical excellence, good engineering and good design enhances agility, that simplicity and the art of maximising the amount of work that does not need to be done is essential, and that the best architectures, requirements and designs emerge from self-organising teams.

Finally, one of the core principles of Agile management is that it values regular adaptation to changing circumstances. Ideally, an agile team reflects on how to become more effective and then tunes and adjusts its behaviour accordingly at regular intervals.

These Agile principles also retain their advantages and their potential usefulness irrespective of the technical nature of the particular project that you’re managing – there is no real difference between a software project or a project working with electronic hardware or any other kind of engineering or non-engineering project when it comes to understanding the potential benefits of these Agile values.

With some thought and buy-in by all members of your team, you can use Agile methods on a wide variety of projects. And if you’re looking for a partner in yoru project development, here at the LX Group we have the team, knowledge and experience to bring your ideas to life.

Getting started is easy – 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.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Agile project management methods aren’t new, however they can still be considered somewhat foreign to most teams developing hardware or combined embedded hardware and software products.

There are a number of both advantages and potential disadvantages that are worth considering when it comes to the role of Agile management methods in hardware projects that should be considered in the decision-making process of switching from a traditional waterfall project management method to an Agile approach for the management of your projects.

Imagine a team that focuses on how their work will be used by the customer, and who quickly incorporates feedback from other teams and test users to build something that gets better and better in noticeable and usable incremental chunks of productivity. They may work without the usual documentation and strict procedures because communication is fast and usually face-to-face, with the results being what is important.

These are some of the typical advantages associated with Agile project management techniques, along with improvements in efficiency and team productivity that come from co-location of teams, pair programming (and more generally, “pair engineering” in the context of a non-software project), regular stand-up meetings and similar interpersonal communication techniques within your project team that are an important part of many Agile methods.

Some of the other key advantages that are typically ascribed to Agile project management techniques include the reduction of traditional, formal written documentation because of the sense that reducing the requirement for this type of documentation allows creativity to increase, a reduction in the time that is typically consumed doing blind research, and the relatively rapid delivery of new iterations of hardware or software prototypes which allow improvements to be demonstrated more rapidly, broken up into smaller chunks.

Another advantage of Agile methods is that multiple cycles of iterative development, testing and feedback speed up the evolution of a quality product, as well as allowing relatively rapid education of new members of the development team, allowing skills and experience with particular tools, client industries or user stories to be learned rapidly where prior experience may be lacking.

Despite many apparently compelling advantages of Agile methods, however, some development teams and companies prefer the perceived stability and predictability of a traditional development process and a “waterfall” project model.

They feel that the traditional approach of comprehensive documentation and specific up-front contract negotiation protects them from risk and allows one team to follow the work of another in a consistent and reproducible way. When your product involves a combination of hardware and software – as is often the case in today’s world of embedded systems and connected Internet-of-Things devices, this involves special hurdles and some people feel that agile methods are not well suited, or insufficiently well developed, to handle this area well and that traditional engineering management strategies are the best when you’re working with this type of technology.

Some possible disadvantages that you may encounter when trying to incorporate agile methods into your product development include an increase in the amount of data that you need to manage, in order to keep track of rapid revisions and many different versions of prototype hardware and software, and the increased complexity of your communication and coordination within your team and between the team and the customer as the project proceeds.

Some organisations may find that they have a hard time getting over the disadvantages of changing their processes and dealing with perceived increases in risk. There are real costs associated with your transition to new, different procedures and tools, and the perception that moving away from formal up-front contract and specification processes with your clients could expose you to increased risks can be, to some extent, correct.

Another one of the challenges facing agile management of projects with both hardware and software development components is that software can normally be developed relatively rapidly, and the software development process broken down into smaller chunks or iterations relatively easily.

On the other hand, it may require three to six months or more to develop an iteration of a hardware product and to demonstrate a working component or feature. Hardware is hard, as they say, and it is harder to break up the project into small components that can be worked on in small, short sprints with a working iteration of a product or component at the end. If the software must wait for the hardware to be created prior to final testing of the integrated system, this can add delays to your testing process.

Nevertheless, don’t let these put you off considering Agile for your project development. By working with experienced partners you can exceed your goals, and here at the LX Group we have the team, knowledge and experience to bring your ideas to life.

Getting started is easy – 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.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Agile project management practices, which can be applied to the management of hardware development or other engineering projects – and not just the software development projects for which these methods were mostly originally developed, have the potential to deliver increased customer satisfaction compared to traditional project management methods such as the “waterfall” technique.

These improvements in customer satisfaction that can be achieved by Agile projects come about because of a combination of many different advantages that Agile practices can offer, particularly in the ways that Agile project techniques involve and engage the customer, the customer’s feedback, ideas and expertise throughout the product development lifecycle.

These Agile project management practices can increase the satisfaction of your customers by keeping the customers involved and actively engaged through the development cycle of their new product, making the customer feel like they are a valuable, integral part of the project team – which, of course, they are.

This enables rapid and precise feedback between the customer (or customer representatives and advocates on the team such as the “Product Owner”, who often play an important role in Agile project teams) and the development team.

Furthermore this also gives the development team an intimate contextual understanding of the customer’s requirements, specifications and ideas by keeping the customer or customer champion embedded in close contact with the development team. Finally, customer satisfaction is increased thanks to your progress and with the product; these practices can help to make the product itself fundamentally better, too.

Whilst these kinds of Agile project methodologies can work at their best when an actual customer representative is available frequently for team meetings, to communicate product requirements and business needs, if a customer representative is not available then the Product Owner, a role filled by one member from the project management team, can perform this role effectively.

The “Product Owner”, who is a core part of many Agile project teams, is an expert on the customer’s needs and product requirements, and serves as an advocate for customer and business outcomes, constantly directing the team in a direction that is focused on customer results and customer centred value, rather than considerations such as what is technically easiest, or technically most elegant, which otherwise may be given greater emphasis by the engineering or development teams.

Agile project management practices can deliver improved customer satisfaction and customer-focused outcomes by keeping the product backlog updated regularly and prioritised, allowing the team to quickly and efficiently respond to urgent issues, to newly established product requirements, or other changes that need to be addressed, without wasting time with less organised project management or implementing new features or changes that are less urgent and less important to the customer and business outcomes. Agile practices can also deliver improvements in customer satisfaction and product outcomes by demonstrating working functionality to customers in every sprint review.

This rapid iteration of new prototypes and repeated demonstration of working software or hardware technology gives the customer and/or the Product Owner a very clear understanding of the project progress that is being made, inspires new ideas for features or changes either in the product itself or in the ways that the product may be used or marketed, and allows for rapid discussion of changes, improvements or design specifications that are desired between the customer and the project team.

Another way that Agile management practices can result in a project with relatively strong satisfaction for the customer is by delivering products to market quicker and more often with every release.

Finally, another factor that can allow Agile project management techniques to deliver greater customer satisfaction from your project is by possessing the potential for better results with self-funded or crowd funded projects; allowing the scope, scale or schedule of a project to rapidly be changed even in the middle of the project development cycle.

This means, for example, that Agile projects can adapt to be most compatible with a changing or insecure funding environment, a self-funded environment with very limited access to cash flow and resources, a crowd funding project that has delivered funding less than what has been hoped, or a crowd funding project that has turned out much more successful than anticipated, with plenty of upfront funding available, but with demands for manufacturing scale and product fulfilment that are much larger than originally anticipated.

These and other Agile hardware development techniques can be harnessed by any organisation. However if this is new to you, or it seems like a complex path – then consult the experienced team here at the LX Group.

We can partner with you – finding synergy with your ideas and our experience to create final products that exceed your expectations.

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.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

There are many different agile development methods and process frameworks, with Extreme Programming, Scrum, Kanban, and Dynamic Systems Development Method being some of the best known. Although there are many different agile process frameworks and methods, most are fundamentally similar in that they promote teamwork, collaboration and process adaptability throughout the whole life cycle of a development project.

The various agile methodologies share much of the same underlying philosophy as well as many of the same characteristics and practices. From an implementation standpoint, however, each has its own combination of practices and terminology. Most agile methods break tasks into small increments with minimal planning, without directly involving long-term planning.

At the end of teach iteration in the agile process, a working product is demonstrated to stakeholders. This minimises overall risk and allows the project to adapt to changes quickly. Iterations might not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.

Multiple iterations might be required to release a product or new features. No matter what development disciplines are required, each agile team contains a customer representative, for example the “Product Owner” in the Scrum method. This person is appointed by stakeholders to act on their behalf and makes a commitment to be available for developers to answer mid-iteration questions.

At the end of each iteration, stakeholders and the customer representative review the project’s progress and re-evaluate project priorities with a view to optimising the project’s return on investment and ensuring alignment with customer needs and business goals.

Extreme Programming, which has emerged as one of the most popular but sometimes controversial agile methodologies, is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every one to three weeks.

The original model of Extreme Programming (XP) is based on four simple values of simplicity, communication, feedback and courage, backed up by various supporting practices such as pair programming, test-driven development, continuous integration and collective code ownership.

In an XP project, the customer or customer advocate works very closely with the development team to define and prioritise granular units of functionality referred to as “user stories”. The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration-by-iteration basis.

Scrum is another popular agile project management framework; a lightweight framework with broad applicability for managing and controlling iterative and incremental projects of all kinds. Scrum has achieved increasing popularity in the agile software development community due to its simplicity, proven productivity, and ability to act as a wrapper for various engineering practices promoted by other agile methodologies.

Using the Scrum methodology, the product owner works closely with the team to identify and prioritise system functionality in form of a “product backlog”. The product backlog consists of features, bug fixes, non-functional requirements and anything else that needs to be done in order to successfully deliver a working software system.

With priorities driven by the product owner – cross-functional teams estimate and sign-up to deliver “potentially shippable increments” of software during successive “sprints” typically lasting 30 days. Once the product backlog for any given sprint is committed, no additional functionality can be added to the sprint except by the development team.

Kanban is another agile method used by organisations to manage the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.

It is based on the three basic principles of visualisation of the work to be done on a given day using large noticeboards, walls or “information radiators”, since seeing all the items in the context of each other can be very informative, limiting of the amount of work in progress at any given time, which helps to balance the flow-based approach so that teams don’t start too much work or commit too much work at once, and the enhancement of efficient workflow, where the next highest-priority task from the backlog is underway quickly once a previous task is completed.

The Dynamic Systems Delivery Method, or DSDM, is another important agile method, which grew out of the need to provide an industry standard project delivery framework for what used to be referred to as Rapid Application Development or RAD.

While RAD was very popular in the early 1990s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened with the goal of devising and promoting a common industry framework for rapid software delivery, and since then the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling agile process and iterative software development projects.

DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focussing on the useful 80% of the system that can be deployed in 20% of the time. Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritised into “must have”, “should have”, “could have” and “won’t have” categories.

All critical work must be completed in a DSDM project, but it is also important that not every requirement in a project or time-box is considered critical. Within each time-box, less critical items are included so that, if necessary, they can be removed to keep from impacting higher priority requirements on the schedule. The DSDM project framework is independent of, and can be implemented in conjunction with, other iterative agile methodologies such as Extreme Programming.

Agile hardware development may seem complex, or quite foreign – however the methods used can decrease the period of time from idea to final product launch – with the right partners. Here at the LX Group we can partner with you – finding synergy with your ideas and our experience to create final products that exceed your expectations.

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.

In the adoption of Agile project management practices to the development of hardware or combined hardware-software engineering projects, and the adaptations to common Agile techniques that may be applied for best results with hardware projects, let’s consider some of the challenges that may be faced and how you might address them.

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.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

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 attempting to apply Agile methods to electronic and hardware design, what methodologies and tools should we consider in order to rapidly prototype and demonstrate hardware systems?

What if the lead time that is required to source components, to fabricate PCBs, to have prototype layouts assembled by an external pick-and-place assembly contractor or to have custom plastics injection-moulded, and so on, is longer than the time allocated to an iteration? 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.

Increasingly popular and accessible tools and technologies such as small-scale CNC milling, 3D printing, and laser cutting are becoming more important in this field, allowing components such as custom plastics to be rapidly prototyped, rapidly demonstrated to the product owner, evaluated, and rapidly iterated, prior to committing to the high cost and high lead time of custom injection-moulding tooling and manufacturing.

In agile methodology, early user testing is important, with rapid feedback focussing the most important characteristics of a product and showing what is or isn’t relevant for customers. To shorten the time required to deliver a prototype iteration, rapid prototyping tools and technologies such as 3D printing are ideal, bringing rapid, small-scale and very agile manufacturing technologies right to the desktop.

Having intimate, agile communication between different team members with different skills – electronic engineers, mechanical engineers, industrial designers, UI designers, software developers, manufacturing experts – with regular meetings, standups and interaction is also good for efficiency and agility, allowing cross-pollination of different experience and ideas and providing confidence in the integration between different parts – between a plastic moulding and a printed circuit board, for example – preventing time-consuming problems with manufacturability later.

If you’re working on a hardware prototype in an agile environment and your external manufacturing of a new prototype board, for example, is going to take longer than the time allocated to an iteration but you need a prototype ready to demonstrate, what options are available to you?

Then it is time to ask if there is anything that you can do so that you can produce a prototype of some kind in an iteration, using the new tools and technologies of rapid prototyping – or even the older technologies of hand construction. Today there are services that can allow you to upload design files for a new 3D printed plastic part or CNC machined metal part and have it manufactured and shipped overnight so that it is ready to go the next morning. These services can be expensive – but so is the time of your team, and the agility that such rapid iteration provides could be more valuable.

A prototype iteration of a hardware system doesn’t have to physically involve hardware, either. Simulation and visualisation tools, such as SPICE for electronic engineering, 3D rendering of PCB component dimensions, 3D rendering of mechanical components, and thermodynamics models for predicting heat transport with a device enclosure, for example, can all play an important role in assuring the quality, interoperability, industrial design, electrical and thermal performance and the “look and feel” of all the components that come together into a new product – even before a prototype is actually physically constructed.

Nevertheless some of the most rapid of rapid prototyping strategies can fail, so is there a different way to somehow produce something at each iteration that can generate the discussion, answers and feedback you can use to drive decision-making within a single iteration?

What are the basic, smallest chunks of hardware functionality that you can deliver? Can you split the hardware prototype up into small modules, for optimum agility and the ability to deliver a prototype of at least one module during each iteration period?

Using standard off-the-shelf components and technology for rapid prototyping can play a valuable role here, along with breadboard-style construction, the use of manufacturer evaluation boards and reference-design boards from chipset and IC manufacturers, the use of general-purpose “building blocks” and “breakout boards” from component distributors, and general-purpose single-board computer and microcontroller modules, which are relatively low cost, flexible, and very easy to learn to use.

The use of Open Hardware and open-source intellectual property, for example for known working circuit designs that can be re-used without having to spend your time reinventing the wheel, is also potentially attractive here.

Today, almost all electronic products and designs incorporate some kind of software or firmware – for an embedded microcontroller, for Internet-connected cloud services or mobile apps or for PC connectivity, for example. This is especially true as we move further into the emerging Internet-of-Things era.

This means there is a relationship between electronic engineering and software engineering for almost all products, and agile methods can help to make this interaction most efficient. 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 most race-condition issues or bugs that may arise, and reduces the amount of “fixing” and time intensive reworking that otherwise might need to occur later into the integration process.

The goal is efficient, concurrent work with hardware developers creating hardware components, and software developers developing and testing software components, at first independently of the hardware development at times, and then testing on the actual hardware prototypes as they are developed. This requires effective collaboration between hardware engineers, industrial designers, software developers, and the product owners who provide the feedback.

No matter the level of expertise within your organisaiton – you may need help or guidance with any or all stages of product development. Here at the LX Group we have a wide range of experience in various development methodologies and can be your partner for 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 concept that may be new to the reader – Agile software development – is a family of software development methods based on iterative and incremental development, in which requirements and solutions evolve through collaboration between self-organising, cross-functional teams.

It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen tight iterations throughout the development cycle. Over the last 15 years or so, the principles, practices, methods and tools of the Agile movement have significantly changed the landscape of the modern software engineering and development industry.

Compared to traditional engineering project management approaches, agile development is mainly targeted at complex systems and projects with dynamic, non-deterministic and non-linear characteristics, where accurate estimates, stable plans and predictions are often hard to establish in early stages, and complex up-front designs and prototypes are not likely to be practical or economical.

These basic principles and precious software industry experience from years of successes and failures have helped shape Agile’s favour of adaptive, iterative and evolutionary development.

However, hardware developers and engineers tend to see software development as something of a foreign land, with strange people, languages, tools and processes. Agile development processes may seem odd or unusual, even though they are becoming more mainstream in software development. While software developers have largely accepted the merits of agile development in many project environments, there is little adoption of agile principles in hardware design and electronic engineering circles.

So, are there any potential benefits to the adoption of agile development methods in hardware engineering? Might the values and principles that guide agile software teams similarly guide hardware engineering teams, or are the differences between hardware and software development too great?

Since Agile practices are relatively unknown in the hardware industry, it can be difficult for the average hardware developer to offer an informed opinion on agile. Complicating matters is the fact that an accurate and tangible definition of agile can be difficult to pin down. Even in software circles where it has been used for years, agile can have different meanings, bring varying degrees of success and bring with it different baggage compared to the traditional methodologies of software development and project management.

Fortunately, hardware developers are usually in a position to develop a “fresh” consideration of agile practices and the benefits that they may have for their work, avoiding the opinions or misconceptions that others may have established about agile methods.

We can begin by considering the core high-level principles of the “manifesto” of agile development and the established practices that have contributed to the success of agile methods in the software development industry for many years.

The Agile Manifesto was conceived as a launchpad from which the developers who first formalised the concept of agile development processes could reverse and change course away from what they considered to be the “damage” that was being done to the software development industry by traditional project management techniques such as the waterfall development model.

The pioneers of agile believed that the top-down, process-centric, heavily formally documented and painfully deliberate style of project management that many organisations followed was proving less and less successful. The underlying premise of the traditional “waterfall” project model is that the design and engineering of some product can be defined in advance through the construction of a detailed project plan, and that development then becomes a largely mechanical process of staged execution according to the plan.

According to agile practitioners, however, a fundamental flaw in applying the waterfall model to the management of many real engineering projects is that the act of designing and constructing software or hardware cannot be completely, reliably defined in advance. Software development, they argue, is a creative process and due to its inherent uncertainty cannot be accurately planned entirely in advance.

Product vision, customer need, target market, target technology and team dynamics, among other things, can vary considerably and unpredictably during development. For a creative process like software development, therefore, it is agility and adaptability that drives success rates to a greater degree than the intense upfront planning that is characteristic of waterfall development.

But is hardware development a creative or defined process? Before jumping into an analysis of the applicability of agile methods in hardware development, it is important to first categorise hardware development as either a creative or a defined process. Presumably, hardware development viewed as a somewhat creative process would benefit through the application of agile development methods in the same way as creative software development.

If, on the other hand, one decides hardware development can truly be captured as a defined, mechanical process in an accurate and reliable project plan, then you might argue that the problems agile methods are designed to address do not exist.

Or if it is not honestly possible to build a detailed project plan that accurately captures a complete development cycle prior to product development, if detailed project plans do not remain completely stable over time, if it is not possible to build a concise set of project requirements that will satisfy customer and market requirements years into the future, or if target technologies and architectures are not going to remain stable, thoroughly understood and unlikely to change into the future, then it is clear that a strictly mathematical, rigid process of project management will not be completely effective, and the benefits of agile development methods are potentially quite applicable to your project’s success just like they are in the software industry.

Development, of hardware and software, is carried out by people complemented by process and tools, not the other way around. Agile proponents believe that businesses erroneously link success to efficiency brought by process and tools as opposed to the innovation and creativity brought by people and teams, and agile encourages organisations to see people and communication as the critical factors in building great teams and great technology, with process and tools being complimentary.

Emphasis on individuals and interactions over processes and tools, rapid delivery of working prototypes and iterations even if they are not perfectly polished and complete, active customer collaboration and responsiveness to change are some of the core values embodied in agile practices, with formal contract negotiation, strict plan-following, and comprehensive documentation in the traditional written sense being de-emphasised if these practices are not the most effective way to understand customer requirements and for the team to understand and support each other’s engineering and project progress.

However, some of these concepts may be new for hardware engineers, since traditional waterfall-model values such as tools, process definition, comprehensive documentation, the hammering out of requirements during initial contract negotiation, the avoidance of feature-creep and the avoidance of change to initially negotiated customer requirements, are traditionally preferred and relied upon in hardware development.

One key philosophy of agile development is that face-to-face conversation and co-location enable the best communication between engineers, developers and customers. and a common practice in agile development is the daily “stand-up” status meeting where team members briefly report to each other what they did the previous day, what they intend to do today, and what their roadblocks are. Whilst there are many specific agile development methods in practice, most consistently promote teamwork, collaboration and process adaptability throughout the project lifecycle.

Agile methods emphasise the creation of working technology, i.e.. a hardware or software prototype, or iteration that can be demonstrated, as rapidly as possible, then demonstrating it and incrementally adding features throughout development. Working technology gives the team, stakeholders and customers regular opportunities to objectively measure progress and offer feedback based on a working prototype product, even if all its functionality is not completely implemented in a form ready for product release, and presenting real technology is likely to be more useful and welcome in a client meeting than just a presentation of documents or slideshows.

Furthermore Agile also encourages regular customer collaboration as the only practical way to gain and maintain a clear understanding of customer value as it inevitably evolves over time. Products are designed to satisfy customer needs, so it is customers that are best equipped to lead development, and agile practices favour close, daily cooperation between business people, customer representatives and engineers.

For many, responsiveness to change is the core value of an agile team, since technical development is a creative process where it is impossible to predict, understand and plan with pinpoint accuracy over an extended period of time. Often, long-range planning becomes a futile attempt to gain confidence and control over the development process. Agile project managers argue that absolute confidence and complete control are impossible to achieve, and customer needs, requirements, team dynamics and project goals will change over time, making long-range plans obsolete. Agile teams pride themselves on successfully absorbing change by combining detailed short-term planning with long-range estimates.

Iterative development, where products are built and demonstrated over a number of regular intervals, is the primary means by which agile teams realise the value of working technology. Hardware demonstrated through simulation, virtual models, prototypes or emulation platforms can be used to demonstrate products, quantify progress and gather feedback.

hile iterative and test-driven development are potentially disruptive for hardware developers, the benefits of objectively viewing progress with tested, working technology are hard to ignore. This is especially true early in development when the value of documentation and untested engineering can be difficult to quantify. Iterative development and regular technology demonstrations are also an effective way to keep customers or customer advocates involved, thereby ensuring progress is indeed progress in the right direction to meet customer needs.

In a step further, some agile teams embed their customer within the actual development team so that they are available at all times for questions and clarifications. For some, embedding a customer within a hardware development team would undoubtedly be controversial. But regardless of the perceived problems, increased collaboration and transparency with the customer is a reliable way to secure trust and ongoing success in the vendor-customer partnership.

Hardware development in itself can be minefield for those without the experience and resources to get the job done on time to specifications and on budget. However by partnering with the LX Group we can work together to offer solutions to your problems.

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.