DevOps

Development and Operations, from sales to service, are often quite separated and have different interests and culture to go with it. Where development is typically more risk taking and busy stirring things up, operations is more risk adverse and prefers to stabilize things. Also, operations is typically customer oriented rather than development, and processes are optimized for that. These processes are designed for the efficient production of large volumes and the longer lead times are accepted. And to make things worse, for the same efficiency driven mindset, development is often forced to use these same processes for small one-of urgent requests.

DevOps is aimed at improving the collaboration between Dev and Ops, and enabling rapid responsive development to its fullest. It is about culture, collaboration, and practices and tools. It is about Dev and Sales, Dev and Supply, Dev and Manufacturing, etc. A special relation is that of development and suppliers.

For rapid responsiveness, we need to change the system:

• Change culture – Development is important and different from operations. All should understand what it is they need and why: purpose, vision, strategy, objectives. They should be willing and able to support that: prepare to handle more risk, fit for purpose processes, remove impediments and constraints, less focus on efficiency and more on effectiveness, accept change and that it comes in small increments.
• Collaborate – A lot of waste in time and effort is caused by dependencies and hand-offs from working in silo’s. Dev and Ops need to collaborate closely and openly, and preferably be part of the same (virtual) team and co-located. This goes as well for external collaboration like with suppliers and co-developers, and of course also with our customers. As Stephen Covey points out: think in terms of win-win. A good practice for that is agile contracting.
• Guide & manage product flow – Dev and Ops should work together to optimize strategy, objectives, and priorities. They should work together to keep the flow going, for instance by keeping work in process low (pull work through and no pushing in), find ways to reduce batch size, and work with rapid responsive suppliers. Also, they should look for waste in the process, e.g. by using a value stream map. Mind however, operations often can’t handle a large volume of small incremental changes and need time to adapt to that.
• Automate build pipeline – We should automate as much as possible: for instance: the flow of information (like specs, instructions, product data management), automated machine instruction generation, production simulation and design verification, agile manufacturing, feature toggles, automated compliance checking, continuous integration and deployment, etc.
• Recover fast & easy – Dev should build trust to allow Ops to take more risks. This means reducing the chance of failure (failure rate) and in case things do go wrong, be able to recover fast and easy, and Dev drops everything to support Ops and fix the problem. For instance by delivering simple to swap modules that can easily be reverted. If that’s not possible, then deliver clear and simple instructions how to revert (which of course have been fully tested by Dev).
• Measure – There are huge amounts of interesting data in operations. How often do users use this feature? How often does the system run on full capacity? What is the fail rate of a certain parts? How much wear does a certain part have? What is the fail rate for updates? We can collect this data and derive valuable information from it and improve our design or future design choices.

Suppliers → Partners

Suppliers are vital to hardware development. Ranging from supplying standard parts (fasteners, motors, etc.), to custom made parts (sheet metal, CNC, etc.), and even to co-developing complex turn-key (sub)systems. Or, delivering services from a developer in a team (contractor), to complete Scrum teams.
For standard parts it’s all about fast and easy. Preferably you have the most commonly needed parts in storage yourself. If ordering is needed, then via a one-stop webshop with <24 hr delivery time. In this case it helps to have accounts with suppliers that support this and as speed matters most, any reasonable price would do. For suppliers of simple custom made parts (e.g. sheet metal, 3D printed, CNC), you need to have direct interaction with suppliers and preferably work from a simple sketch. This requires a type of contract and relationship that supports this. Again, speed is more important than what is costs to make and deliver the part. Cost price of the part when in production is something different and will be addressed as part of the iterative development (usually later, first see if it works).

When it comes to more complex (sub)assemblies and (sub)systems, a different type of relationship and contract is needed. In this case the increased complexity, investment and time will require a closer collaboration and win-win approach. In this case we should really refer to our suppliers as partners. We prefer those who are involved from proto to production and match well with the following objectives:

• Optimize economic value for all parties in both short- and long-term
• As new knowledge emerges, exploit options via adaptive responses to requirements
• Continuously provide visibility and objective evidence of solution fitness
• Provide a measured approach to investment that can vary over time and stop when sufficient value has been achieved (beneficial to customer, but also to supplier)
• Offer the supplier near-term confidence of funding and sufficient notice when funding winds down or stops (beneficial to supplier, but also to customer)
• Motivate all parties to build the best solution possible within agreed-to economic boundaries

For effective collaboration with suppliers, we need to address the following topics:

Have a solid foundation with a win-win agile contract based on the objectives mentioned above. Make sure the supplier is involved as early as possible, understands what’s expected and why, and agree to collaborate as partners. Agree to a shared definition of done and design from behavior driven by data and testing. Have a single source of truth which is preferably model based. Grow the product in small incremental and iterative steps for functionality and performance as well as production aspects. Apply cadence and synchronization to align, and guide and maintain flow. Use structured sessions to sync and align.

The frequency and intensity of collaboration with suppliers and way of working depend on aspects like size (part, sub-assy, subsystem, …), complexity, uncertainty, risks, dependencies (tight coupling, overall performance, etc.), etc. For components and sub-assy’s, the development team will be in the lead and in direct contact with a supplier. To maintain rapid and responsive, you will need cadence and syncing. In the image you see an example of this.

The development team meets on a fixed cadence with the supplier to align and collaborate. The sync meeting is like a mini-Scrum where you briefly review the results from actions planned in the previous sync, then check if the process and relationship are still ok, then look ahead what to do next. If needed some time can be reserved for working on the agreed actions. Keep the frequency high to keep the ‘package small’, feedback loops short, risks low, learn and adjust fast, and limit emails, phone calls, ad-hoc meetings. Keep the frequency stable and only adjust when circumstances change for a longer time, and do not skip syncs when ‘too busy’ or ‘nothing to discuss’, instead finish the sync early.

For larger developments of (sub)systems, the supplier might be a Scrum team or even team-of-teams. In this case, some form of scaled agile structure is needed to align and sync.

Another factor of influence is how capable and willing suppliers in your network are to work in an agile way. If willing but new to agile working, you could guide and support them. If however unwilling, you may need to consider how important this supplier is to your organization and if perhaps it is better to part and find a supplier with a better match. If there is no escaping this supplier then you have to find some practical (‘hybrid’) way of dealing with it. Try to make at least part of the scope variable (for instance bits that have more uncertainty, risk). Try to get some intermediate value based milestones that provide some objective inspect and adapt opportunity, preferably on working systems. Try to get representatives of the supplier to participate in your demo’s. Try to agree on sync meetings where the win-win is emphasized (show that it’s also in the supplier interest). The least you want is regular updates of progress and risks. Since the supplier may be less flexible, you may need to be more and anticipate and plan for this. What also helps is minimize dependencies, for instance by adapting the architecture or design.

When you don’t have a supplier yet, make sure that agile working is part of the search criteria. Also, whoever is sourcing for suppliers should understand agile, what kind of suppliers fit with that culture, how we want to collaborate, type of contracting, and that speed and agility are more trump lowest price.
Traditional contracts are more about distrust. We need to know exactly what we’re going to get, when, and how much it’s going to cost. Next, we need to monitor that everything is being delivered exactly as planned. We fight on both ends of the table as sometimes we are the supplier and sometimes the buyer. We gain the most if we think in terms win-win. A mindset of mutual benefit, satisfaction and collaboration. It requires integrity, an abundance mentality and maturity. Or put in other words: stay true to yourself, there’s enough for everyone, and have courage and compassion.