From industry to Agile

The posts of @Martijn van de Haterd and @Pieter Withaar, gave us an insight how they, with their broad agile knowledge and experience, were ‘dragged’ into #agileIndustry. Well Martijn and Pieter, you’re more than welcome!

The other way around

Where Martijn worked in Agile first and was introduced to Industry later, my story is somehow the other way around…. I 'grew up' around Industry and was introduced to Agile later on.

"my story is somehow the other way around…."

About 30 years ago after finishing my studies in Mechanical and Automotive Engineering. I started working on production processes and cost calculations and got involved in metal constructions, bending, punching, laser cutting, surface treatments, plastics, and more.

At that time there where not that many computers, not even in the offices of the factories I worked. But somehow I was attracted to two things: “quality” and “anything with a keyboard attached”. Almost 25 years ago I decided to make a career switch and went into IT and started as a tester: combining quality and IT.

It was about 15 years and many IT projects later where I was assigned to a (test) project in the ‘embedded world’. In the development of a medical DNA analysis system, IT, mechanics, plastics and electronics hardware strongly came together. And on top of that: in a regulated environment, the medical industry.

Industry

Typical for such environments is that for example software development AND production of printed circuit boards (PCB’s) and mechanics are not as flexible as developing and deploying software. I’ve seen examples of software changes that require certain behavior of the PCB where the actual PCB wasn’t able to do so and needed change. Although the change wasn’t that big, requesting and fabricating new PCB’s minimally costed 3 weeks excluding shipping.

With plastics it is even worse. Plastic parts are made using an injection molding process. This requires a mold in which the part is casted in an expensive machine and complex process. Making such a mold can be very expensive in terms of material, but even more the manufacturing time on lathes and/or milling machines. Fabricating such molds is done by specialized companies who do that for multiple clients. So if you want to change such a mold, as a result you are assigned to the next production timeslot, in 12 (!) weeks. And the bad news is: if the mold is milled and the change requires material that has been irreversibly removed by the milling, you are at #1. A new full mold has to be made.

What about 3D-printing then? That is modern and flexible!

Well yes, partly true. Re-design may be done quickly but printing also costs quite some time, and the quality (finish and strength) is far from molded parts. Good for an internal prototype or demo, but not for products that should go to the user and should last for a longer time. Something similar is applicable for PCB’s with multiple layers, shielding etc..

Back to the software industry

Well, let us now go back to agile (software) development in such integrated areas:

In many cases the software and (let’s call it) hardware development work in parallel and not in a ‘real’ agile collaboration. Simply because they are different disciplines with different activities, skills tools and with different heartbeats. My observation is that the people with the different disciplines of course do work together, but are seldomly fulltime working in the same team, let alone that they are closely located and can help with discipline specific knowledge related tasks. Hmmm, what about T-shaped? Maybe I should do a deeper dive in a later post how “T” one can be.

From the software perspective you might think that those hardware engineers are not flexible, but maybe you should ask yourself the question:

What do I know of the other discipline?

From the hardware perspective you could think that those software engineers are too flexible. Fixing and flashing a new software version may, in their eyes, take some minutes but re-fabricating a € 25.000 mold via subcontractors requiring weeks of planning and producing isn’t done in a few minutes. Similar to an example I used in an earlier artcile on requirements engineering where I referred to the Lethbridge Viaduct in Alberta Canada. In a complex (mechnical) construction that has worked since 1909, you don't just make a bend.

(Picture: Patrick Duisters, location: Lethbridge Canada)

We should also consider that the mechanical engineering industry is probably even a more mature industry than the software industry. Steam trains (as an example of the industrial revolution) date back from the 1800’s. Software just from the late 1900’s. Principles like Lean and Kanban are hip for software development, but they originate from the 1960’s by Toyota. Most likely I (or we, from our #agileIndustry expertise group) will come back on that in a later post to see what we can learn from such topics.

Regulations

And there is another aspect, typical for regulated environments like medical and automotive: submission and approval! In the mentioned industries you need product certification or market approval by a regulatory body. This sets requirements for the product as well as for the development process, before you are even allowed to sell or use your product on the market.

Working agile in this area is for sure possible but it will have effect on the agility. For now I will not go into too detail on this topic now.

Against agile?

You may think: is he against agile? Well absolutely not!

I see a lot of advantages of agile development, even in environments where hardware and software meet. But we must realize that software in many industries and products is or cannot be developed in isolation and our agile ideas requires some adjustments.

My humble opinion is that we should learn from (or at least recognize) other disciplines knowhow and experiences. And we should understand the differences in processes, techniques and heartbeats.

Part of my mission is to create this shared understanding…

..and explore together how the disciplines can work together and see what CAN be done and what benefits an agile way of working can bring!

And this is where the strength of synergy comes in…

Within Improve Quality Services and ICT Group the knowledge and experience of multiple disciplines join to team up in a #agileIndustry expertise group. We will discuss and share our observations and experiences from software-only environments, products with software in it, and software for production systems (industrial automation). More than enough topics to talk (and write) about! Who is next?

This article is an article in the series about the versatile field of Agile in the Industry in which, on a regular basis, a colleague from Improve Quality Services and ICT Netherlands will take the reader into the issues that the Agile development in the Industry faces today.

Articles and comments can be referred to by using #IndustryAgile or #AgileIndustrie (for Dutch posts).

Until now have been published:

1.    Embedded Agile, how my Agile principles got tested (Martijn van de Haterd, March 1, 2021)

2.   Agile does !not work for industry (Pieter Withaar, March 24, 2021)