Agile technical practices outside IT

It has become common nowadays to adopt Agile and several Agile practices also outside IT and Software Development.

This is true, especially for Agile practices related to Teams collaboration, Customer collaboration as well as Product/Service development and delivery. Examples include practices such as visualising the work, the planning game, backlog prioritisation, products over projects, estimates or no-estimates, and so on.

On the other hand, Agile technical practices depend very much on what one is doing. Agile technical practices in IT and Software Development are different from those in the automotive sectors, semiconductors manufacturing, Finance or Legal services. And below is discussed why.

But first, business agility, organisational agility and team agility need technical agility achieved by Agile technical practices. All these business + organisational + team + technical agilities are all necessary together. Because without Agile technical practices and so technical agility they would be a table with three legs, unstable and very easily it would fall apart.

Each sector has its own Agile technical practices.

Agile Software Development has it, thank you Extreme Programming (XP).
Developing technical practices for other sectors is not trivial.
And new tools may be needed too to enable such new practices. To support the development of such new practices and tools, it is better to share the effort industry-wide instead of a closed commercial approach (see the open-source mindset and “The Cathedral and the Bazaar” essay).

There are three principles that underpin all Agile technical practices in every sector you may be working in. They can guide you while exploring and searching for new Agile technical practices for any non-IT sector. The purpose of all the Agile technical practices is to:

• Reduce the cost of change
  
• Increase the speed of learning
  
• Tame Irreversibility (makes it fast and cheap to reverse previous decisions and recover from mistakes)

These are a few useful learning, from the experience of the Agile community and XP, to put the previous 3 principles into practice, and can be applied for the development of new Agile technical practices in any sector:

• Strive to collect early and frequent feedback from the Customer
  to continuously validate that we are solving the right problem and that the solution works.
  Beware: If you don’t know already who is your (internal or external) customer, what problems they are trying to solve and why, and what service/product you are delivering to them to help them, stop and clarify this first.
  
• Strive to collect early and frequent feedback from the work artefacts produced
  to continuously test and improve the quality and correctness of the work being produced.
  
• Strive for continuous reflection and improvement of the practices employed
  to improve and evolve the practices and the way of working and to adapt them to the work at hand with curiosity, ingenuity, experimentation and courage. Be it collective and inclusive.

A few more practical tips valid in any sector (industrial, financial, legal, engineering, education, …):

1. Focus on a specific problem (not its generic or universal formulation)
   
2. Start with a local solution (avoid the global or scaling obsession)
   
3. Create a simple working solution first & evolve it (don’t create all-inclusive solutions to be tailored down)
   
4. Adopt a just-in-time just-good-enough approach (don’t strive for up-front perfection, getting it right the 1st time)
   
5. Focus on one thing at a time (no multi-tasking)
   
6. If something is hard, do it more often (don’t wait until the problem grows too big)

Other practical things that worked in several sectors outside IT, and so worth considering, are: Continuously Integrating (assemble, build, aggregate, produce), Shift-left Testing (start testing earlier in the process, ideally in parallel with development to spot and fix defects when it is cheaper and to avoid the recurrence of similar defects), Automate Testing (to reduce or eliminate the rework and avoid costly mistakes, for example, see the simulators employed for semiconductors or constructions), Small Releases (early, frequent, incremental), Versatile Automation (think about CAD/CAM or the multi-function programmable robots of the new assembly-line).

For multi-domain/multi-workstream products and services development (for example mechanical + electrical + chemical + legal + logistic + … ) consider also:

• Continuous Integration: define a modular structure for the product or service, to make it easy to integrate early and frequently any progress achieved independently in each domain/workstream; whenever possible (and that is much more often than people might think) bring all domains/workstreams together starting the work on a low-fi prototype that includes all the domains/workstreams;
  
• Continuous Compliance: have the regulator working onsite side-by-side from the beginning, identify together which changes allow an incremental compliance check and which trigger a complete re-verification of the compliance; create a product/service design modularisation that maximizes the former and minimises the latter;
  
• Adaptive Suppliers: adopt contracts that allow room for manoeuvre and flexibility, for example, time and material instead of fixed time and scope; partner with the suppliers and choose suppliers capable of technical agility in their domain so that they won’t hinder your agility.

See also:
– Agile Automation practices outside IT
– Scrum for Hardware, Paolo Sammicheli
– Fabbrica Agile, Claudio Saurin (in Italian, English translation coming soon)
– Agile at Tesla, Joe Justice

Thank you: to Paolo Sammicheli, Claudio Sauring, Joe Justice and Carlo Volpi for taking the time to discuss this topic with me, share their insights and experience with me, and give me valuable feedback.

Boost your Agile to a whole new level of mastery.

See how we can help.
You, your team, your organisation.

Virtual Mentoring Virtual Assessments