Five reasons why you need to tweak Agile methodology for Industry 4.0 projects

No “Best practice framework” should be cast in stone

Standardized Methodologies, just like Technology, are just enablers. They exist to deliver value, they are not the focal point. The output, value or solution generated by these methodologies are important.

But everytime a new methodology/tool is on horizon, the rush to embrace it is so intense that the methodology itself becomes more important than the goal. Agile is one such methodology. In my personal experience, I have seen companies become so passionate about adopting Agile approach, that the focus became -“How do we write stories for sprints that we can successfully deliver”.

The focus shifts to “how we can showcase that we successfuly embraced Agile approach”. The value from successfully solving the problem becomes secondary. This applies more to Industry 4.0, where, as per my perspective, the Agile methodology, as currently used, can not be used “As Is”. And force fitting may turn out to be disastrous.

My this article explains why Agile approaches need to be modified before leveraging them in Industry 4.0 projects. I will share a detailed “Modified Agile Frameowrk” for Industry 4.0 in a seperate article.

Five challenges with leveraging Agile methodology “As Is” for Industry 4.0 implementations

Scaling Agile to large, distributed project organisations

Remember that many basic Agile or similar methods like Scrum were initially not designed to support large, highly distributed projects which span multiple organizational silos. Then, over time, different “versions” of Agile emerged to address this problem, including Scaled Professional Scrum  (SPS), Large-Scale Scrum (LeSS), and Scaled Agile Framework (SAFe). It is difficult to say at this point exactly which of these frameworks will prevail- and none of these will fit “As Is” in an Agile project.

“Work Culture” differences

Industry 4.0 projects are unique in the aspect that there are both software and hardware implementations involved. Software development teams in most large organizations organizations have adopted Agile for a couple of years now, but the fact is that many IT hardware or asset engineering organizations are still used to working with sequential, long term planning based project management approaches. Imposing Agile methodology, “As Is” on them may lead to “clash of two worlds”.

Hardware is not “virtual”

Hardware plays a major role in Industry 4.0 projects and all resources required in hardware development are physical like:

  • Amount and type of memory needed
  • Number and type of interfaces
  • Amount of logic to perform tasks

This is very different from software development, where all resources such as memory allocation and so on—are virtual and can be easily changed. Further-more, software is compiled or interpreted. With today’s “build environments”, this means that changes to software can be applied and tested virtually immediately. Physical hard-ware design, on the other hand, takes longer and requires longer-term planning.

Finally,the virtual nature of software makes it so much easier to define self-contained increments that can be delivered and tested as the result of a sprint.

The Release Management challenge

The often highly distributed nature of assets, as well as the difficulty in applying remote software updates, (not to mention hardware updates) makes change and release management for IoT solutions extremely challenging.

It does not mean that that this makes Agile development impossible, but it certainly changes some basic assumptions of Agile software development process, especially compared to Internet-style applications which frequently apply a “Perpetual Beta” philosophy, which cannot be applied to most IoT solutions.

Longer planning and validation cycle requirements for physical a-ssets

Many IoT projects require alignment of different, often highly siloed organizations, such as the asset manufacturing and after-sales services organizations. Especially in enterprise environments, this often requires a long-term planning horizon. Furthermore, many, if not most IoT solutions will have to undergo long validation phases, again requiring long-term planning perspective.

Furthermore, in many industries, such as the healthcare industry, it is virtually impossible to apply changes to a validated environment without complete updated project, including a new validation.

Concluding note

I don’t think that any of these points should prevent an organization with a high level of experience in an Agile, multidisciplinary development to apply a full-scale Agile approach to IoT, but i also think it is important to be aware of these potentially challenging issues.

So then-what Agile should look like for IoT ?

Leveraging some of the established approaches for scaled Agile development like [Sp5l o:[SAFe], I think that a full-scale Agile approach to an IoT project organization can be developed. I will be sharing a customized Agile framework for Industry 4.0 projects in a seperate article .


Views my own.

#blacklivesmatter

 

 

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s