Note: As a standard practice, I will include a plagiarism detection link in all the articles on my blog site. You can use the online tool below to evaluate any article published on the web for plagiarized content. All you have to do is to paste the url of the article there and it will go through every sentence in the article and flag any plagiarism. I believe as a follower of “writer’s integrity” I should include this tool in all my articles:
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 most of the resources are virtual and can be easily changed. Further-more, software is compiled or interpreted. What this means that you can apply changes and then test those changes almost immediately. Physical hard-ware design, on the other hand, takes longer and requires longer-term planning.
The Release Management challenge
Remember that in an Industry 4.0 setup, assets are highly distributed. This also makes it difficult to apply remote software updates, and tasks like 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 where applications are updated kind of continuously, which cannot be applied to most IoT solutions.
Longer planning and validation cycle requirements for physical a-ssets
Many IoT projects require close co-ordination between different divisions of highly siloed organizations. If you think from the context of enterprise environments, this means you need a long-term planning horizon. To add to that, many, if not most IoT solutions will have to undergo long validation phases, again requiring long-term planning perspective.
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.