We don’t apply Agile ways to make the simple stuff. We use Agile because what we create is hard. By that, I mean those hardware manufacturers that seek to apply Agile ways of working are usually in complex manufacturing industries: automotive, semiconductors, medical tech. Embracing Agility in such industries is very advisable, and indeed many are attempting this in some way. But it does come with its own manual. Here’s a page from my book.
Hardware development comes down to highly skilled engineers, each gifted in their own highly specific niche. The various components to each product are often deeply inter-dependent, which combined with the dependency on physical brings in long lead items. Conventional project management answers these challenges with an impressive deal of governance, but Agile offers a different answer: put the authority where the knowledge is – with your team of engineers, that is.
Yet while there is a lot of logic in this idea, it does require that information starts to cascade downwards to these teams. Conventional management cascades information upwards: professionals tell their superiors how far they’ve progressed, so the latter can decide how to progress. Instead, your Agile engineering teams and their facilitators (Scrum Masters, mostly) must become aware of what’s happening around them, so they can work in sync.
Scrum Master vs Project management
It’s here that we see the difference between a project manager and a Scrum Master: someone who cascades information downwards to the team, rather than collecting it for local decision making and aggregation upwards along the chain. The difference is in setting teams up to plan work collectively, manage dependencies as teams of teams, and reducing project risk incrementally.
Enabling collective decisions
Is it the same information that cascades down as would cascade up in the conventional approach? Ideally, no. Rather than cascading conventional instructions, Agile organizations cascade challenges. Agile environments cascade down problems, sub-problems, knowledge gaps, conflicting configurations, and opportunities.
After an Agile Team learns how to work together, what to integrate, how to design, and what to test next, it is left to the collective to determine the work that needs doing to solve the problems, tackle the challenges, and leverage the opportunities.
How do you manage your hardware development processes? Do you consider yourself an Agile team? Join the LinkedIn Group and let me know: https://www.linkedin.com/groups/13656375/
Cascade challenges of Agile
As Agile teams work in short iterations to arrive at the right solution, the right approach, and the most valuable task to perform, a new challenge arises for leadership.
The common question I get after proposing an Agile way of working at a team that creates hardware products is; “How can I allow people to review my results from a Sprint if I don’t always have a physical piece of hardware to demonstrate?”.
A common misconception!
A common misconception of an iteration review (Sprint Demo, Sprint Review, System Demo, or some other feedback moment at the end of an iteration) is that we must always review ready-to-ship results. This might be possible for software teams, but it doesn’t apply for hardware teams – it cannot, for obvious reasons. Yet a hardware teams should nonetheless review results of the iteration: design choices, technological solutions and development intentions. It is crucial for a team to receive feedback on such results, to determine together what to do next.
Must all stakeholders always be present during such review moments? Most, often, not mandatorily. These reviews, as much as they are there to receive feedback from users, are also there to receive contextual input from other teams about mutual dependencies. With mechanical, electrical, chemical and mechatronic development teams, dependencies are naturally widespread. The decisions each makes during a sprint naturally impact the work of other teams. The reviews are there to maintain such awareness as much as they are there to harvest user or customer feedback.
Communicating information to fellow teams in this manner – ‘sideways’ if you will – allows for much faster progression than having to first communicate progress reports upwards, then translating these into specific technical instructions for to be communicated downwards into other teams again. Let the fellow teams think about how to solve a mutual dependency or problem and allow them the time to respond with options.
When you evaluate results and share progress iteratively, ask your fellow teams about the decisions made, rather than whether and when a thing will be ‘done’. Only then will you start to leverage the brilliance and creativity of all engineers and their niche knowledge pools combined. Sometimes an answers merely requires the re-definition of work instructions.
Want to learn more about Agile for Hardware? Join the introductory workshop on 7 February 2020 in Amsterdam!
About the author
Ali Hajou is a Senior Trainer and SPCT Candidate at Gladwell Academy.
Ali has carried out assignments in the pharmaceutical, financial, and public services industries, among others. In these projects Ali had the privilege to support, various development and management teams in finding and scaling their Agile Way of Working.
He has experienced the advantages of iterative product development that include the development of hardware and software components in the pharmaceutical industry, the semiconductor industry, and more. Ali helped them find their own Agile Way of Working, as ‘the standard practices’ do not always apply ‘right out-the-box’.
Learn more about Ali here.