People are at the heart of development. They are the ones to come up with creative solutions, make difficult decisions, continuously scout for risks and how to counter them, etc. Sometimes working by themselves, but mostly working in an agile team where 1+1>2 but not always so easy for the different specialists and challenges like lead times.
And of course the team is not in isolation, it’s an integrated part of an organization with all kinds of stakeholders like customers, the business, operations, suppliers. For hardware there is usually a lot of interaction required between development and operations (also know as DevOps), and suppliers. For details see the article on DevOps and Suppliers.
Trying to build a complex physical system in a complex adaptive organization is challenging. To make this work, we need strong leadership with the right competences (knowledge, insights, skills, attitude/mindset).
Whatever you try to develop and build, there will be some rules to adhere to. Sometimes, they are valuable lessons learned collected in for instance design guides, sometimes more strict rules like company regulations and procedures. Sometimes from the outside world like machinery directive or medical device compliance. There are several good practices to deal with compliance in agile hardware development. For more information see the article on compliance.
Organize around value
The core job of the organization is to bring value to job executors (a.k.a. users) so they can get their job done better. To maximize effective and efficient value delivery, and being rapid and responsive while doing so, we need to put the user, and their job-to-be-done, in the center. Knowing with the user, their job-to-be-done (JTBD) and the desired outcome (a.k.a. needs) that come with it, is key to building the right thing, so start your organization there in what is known as opportunity space.
The solution we develop to get the job done better, typically depends on other solutions forming the so-called value network (consisting of various value chains). Solutions vary from hardware, software, energy, activity, etc. and take form of systems, sub-systems, components, platforms, etc. By mapping the value network, we can now determine how to organize around it in a way that maximizes focus, autonomy, alignment, etc. and minimizes dependencies, hand-offs, delays, etc.
A very powerful tool to use for this, is called Wardley mapping (to it’s creator, Simon Wardley). It’s a tool for strategizing and provides some powerful insights. The Wardley map starts with mapping the user (including JTBD and needs) and the value network supporting it as shown in the figure above.
Next, we add the evolution stages (Genesis, custom build, product, commodity) which allow us to show movement. The figure below is copied from Simon Wardley’s twitter and shows many interesting details like team culture (pioneers, settlers, town planners). method to use (agile, lean, six sigma), etc. One typically plots the current and some future state in it to allow strategizing, For more details on Wardley mapping, please check out this site: https://learnwardleymapping.com/landscape/.
If you like to know more about Wardley mapping in combination with (strategic) Domain Driven Design, Conway’s law, and team topologies, check out the webinar below from Susanne Kaiser.
Product Development as a Service
Many people nowadays are familiar with the “as a Service” business model where infra (IaaS), platform (Paas), or even software (Saas) are running remotely and, as the name suggests, are offered as a service to customers (users). This has huge advantages like agility, scalability and cost savings. Nowadays you see more variant of this model, using the umbrella term Xaas (Anything as a Service), for example vehicles as a service, warehouse as a service, etc.
In this same line of thinking, you could consider having Product Development as a Service (PDaaS). Instead of adding a development team of your own which means stealing people from ongoing developments which results in conflicts, or employing new people, onboarding them, finding them office space, providing them with all the necessary tools, scale up your HR, and more, you could also hire this as a service. On the surface very similar to outsourcing but really not the same at all. Where outsourcing is typically project-based usually with an hourly, performance-based or profit-sharing model and tightly scoped contract, PDaaS typically involves a long term partnership model usually with a monthly subscription and an agile form of contracting. Both types have their uses and suitability depends on the situation.
To remain competitive, the service provider has to offer a high quality service at low cost. This will drive them to invest in effective and efficient ways of working including lots of automation. For the service user, the biggest benefits are: scalability, agility, speed / time to market, cost savings, transparency on costs, and access to specialist capabilities. Since it involves a long-term partnership, it usually also means that service provider has a good understanding of their customers domain. For the service provider, the benefits from outsourcing to DaaS are: long term contract / revenue stream, competing on service fees by automation and smart working instead of competing for hourly rates, flexibility in how to organize work / people.