The Secrets Behind Agile Hardware Engineering
If you haven’t — in the wise words of Arnie: do it now.
If you have, let’s get back to the topic at hand: applying agile software development techniques to hardware!
When taking a waterfall approach, most teams don’t have the opportunity to connect what they are building with fundamental customer needs, or to absorb and implement new information as part of the development process.
In comparison, by following an agile approach, teams can de-risk their engineering efforts, stay nimble, quickly react to new learnings, and build a product that matters to people.
Below are four steps that we take with our clients everyday, to help them apply an agile approach:
Step 1: Establish clear product priorities
If product priorities aren’t made clear upfront, debating features and their implementation eats precious time.
We often see this occur late in development, when the cost of changes are especially high.
To lessen the chance of this happening, we use a framework called Product Nucleus.
Product Nucleus helps you clarify a product’s feature priorities up front and makes sure that they are aligned with business objectives.
To create a Product Nucleus, you start by establishing the needs that your product should address.
Do this in order of importance. Clear prioritization is key—without it, there’s still way too much wiggle room. You’ll think your team is aligned, when in fact you’re not.
From there, describe the minimal set of features required to meet each need.
As an example, here’s a simplified version of the Product Nucleus from Adobe Ink, a pressure sensitive, cloud-enabled drawing stylus for Apple’s iPad:
User Need #1: Ability to Create Beautiful Lines on an iPad
- Feature 1: Capacitive stylus
- Feature 2: Palm rejection
- Feature 3: Pressure-sensitive
User Need #2: Designers are Proud to Use It
- Feature 4: Beautiful, fashionable industrial design
- Feature 5: Excellent feel in the hand
- Feature 6: Class-leading ease of use
User Need #3: Better UI Workflow Than Finger Alone
- Feature 7: Hardware inputs/interface element (single button, LED status light)
- Feature 8: Stylus-enabled UI elements (pen-tip menu)
Step 2: Focus the team on the top priority first
Okay, so this sounds obvious — but it will fundamentally change how you build your product.
You would be shocked at how few development teams focus on a single, well-defined set of features at a time. Instead, most teams will divvy work up so that a person or small team attempts to tackle one priority on their own, and then they integrate everything together at a later date.
This inevitably leads to pain and extends development schedules.
Instead, focusing on the most important priorities forces key learnings to surface as early as possible. The earlier the learning, the longer the team has to mitigate risks and make corrections as needed.
In addition, this allows the team to build together and build step-by-step.
This is key to shipping a great product, on time.
Once the first feature (or relatively small set of features) is complete, the team can move to the next one, adding a new feature layer. Integrating various features together becomes a non-issue, as the product is built step-by-step, and features are continuously integrated.
Finally, if it comes to crunch time and the team has only been able to complete four out of your eight top features, then they will at least be the most impactful ones.
Step 3: Build less, faster
Engineers usually structure development similarly for every development effort.
A ton of time is wasted by building things that aren’t important, so we ask ourselves one, simple question:
“What do we need to learn about the product?”
For example, in Adobe’s case, the top product priority was for the user to be able to create beautiful lines on an iPad. So our goal was to learn how we could achieve that, as quickly as possible.
So instead of sitting and creating a full development plan from the start, we immediately created a super rough prototype and touch stylus, together with a simple iPad app for testing.
We quickly learned that the smallest stylus pen point that would register on the iPad was far too large to create thin, accurate marks. That meant we would need to go beyond capacitive touch and reverse engineer aspects of the iPad, to create a thinner-pen point that would register on the iPad.
Learning this within the first few weeks made the difference between shipping a great product, and not shipping at all.
Step 4: Make frequent course corrections
Valuable learning occurs from day one on every product development effort, but most development processes discourage benefitting from it.
If you want to build a fantastic product, you need to actively seek these learnings as frequently as possible throughout development.
At Mindtribe, we set defined sprints, and then check-in with the entire product ownership team to make sure we are building according to the product priorities we all laid out together.
We’ll also check-in with appropriate voices every week and go over user feedback as often as possible. This helps the team keep validating that they’re on the right path.
So, to recap:
- Understand product priorities, and ensure your entire team agrees
- Focus the entire development team on a well defined set of the most important features
- Build as little as possible to more quickly understand development challenges
- Establish opportunities to frequently revisit your plan and quickly update it when needed
Doing all of this will increase the likelihood of shipping on time and building the product you envision for your customers.