Agile and Scrum - you've heard the terms whispered around the office and seen 'Scrum Master' listed under acquaintances Linkedin profiles. 

But what does it all mean? What can you do with it? Why should we care? 

agile for hardware development

Agile methodologies aren't new, but have gained considerable popularity in the last few years. Companies and teams are having massive amounts of success with the collaborative, fast, effective planning, and the continuous improvement of products.

In this post, we've put together our 5 top processes for achieving Agile for hardware development success.

Brief Definitions and History

In short, Agile is historically a philosophy which emerged from a group of software development methods where collaboration between kickass teams brings much success.

Definition:

Relating to or denoting a method of project management, used especially for software development, that is characterised by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.

Scrum is the most popular Agile software development method - a management and control framework for developing complex products.

Scrum Definition:

A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

These methods have now progressed far from just software, and are currently disrupting just about every aspect of doing business; startups, marketing, operations etc. Pretty much everything is receiving the treatment. 

Want a more detailed history? Check out the Agile and Scrum wiki pages.

Agile for Hardware Development

Agile's original intention and ever-increasing popularity is with software development, but it is disrupting everything else. Does it also work for hardware development? 

The answer is slightly more involved than just 'yes.'

The truth of the matter is, a bespoke solution usually works a whole lot better than out-of-the-box Agile practicing. If teams don't understand the fundamentals of Agile it may be poorly practiced, and you may not get it right.

In our experience, it's far better to start with the fundamentals of Agile and then build a detailed bespoke process which better suits the problem.

Here are our 5 top processes:

1.   MVP (Minimal Viable Product)

Due to the cost of making changes to the product (especially hardware changes), there is often the pressure to cram as many features in as possible in an attempt to reduce costs and future proof the hardware.

minimum viable product MVP

While this may seem to be sensible and cost effective, don't do it! Downfalls include:

  • Delays in getting the product out
  • Increases in development and BOM costs (Bill of Materials - the cost of the materials and components to make a single unit)
  • Extra complexity that all these other features bring (which the customer may not care about)

Then there are the benefits that you are missing out on by not getting the product to market quicker, both in terms of generating revenue earlier and getting feedback from the market. 

Why try to second-guess what your market's future requirements will be? Odds are you may be wrong,  and delays in product release may mean you miss market changes, and therefore opportunities, altogether. More about this below.

It's often possible to introduce additional features via software updates, but this needs some forward planning to include the hardware to support those features.  Don't go overboard though!

Check out these highly recommended short videos by MVP masters Eric Ries and Steve Blank.

Top Tips: Focus on the Minimum Viable Product. Don't cram a bunch of features in in the first instance. Focus on getting the product to market and reducing what you are spending developing it.

2. Short Iterations (Thin Vertical Slices)

Don’t fall into the trap of trying to predict the future without real data to support it.  And don’t think that doing a whole lot more planning upfront is going to make it any more predictable. It won't.

hardware data

One of the key practices of Scrum for software is performing short iterations called 'Sprints', which take a fixed period of time, typically around 2 weeks. The idea is to have an operating piece of software at the end of the sprint that can be validated; the key benefit being to get feedback (data) sooner and more often.

Quote from hardware developers everywhere:

"Its not possible to produce an operating piece of hardware in 2 weeks!"

Luckily for everyone this isn't as much of a problem these days.

The timeframe for producing prototype mechanical parts has been dramatically reduced in time (and cost) with 3D printing. Even with electronics, there are fast-turn-around PCB manufacturers.

If you do some forward planning on components, the boards can be assembled quickly as well. In fact, one of the trade-off's when selecting components could be the availability and lead time of sourcing the components.

The other factor which makes short iterations possible is that you don’t have to design the whole product in one go.  You could start initially using development hardware based on the choice of microprocessor.  While it may not perform exactly as the custom board, it may still provide valuable info.  This could also give the software team hardware to test the software, again helping identify issues earlier on.

You could also focus on the parts of the design that have the most risk and develop a board specifically to validate the design for these parts.  While this may seem to be a waste as it is potentially a throw-away, the risk it can mitigate can save a whole lot of time and costs.  So don’t shy away from performing experiments in order mitigate risks or create knowledge.

Additionally, the output of a sprint doesn’t need to be a piece of hardware. It could be specifically design related - a portion of the hardware that a review can be performed on, or given to the manufacturer to get feedback on the design. Will it impact manufacturability? 

Top Tips: Focus on 'Sprints.' Get feedback early and often. Don't spend time worrying about building complex products in short periods of time - its achievable. 

3. Stories

Agile uses 'User Stories' as a powerful way for the development team to understand the requirements of the product from the perspective of a user.  The general format of a user story is 'As a <WHO>, I want to <WHAT>, so that I can <WHY?>.'

Firstly, don’t get hung up on the term 'User' in 'User Story' and the WHO.  Even for software development, it can be hard when the user is only indirectly related to a particular story.  In fact sometimes the WHO may be the developer or part of the system that depends on the requirement to be met, eg: a part of the circuit needs a certain characteristic power supplied to it to work effectively.  So we normally call then 'Stories' rather than 'User Stories.'

When it comes to the WHAT,  it’s important not to confuse this with the HOW – placing the focus on the WHAT ensures that there is a good understanding of what requirement needs fulfilling.  This ensures that the development team have a clear understanding of WHAT so they can then select HOW the requirement can best be met.

WHY?  WHY is probably the most important part of the story, even more than the WHAT.  It’s from understanding the WHY that you can enlighten the development team with the reason why they expect the product to work in a certain way.  In fact, this may mean that the WHAT part of the Story is not fulfilled because the team identifies an innovative alternative approach to address the WHY.

The last thing we'd like to suggest is defining the Definition of Done (I often use the term Acceptance Criteria, which is even clearer).

definition of done agile

However you frame it, these words are very powerful as they address the issue of things that are left unfinished, or in the case of Stories, Stories that are fulfilled to the degree required and cause users frustration.

Top Tips: Use 'Stories' to discover user requirements. Also, define what the Definition of Done means.

4. Agile Processes

In our experience hardware teams have benefitted from applying basic Agile processes which include:

  • A deliberate iteration routine
  • Three role
  • Visible task board & backlog

Check out Henrik Kniberg's short video on an introduction to Agile Product Ownership

Agile can be easy to learn but very difficult to master.  Here are a few tips for adopting Agile for hardware:  

  • Start a conversation with all the stakeholders in or around your development team
  • Get buy-in from the top or risk everything being overturned later on
  • Start simple and then build complexity in the process later as it becomes clearer which practices add value
  • Enlist a credible coaching organisation for advice on the best way to adopt Agile (this is where a 'Scrum Master' comes in - it's common wisdom in our industry that you could accelerate adoption by around 10 times by receiving help - contact us if you want advice on this).
scrum master

Top Tips: Practice Agile processes. Start the conversation, get upper-level buy-in, and get a coach if you can - remember, easy to learn but difficult to master.

5. Small Cross-Functional Teams

Arguably the biggest risk to product delivery is how well the overall solution integrates - will the end solution work as expected when everything (hardware and software) is brought together?  

I’ve worked in many companies developing products and I almost always see the hardware vs. software tension, either as friendly banter or as a full-on blame game when things turn to custard.  

Often integration can only be tested in the late stages of development (especially with 'Waterfall' development approaches) when very little can be done to correct any major design or analysis flaws. Single function teams, or people all from the same department, can seem all too seductive to management as it offers an illusion of efficiency. 

Part of the answer to integration risk however is having cross-functional teams and fast feedback loops. Cross-functional teams include people from different departments working cooperatively towards a common goal.

Focus on building small, cross-functional teams.

Focus on building small, cross-functional teams.

Cross-functional teams regularly demonstrating a working solution (with both hardware and software integrated) is a powerful way to:

a) Detect major issues earlier
b) Demonstrate more meaningful progress
c) Get to market faster

Top Tips: Single function teams are out, cross-functional teams are in.

Additional Extras

As mentioned above, teams perform Sprint Retrospectives to identify 'likes and changes' to the process.  Normally as the Scrum Master, you leave it to the team to identify the likes and changes, but as an experiment with a team I was working with recently, I decided to pose this question:

"Is all this detailed planning at the beginning of a sprint worth it, especially when dealing with hardware?" 

There was an uneasy silence for about 4-5 seconds, but it was one of the hardware guys who spoke up. 

He explained that from his standpoint, it was worth it, because at times there are key interactions identified between the hardware and software which need some focused effort in the sprint.  Otherwise these interactions may not be identified until much later on in the development process, once boards are built and the software is tested on the hardware. 

This could result in design changes that may require a new version of the hardware, adding both time delays and cost to the project.  The other benefit is that it creates a focus on the product as a whole rather than the software vs. hardware discussions.


Recap of Top Tips:

1. Focus on the Minimum Viable Product. Don't cram a bunch of features in in the first instance. Focus on getting the product to market and reducing what you are spending developing it.

2. Focus on 'Sprints.' Get feedback early and often. Don't spend time worrying about building complex products in short periods of time - its achievable. 

3. Use 'Stories' to discover user requirements. Also, define what done means.

4. Practice Agile processes. Start the conversation, get upper-level buy-in, and get a coach if you can - remember, easy to learn but difficult to master.5. Single function teams are out, cross-functional teams are in.

Thanks for reading!