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.
